- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 6 Jul 2019 16:57:12 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Multicol
------------
- RESOLVED: Column-gap percentages no longer at-risk. Add some
tests to WPT. (Issue #3988: Remove at-risk marker for
percentages in column-gap)
- RESOLVED: Keep a section to explain how column-gap works in
multicol, but define in box-alignment only (and link
between them) (Issue #3641: Should we refer to
definition of `column-gap` in Box Alignment?)
CSS Sizing
----------
- RESOLVED: cbiesinger will document chrome's behavior and we will
revisit (Issue #3973: Why was min-content redefined to
do nothing on the block axis?)
CSS Display and UI
------------------
- RESOLVED: Outline of 'display: contents' is propagated to children
for painting (for a11y on focus); implementers should
give feedback on it (Issue #3323: Should outline apply
to elements with display:contents)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/toronto-2019
Scribe: fremy
CSS Multicol
============
Remove at-risk marker for percentages in column-gap
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3988
rachelandrew: There was a resolution before I joined the group to
mark percentages in column-gap at risk
rachelandrew: but Firefox implemented it, and now the property
applies on grid and flexbox as well
rachelandrew: so they asked if the at-risk could get removed
astearns: Do we have implementation report?
rachelandrew: Yes
astearns: Does any other implementation want to get it removed?
astearns: I assume not since we resolved to allow it?
florian: Yeah, I'd agree to remove because sometimes implementors
are afraid to implement it
AmeliaBR: Yeah, at-risk should be redefined to be less scary
florian: Yeah, that's just the name though, the description is
already encouraging implementation
florian: It would be nice to change the name at the w3c level, but
this hasn't happened yet
AmeliaBR: Do we have tests to back this up?
rachelandrew: Yes, and on top of that we have tests for grid as
well, where it is implemented
astearns: Any objection to remove the at-risk comment?
iank: There is only one test, and that is a bit low
iank: We would need tests for intrinsic sizing etc
iank: but I'm ok to remove the at-risk
astearns: resolved then
RESOLVED: Remove at-risk percentages on column-gap (and add some
tests)
Should we refer to definition of `column-gap` in Box Alignment?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3641
rachelandrew: We define column-gap in multicol and box alignment
rachelandrew: Authors were discussing how confusing that was
rachelandrew: I'd rather define column-gap in alignment, and just
mention the specificities of column-gap for columns in
multicol
florian: We kinda did the same thing for break properties, where
they usually were defined in multiple places, and now we
consolidated in css-break and we added notes to the other
places
AmeliaBR: We should consider REC progress though, so we don't get
stuck
fantasai: css-align is really close to CR, so I don't think that
would be an issue
fantasai: The only remaining significant source of issues is
baseline alignment
fantasai: and we could move that to the next level if needed
AmeliaBR: Then that seems fine
rachelandrew: Suggested edit is to add an heading to explain how
column-gap works in multicol, but define in
box-alignment only
astearns: Any objection?
RESOLVED: Add a heading to explain how column-gap works in
multicol, but define in box-alignment only (and link
between them)
CSS Sizing
==========
Why was min-content redefined to do nothing on the block axis?
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3973
fantasai: Since Christian raised this issue, it would be good to
have him on the line when we discuss this?
fantasai: (this was a question)
astearns: We could move to the next one to see if we can get
Christian on the line?
[brief break getting cbiesinger on a call]
astearns: cbiesinger can you summarize the issue?
cbiesinger: There was a change in css-sizing spec
cbiesinger: Now min-content does the same as the initial value
cbiesinger: which is great for height
cbiesinger: but for min-height for instance, this is a change in
behavior
cbiesinger: and in flexbox with auto, you can't get a specific
effect that you used to get before
cbiesinger: So we should probably redefine it again so that it does
a different thing by property
fantasai: Makes sense to me
dbaron: The assumption is that it was defined before
dbaron: but before it wasn't clear to me what it was actually
supposed to do
dbaron: You have block size that is derived from the content
dbaron: but it doesn't say which inline size is used to get that
layout done
dbaron: So in the general case, what would be that inline size?
dbaron: Is that a function of something else? how does it get passed
in to this?
cbiesinger: That's true
cbiesinger: The definition of the min-content block size still
exists in the spec though
cbiesinger: and it has this issue, so we need to fix this no matter
what
dbaron: Sure, but I'm not sure we should have this in the spec at all
<AmeliaBR> min-content block size definition:
https://drafts.csswg.org/css-sizing-3/#min-content-block-size
cbiesinger: In the common case in a column-flexbox, it defaults to
min-height: min-content
dbaron: And how do you determine what that height is?
cbiesinger: You use the inline size you derive from the sizing
properties
dbaron: So it's not really an intrinsic size, it's a specific size
that depends on the layout you are in the middle of doing
dbaron: So we don't really need this concept for that case
dbaron: but for orthogonal flows, you'd allegedly need the general
case?
fantasai: For orthogonal flows, you have to pick a size anyway
dbaron: So, ok, regardless, we need to define very precisely that
inline size
iank: Is it true that in our implementation, the value is (...) ?
cbiesinger: Yes, the post-layout size is (...)?
iank: In our implementation, min-content and max-content were the
same, and were the post-layout block size of this element, as
if no other constraints were applied
iank: and it works thanks to the clamping
fantasai: I think it's very clear to me that the change was not
correct anyway
fantasai: so we should revert this edit anyway
fantasai: but I agree we should also make sure we get things defined
explicitly
fantasai: and maybe think whether min-content and max-content should
be the same
dbaron: And even if they are the same, we need to define what they
are
dbaron: but if we don't have a first-layout pass, sometimes it
happens?
iank: For min-height/max-height you do, because you clamp an
existing height
fantasai: So, yeah, using the default value is wrong because
sometimes auto is not min-content
fantasai: I can't think of a reason for blocks to want min-content
!= max-content
fantasai: but for grid, we could trigger the different distributions
algorithms for them
fantasai: We should think about that
<fantasai> It's less clear that they should be different in this
case, because there are different space distribution
rules for each
astearns: So, I hear that we want to revert, and try to get a
definition for this
astearns: Even if there is some skepticism we can get a definition
that works
dbaron: I would also not want to call them intrinsic if they are not
intrinsic anymore
dbaron: It seems to me we are defining something else entirely
dbaron: Doing some of these things require major changes in some
algorithms, and I'm not sure what the use cases are
cbiesinger: min-height:min-content seems useful
<cbiesinger> I tried to ask if gecko supports this right now
dbaron: It is not impossible that this could take a year for us to
implement, and I'm not sure this is worth
dbaron: There are some existing implementations, but did we check
that they match, and not are just superficially similar?
dbaron: I am not sure
dbaron: so I don't want to take this lightly
dbaron: so I would rather have a full proposal
dbaron: so I can evaluate complexity, and evaluate the cost/benefit
ratio
dbaron: There are things that happen in gecko when you specify these
things of course, but are we interop? probably not?
emilio: I don't think we have implemented to block size that works
in the block axis
TabAtkins: (pointing another case that seems wrong in gecko, even in
the inline axis)
[this might have been wrt intrinsic width of a multi-col container]
cbiesinger: Agreed that some cases are difficult in the inline cases
TabAtkins: We do use an approximation here, that was better than
gecko that assumes a single-column
TabAtkins: Edge had a good implementation
TabAtkins: but regardless, we didn't
TabAtkins: so I tend to agree that intrinsic isn't always as
"intrinsic" as the name implies
TabAtkins: it sometimes requires full layout
fantasai: How about changing the spec to say that we want to match
the `auto` height
fantasai: but in the sense of `auto` that computes an height based
on the content size, rather than filling the container etc.
fantasai: not like in grid where `auto` sometimes means `stretch` etc
astearns: Can we resolve of reverting?
dbaron: I'm uncomfortable going back to undefined
astearns: But other engines don't want that current spec text
dbaron: ok, but this is a can of worms
dbaron: (snarky comments about multiple engines)
cbiesinger: I'm optimistic we could get this interoperable
iank: For the cases that cbiesinger described, it would be easy to
implement the correct behavior for that subset
iank: and we think it's useful
astearns: As you implement subset, it would be nice to describe
things in details, so we could find out if interop is
possible
fantasai: Technically, the behavior we want should already exist in
the engine, it might not just be called in that specific
scenario
fantasai: but the keyword would allow to tap in the computations
that exist
fantasai: Possibly there are cases where you would need much more
layout than engines are willing to do, e.g. for the width
of a multiline column flexbox
fantasai: but there are a lot of reasonable cases
fantasai: and for those cases we should figure out what should
happen and standardize that
astearns: Basically dbaron hesitates due to lack of precise details]
cbiesinger: Is there a particular case you think would be very hard?
cbiesinger: So we could find out if we could solve that one?
dbaron: Intrinsic size depending on the inline, it could depend on
layout optimizations
dbaron: and there might be cases where we try to figure out block
before inline
dbaron: and all those cases seem intricate
fantasai: Yeah, grid has two passes for that reason
fantasai: (explains how these metrics are computed already today,
she thinks)
<cbiesinger> for flex you need it go calculate the hypothetical main
size, too
<cbiesinger> or maybe I mean the flex base size
dbaron: I'm worried it uses a value from late in the system, early
in the system
dbaron: Gladly calc doesn't allow to make computations based on
those values usually
dbaron: but there might be cases where we do this accidentally in
the algorithm
dbaron: and it might cause instability, etc.
cbiesinger: I understand the concerns now
cbiesinger: I'm still inching towards it's sufficiently useful
dbaron: Is it sufficiently useful that you would be willing to write
a spec?
<hober> fwiw, i agree with dbaron
TabAtkins: (proposed to meet next time he was in new-york to work on
it, but cbiesinger is not based in NY)
cbiesinger: I will write something
cbiesinger: I can try writing a spec
<fantasai> thinks maybe we just need to make a chart of all the
cases, and then show what happens in each case and make
sure the spec covers that
<fantasai> https://github.com/w3c/csswg-drafts/issues/3973#issuecomment-498062046
astearns: So, first resolution attempt, can we revert what's in the
spec now?
dbaron: Do we know why we made the resolution that let to this
changeset?
<fremy> (can we get a link to the change)
TabAtkins: I don't recall
dbaron: What I don't like is that the revert will trigger chrome to
revert
dbaron: and that revert will be unspecced but people will rely on
their behavior
florian: We could have an issue in the spec
Rossen: That seems overkill, we have an issue on github seems enough
Rossen: I think it would be better to first get a strawman of the
chrome behavior, and we can resolve the revert at that time
cbiesinger: ok, sounds fine
astearns: Any objection to this way forward?
RESOLVED: cbiesinger will document chrome's behavior and we will
revisit
CSS Display and UI
==================
Should outline apply to elements with display:contents
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3323
TabAtkins: I don't think it shouldn't
TabAtkins: This property is already weird and magic
florian: There is a trend however towards removing the magic
TabAtkins: It's ok, we will then spec this case
dbaron: We usually had outlines around descendants
dbaron: and that caused issues
iank: In chrome there is a difference between focus and normal
outlines.
bkardell: Can you clarify that?
iank: Not correctly.
florian: When outline-style is auto, browsers can do even more magic
than the other values, which already are permissive
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
TabAtkins: What if required to be the bounding box of all descendants
florian: That's too much
florian: we still want fragment outlines
florian: I think it's ok to just say that for that special cases we
will support the children
florian: We will spec later
una: But we would still render an outline around the element, right?
TabAtkins: for display:contents there is no box for the element
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
TabAtkins: Sure, but I would want to special case this in this very
specific case
AmeliaBR: Also for other cases, or just display contents
TabAtkins: Obviously people don't like it, so maybe just for
display:contents
iank: Enabling outlines on display:contents is very difficult for
our implementation to do
iank: so I'd prefer not to go down that path
iank: I'm a little bit concerned about the accessibility case
emilio: My comment was in the same direction
emilio: Drawing something keyed off that doesn't exist in the tree,
is tricky
emilio: Focus on these elements is already something that is weird
already
emilio: I'm afraid it wouldn't be interoperable
TabAtkins: Well we could define this
emilio: For the bikeshed cases, we could add a css rule like
a:focus > * { outline: auto }
TabAtkins: Yeah, and if I had subgrid I wouldn't need it either way,
maybe that's fine
emilio: And for the a11y tree, I think we resolved they would be in
the tree
fantasai: Yes, they are in the tree, we resolved on this
TabAtkins: So for bikeshed, I can add the rule, and use subgrid
later, it's fine
TabAtkins: You can already tab to them
fremy: That's not true yet
<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
<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
dbaron: Saying these elements have an outline is like poking a hole
in the model
dbaron: It's a bit weird, at what point are we not opening a can of
worms?
dbaron: like, people might want to ask other stuff like background
TabAtkins: I think this is very specific though
TabAtkins: like you can focus or interact with something, and
outline is needed to show that, but it's very specific
una: So you use display:contents and still want to interact, what is
the use case?
TabAtkins: [explains the use case (bikeshed)]
una: So, you definitely want outlines here right?
TabAtkins: Yes!
TabAtkins: And I believe this is the only hole we want to make
fantasai: Can we get bikeshed to stop doing this while a11y is not
fixed everywhere though?
TabAtkins: ...
astearns: So, can we resolve on this?
florian: I think it's fine to let authors have to supply the rule?
emilio: I would like that
TabAtkins: It wouldn't work by default though
emilio: Yes, I think
[discussion about the fact we might get a few outlines next to each
other]
TabAtkins: I think it's fine
florian: And we want a note to make sure authors are aware if we
don't do this?
TabAtkins: ok, I'm fine with this, authors can use :focus-visible
TabAtkins: I'll put a note and a remark about subgrid
Scribe: emilio
astearns: So, proposal, is to not change the spec, outlines do not
apply, but we add an example to the spec
fremy: I had a proposal for the outlines for the children itself
fremy: that doesn't sound weird
fremy: When you're focusing something you add an outline to it
fremy: not sure if it's complex
florian: I think it's complex
fremy: But I'd set the outline property on the child box
Scribe: fantasai
emilio: At least in Gecko, those outlines are added via CSS
emilio: It's effectively via :focus-visible { outline: 1px dotted }
emilio: so you cannot special-case on the value of display
florian: Was saying it'd be based on used value
emilio: Focusing an element changes the value of descendant elements?
<fremy> and we cannot special case because selectors cannot depend
on values
heycam: If it's up to the authors to specify outline on the
children...
fremy: ok, I understand the concern
heycam: There's no way to do that if only a text node child
TabAtkins: No real use case for 'display contents' in that case
dbaron: What about two pieces where some are text
dbaron: e.g. link with plaintext and a span
TabAtkins: We need a pseudo-element for naked text then
fremy: If you do that, then you can add another span
heycam: Check if parent is display contents?
heycam: flattened tree parent
emilio: That's awkward
jensimmons: Any use cases for 'display: contents' besides lack of
subgrid or maybe flex?
TabAtkins: Probably, but subgrid's the only one I've used personally
jensimmons: Why did we invent display: contents?
AmeliaBR: To have layout modes depending on parent-child
relationships not disturbed semantic wrapper markup
TabAtkins: Before grid, was for flexbox
hober: Basically grid or flex
rachelandrew: Weird flex but okay
rachelandrew: so would want to use it there
rachelandrew: to get rid of things like box around fieldset, etc.
rachelandrew: once a11y issues are solved
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
jensimmons: Maybe 'display: contents' was the wrong solution, too
general
jensimmons: what we wanted was subgrid
jensimmons: now we've eliminated the box, and dealing with fallout
jensimmons: but there wasn't a good reason to eliminate the box,
except lack of flexbox
TabAtkins: Well, in flexbox, still want to be able to reorder things
dbaron: If you want the box back, you have to figure out where the
box is
dbaron: By eliminating box, don't have to define where box is
dbaron: you make the element disappear so you can deal with the
children individually
dbaron: so layout hasn't assigned a position for it, so can't draw
the box if you don't know where it is
TabAtkins: So if shadow-including parent is 'display: contents' but
should have an outline drawn on it, draw on children
instead
AmeliaBR: How does that definition work if you have 'display:
contents' inside 'display: contents', how do we propagate
this?
emilio: Recursive
emilio: not a big deal
emilio: but if should have an outline at paint time, that's vague
emilio: Has to count for visibility, bunch of other stuff
heycam: Accounting for visibility is annoying
heycam: ...
AmeliaBR: You can have a focusable element with visibility :hidden
and some children that are visible
AmeliaBR: don't see an outline
<una> Test case to play with (nested display:contents) forked from
Rachel's pen: https://codepen.io/una/pen/joRMEL
* leaverou is actually surprised visibility: hidden; has an effect
on display: contents; elements
myles: Why don't we apply this logic to other CSS properties?
myles: I don't think that's a road we want to go down
astearns: When parent has visibility: hidden?
florian: If you have 'display: contents; visibility: hidden' can you
focus it?
AmeliaBR: Most browsers won't focus such a thing
fremy: We draw it in Edge...
astearns: Does sound like model-breaking behavior
astearns: Defining whether box can be focusable based on CSS
properties we should ignore
fremy: If you're visibility: hidden, you cannot be focused anyway
fremy: So this issue isn't relevant
astearns: Two options I've heard
astearns: 1) Don't draw an outline. Stylesheet can try to style
children or something
astearns: 2) Have UA figure out something to do with 'display:
contents' things that should have an outline
astearns: We have one possible definition of how that could occur
astearns: I'm unclear as to whether there's enough motivation to
figure out UA magic to get this done
AmeliaBR: I prefer solution that requires authors to do less
a11y-aware work, since lots of authors won't bother
fremy: Also government requirements, so browsers should do it by
default
astearns: Cameron, do we need to evaluate conditions for outlining?
heycam: I don't know, if you had opacity: 0...
AmeliaBR: Then you wouldn't see it on the children either
TabAtkins: Aside from "don't draw this element", won't get focus
outline
dbaron: But if you're display: contents, opacity has no effect
florian: Painting outlines on elements not in rendering tree
florian: Usually you don't iterate over tree to paint an element
florian: This is not the case for focus, you don't have to evaluate
the entire tree to find focus
florian: We know if a focused element is focused
AmeliaBR: Much more narrow case
dbaron: There's another option along those lines, which is to say
... maybe you can't do that because selector-property
dependency
dbaron: Was going to say was if you're display: contents and you're
focused, focus-visible applies to descendants but can't do
that
fantasai: I think what heycam said was the simplest solution
emilio: I still think they're hacks
emilio: It's not impossible, just feels like a layering violation
florian: iank, you were saying it's hard?
iank: I believe our focus outlines get painted differently from
normal ones
florian: What would be hard about normal ones
iank: Don't have anything to hook up to invalidation logic
iank: We'd need to introduce this backing to layout tree
fremy: The children draw the outline, so children invalidation
florian: but if you change the property on the parent, you need to
know that the children have to be invalidated
emilio: It's a hack
heycam: We'd have to propagate a change hint to the children. Not
impossible.
emilio: Nothing is impossible
heycam: Sure, but also doesn't seem too hard
astearns: It is slightly better to introduce hack into UA than to
expect authors to have the same hack in their CSS
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
emilio: Whether propagating outline and someone mentioned browsers
don't focus visibility hidden elements even if you have
visible children
florian: Because you can't focus them
emilio: Link with 'display: contents' we say has to be focused
emilio: but link with 'visibility: hidden' we don't focus, and it's
OK
TabAtkins: I consider it a bug. That I don't care about.
florian: ...
TabAtkins: Nobody has brought up that as a problem in the 20+ yrs
TabAtkins: Whereas within 6 months we had bugs filed against
'display: contents' for not being focusable
<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
leaverou: If we draw outlines on children, might be confusing if
only one child that is also focusable
leaverou: There would be no visible difference
fantasai: There's already no difference if you have an unstyled box
wrapped around a child
fantasai: the outlines will look the same
fantasai: It's not a new problem. Whether the box is unstyled with
no pbm, or it's display:contents, it makes no visible
difference whether the outline is on the parent or child
AmeliaBR: Comes down to a design issue
florian: Back to earlier point, difficulty in invalidation logic
florian: you could reduce to focus case
fantasai: I think that's harder
emilio: Think it's harder for us
emilio: First one you would implement display: contents with outline
changed, go down the tree and invalidate other elements
inside it
emilio: but in the other case would also need to evaluate focus.
More special-case-y
iank: Can't speak with authority for us
iank: The thing that scares me is potentially if outline is painted
by the children, how do you make sure the outline is contiguous
florian: You don't
florian: You just make it on the children and whatever
fremy: That's the proposal
florian: If you're existing logic merges outlines, then do that.
Otherwise don't
emilio: That's not quite similar
emilio: You also have to check outline on parent vs child
emilio: If have different outline properties...
AmeliaBR: What if say children treated as have 'outline: inherit'
fremy: Just check if 'outline-style' is 'none', and if parent's
'display: contents' draw parent's outline
dbaron: Or draw two outlines?
dbaron: And don't worry about those conditions?
una: I think it's more confusing to have simultaneous outlines
una: if you're tabbing into the children ...
fantasai: Only draw the outline if it's specified
fantasai: If you happen to specify 3 outlines on the 3 different
elements, you'd draw all of them
fantasai: might just be drawing because one is focused, because
you've got outline specified, ...
fantasai: Not dissimilar to how you handle borders for example,
layer them all and paint them
fantasai: if they fall on top of each other, you won't see the ones
underneath
dbaron: In the normal case for focus, if you have a box 'display:
contents' with three children
dbaron: You tab to parent, you see all three outlined, and then each
one outlined individually as you tab through them
florian: Don't see how to do better than that, the children could be
anywhere not necessarily adjacent
fremy: We're defining a default.
fremy: Not preventing authors from doing better
fremy: Just saying by default, we show an outline
fremy: Not required to be pretty. Pretty would be great, but people
already change outlines on focus all the time
fremy: to make it prettier
fremy: But by default we want there to be an outline so it will be
accessible
fremy: doesn't have to be pretty
emilio: It's still a hack
fremy: The goal is everybody at least gets an outline to show the
focus
fremy: if someone doesn't like it, you can refine it
fremy: Not prevent that, but at least provide something that works
florian: If outlines that are drawn for non-focused elements are not
drawn, that's OK
florian: But for focus case should do it
AmeliaBR: So UA must propagate outline if it was caused by a focus
change, but?
florian: Either do it always, or do it only for focus-triggered
outlines, whichever is easier to implement
fremy: My guess is display: contents is much harder to implement
than what we are discussing now
fremy: we're just going the last mile to make it great
AmeliaBR: Can we make a tentative resolution that we will at least
support the a11y use case and ask implementers to give
feedback on which would be easier to implement:
special-case for focus, or any outline?
emilio: display:contents make sense conceptually, this thing we are
discussing makes no sense
emilio: It's a hack
emilio: In any browser implementing it's a hack
fremy: Users > web authors > implementers
emilio: I won't oppose but I will be very upset to implement this
TabAtkins: Make heycam do it :)
astearns: So deciding whether to draw only for focus?
Rossen: At least
<TabAtkins> I don't disagree that it's a hack.
<TabAtkins> It's just a necessary hack for a11y.
<una> When authors use hacks, its our responsibility to make that
experience more accessible
<rachelandrew> CSS is making people sad again.
bkardell: Are we positive you need to be able to set focus on
display: contents element?
TabAtkins: Yes
TabAtkins: because there are use cases to display: contents a link,
and you need to be able to activate the link if you're a
keyboard user
TabAtkins: And when focusing you need to be able to see that it's
focused
bkardell: Can we just say you can't display: contents a link?
florian: There are use cases for it, though
<TabAtkins> Yes, that's valid markup.
<AmeliaBR> Real world example: `<article class="slide"><a href="..."
style="display: contents"><h2>article title</h2><img
src="thumbnail"/></a><p>description</p></article>`
<AmeliaBR> (where the slide has flex or grid layout)
[AmeliaBR describes her use case]
AmeliaBR: Want to lay out this article as three separate items in
your layout
AmeliaBR: When someone tabs to that link, want to be able to see
something is focus
<emilio> AmeliaBR: why not making the link the flex container?
<TabAtkins> <a> is allowed to wrap things as a block. Changed in
HTML several years ago.
* fantasai approves of that change, seems useful
<una> Amelia's example: https://codepen.io/una/pen/ZNZprm
<AmeliaBR> Una 👍
[florian gives a use case for page numbers or something]
iank: I'll have to check with implementers. I will project their
sadness.
* emilio thinks AmeliaBR's example would work just fine with the
link being a regular block
<AmeliaBR> emilio: not if you want the things inside and outside the
link to be equal children in a grid or flex layout
astearns: So proposed resolution is we paint outlines on the
children of a display: contents element
florian: ... special-case focus?
fantasai: I'm pretty sure it's easier to not special-case.
iank: Unsure
astearns: OK, but this is the case we want to support for a11y
TabAtkins: You can come back and say "no, it's really too hard"
TabAtkins: I don't want us to give up just because it's a little not
great so we made it inaccessible
astearns: So any objection to make this change and get implementer
feedback
RESOLVED: Outline of 'display: contents' is propagated to children
for painting (for a11y on focus); implementers should give
feedback on it
Meeting closed.
Received on Saturday, 6 July 2019 20:58:06 UTC