W3C home > Mailing lists > Public > www-style@w3.org > August 2021

[CSSWG] Minutes Telecon 2021-08-11 [css-content] [css-transforms] [css-grid] [css-display-3]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 11 Aug 2021 18:39:01 -0400
Message-ID: <CADhPm3tihR2LRWdW=yvq1YiJKBgOKfW2LZqvw8CzOrqgXUzD3A@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 Content

  - RESOLVED: Spec content:none as having no effect on elements (Issue
              #6503: Implementing content:none on elements is not

CSS Transforms

  - RESOLVED: Add perspective(none) (Issue #6488: After #6320 there's
              no way to get an identity transform for interpolation of

Draft Server

  - The group is aware of the outages of the drafts server. There's a
      proposed solution and work is being done to find time/funding to
      implement it.

CSS Grid

  - RESOLVED: Clamp automatic minimum size of compressible elements,
              and the transferred size suggestion of non-compressible
              aspect-ratio elements (Issue #6278: Replaced elements
              canvas, img, etc should behave as expected when styled
              with relative sizes in grid, transferred size should not
              affect them unless specifically asked to)
  - RESOLVED: Close no change (Issue #5566: Resolution of percentage
              row tracks and gutters with indefinite height)

CSS Display

  - RESOLVED: Accept proposal (Issue #6123: For the Accessibility API
              visibility:visible within visibility:hidden is
      - Proposal:
          - Import 'visibility' from CSS2 to css-display-3 (since it is
              currently only defined in CSS2).
          - Define impact of visibility: hidden similar to display:
              contents (shouldn't strip necessary a11y information from
              the tree).
          - Add a warning to authors that marking a required structural
              parent box as invisible while descendants are visible
              (e.g. table-row invisible while table-cell is visible)
              can be problematic.


Agenda: https://lists.w3.org/Archives/Public/www-style/2021Aug/0003.html

  Adam Argyle
  Rossen Atanassov
  Tab Atkins-Bittner
  Tantek Çelik
  Emilio Cobos Álvarez
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Daniel Holbert
  Sanket Joshi
  Brad Kemper
  Jonathan Kew
  Vladimir Levin
  Daniel Libby
  Rune Lillesveen
  Ting-Yu Lin
  Peter Linss
  Jen Simmons
  Alan Stearns

  David Baron

Scribe: fantasai
Scribe's scribes: florian, Rossen

  Rossen: Any other items?
  plinss: Wanted to talk about draft server

CSS Content

Implementing content:none on elements is not web-compatible
  github: https://github.com/w3c/csswg-drafts/issues/6503

  emilio: We implemented it, broke tons of sites
  emilio: We should at least fix the spec to say that content:none has
          no effect on non-pseudo elements
  emilio: It's a bummer because 'content' does have effects on some
  emilio: We could add another value to the content property to
          represent that behavior
  Rossen: How broken?
  emilio: content:none suppresses boxes for children of element
  emilio: Sites were specifying it on a bunch of stuff using e.g.
          * { content:none; }
  emilio: Initial value is normal
  florian: I wouldn't have expected it to be Web-compatible, has been a
           no-op for a long time, so mistakenly applied in lots of

  emilio: Any objection to change the spec to match reality?
  emilio: Other question is should we add a new value

  fantasai: We should spec it
  fantasai: If we need a new keyword, I'd suggest "empty"
  fantasai: Not too sure what the use cases are though
  Rossen: Any other comments?

  emilio: Not sure we should even add the keyword, we implemented for
  <rachelandrew> it would be interesting to see if authors have use
  bradk: I think there could be some interesting cases for having the
         box but not its contents
  emilio: also interesting question about interaction with
  <TabAtkins> we can just leave the discussion out of this issue for
              now, and open a fresh issue arguing for adding this new
  <TabAtkins> no reason to tie it to this discussion
  <astearns> +1 to new issue for use cases
  bradk: maybe ask authors
  <emilio> +1
  Rossen: ok, let's deal with that in a separate issue

  RESOLVED: spec content:none as having no effect on elements

CSS Transforms

After #6320 there's no way to get an identity transform for
    interpolation of perspective
  github: https://github.com/w3c/csswg-drafts/issues/6488

  emilio: I wasn't on last week's call
  <astearns> we ran out of time last week to get to a resolution
  emilio: Seems fine to add a new value to represent this
  emilio: ...
  smfr: I'm ok with something like perspective(infinity)
  smfr: I do wonder about the lack of units, wonder if it adds
        complexity to animations and blending
  TabAtkins: Perspective is normalized to matrix, so shouldn't be a
  TabAtkins: Addition with infinity would swamp whatever value the
             other side was, so don't have to worry in that case either

  Rossen: Sounds like we're going forward with infinity?
  astearns: There was also the suggestion of perspective(none)
  TabAtkins: smfr brought up that animation-iteration-count uses
             'infinite' whereas calc() uses 'infinity', so 'none' would
             dodge the issue
  <jfkthame> +1 to perspective(none)
  Rossen: Is everyone ok with none?

  RESOLVED: Add perspective(none)

CSS Sizing

Compressible elements with aspect ratio
  github: https://github.com/w3c/csswg-drafts/issues/6341

  Rossen: Is this ready for discussion?
  <TabAtkins> ian added the agenda+ ^_^

Draft Server

  plinss: As many noticed, drafts server has been unreliable lately
  <TabAtkins> it is currently down, for example
  plinss: Fundamental issue is it puts a lot of load on database
  plinss: when get hit by ton of crawlers
  plinss: Fix is to make code less reliant on database, serve static
  plinss: Unfortunately it's 1-2 weeks of time for me
  plinss: which I can't take off from work
  plinss: If anyone wants to sponsor it, I can just do it
  plinss: Server also needs a bunch of other tuning, which is why
          estimating up to 2 weeks work
  plinss: Alternatively, look for a different solution
  plinss: but that would not have the same features as the draft
          server, e.g. regenerating to ensure cross-links continue to
  plinss: I would not be doing the alternative work. I would not
          recommend that.
  plinss: My recommendation is to just fix the infrastructure
  gsnedders: Alternative where any of us, not just plinss, can do
             maintenance might be better.
  plinss: Either way, someone else has to do the work
  plinss: Doesn't have to be done by me, I'm happy to give access to
          the current infrastructure
  plinss: Just I'm the most familiar with it, so can do it the fastest
  plinss: So looking for anyone to sponsor the work, or to take on the
          work for setting up alternatives
  <TabAtkins> yup, will look into this
  <florian> thanks plinss for running the infrastructure in the first

CSS Grid

Replaced elements canvas, img, etc should behave as expected when
    styled with relative sizes in grid, transferred size should not
    affect them unless specifically asked to
  github: https://github.com/w3c/csswg-drafts/issues/6278

  iank: There's concept of compressible elements, if you put a
        percentage width in one axis, it will compress to min-size
  iank: Chrome did a bunch of fixes in this area (replaced elements)
  iank: That brought our behavior more inline with the spec here
  iank: which applied an automatic minimum size in this case
  iank: Web author found this really surprising behavior, filed issue
  iank: Question is do we want to follow the spec, and if not, how do
        we match the author's expectation?
  iank: Firefox behaves as expected, because there is some behavior
        around transferred sizes that they still don't do correctly.

  <fantasai> https://github.com/w3c/csswg-drafts/issues/6278#issuecomment-863439988
  fantasai: Tab and I looked over this
  fantasai: Our conclusion is summarized in the issue
  fantasai: The author's expectation is reasonable in this case
  fantasai: Chrome and firefox used to match that, until chrome fixed
            to match the spec
  fantasai: [explains example]
  fantasai: 1fr has an auto min implied and that's what's causing the
  fantasai: The auto min size is supposed to be weaker constraint of
            specified height... and that's what's happening because the
            % isn't taking affect
  fantasai: the sln we are interested in is to make % resolve against
            min definite height. resolving against 0 is to clamp the
            min size. do it for compatible elements and potentially all
  <TabAtkins> Summary: During Grid layout, we first lay out to figure
              out row heights, then lay out given that height to figure
              out column widths (then maybe do both of those again). A
              1fr item size has an automatic minimum; during the first
              layout both dimensions are unknown so the auto-min
              doesn't trigger, but in the second layout there is a
              height so it *does* trigger, and this ends up giving us
              the bad behavior where the height is frozen as "large"
  <TabAtkins> But our intention was always that auto-min be a
              relatively weak constraint - it shouldn't be taken as
              gospel in the middle of this algo and have this effect.
  <TabAtkins> (because of the ordering of row vs height resolution,
              this behavior doesn't have a bad effect when the space is
              tall; it only makes the element too-large when the space
              is wide, which is an annoying discontinuity)

  fantasai: Did everyone follow, or should I explain something again?
  iank: I did :)
  iank: I'd be concerned about doing this for all elements
  iank: If we do, should only do for compressible elements
  Rossen: What's downside to doing it for all elements?
  iank: Currently, if you've got a non-replaced element with width:100%
  iank: that would change behavior pretty drastically
  fantasai: What if we only clamp the transferred size
  iank: so only things with aspect ratio ...
  iank: would need to think about that a bit more
  Rossen: can add aspect-ratio to anything, now, right?
  fantasai: 2 inputs into auto min size: content size in that axis, and
            for items with aspect ratio (previously only replaced
            elements), size transferred
  fantasai: Suggestion would be to make transferred size weaker than
            percentage size
  iank: There's a difference between spec and implementations atm with
        this stuff
  iank: Spec says to resolve lengths against zero, whereas
        implementations will actually ignore that length
  iank: Ignoring that difference, your suggestion and mine are
        effectively equivalent

scribe: emilio

  fantasai: No, because you are saying to do it only for compressible
            elements and I'm suggesting to do it for all elements with
  iank: If I change my suggestion then it agrees right?
  fantasai: [missed]. It'd be more consistent if we only clamp the
            transferred size. If we do clamp AMS if you have an
            aspect-ratio then it changes behavior
  iank: If a replaced element has an intrinsic size I don't think that
        we'll want to respect that in this case
  iank: If you have width 100%
  iank: That'd break the person's initial issue, the intrinsic size was
        actually quite large
  fantasai: In that case I wonder if that should depend on whether
            they're compressible. Clamp transferred size always, clamp
            content-based size if it's compressible
  iank: Why not do it for both then?
  fantasai: Mainly because it means that aspect-ratio affects sizing in
            an axis where it'd otherwise not have any effect
  fantasai: I don't have an objection but it's a bit weird
  fantasai: if you apply an aspect-ratio to a div where we apply the
            content size, then it'd suddenly clamp to zero

  Rossen: Can we go back to the previous proposal, to make it apply to
          all elements?
  Rossen: We can try to constrain later if we have strong reasons to
  fantasai: I think we may have problems if we try to apply to all
  Rossen: This is something we should be able to figure out quite
  iank: I think we can do the change for compressible and aspect-ratio
        elements quite easily. I need to think about non-replaced
        elements with aspect-ratio inside an auto-sized thing, dunno
        how to implement that yet
  Rossen: So, let's start with compressible, would that work?
  fantasai: I think my preferred suggestion would be all elements, but
            if we can't we should do it for compressible elements, do
            it for transferred and content size, and for aspect-ratio
            elements just the transferred size
  Rossen: Not opposed, but it's weird to make special elements more and
          more special, specially if the behavior is useful for all
  Rossen: so I'd prefer to pursue that if possible
  <tantek> +1 agreed with Rossen
  <tantek> and with that methodology in general
  fantasai: I'm fine with all elements, but if not I prefer the
            suggestion above, I think it's the closest

  Rossen: Can we resolve on all elements and if you come back with
          strong reasons why it doesn't work we can consider the other
  iank: When we say all elements we mean all elements with aspect-ratio?
  Rossen: we meant all elements
  iank: That's a very big change, I don't think that'd be ok
  fantasai: I'm also skeptical about that
  Rossen: So should we resolve on compressible elements + aspect-ratio?
  fantasai: [explains her suggestion again]
  Rossen: sounds reasonable, other comments / objections?
  proposal: clamp automatic minimum size of compressible elements, and
      the transferred size suggestion of non-compressible aspect-ratio
  <tantek> sounds reasonable to limit to those elements

  RESOLVED: Clamp automatic minimum size of compressible elements, and
            the transferred size suggestion of non-compressible
            aspect-ratio elements

  fantasai: Thanks everyone. That was a complicated issue, and I
            understood it better by talking it through with all of you.

Resolution of percentage row tracks and gutters with indefinite height
  github: https://github.com/w3c/csswg-drafts/issues/5566

  [ discussion of whether we have time for this issue ]
  Rossen: [ reads mrego's comment ]
  <fantasai> https://github.com/w3c/csswg-drafts/issues/5566#issuecomment-886483173
  Rossen: Would be nice to close the issue and move on, if we all
          already agree
  Rossen: Anyone object to closing the issue with no change?

  RESOLVED: Close no change

CSS Display

For the Accessibility API visibility:visible within visibility:hidden
    is problematic
  github: https://github.com/w3c/csswg-drafts/issues/6123

  TabAtkins: Some a11y folks brought up that the visibility property is
  TabAtkins: In particular, visibility:hidden on visibility:visible
  TabAtkins: Problem is invisible items gets stripped from a11y tree
  TabAtkins: Very similar to 'display:contents' a11y bug
  TabAtkins: Our proposal is to specify impact of 'visibility:hidden'
             as similar to 'display:contents'
  TabAtkins: with regards to a11y
  TabAtkins: To do that, pull visibility property definition from CSS2
             to css-display-3
  TabAtkins: and add a warning to authors that in special cases (like
             tables) can cause problems to have invisible ancestor of
             visible child
  TabAtkins: This proposal got a thumbs up from the original commenter
  florian: ...
  florian: Unlike table cell example, what if these hidden boxes have
           text content?
  florian: Do we retain the box but not the text, or what
  TabAtkins: Text isn't an issue here, because invisible to everyone
  TabAtkins: It's the implicit structural relationships that shouldn't
             get lost
  florian: So text shouldn't be in accessibility tree either, just the
           box structure
  TabAtkins: Yes

  Rossen: Referring to text inside cell made visible?
  TabAtkins: No, invisible text
  Rossen: So text inside of other cells
  florian: That, or if div with text in it that's hidden, and span
           that's visible
  florian: Do we hide all the text outside the span
  Rossen: Yes, this is expected behavior and implemented
  florian: Is it implementable
  fantasai: Shouldn't be any problem, text has its own boxes in

  Rossen: ...
  Rossen: Text for role/description can be taken from hidden areas, but
          that's a known pattern that works
  Rossen: Current implementations already support display of visible
          text inside of hidden elements
  Rossen: The issue is only when there's structure part of the
          invisible elements, then want to be able to recreate that
  Rossen: Tab, one question I have is
  Rossen: the use case here is very specific to when a table has
          visibility:hidden and cell is visibility:visible
  Rossen: Is the same behavior here, are we trying to specify same for
          table which is inside of visibility:hidden?
  TabAtkins: I don't believe the issue is specific to that
  TabAtkins: Applies the same if you visibility:hidden a link, and
             visibility:visible some contents of the link
  TabAtkins: We don't want that to strip the linkness of the text
             inside which is still visible
  Rossen: ok, didn't want to make it too specific
  fantasai: no, going to make it quite general
  Rossen: so expected behavior is to provide the structural role of the
          invisible ancestors of visible elements in the a11y tree
  TabAtkins: yes, same as display:contents
  <fantasai> proposal is
    - Import 'visibility' from CSS2 to css-display-3 (since it is
        currently only defined in CSS2).
    - Define impact of visibility: hidden similar to display: contents
        (shouldn't strip necessary a11y information from the tree).
    - Add a warning to authors that marking a required structural
        parent box as invisible while descendants are visible (e.g.
        table-row invisible while table-cell is visible) can be

  Rossen: Anything else?
  fantasai: We're pulling visibility propdef from CSS2 to css-display-3
            (not defined anywhere else than CSS2 atm)
  Rossen: Hearing no objections here

  RESOLVED: Accept proposal
Received on Wednesday, 11 August 2021 22:40:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:19 UTC