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
              web-compatible)

CSS Transforms
--------------

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

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
              problematic)
      - 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.

===== FULL MEETING MINUTES ======

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

Present:
  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

Regrets:
  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
          elements
  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
           places

  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
          completeness
  <rachelandrew> it would be interesting to see if authors have use
                 cases
  bradk: I think there could be some interesting cases for having the
         box but not its contents
  emilio: also interesting question about interaction with
          content-visibility:hidden
  <TabAtkins> we can just leave the discussion out of this issue for
              now, and open a fresh issue arguing for adding this new
              keyword
  <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
             problem
  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
          files
  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
          work
  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
            place

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)
        recently
  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
            breakage.
  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
            els
  <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
            aspect-ratio
  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
            elements
  Rossen: This is something we should be able to figure out quite
          quickly
  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
          elements
  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
          suggestion
  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
      elements
  <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
             tricky
  TabAtkins: In particular, visibility:hidden on visibility:visible
             ancestor
  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
            implementations

  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
https://github.com/w3c/csswg-drafts/issues/6123#issuecomment-893890561
  [
    - 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.
  ]

  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 : Wednesday, 11 August 2021 22:40:42 UTC