[css-ui-4][css-tables-3] should table outlines surround captions too?

[heycam]

https://drafts.csswg.org/css-ui-3/#outline-props
https://drafts.csswg.org/css-tables-3/#drawing-table-backgrounds-and-borders

See this test:

https://bug1482778.bmoattachments.org/attachment.cgi?id=9012757

In Firefox and Edge, the outline surrounds the main table grid. In Chrome and Safari, the outline also includes the caption. The not-ready-for-implementation css-tables-3 says that backgrounds, borders, and outlines that would be positioned relative to the border-box of the table are adjusted to be relative to the table grid and its border spacings.

I think drawing an outline around the table including the caption would be a little more useful.

[jonjohnjohnson]

Though this would be a unique (strange) distinction between borders and outlines, I agree with @heycam, since tbody is also allowed outline styles. Whereas tbody cannot have its own border styles if borders are separate, making the border set on table useful around its table grid.

[frivoal]

This fits in the the broader question of how much we should define outlines in general. In the past, the answer has been that we should hardly define them at all.
The logic for that being that outlines is mostly a UI feature and UI is an areas where browsers should be free to innovate.

I'd be in favor of gradually tightening it up and trying to converge onto something, but it's a broad topic, there are many points of divergence. If there's a will on the implementer side to try and reach for interop, i'm happy to give it a go, but this has not always been the case.

[Archibald2]

Much of this issue stems from very poor HTML standards: label, caption and figcaption have very differing constructs for essentially the same purpose.

In my view an outline should always outline the whole of an element, not just part of it. A caption is within a table element so should be included within the outline of a table.

I note that if a listener is added to a table element, the whole area of the element becomes responsive, including the caption (Chrome, Firefox, Edge & IE11 at least).

A workaround for differing browser behaviour is to put a table within a figure element and use figcaption instead of caption. As figure and figcaption have much more sensible HTML coding and semantics, in my view use of caption and label should therefore become deprecated in favour of use of figcaption within a figure.

[css-meeting-bot]

The CSS Working Group just discussed Defining Outline.

The full IRC log of that discussion

<fantasai> Topic: Defining Outline
<astearns> github: https://github.com//issues/3184
<fantasai> florian: Outline property is quite loosely defined, and to a certain degree intentionally so
<fantasai> florian: Ther'es a design reason and a process reason
<fantasai> florian: Design reason is because outline is used for focus, and we didn't wnat to constrain too much how UAs draw their focus rings
<fantasai> florian: On the other hand, outlines are used for decorative purposes all the time, and not having inteorp there is an issue
<fantasai> florian: Process reason was that for L3, we were trying to wrap up and didn't have a clear proposal or interop
<fantasai> florian: So question is, now in L4, do we want to define this more precisely?
<fantasai> florian: Should we pick a behavior and have everyon conform to it?
<fantasai> florian: Or are we still thinking we don't want to constrain the outline.
<fantasai> florian: Wanted to see where the WG stands on these types of issues
<fantasai> florian: Should we try to constrain and find inteorp, or leave open to experimentation by UAs?
<fantasai> smfr: Special behavior in webkit only happens on auto style
<fantasai> florian: That could be a reasonable compromise
<fantasai> florian: let auto do whatever, then gradually narrow down behavior of the rest
<fantasai> florian: Specific issue triggering this discussion was raised by heycam
<fantasai> florian: Seems like you have some interest in increased interop?
<fantasai> heycam: Even if we didn't get to a world with mandated behavior, would be helpful to have more guidelines on which boxes contribute to the outline rectangle
<fantasai> florian: Was contacted by person from Google who works on this
<fantasai> Aleks: I'm implementing this, so that's my interest. My take on outline, I talked to fantasai about them
<fantasai> Aleks: There was a difference for us between focus outline and css outline, and that was annoying
<fantasai> Aleks: Would be nice to define whether focus and css outlines are the same or different, and if different then define css outline strictly for interop
<fantasai> ...
<fantasai> Aleks: When you're tabbing through, you get the "tabbing outline"
<fantasai> florian: If you put 'outline: auto', do you get the same outline as the focus outline or something else?
<fantasai> Aleks: that's a weird edge case in my opinion
<fantasai> florian: current suggestion is to allow UA to do whatever for 'auto' style outline, and otherwise tighten up what the outline is
<tantek> outline was always intended to represent the focus outline, period. and if there's been a divergence it's because implementations were lacking, likely unintentionally.
<fantasai> florian: So I think that's a direction we can look into

[FremyCompany]

Quick note that the table spec is specific about this, so it wasn't clear to me today's discussion was addressing this particular issue, that seems to be about changing what we define and is implemented by two user agents.

[Reinmar]

A workaround for differing browser behaviour is to put a table within a figure element and use figcaption instead of caption. As figure and figcaption have much more sensible HTML coding and semantics, in my view use of caption and label should therefore become deprecated in favour of use of figcaption within a figure.

Unless that <figure> is styled with display:table where it becomes the exact same scenario to captions inside tables 😅

CKEditor 5 (but I know that not only we went this way – it's also used e.g. by Drupal) use display:table on <figure> to make it take the image's width. Unfortunately, with those styles we hit Firefox's issue: ckeditor/ckeditor5#1979.

[dbaron]

I'd note (based on bug 1603049) that specifying the Gecko behavior here would require extending the list of properties used on the table wrapper box (currently "The computed values of properties 'position', 'float', 'margin-*', 'top', 'right', 'bottom', and 'left' on the table element are used on the table wrapper box and not the table box") to include both outline (the shorthand) and outline-offset.