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

[CSSWG] Minutes Telecon 2021-06-09 [css-overflow-4] [css-color-adjust] [css-variables] [css-contain] [mediaqueries] [css-sizing]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 9 Jun 2021 15:03:48 -0400
Message-ID: <CADhPm3vOGR_BRy5UcnQzX8pT-pGVTapnpWHr02kP6YzSg=-A+w@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 Overflow 4
--------------

  - RESOLVED: Accept the edited changes as described by florian (Issue
      #4674: scrollbar-gutter is too complex)
      - Edits: https://drafts.csswg.org/css-overflow-4/#scrollbar-gutter-property
      - New appendix: https://drafts.csswg.org/css-overflow-4/#sbg-ext

CSS Color Adjust
----------------

  - RESOLVED: Accept changes and add only keyword (Issue #5089: Re-add
              only to mean "don't auto-adjust me", per WebKit's
              behavior)
  - RESOLVED: Add forced-color-adjust propagation to apply to root
              (Issue #6307: viewport propagation of forced-color-adjust)
  - RESOLVED: Add color-only value as described in the issue and
              clarified by TabAtkins (Issue #6310: Spec currently
              breaks use of currentColor for SVG icons in WHCM)

Variables
---------

  - RESOLVED: Accept the proposal [Add an exception to the general
              comma-omission rules] (Issue #6345: Whitespace-trimming
              and custom properties)

CSS Contain
-----------

  - RESOLVED: Add contain:paint to list of grouping properties (Issue
              #6202: Should it be possible for an element with
              contain:paint to be part of a transform-style:preserve-3d
              scene?)

Media Queries
-------------

  - RESOLVED: Adopt this media feature as a part of Media Queries
              (Issue #6343: Display mode media feature)

CSS Sizing
----------

  - A grid of possible cases will be added to issue #6341 (Compressible
      elements with aspect ratio) in order to clarify the expected
      behavior.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jun/0006.html

Present:
  Rachel Andrew
  Adam Argyle
  Rossen Atanassov
  Tab Atkins-Bittner
  David Baron
  Christian Biesinger
  Oriol Brufau
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Jonathan Kew
  Daniel Libby
  Rune Lillesveen
  Chris Lilley
  Ting-Yu Lin
  Peter Linss
  Alison Maher
  Tess O'Connor
  Morgan Reschenberg
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Miriam Suzanne
  Lea Verou

Regrets:
  Greg Whitworth

Scribe: dael

  Rossen: It is 2 minutes past the hour, let's get going
  Rossen: As usual, I wanted to ask for any extra agenda items or
          agenda changes we want to do
  Rossen: Let's assume there are none

CSS Overflow 4
==============

scrollbar-gutter is too complex
-------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4674

  Rossen: Update of the breakout that took place last week
  Rossen: It also had spec text added to capture what was decided and
          discussed
  Rossen: I wanted to give chrishtr or florian a few minutes to recap
          and then see if we need resolutions

  florian: We had a meeting for about an hour
  florian: Talked about scrollbar-gutter, figured out extent of use
           cases which are possible to address. Also focus on subset of
           values we can be sure are good to ship soon
  florian: Make sure we don't paint into a corner with incorrect subset
  florian: Stable is 'auto' and 'stable' values with a twist of making
           'stable' apply to overflow:hidden state as well
  florian: With that addition 'auto' and 'stable' are the core subset
           to serve the main use case
  florian: The 'both' value to apply to both sides is least
           controversial. Everything else has not been deleted but
           moved to non-normative appendix of things being explored.
  florian: No radical redesign to what has been moved. Discussion
           during the call could leave to radical changes, but not
           there yet. Just moved off.
  florian: One extra thing I did after the call is we had come
           complaints names were hard to figure out. I thought 'both'
           value was tricky. For now, named to 'mirror' to hopefully be
           more explicit
  florian: We can bikeshed if you don't like
  florian: Spec now includes overflow:hidden with 'stable'; 'both'
           renamed to 'mirror'. Everything still being discussed moved
           to appendix. Since remaining properties can only do anything
           to scroll containers applies to line has been changed from
           all elements to scroll container
  florian: When we extend to the cases in the appendix may that will
           relax but not defined narrow
  florian: All this is in place. If that sounds good we leave spec as
           if. If it doesn't we have to make changes
  <florian> https://drafts.csswg.org/css-overflow-4/#scrollbar-gutter-property
  florian: Main body of text ^
  <florian> https://drafts.csswg.org/css-overflow-4/#sbg-ext
  florian: Appendix ^
  Rossen: Thanks florian

  Rossen: Given the extensive changes and discussion during the
          breakout I wanted to ask if there were any comments at the
          moment. If not we can use summary and links to propose any
          changes and then come back to resolve next week
  <TabAtkins> +1 to the changes
  florian: I will do a bit of triage on the rest of the spec to see
           where we're at. If nothing blocking I may ask for a new WD
           which could be occasion to bless or reject
  chrishtr: I didn't fully understand Rossen; suggesting delay to next
            week for resolution?
  Rossen: Inviting people to engage in comment now or given extent of
          changes we can give it a week for review. Is there are reason
          we can't wait?
  chrishtr: Don't see reason to wait. It has been 2 weeks since
            breakout call
  Rossen: Trying to see if people have strong reasons to require the
          extra time
  chrishtr: If anyone has such a concern we can wait. It didn't
            anticipate one
  fremy: If everyone in call was fine with changes I think it will be
         okay. Would be great to know exact changes we will resolve on
  Rossen: That's my point, a lot of people missing on breakout call.
          They need full context before we can resolve. florian did a
          great job of summarizing, but it's not the details
  florian: Other option is assume it's fine and let people raise issues
           with no deadline on that

  Rossen: Back to the WG and everyone interested. Does anyone need
          extra time to review the changes reflected in the spec? Or
          are we fine accepting now?
  fremy: Would like to review, but fine to accept now and raise issues
         later
  Rossen: Okay. Anyone else?
  Rossen: Not hearing any strong reasons to delay the acceptance of the
          changes. Objections to accept the edited changes as described
          by florian ?

  RESOLVED: Accept the edited changes as described by florian

  Rossen: For those who need time to review, please open issues. And
          other part is naming of the new values which I'm sure we can
          come back to
  florian: A heads up that stuff in the appendix is expected to change.
           I have ideas, but it's explicitly marked as unstable and no
           one is trying to ship that part

CSS Color Adjust
================

Re-add only to mean "don't auto-adjust me", per WebKit's behavior
-----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5089

  <TabAtkins> https://drafts.csswg.org/css-color-adjust/#color-scheme-override
  TabAtkins: As discussed earlier we want to re-add auto to turn off
             auto adjustment. Means spec had to recognize auto
             adjustment. Edits are in and approved by smfr which is
             only browser currently doing auto adjusting.
  TabAtkins: If people are cool we can accept edits. Also happy to
             adjust if there are concerns
  <Rossen> https://github.com/w3c/csswg-drafts/issues/5089#issuecomment-844525850
  Rossen: Proposal ^
  <chrishtr> Looks good to me!
  TabAtkins: Yes, end of comment is what went into spec
  Rossen: Assuming people have been able to read, additional comments
          or objections to accept changes and add only keyword?

  RESOLVED: Accept changes and add only keyword

viewport propagation of forced-color-adjust
-------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6307

  alisonmaher: Currently propagating from root and body to viewport.
               Since we force colors at used value time we can get
               wrong if don't propagate forced-color-adjust to viewport
  alisonmaher: We previously resolved not to propagate any new
               properties from body to viewport but wondering if we
               should have an exception here so forced color does
               propagate when set on body
  TabAtkins: I see argument for it.
  TabAtkins: As not a direct implementer I can't say if it's cool to
             add one more to the list, but I can see why it's confusing
             to figure out when color comes off body
  Rossen: Effect of not doing it? You may have background of viewport
          that's different than forced?
  alisonmaher: Set forced-color-adjust to none and want background to
               be another color we would end up forcing the viewport
               background color because it's not none at viewport.
               Wouldn't get background color at the viewport

  fantasai: Two comments. Seems bad practice to set forced-color-adjust
            none on body. Seems a bit user hostile to say I don't care
            what you want
  fantasai: If concern is tweak color of background we have similar
            problem with color scheme. If we propagate one we should
            propagate both. Not sure we should; we should encourage
            people to set in html
  alisonmaher: If we were to do it for forced-color-adjust doing it for
               color-scheme would make sense as well
  futhark: I was thinking that is it really we should propagate the
           property to viewport and not we should take into account
           when propagating. When try and propagate background we look
           at display value and if it's display:none it's not
           propagate. Maybe similar
  alisonmaher: Yeah, when look at forced-color-adjust at used value
               time we could end up forcing the propagated value of
               viewport no matter what.
  Rossen: Are options to leave as-is and use this as a soft mechanism
          to discourage such usage patterns by authors? On the other
          hand we can still add that same question applies to do we add
          back color scheme to the list
  alisonmaher: Those are two options. One use case from author to set a
               background color for svg image which are similar to root
               and viewport propagate. To fix that we would need to
               propagate from root to viewport. Hoping can resolve on
               propagate from root. If doing for root might makes sense
               to do from body as well
  Rossen: Other opinions?
  fantasai: If we're doing from root make sense to do from body as well
            statement doesn't make sense. Have lot of properties that
            propagate from root but not body so don't think that holds
  alisonmaher: If feel we shouldn't do from body I'm okay with that.
               Root piece is major thing looking for. Can see author
               confusion but wouldn't object
  <emilio> +1 for doing it just for the root
  fantasai: A bunch of scrolling properties that don't propagate from
            body even though overflow does. We locked down to some css
            2 properties
  Rossen: Not hearing disagreement about root. Sounds reasonable.
          Conversation seems to support adding to root. For body we've
          been making steady attempts to min exposure that's propagated.
  Rossen: Sounds like current consensus is around adding to root but
          not body.
  alisonmaher: That works
  Rossen: Other thoughts?
  Rossen: Objections to adding forced-color-adjust propagation to apply
          to root

  RESOLVED: Add forced-color-adjust propagation to apply to root

  <oriol> Note in
https://github.com/w3c/csswg-drafts/issues/6079#issuecomment-816307011
          we resolved "No future properties should propagate from
          <body> to the ICB"

Spec currently breaks use of currentColor for SVG icons in WHCM
---------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6310

  alisonmaher: This is around handling currentColor. AmeliaBR noted
               that SVG icons will not inherit appropriate forced-color
               through currentColor.
  alisonmaher: 2 solutions. 1) undo the resolution to use forced colors
               at used value time. 2) introduce a color-only value that
               only adjusted color. Make that default for SVGs. Because
               color-only effects svg through currentColor works well
               for icon
  alisonmaher: Only possible unexpected is an svg ancestor set
               forced-color to none the svg would still set to
               currentColor. This seems rare so in favor of color-only.
               Looking for other opinions

  TabAtkins: Definitely need to fix this. Only consideration to fix
             issue you raised could the value act as none if inherited
             value is none but act as color if it's auto.
  TabAtkins: Then it still works as expected
  alisonmaher: Good idea. Will need to look into how to impl but could
               be good way to handle
  TabAtkins: Seems reasonable to add, I'm in favor
  Rossen: Proposal to fix the issue through a spec clarification and
          not adding color-only value?
  TabAtkins: No, still add value. The value acts as alisonmaher and
             AmeliaBR spec in auto case. If inherited is none it would
             act as none. It would automatically opt-out
  Rossen: I see
  Rossen: Other opinions or suggestions?
  Rossen: alisonmaher do you want a resolution now? Or do you prefer to
          go back and figure out if implementable?
  alisonmaher: Can resolve and come back if implementation is tricky.
               Seems adding color-only value we can resolve on
  Rossen: Objections to add color-only value as described in the issue
          and clarified by TabAtkins

  RESOLVED: Add color-only value as described in the issue and
            clarified by TabAtkins

Variables
=========

Whitespace-trimming and custom properties
-----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6345

  emilio: This one; we resolved a while ago on trimming whitespace from
          decorations. TabAtkins pointed out some examples invalid in
          impl should be valid.
  emilio: For system propagating fallback there's no trimming. Felt odd
          when impl that if you're using fallback in computed you get
          whitespace but if the fallback you have a variable it's
          stringed.
  emilio: Trimming whitespace from fallback functions would be
          simplest. I think in general makes sense
  Rossen: Feedback?

  TabAtkins: Yes, we absolutely should. That this doesn't work is
             accident of css rules for comma omission. You have to omit
             comma when not separating but this is the case where lack
             of a thing can be a thing. Need something in var to set
             the exception that you can set a comma
  emilio: fwiw it's very easy to impl
  <TabAtkins> `foo(--a,)` is currently syntacitcally invalid, and that
              is good for everything *but* `var()`

  Rossen: Other feedback? leaverou_ you're active in the issue.
          Anything to add?
  leaverou_: I added my thoughts to issue. I support that change
  Rossen: Objections to adding the spec proposal?

  RESOLVED: Accept the proposal

CSS Contain
===========

Should it be possible for an element with contain:paint to be part of
    a transform-style:preserve-3d scene?
---------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6202

  TabAtkins: The summary is when you have a preserve-3d transform
             nothing prevents a contain:paint participate in the 3d
             scene.
  TabAtkins: A bunch of properties restricted to force it to become
             flat so children are container
  TabAtkins: contain:paint should work the same
  <smfr> overflow does NOT create a graphical group
  TabAtkins: Spec also allows overflow:clip to have children leave
             element entirely and florian pointed out that doesn't make
             sense.
  TabAtkins: If we're having contain:paint to cause flattening we
             should have them both
  TabAtkins: Proposal: add contain:paint to list of grouping properties
             that force it to be flat. Remove clip value form
             exceptions so it also causes it to be flat

  smfr: I think this is right thing. I think contain:paint causes
        stacking but should flatten
  smfr: I think TabAtkins said non-visible overflow creates stacking?
  TabAtkins: Overflow:clip is on list of values that don't cause
             flattening. Feels weird. I think it should
  smfr: That's fine. I agree with proposal
  <chrishtr> agree that clip and contain:paint should cause flattening
  dbaron: I agree as well

  Rossen: Other feedback or objections?
  smfr: Proposal to make overflow:clip a grouping property.
        Implementing it creates stacking context?
  florian: Don't think so
  smfr: Think it does
  dbaron: We do have that grouping properties create stacking context.
          That said, I wrote a test a few weeks ago to see what
          browsers made group. Tested with transform flattening and
          mixed blend and got entirely different results in all
          browsers.
  dbaron: Given that I think we don't have a good sense of grouping
  smfr: Testing with opacity or filters might have given more consistent
  smfr: I don't want to separate grouping from stacking context. Would
        create complexity
  florian: I don't think the grouping are defined to create stacking
  dbaron: Don't have a spec for this. I did have understanding that the
          set of things grouping is subset of things that create
          stacking
  <dbaron> the test I'm talking about was
https://dbaron.org/css/test/2018/stacking-context-z-order

  TabAtkins: Happy to remove overflow:clip part and just do
             contain:paint
  smfr: contain:paint can imply overflow:clip. Would love overflow
        properties that create stacking, but that ship has sailed
  Rossen: TabAtkins just resolve on contain:paint and leave
          overflow:clip for now?
  TabAtkins: Yes
  Rossen: That's the proposal. thoughts or objections?
  florian: Thought; maybe misunderstanding. Seems it's not necessary
           for overflow:clip to flatten a 3d transform because can
           position in 3d model. If when it's time to paint the
           projection is outside area you paint you clip
  smfr: Please don't make clipping a thing we need in 3d scenes
  Rossen: Great conversation that should happen when additional
          investigation of overflow:clip takes place

  smfr: If we resolve on this do we need to resolve on if will-change
        contains side effects. From dbaron's chart it does not have
        stacking.
  TabAtkins: Can you open as separate issue?
  smfr: Yes
  <dbaron> I think will-change's definition is pretty clear about
           what's supposed to happen...
  Rossen: Not hearing objections to contain:paint

  RESOLVED: add contain:paint to list of grouping properties

  Rossen: Anything else on this?

Media Queries
=============

Display mode media feature
--------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6343

  florian: Media feature in a non Media Queries spec. Should it move?
  florian: Currently in App Manifest spec. Lets you tell if app is in
           full screen or normal context or if it has minimal UI
  florian: That exists. I think shipped in everything. I think we
           should adopt it
  TabAtkins: Since it's been shipped it's stable. Happy to pull in.
             Should at least mention, but I think we can pull in

  Rossen: florian have you been engaged with App Manifest team to make
          sure this is their intent?
  florian: Request is coming from them
  Rossen: Great
  Rossen: Objections to adopt this as a part of MQ?

  RESOLVED: adopt this as a part of MQ

CSS Sizing
==========

Removing intrinsic aspect-ratio from an image
---------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6257

  TabAtkins: This was agenda+ in an earlier week and discussed. Label
             wasn't removed. Was that intentional?
  TabAtkins: Still active discussion in issue. Wanted to make sure
             something to discuss here.
  dbaron: bot's rule is it only removes if there's a resolution
  Rossen: Right. Since not resolved it's been kept there. Happy to push
          it back to GH for discussion

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

  fantasai: iank noted we allow compressible to compress when have
            percent width or max width. We floor with explicit min size.
  fantasai: Suggested things with aspect-ratio might want to consider
            min in other dimension. aspect-ratio and a min height might
            want to floor compression of width
  fantasai: Wanted to ask WG if we want to spec that in Sizing 3. No
            one impl but iank wants to try
  iank: I think FF may impl it in some cases.

  Rossen: What is percent resolved in this case?
  fantasai: Case where they don't resolve. Want min content
            contribution of the item.
  fantasai: Usually we use natural size. When have percent width we
            allow compress to close to 0. Exists for compat
  Rossen: Want to resolve the min width calc base on min-height because
          we have aspect-ratio
  Rossen: And if min height is also percent?
  fantasai: Wouldn't transfer anything, I think
  Rossen: And we would favor over min-width that's spec
  fantasai: I think we would honor spec min-width
  fantasai: iank, what are your thoughts on that?
  iank: It would take the maximum if min width and height are spec and
        don't agree
  <iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9399
  iank: Percent would resolve if they can, similar to today. Can get
cases where percent height will resolve. Link to case^
  iank: You can see image is distorted. Doesn't have to be

  Rossen: My take is in general this make sense. Too many details. I
          think it would benefit if we tried to capture a short table
          of interaction and expected resolution
  Rossen: And expected values as to if percent or spec and which wins
  Rossen: Would this be something iank you want to take on?
  iank: I can create a simple table. Should be straight forward. Order
        already resolves percent if we can so straight forward
  Rossen: Cool. We can bring it next week and resolve

  Rossen: I'll give everyone some seconds back
  Rossen: We'll start from these issues next week
  Rossen: Thank you for calling. Have a great rest of your week
Received on Wednesday, 9 June 2021 19:05:28 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 9 June 2021 19:05:32 UTC