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