[css-display][css-ui] Should outline apply to elements with 'display: contents'?

[fantasai]

François Remy wrote:

I think outline should work on display contents elements. Just like it works if an online gets split into lines or bidi or even regions or by a block-in-inline. I think the element should be focusable and tab-focusable too, but only if it is not replaced or a shadow host or none of its descendants in the light tree produce a box. The elements in cases noted above behave as if they were display none and should therefore not be focusable. Besides outline and a few other properties like pointer-event, properties should have no effect on the elements that do generate boxes for their descendants, besides being inherited by default.

I think a case can be made here.

Outlines may be non-rectangular. For example, if the element is broken across several lines, the outline should be an outline or minimum set of outlines that encloses all the element’s boxes.

The parts of the outline are not required to be rectangular. To the extent that the outline follows the border edge, it should follow the border-radius curve.

The position of the outline may be affected by descendant boxes.

Now to the question "does the spec say you should have an outline in that case" I'd say probably no. Whether it should say so is another question. You will have to answer these questions anyway when working on exposing these elements to assistive technologies. If these elements are there for semantic purposes, they must be exposed, and you will somehow need to synthetize something for them.

[frivoal]

Is the question of focusability of display:contents elements settled? I would expect them to stay focusable if they would have been focusable normally, as that's a semantic non presentational thing, but I have not followed that discussion as closely as I should have.

Assuming that they are focusable, that gives a rather strong usecase for supporting outline as well.

I'd be in favor of doing it in two steps: first, we should spec that UAs must display an outline on elements with display: contents when so instructed, without getting into what the outline looks like. In a later phase, as we narrow down the general question of outline interop, we can try and give more details about what shape it should have, what box it should encompass, and so on.

[fantasai]

@frivoal Yes, it's normatively defined in css-display-3. https://www.w3.org/TR/css-display-3/#the-display-properties

[dbaron]

While the spec does say (as quoted above):

The position of the outline may be affected by descendant boxes.

Gecko has been having to move away from doing this (or at least seriously consider doing so) for web compatibility, since other browsers don't do it (at least in many cases).

So I'd be pretty hesitant to add new behavior that depends on it, unless other browsers are committing to making outlines enclose descendant boxes.

[FremyCompany]

I'd like to note that we have had multiple discussions on this topic both in other issues and outside of github in the past few weeks, and I have come to revise my opinion here a bit.

I think it wouldn't make no sense to decide that display:contents elements do not render outlines, since they do not have boxes on which the outline drawing request can be stored. In the end, what I think really matters is that when a display:contents link gets keyboard-focused, an outline is drawn around the boxes it's associated with, but that can be achieved by "manually giving a default auto outline to the boxed descendants of an un-boxed focused element" rather than having an element without a box draw an multipart outline.

Both options are possible, really, and I'd be fine with both of these ways of doing things, but my understanding of the current consensus from people invovled in this issue is that, implementation-wise, not drawing an outline for a display:contents element makes more a lot more sense, and I'm inclined to believe it.

[SelenIT]

I agree with @FremyCompany. Absence of focus outline for the element with display:contents itself would be completely OK as long as the element remains focusable and keyboard-accessible, and its :focus state can be used to style its descendants and pseudo-elements.

[css-meeting-bot]

The CSS Working Group just discussed should outline apply to elements with display:contents, and agreed to the following:

• RESOLVED: Outline of 'display: contents' is propagated to children for painting (for a11y on focus); implementers should give feedback on it

The full IRC log of that discussion

<fremy> Topic: should outline apply to elements with display:contents
<astearns> github: https://github.com//issues/3323
<fremy> TabAtkins: I don't think it shouldn't
<fremy> TabAtkins: this property is already weird and magic
<fremy> florian: there is a trend however towards removing the magic
<fremy> TabAtkins: it's ok, we will then spec this case
<fremy> dbaron: we usually had outlines around descendants
<fremy> dbaron: and that caused issues
<fremy> iank_: in chrome there is a difference between focus and normal outlines
<fremy> bkardell_: can you clarify that?
<fremy> iank_: not correctly
<fremy> florian: when outline-style is auto, browsers can do even more magic than the other values, which already are permissive
<fremy> florian: focus outline in chrome is even more special than auto, I think, but it's not clear this is a requirement or historical accident
<fremy> TabAtkins: what if required to be the bounding box of all descendants
<fremy> florian: that's too much
<fremy> florian: we still want fragment outlines
<iank_> q+
<emilio> q+
<fremy> florian: I think it's ok to just say that for that special cases we will support the children
<fremy> florian: we will spec later
<fremy> una: but we would still render an outline around the element, right?
<fremy> TabAtkins: for display:contents there is no box for the element
<fremy> AmeliaBR: if we define an algorithm that creates a set of polygons based on the descendants, that would be fine, but if we want to use a box, this won't work
<bkardell_> q+
<fremy> TabAtkins: sure, but I would want to special case this in this very specific case
<fremy> AmeliaBR: also for other cases, or just display contents
<astearns> ack iank_
<fremy> TabAtkins: obviously people don't like it, so maybe just for display:contenents
<fremy> iank_: enabling outlines on display:contents is very difficult for our implementation to do
<fremy> iank_: so I
<fremy> 'd prefer not to go down that path
<fremy> iank_: I'm a little bit concerned about the accessibility case
<fremy> emilio: my comment was in the same direction
<fremy> emilio: drawing something keyed off that doesn't exist in the tree, is tricky
<fremy> emilio: focus on these elements is already something that is weird already
<fremy> emilio: I'm afraid it wouldn't be interoperable
<fremy> TabAtkins: well we could define this
<fremy> emilio: for the bikeshed cases, we could add a css rule
<fremy> like a:focus > * { outline: auto }
<fremy> TabAtkins: yeah, and if I had subgrid I woudln't need it either way, maybe that's fine
<bkardell_> q-
<fremy> emilio: and for the a11y tree, I think we resolved they would be in the tree
<fremy> fantasai: yes, they are in the tree, we resolved on this
<fremy> TabAtkins: so for bikeshed, I can add the rule, and use subgrid later, it's fine
<fremy> TabAtkins: you can already tab to them
<fantasai> fremy: That's not true yet
<fremy> dbaron: saying these elements have an outline is like poking a hole in the model
<fremy> dbaron: it's a bit weird, at what point are we not opening a can of worms?
<jensimmons> subgrid will lessen the desire to use `display: contents` to make grandchildren into grid items — but the usecase for Flexbox is the same. To make a flexbox grandchildren into flex items
<fremy> dbaron: like, people might want to ask other stuff like background
<fremy> TabAtkins: I think this is very specific though
<leaverou> fwiw, it looks like elements with display: contents elements don't receive focus right now in either Chrome or Gecko (not sure if that's related to the bug mentioned): https://codepen.io/leaverou/pen/oROLQm
<fremy> TabAtkins: like you can focus or interact with something, and outline is needed to show that, but it's very specific
<fremy> una: so you use display:contents and still want to interact, what is the use case?
<fremy> TabAtkins: explains the use case (bikeshed)
<fremy> una: so, you definitely want outlines here right?
<fremy> TabAtkins: yes!
<fremy> TabAtkins: and I believe this is the only hole we want to make
<fremy> fantasai: can we get bikeshed to stop doing this while it's not fixed everywhere though?
<fremy> TabAtkins: ok, fine
<fantasai> s/it's/a11y is/
<fremy> astearns: so, can we resolve on this?
<fremy> florian: I think it's fine to let authors have to supply the rule?
<fremy> emilio: I would like that
<fremy> TabAtkins: it woudln't work by default though
<fremy> emilio: yes, I think
<fremy> (discussion about the fact we might get a few outlines next to each other)
<fremy> TabAtkins: I think it's fine
<fremy> florian: And we want a note to make sure authors are aware if we don't do this?
<fremy> TabAtkins: ok, I'm fine with this, authors can use :focus-visible
<fremy> TabAtkins: I'll put a note and a remark about subgrid
<fremy> astearns: so, proposal, is to not change the spec, outlines do not apply, but we add an example to the spec
<emilio> fremy: I had a proposal for the outlines for the children itself
<emilio> fremy: that doesn't sound weird
<emilio> fremy: when you're focusing something you add an outline to it
<emilio> fremy: not sure if it's complex
<emilio> florian: I think it's complex
<emilio> fremy: but I'd set the outline property on the child box
<fantasai> emilio: At least in Gecko, those outlines are added via CSS
<fremy> emilio: at least in gecko, those outlines are added via css
<fantasai> emilio: It's effectively via :focus-visible { outline: 1px dotted }
<fremy> so we use :focus-visible { outline... }
<fantasai> emilio: so you cannot speical-case on the value of display
<fantasai> florian: Was saying it'd be based on used value
<fantasai> emilio: Focusing an element changes the value of descedant elements?
<fremy> and we cannot special case because selectors cannot depend on values
<fantasai> heycam: If it's up to the authors to specify outline on the children ...
<fremy> fremy: ok, I understand the concern
<fantasai> heycam: There's no way to do that if only a text node child
<fantasai> TabAtkins: No real use case for 'display contents' in that case
<fantasai> dbaron: What about two pieces where some are text
<fantasai> dbaron: e.g. link with plaintext and a span
<fantasai> TabAtkins: We need a pseudo-element for naked text then
<fantasai> florian: If you do that, then yo ucan add another span
<fantasai> s/florian/fremy/
<fantasai> heycam: Check if parent is display contents?
<fantasai> ScribeNick: fantasai
<fantasai> heycam: flattened tree parent
<fantasai> emilio: that's awkward
<fantasai> jensimmons: Any use cases for 'display: contents' besides lack of subgrid or maybe flex?
<fantasai> TabAtkins: Probably, but subgrid's the only one I've used personally
<fantasai> jensimmons: Why did we invent display: contents?
<fantasai> AmeliaBR: To have layout modes depending on parent-child relationships not disturbed by markup
<fantasai> TabAtkins: Before grid, was for flexbox
<fantasai> hober: Basically grid or flex
<AmeliaBR> s/by markup/semantic wrapper markup/
<fantasai> rachelandrew______: Forms have a ton of markup
<fantasai> rachelandrew______: so would want to use it there
<fantasai> rachelandrew______: to get rid of things like box around fieldset, etc.
<hober> s/Basically grid or flex/weird flex but okay/
<fantasai> rachelandrew______: once a11y issues are solved
<fantasai> jensimmons: We've eliminated the box, but the desire wasn't to eliminate the box but to have a flattened layout model with hierarchical markup
<fantasai> jensimmons: Maybe 'display: contents' was the wrong solution, too general
<fantasai> jensimmons: what we wanted was subgrid
<fantasai> jensimmons: now we've eliminated the box, and dealinng with fallout
<fantasai> jensimmons: but there wasn't a good reason to eliminate the box, except lack of flexbox
<fantasai> TabAtkins: Well, in flexbox, still want to be able to reorder things
<fantasai> dbaron: If you want the box back, you have to figure out where the box is
<fantasai> dbaron: by eliminating box, don't have to define where box is
<fantasai> dbaron: you make the element disappear so you can deal with the children individually
<fantasai> dbaron: so layout hasn't assigned a position for it, so can't draw the box if you don't know where it is
<fantasai> TabAtkins: So if shadow-including parent is 'display: contents' but should have an outline drawn on it, draw on children instead
<fantasai> AmeliaBR: How does that definition work if you have 'display Contents' inside 'display contents', how do we propagate this?
<fantasai> emilio: Recursive
<fantasai> emilio: not a big deal
<fantasai> emilio: but if should have an outline at paint time, that's vauge
<fantasai> emilio: has to count for visiblity, bunch of other stuff
<fantasai> heycam: accounting for visibility is annoying
<fantasai> heycam: ...
<fantasai> AmeliaBR: You can have a focusable element with visibility :hidden and some children that are visible
<fantasai> AmeliaBR: don't see an outline
<fantasai> ...
<fantasai> myles: Why don't we apply this logic to other CSS properties?
<fantasai> myles: I don't think that's a road we wnat to go down
<fantasai> astearns: When parent has visibility: hidden?
<fantasai> florian: If you have 'display: contents; visibility: hidden' can you focus it?
<fantasai> AmeliaBR: Most browsers won't focus such a thing
<fantasai> fremy: we draw it in Edge...
<fantasai> astearns: Does sound like model-breaking behavior
<fantasai> astearns: Defining whether box can be fousable based on CSS properties we should ignore
<una> Test case to play with (nested display:contents) forked from Rachel's pen: https://codepen.io/una/pen/joRMEL
<fantasai> fremy: If you're visiblity: hidden, you cannot be focused anyway
<fantasai> fremy: So this issue isn't relevant
<bkardell_> display: schrodinger-cat;
<fantasai> astearns: Two options I've heard
<fantasai> astearns: 1) Don't draw an outline. Stylesheet can try to style children or something
<fantasai> astearns: 2) Have UA figure out something to do with 'display: contents' things that shoudl have an outline
<fantasai> astearns: We have one possible definition of how that could occur
<fantasai> astearns: I'm unclear as to whether there's enough motivation to figure out UA magic to get this done
<fantasai> AmeliaBR: I prefer solution that requires authors to do less a11y-aware work, since lots of authors won't bother
<fantasai> fremy: Also govt' requirements, so browsers should do it by default
<fantasai> astearns: Cameron, do we need to evaluate conditions for outlining?
<fantasai> heycam: I don't know, if you had opacity: 0...
<fantasai> AmeliaBR: Then you wouldn't see it on the children either
<fantasai> TabAtkins: Aside from "don't draw this element", won't get focus outline
<fantasai> dbaron: But if you're display: contents, opacity has no effect
<fantasai> florian: Painting outlines on elements not in rendering tree
<fantasai> florian: Usually you don't iterate over tree to paint an element
<fantasai> florian: This is not the case for focus, you don't have to evaluate the entire tree to find focus
<fantasai> florian: We know if a focused element is focused
<fantasai> AmeliaBR: Much more narrow case
<fantasai> dbaron: There's another option along those lines, which is to say ... maybe you can't do that because selector-property dependency
<fantasai> dbaron: was going to say was if you're display: contents and you're focused, focus-visible aplies to descendants but cna't do that
<fantasai> fantasai: I think what heycam said was the simplest solution
<fantasai> emilio: I still think they're hacks
<fantasai> emilio: It's not impossible, just feels like a layering violation
<fantasai> florian: iank_ You were saying it's hard?
<fantasai> iank_: I believe our focus outlines get painted differently from normal ones
<fantasai> florian: What would be hard about normal ones
<fantasai> iank_: Don't have anything to hook up to invalidation logic
<fantasai> iank_: We'd need to introduce this backing to layout tree
<fantasai> fremy: The children draw the outline, so children invalidation
<fantasai> florian: but if you change the property on the parent, you need to know that the children have to be invalidated
<fantasai> emilio: It's a hack
<fantasai> heycam: We'd have to propagate a change hint to the children. Not impossble.
<fantasai> emilio: Nothing is impossible
<fantasai> heycam: Sure, but also doesn't seem too hard
<fantasai> astearns: It is slightly better to introduce hack into UA than to expect authors to have the same hack in their CSS
<leaverou> wouldn't drawing outlines on children be confusing if an element only had one child, which was focusable? Tabbing would produce no visible difference
<fantasai> fremy: If we have in the platform 'display: contents' then it's our responsibility to provide a11y support, putting it in the tree and providing outlines is part of that
<fantasai> emilio: Whether propagating outline , and someone mentioned browsers don't focus visibility hidden elements even if you have visibile children
<fantasai> florian: Because you can't focus them
<fantasai> emilio: link with 'display: contents' we say has to be focused
<fantasai> emilio: but link with 'visibility: hidden' we don't focus, and it's OK
<fantasai> TabAtkins: I consider it a bug. That I don't care about
<fantasai> florian: ...
<fantasai> TabAtkins: Nobody has brought up that as a problem in the 20+ yrs
<fantasai> TabAtkins: whereas within 6 months we had bugs filed against 'display: contents' for not being focusable
<fantasai> leaverou: If we draw outlines on children, might be confusing if only one child that is also focusable
<fantasai> leaverou: there would be no visible difference
<heycam> fantasai: there's already no difference if you have an unstyled box wrapped around a child
<heycam> ... the outlines will look the same
<heycam> ... it's not a new problem. whether the box is unstyled with no pbm, or it's display:contents, it makes no difference whether the outline is on the parent or child
<heycam> AmeliaBR: comes down to a design issue
<fantasai> florian: Back to earlier point, difficulty in invalidation logic
<fantasai> florian: you could reduce to focus case
<fantasai> fantasai: I think that's harder
<fantasai> emilio: think it's harder for us
<fantasai> emilio: First one you would implement display: contents with outline changed, go down the tree and invalidate other elements inside it
<fantasai> emilio: but in the other case would also need to evaluate focus. More special-casy
<fantasai> iank_: Can't speak with authority for us
<fantasai> iank_: The thing that scares me is potentially if outline is painted by the children, how do you make sure the outline is contiguous
<fantasai> florian: You don't
<fantasai> florian: You just make it on the children and whatever
<fantasai> fremy: That's the proposal
<fantasai> florian: If youre existing logic merges outlines, then do that. otherwise don't
<fantasai> emilio: That's not quite similar
<fantasai> emilio: You also have to check outline on parent vs child
<fantasai> emilio: If have different outline properties...
<fantasai> AmeliaBR: What if say children treated as have 'outline: inherit'
<fantasai> fremy: Just check if 'outline-style' is 'none', and if parent s 'display: contents' draw parent's outline
<fantasai> dbaron: Or draw two outlines?
<fantasai> dbaron: and don't worry about those conditions?
<fantasai> una: I think it's more confusing to have simultaneous outlines
<fantasai> una: if you're tabbing into the children ...
<heycam> fantasai: only draw the outline if it's specified
<heycam> ... if you happen to specify 3 outlines on the 3 different elements, you'd draw all of them
<heycam> ... might just be drawing because one is focused, because you've got outline specified, ...
<heycam> ... not dissimilar to how you handle borders for example, layer them all and paint them
<heycam> ... if they fall on top of each other, you won't see the ones underneath
<fantasai> dbaron: In the normal case for focus, if you have a box 'display: contents' with three children
<fantasai> dbaron: you tab to parent, you see all three outlined, and then each one outlined individually as you tab through them
<fantasai> florian: Don't see how to do btter than that, the children could be anywhere not necessarily adjacent
<fantasai> fremy: We're defining a default.
<fantasai> fremy: Not preventing authors from doing better
<fantasai> fremy: Just saying by default, we show an outline
<AmeliaBR> s/btter/better/
<fantasai> fremy: Not required to be pretty. pretty would be great, but ppl already change outlines on focus all the time
<fantasai> fremy: to make it prettier
<fantasai> fremy: But by default we want there to be an outline so it will be accessible
<fantasai> fremy: doesn't have to be pretty
<fantasai> emilio: it's still a hack
<fantasai> fremy: The goal is everybody at least gets an outline to show the focus
<fantasai> fremy: if someone doesn't like it, you can refine it
<fantasai> fremy: not prevent that, but at least provide something that works
<fantasai> florian: if outlines that are drawn for non-focused elements are not drawn, that's OK
<fantasai> florian: But for focus case should do it
<fantasai> AmeliaBR: So UA must propagate outline if it was caused by a focus change, but?
<fantasai> florian: Either do it always, or do it only for focus-triggered outlines, whichever is easier to implement
<fantasai> fremy: My guess is display: contents is much harder ot implement than what we are discussing now
<fantasai> fremy: we're just going the last mile to make it great
<fantasai> AmeliaBR: Can we make a tentative resolution that we will at least support the a11y use case and ask implementers to give feeback on which would be easier to implement: special-case for focus, or any outline?
<fantasai> emilio: display:contents make sense conceptually, this thing we are discussing makes no sense
<fantasai> emilio: it's a hack
<fantasai> emilio: in any browser implementing it's a hack
<fantasai> fremy: Users > web authors > implementers
<fantasai> emilio: I won't oppose but I will be very upset to implement this
<fantasai> TabAtkins: make Cameron do it :)
<fantasai> astearns: So deciding whether to draw only for focus?
<fantasai> Rossen: at least
<TabAtkins> I don't disagree that it's a hack.
<TabAtkins> It's just a necessary hack for a11y.
<fantasai> bkardell_: Are we positive you need to be able to set focus on display: contents element?
<fantasai> TabAtkins: Yes
<una> When authors use hacks, its our responsibility to make that experience more accessible
<rachelandrew______> CSS is making people sad again.
<fantasai> TabAtkins: because there are use cases to display: contents a link, an dyou need to be able to activeate the link if you're a keyboard user
<fantasai> TabAtkins: And when focusing you need to be able to see that it's focused
<AmeliaBR> Real world example: `<article class="slide"><a href="..." style="display: contents"><h2>article title</h2><img src="thumbnail"/></a><p>description</p></article>`
<fantasai> bkardell_: Can we just say you can't display: contents a link?
<AmeliaBR> (where the slide has flex or grid layout)
<fantasai> florian: There are use cases for it, though
<fantasai> AmeliaBR describes her use case
<fantasai> AmeliaBR: Want to lay out this article as three separate items in your layout
<emilio> AmeliaBR: why not making the link the flex container?
<fantasai> AmeliaBR: when someone tabs to that link, wnat to be able to see somehting is focuse
<una> Amelias example: https://codepen.io/una/pen/ZNZprm
<fantasai> florian gives a use case for page numbers or something
<fantasai> iank_: I'll have to check with implementers. I will project their sadness.
<fantasai> astearns: So proposed resoution is we paint outlines on the children of a display: contents element
<fantasai> florian: ... special-case focus?
<fantasai> fantasai: I'm pretty sure it's easier to not special-case.
<fantasai> iank_: unsure
<fantasai> astearns: OK, but this is the case we want to support for a11y
<fantasai> TabAtkins: You can come back and say "no, it's really too hard"
<fantasai> TabAtkins: I don't want us to give up just because it's a little not great so we made it inaccessible
<fantasai> astearns: So any objection to make this change and get implementer feedback
<fantasai> RESOLVED: Outline of 'display: contents' is propagated to children for painting (for a11y on focus); implementers should give feedback on it

[dbaron]

Is our resolution clear about what should happen in case (2) here?

<div style="display: contents; outline: 1px dotted">
    <div>(1) This div clearly has an outline.</div>
    <div style="display:contents">
        <div>(2) Does this div have an outline?</div>
    </div>
</div>

[SelenIT]

My understanding is that it implies recursive propagation (as mentioned in the discussion), so I'd say that the resulting outline should span both rendered divs.

[annevk]

Reading the discussion I'm not sure that was considered and I also recall @MatsPalmgren pretty explicitly objecting to this in a Bugzilla bug.

I'm rather worried that this case-by-case decision-making regarding which aspects of a box matter and which don't for display:contents will lead to a rather confused design.

[SelenIT]

I'm afraid that any design of the feature like display:contents (aptly dubbed display: schrodinger-cat; in the discussion:) couldn't completely avoid any confusion. But the proposed solution looks significantly less confusing for users and authors than the existing implementations, and thus better conforming to the Priorities of Constituencies principle.

case-by-case decision-making regarding which aspects of a box matter and which don't

As far as I understand, it's not the change in "which aspects of the box matter", it's "which boxes matter" that is changing. When the element clearly has a visible and interactive box tree, making the closest visible boxes in that tree matter instead of the only absent box in it makes much sense to me.

[annevk]

It does not make sense to me, since above you're arguing for enclosing two child boxes with a new wrapper box of some kind that has the outline...

[SelenIT]

I don't argue for that. I only said that, according to my understanding of the CSSWG resolution, both boxes should have an outline around them. I have no preference how exactly this compound outline should be implemented, it's up to vendors.

The only thing that I really argue for is that an interactive element that has any visible and interactive box tree should be focusable and keyboard-accessible by default.

[dbaron]

So given the more recent discussions in whatwg/html#9425 and mozilla/standards-positions#772 and elsewhere, I'm coming back to this issue.

I think the idea of propagating the outline to children (possibly recursively) mostly makes sense, although it may or may not be quite difficult to implement. I think there are a few issues we'd need to sort out at a conceptual level, though:

• Is it a "merged" outline or separate rectangles around each child? (Chrome does "merged" outlines for multiple lines of links, and I think this sort of merging was part of the original intent of outline. I'm not sure about the current state in other browsers.)

• How do we handle children that are text nodes? Text nodes normally don't draw outlines.

If we do a "merged" outline I think we could associate it with the first relevant child (for z-ordering, filtering, etc. purposes). Or maybe the last one if outlines aren't (in some engines, at least) implemented at a special position in the z-order.

I think the difficult parts from an implementation perspective probably relate to getting invalidation right when things change (such as changes to the size of the children or addition or removal of children).