W3C home > Mailing lists > Public > www-style@w3.org > July 2019

[CSSWG] Minutes Toronto F2F 2019-06-04 Part IV: CSS Multicol, CSS Sizing, CSS Display and UI [css-multicol] [css-sizing] [css-display] [css-ui]

From: Dael Jackson <daelcss@gmail.com>
Date: Sat, 6 Jul 2019 16:57:12 -0400
Message-ID: <CADhPm3vXYo75FsEmR3bQ1=0arBk_z78CEouS+5=fk0Q1FOQwxA@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Saturday, 6 July 2019 20:58:06 UTC