Ckeditor5: The output HTML should use <figure>

[Reinmar]

The output should match the format proposed by http://ckeditor.github.io/editor-recommendations/features/table.html

[jodator]

@Reinmar even though we do not provide caption for now? Just to be sure the output table should be just wrapped in <figure> element:

<figure>
    <table>
        <tbody>
            <tr><td>foo</td></tr>
        </tbody>
    </table>
</figure>

[Reinmar]

Just to be sure the output table should be just wrapped in <figure> element:

Nope ;) Please read editor recommendations :P

Especially this:

The

element MUST be used to represent the Table feature as it is the standard way to express self-contained non-textual additional content[1].

And:

The

element SHOULD have a class attribute which value is set to table to identify that the element is being used for representing table and to allow styling that particular use-case.

And:

he caption for the table, if it is present, MUST be placed inside

element[10].

So, the <figure> is a must have. It should be marked with a table class (for us it's a must). And this is regardless of whether we support captions for now.

[wwalc]

Why precisely the table element MUST be surrounded by the <figure> element? I am unable to find such requirement in the HTML5 spec.

The <figure> element MUST be used to represent the Table feature as it is the standard way to express self-contained non-textual additional content[1].

Not sure what's the definition of "non-textual". After all tables cells usually contain just text, just like the blockquote element etc.

Here's a sample table taken from the specification:

What I'm worried about is that we'd start producing more markup than it's really needed, not sure how many people when styling <figure> with CSS consider that it would wrap tables as well and so on.

[Comandeer]

The main reason for wrapping table with figure is that sentence from the HTML 5.x specification (bold's mine):

The figure element represents some flow content, optionally with a caption, that is self-contained (like a complete sentence) and is typically referenced as a single unit from the main flow of the document.

CKEditor is supposed to be used to create semantic HTML output. In that case every code listing, image, quote, table etc. should be treated as self-contained and meaningful. In other words: nearly everything that isn't plain text (that's what I mean by "non-textual additional content") should be treated as something that could be taken away from the original context without loosing meaning (think of this like moving such things to appendix in thesis).

Such understanding of figure element is even described in the specification:

When a figure is referred to from the main content of the document by identifying it by its caption (e.g., by figure number), it enables such content to be easily moved away from that primary content, e.g., to the side of the page, to dedicated pages, or to an appendix, without affecting the flow of the document.

OTOH I admit that figure > table without figcaption has much less sense than figure > table + figcaption and in such case we could drop the figure element. But then we'll loose this nice indication that this table means on its own, without surrounding context.

[wwalc]

every code listing, image, quote, table etc. should be treated as self-contained and meaningful

With such reasoning we should put into figure virtually everything, lists, blockquotes, not just tables. Not sure if it isn't an overkill since the table tag itself already has a precise meaning.

For me using <figure> for tables and so on makes sense only with the combination of <figcaption>.

[Reinmar]

Images are wrapped with <figure class=image> regardless of whether they are captioned. So, I don't see a problem with tables being wrapped too. In fact, it'd be odd if they weren't.

It's a good point about block quotes, though. But it depends, I believe, on the context. External quotes are self-contained and would have to be wrapped. Message quotes (like quoted emails) are a different story and perhaps should not be wrapped. The current block quotes feature is in between. It's a bit of a compromise that we had to make.

[Comandeer]

With such reasoning we should put into figure virtually everything, lists, blockquotes, not just tables.

Well, ER recommends putting quotes in figure – but it seems that implementation in CKE5 doesn't do that.

In case of lists: lists are very often not self-contained. They're part of bigger chunk of text, e.g.:

<p>I already know these languages:</p>

<ul>
    <li>JavaScript</li>
    <li>PHP</li>
    <li>HTML</li>
    <li>CSS</li>
    <li>Java</li>
</ul>

In that case list is tightly coupled with the sentence above it, therefore it's not self-contained and not a good candidate for being put into figure.

[wwalc]

Regarding lists: https://www.w3.org/TR/html5/grouping-content.html#example-b4ac5f5b

[jodator]

:popcorn: quite interesting talk but I see that editor recommendations were already thought thoroughly and since images without a caption are in a <figure> then we can go with figure > table now.

ps.: side question what about table > caption? It looks like another choice do describe table.

[Comandeer]

Regarding lists: https://www.w3.org/TR/html5/grouping-content.html#example-b4ac5f5b

OK, but in that example list is not connected with any sentence, is not part of sentence and it has meaning on its own. Case depends on the context and most lists are tightly coupled with other parts of content.

side question what about table > caption? It looks like another choice do describe table.

There are several techniques for describing table. In our case we use figcaption as also the mean to describe the whole figure element. Probably it would be nice to additionally bind figcaption with table using [aria-labelledby]/[aria-describedby].

[oleq]

A figure would definitely make implementation of the selection/drag handler much easier for us. ATM there's no wrapper around the table to anchor one.