Image

[Comandeer]

The first multimedia issue here ;)

Today images are as important as text itself (or even more important in some cases), therefore we should implement that feature in the most semantic way possible.

The necessary starting point is img HTML element with:

• [src] attribute that points to image,
• [alt] attribute that provides appropriate textual alternative.

But there is also a matter of responsive images. Really good WYSIWYM/WYSIWYG content editor should be prepared to handle such cases. It can be handled by:

• [srcset] attribute on img element
• picture element.

I think that including support for responsive images should be one of fundamental "features" of that Feature.

[Comandeer]

I've created 1. version of draft for that feature. Feel free to comment on it.

[fredck]

I was wondering if we should ever go with <img> alone. Do we really have to support inline images, in the scope of the recommendation?

My question doesn't take into consideration things like emoticons which may technically require inline images but are not part of the "Image" feature.

[Comandeer]

I was also thinking about it and there is even a trace of it in draft:

Additional semantic value for images MAY be provided by using figure and figcaption elements.

However not all images could be marked as figure (e.g. some decoratve image) – img is safer. On the other hand, it feels a little bit "naked" without any wrapping.

[fredck]

However not all images could be marked as figure (e.g. some decoratve image)

That's the point of the recommendation. I don't think we're here to propose the adoption of "decorative" images. The whole scope of the project is driving developers to have editor installations for the creation of quality content.

[Comandeer]

Ok, that example was unfortunate, but besides that figure is really specific element. As the HTML5 specification states it's intended to mark up object that is

self-contained (like a complete sentence) and is typically referenced as a single unit from the main flow of the document

There is also nice example of image that is a part of content, but can't be treated as figure, because it is the part of sentence:

<p>This case centered on some sort of "intellectual property"
infringement related to a comic (see Exhibit A). The suit started
after a trailer ending with these words:

<blockquote>
 <img src="promblem-packed-action.png" alt="ROUGH COPY! Promblem-Packed Action!">
</blockquote>

So even in quality content there can be place for inline images (but I must admit that this use case is much rarer).

On the other hand, figure is intended to mark up semantic content that is independent from the main page's content, so it's not limited to images – it can contains videos, audio, tables, diagrams, even some other text (e.g. quotes with caption that are later referenced from text). It could be really good candidate for marking "Widget" ("Semantic Attachments") feature. Maybe we can define "Image" as a subfeature of "Widget".

[fredck]

@Comandeer: Strange example... if I'm not wrong, <blockquote> cannot be inside <p>.... additionally, it doesn't seem to be part of a sentence at all. The first paragraph is infact "making a reference" to the quote ("these words" is actually referencing to the words that follow... it could in fact be replaced by the actual words).

When it comes to the "Widget" thing... it makes sense (unsure about the name). After all <figure> applies to several different cases, so we could think about generalizing it. Maybe a ticket where we could list the appropriate (and non appropriate) cases would be useful.

[Comandeer]

Strange example...

Taken directly from HTML5 spec ;)

if I'm not wrong, <blockquote> cannot be inside <p>

No, you're not wrong, but you miss very important quirk:

A p element's end tag may be omitted if the p element is immediately followed by an address, article, aside, blockquote, div, dl, fieldset, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, nav, ol, p, pre, section, table, or ul, element, or if there is no more content in the parent element and the parent element is not an a element.

So technically speaking, it's p element followed by blockquote element.

additionally, it doesn't seem to be part of a sentence at all.

IMO it is, as the end of sentence is denoted by dot. In this example we have colon informing that the next part of the sentence is some kind of enumeration or pointing explicitly to something.

"these words" is actually referencing to the words that follow

And that's the point why figure can't be used here. figure, according to the specification, should be applied only to elements that can be moved inside the document (or even detached from it). If we move such quote into the other place, the sentence would become senseless.

If a figure element is referenced by its relative position, e.g. "in the photograph above" or "as the next figure shows", then moving the figure would disrupt the page's meaning. Authors are encouraged to consider using labels to refer to figures, rather than using such relative references, so that the page can easily be restyled without affecting the page's meaning.

[Comandeer]

Ok, I think that we could drop the ability to insert inline images and stick to the much stricter version of the draft, which allows only figure based images (as inline images are mostly decorative ones). I've already updated it.

[fredck]

I agree. If Inline Images would be necessary, we could (and should) see them as a different feature, with different scope, semantics and implementation details. I don't see them as necessary though.

[Reinmar]

I totally agree about inline images being a totally different feature. We've been analysing this for CKEditor 5 in context of the awful issues we had with images in CKEditor 4 where image can change its type from block to inline and back. We agreed that inline images are unnecessary unless you want something like smileys, inline equations, etc, but these are all separate features. Only sometimes you want to have a real inline image but this can be an opt-in feature of an editor.

[Reinmar]

However, one thing worries me in the spec – the <figure> must have a <figcaption> inside. The editor recommendation says that the image must be inside <figure>. But what if the user doesn't want to caption it?

[Comandeer]

I think you're wrong. From the spec (bolds mine):

The figure element represents some flow content, optionally with a caption [...] The first figcaption element child of the element, if any, represents the caption of the figure element's contents. If there is no child figcaption element, then there is no caption.

[Reinmar]

So this is outdated: https://www.w3.org/TR/html-markup/figure.html?

Permitted contents One figcaption element, followed by flow content or flow content followed by an optional figcaption element

[Comandeer]

But it says the same as the spec - you have even quoted that!

flow content followed by an optional figcaption element

[Reinmar]

Errr... sorry :P.

[Comandeer]

I'm thinking of one more addition to the draft…

Probably we will use figure also in other features (quotes, tables etc.) and it could be useful to differentiate that use cases. For some elements (b, i), the HTML5 spec recommends de facto microformats:

As with the i element, authors can use the class attribute on the b element to identify why the element is being used, so that if the style of a particular use is to be changed at a later date, the author doesn't have to go through annotating each use.

Maybe we can add to the draft that figure with image should have .image class?

[fredck]

Maybe we can add to the draft that figure with image should have .image class?

I like this proposal a lot. ++1 from me.

[Reinmar]

+1. Otherwise all this cannot be styled (CSS FTW!).

[Comandeer]

Ok, I've added fragment about that class attribute.

[Reinmar]

I think that including support for responsive images should be one of fundamental "features" of that Feature.

I'm not sure about that. How the image should be sent to the client is CMS's responsibility. The editor's responsibility is to allow inserting the image into the content. If that image stores a reference to an image entity in that CMS, then that CMS can render the image correctly, specifying the right sizes and URLs.

It would also be very hard to imagine how it would need to work from the user perspective. The user would not have a chance to understand the UI which asks about things that the editor would need to create a responsive image.

Hence, for me it's strictly CMS's responsibility.

[fredck]

I agree that it would be difficult (and pointless) to come with "variations" on the spec. We should stick with a single recommendation for it and leave such variations to integrators. I agree with @Reinmar that a serious responsive feature would not be part of the editor itself, but of the system it is embedded within.

[Comandeer]

Hm, at the moment we have a small note in "Implementation concerns" about that and it uses "SHOULD" keyword. Maybe switching to "MAY" will be enough? Or just drop it completely?

Art direction cases could be possibly handled by the UI to select different images for "mobile", "tablet" and "desktop", but more sophisticated cases aren't so easy to solve.

[fredck]

Maybe the point is... do we really want to be the ones saying how to do this thing right?

[Comandeer]

do we really want to be the ones saying how to do this thing right?

Is there anyone who does it actually? :D But yeah, pretty good point. Responsive images are so difficult to be done right that probably it would do no harm if we drop that part of the spec completely.

[Comandeer]

Ok, info about responsiveness is dropped.

[Comandeer]

Ok, it seems like a stable feature. I propose moving it from draft to the recommendation status. I'll wait 3 days for objections and then do what should be done ;)