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

[CSSWG] Minutes Telecon 2021-11-10 [css-syntax-3] [css-values-3] [css-cascade-4] [css-fonts-4] [css-lists] [mediaqueries] [css-position] [css-color-adjust] [css-color] [css-cascade]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 10 Nov 2021 19:32:31 -0500
Message-ID: <CADhPm3s2V6ysN6+PB48wQrNFbNnE5H3QjXm1Qhs=2wDxznsTCw@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.
=========================================


Syntax, Values, Cascade, and Fonts
----------------------------------

  - There are several people coordinating to review pull request #6175
      (Formalize fetching and resource timing reporting)

CSS Lists
---------

  - RESOLVED: Accept proposal (Issue #6797: Algorithm for initial
              counter value in reversed list should repeat the last
              increment instead of the 1st one)

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

  - There are several smaller questions that need to be resolved in
      order to address issue #6793 (Clarifications on
      [video-]dynamic-range MQs). There are editorial changes necessary
      to differentiate similar media queries. Additionally, there is
      clarification needed to state what the combo of UA and output
      device is intended to be a superset of the values. Last, there
      needs to be a better definition about what should be returned and
      when for video-dynamic-range. Discussion will continue on GitHub
      to develop proposed new text.

CSS Position
------------

  - The group will wait on Firefox to see if they can change their
      behavior before resolving on issue #6789 (Behaviour of
      semi-replaced elements)

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

  - The group will revisit issue #6773 (Consider reversing the
      resolution of #3847) once there is more implementation experience
      to indicate the right direction.

CSS Color
---------

  - RESOLVED: Move @color-profile and device-cmyk() to L5 (Issue #6765:
              Defer @color-profile to L5)
  - RESOLVED: Add srgb-linear color space (Issue #6087: Expose
              Linear-light sRGB as CSS syntax?)

CSS Cascade
-----------

  - RESOLVED: WG leans towards weak proximity at this time, and
              recommends this direction for prototyping to get more
              feedback (Issue #6790: Strong vs weak scoping proximity)

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2021Nov/0005.html

Present:
  Adam Argyle
  Rossen Atanassov
  Tab Atkins-Bittner
  David Baron
  Mike Bremford
  Oriol Brufau
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Brad Kemper
  Chris Lilley
  Peter Linss
  Alison Maher
  Morgan Reschenberg
  Jen Simmons
  Miriam Suzanne
  Lea Verou

Regrets:
  Jonathan Kew

Scribe: drott

Syntax, Values, Cascade, and Fonts
==================================

Formalize fetching and resource timing reporting
------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/pull/6715

  fantasai: Areas where we need to better integrate with the fetch spec
  fantasai: chris recently merged PR contributed by contributor
  fantasai: We need those to be reviewed - and ask to publish these
            changes

  iank: did these get reviewed by Anne or Dominic Denicola?
  TabAtkins: I did review it
  TabAtkins: Anne and Domenic coordinating on reviewing...
  <chris> Yeah I reviewed it too
  fantasai: If it sounds like it's been reviewed, then I'd suggest to
            accept the changes

CSS Lists
=========
  scribe: fantasai
  scribe's scribe: drott

Algorithm for initial counter value in reversed list should repeat the
    last increment instead of the 1st one
----------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6797

  oriol: Define reversed counters
  oriol: Either specify start explicitly or calculate automatically
  oriol: I think algorithm doesn't make sense
  oriol: If don't have any counter-set, some of the increments of the
         items for the counter
  oriol: but first increment is counted twice, not once
  oriol: and then sum is adjusted by -1 to get start value
  oriol: Counting the first increment twice, the reason might be
         otherwise last item will have value of ??
  oriol: but in case of -1, we want the last item to get a value of 1
  oriol: If all increments are the same
  oriol: when they are different, I think we should actually repeat the
         last increment
  oriol: I have some examples in the issue
  oriol: if list with all increments -1
  oriol: and take one item in middle of list to -2, this only affects
         preceding items
  oriol: but if we change first item, this will affect the value of the
         last item
  oriol: and modify all values in the list
  oriol: which seems unexpected
  oriol: Another issue with counter-set, you have some increment there
         and the with counter-set
  oriol: start without counter-set, and item with value 2
  oriol: and then we assign counter-set: 2
  oriol: This should have no effect
  oriol: Probably it's what the author expects
  oriol: with current spec this can have an effect
  oriol: in issue itself I proposed how to update the spec
  oriol: Also variant of spec text taking into account resolution from
         6738
  oriol: where we decided to skip elements that are hidden
  oriol: so only non-zero increments
  oriol: Mats said it makes sense
  oriol: and he already has an implementation
  oriol: so suggest to take this change

  Rossen: Sounds like a reasonable change, any others with an opposing
          opinion?
  [silence]
  <TabAtkins> +1 btw
  Rossen: objections?

  RESOLVED: Accept proposal

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

Clarifications on [video-]dynamic-range MQs
-------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6793

  florian: We have 2 MQ which are similar, dynamic-range and
           video-dynamic-range
  florian: 2 issues in 1 here
  florian: One is primarily editorial, doing poor job of explaining the
           difference between these two queries
  florian: Notion of video plane is fairly rare concept that relates to
           TVs and how they have unusual screen buffer impls that we
           can query separately
  <chris> +1 to that editorial clarification
  florian: Core question raised in this issue, besides clarification
  florian: is that we have 2 values: high and standard
  florian: You might assume, and this apparently is what Safari did,
           that any device will match standard and some will match high
           as well
  florian: this is not how currently specced, though
  florian: Devices expected to match one or the other
  florian: Not standard and high simultaneously
  florian: The query about color-gamut does behave differently, it has
           3 values
  florian: and these are additional, when you match broader gamut you
           also match narrower one
  florian: unclear what we should do here

  chris: I agree, media capability does the same thing, of using
         supersets
  chris: Overall I think it's a better model, think we can easily make
         spec say that
  chris: The reason to do it is that when we add super-high later on,
         we want it to be a superset that still passes high
  chris: so I think we should change the spec; not because it's what
         implemented, but because it makes more sense
  <chris> see also https://w3c.github.io/media-capabilities/#hdrmetadatatype

  dbaron: Wanted to add, think there's a 3rd issue
  dbaron: Currently wording in spec about combo of UA and output device
  dbaron: needs clarification what the UA part of it means
  dbaron: Definition of high says, combination of UA and output device
          fulfill all the following criteria
  dbaron: There are a number of people in the issue saying that the UA
          bit should be ignored, and should only be query about the
          output device
  dbaron: but if this is question of UA capability, which are you
          considering if UA can do for some things but not others
  dbaron: e.g. videos but not images, or ...
  florian: I suspect querying device and not UA is useless
  florian: because if the UA isn't able to access the capability, it's
           not helping you
  florian: but if capability varies within UA, that's a problem
  Rossen: Is one a superset of other? Is UA subset of device?
  dbaron: I wouldn't think of it that way
  florian: We're querying union of both
  florian: need both UA and device to be capable
  chris: Also, HDR capability can vary over time
  chris: high power usage
  chris: so off by default
  chris: so need to know that it can change
  chris: One, is the device capable of HDR mode, and then two, is it in
         that mode?
  chris: we are mixing those two up
  florian: We do

  fantasai: We should take a resolution to change the query to superset
            model
  fantasai: multiple things to be clarified
  fantasai: Let's ask editor to go back to the thread to work out
            results
  fantasai: A lot of the clarifications are straightforward
  fantasai: need a resolution to change the media queries
  florian: Don't quite agree, question of capability or in HDR mode
           currently
  florian: or videos vs images etc.
  florian: Not quite clarification, is change in functionality
  florian: Puzzle how to answer if we don't change the syntax
  florian: so can do things fantasai highlighted, but not enough to
           solve the issue

  chris: Media capabilities spec talks about capability, "can the
         device do it"
  chris: If we clarify that way, need the other query as well
  chris: The capability and concrete "am I in this mode" are separate
  florian: Is it expected to remain this way?
  chris: Especially for mobile, definite power drained
  chris: Can be switched automatically, doesn't require user action
  chris: but there needs to be a capability
  chris: and need to know which mode you're in
  fantasai: I think we should spec as being able to use the switch
  fantasai: from a media queries point of view, how are we styling the
            document - many of those questions on depend on current mode
  fantasai: [missed parts]
  florian: What do we do about if UA can do for images and video but
           not CSS colors?
  florian: or some other variation?
  florian: Should we consider the UA does or does not fulfill the
           criteria?
  florian: or do we think about query in a different way
  florian: I haven't thought about deeply, but maybe you would have
           high-dynamic-range: video | canvas | etc.
  florian: and would get something true if that specific thing is in
           HDR mode

  Rossen: Sounds like a conversation to continue in GH
  Rossen: and doesn't seem we're ready to resolve just yet
  Rossen: Propose we stop here, and then after working out proposal in
          issue, bring back and we'll record a resolution
  Rossen: but hopefully attracted some help on this issue

CSS Position
============

Behaviour of semi-replaced elements
-----------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6789

  iank: Bunch of history here
  iank: When we have width/height=auto
  iank: can either shrink-to-fit or stretch in that axis
  iank: in Grid Layout, most items will stretch except replaced elements
  iank: every layout mode make these decisions
  iank: semi-replaced element in block layout, flex, is shrink-to-fit
  iank: Question is about abspos semi-replaced element, say with
        inset: 0
  iank: Firefox stretches in block axis, shrink in inline
  iank: webkit stretch both axes
  iank: chrome ...
  iank: So what do we want to do here?
  iank: previously FF team strongly wanted shrink-to-fit here
  Rossen: anyone from FF?
  Rossen: Do we shrink-to-fit in both axes, or stretch in both axes, to
          make behavior symmetric and consistent
  dholbert: Don't have an answer atm, but will take a look

  <TabAtkins> As I said in the issue a few minutes ago, "every
              divergence that buttons make from a standard inline-block
              is unfortunate."
  <TabAtkins> Because it has been asserted quite confidently in the
              past by implementors that buttons were *not* replaced
              elements, and were fully described solely by inline-block
              behavior ^_^
  fantasai: TabAtkins and I figured that
  fantasai: since webkit implements stretch on both axis
  fantasai: that makes it web compatible
  fantasai: [missed] you can always get the other behavior by switching
            alignment
  TabAtkins: In the past, impl have said that buttons aren't replaced
             elements
  TabAtkins: and fully described by inline/block behavior, so the more
             we can make that true the better
  TabAtkins: Having them stretch by default would make them match
             non-replaced
  iank: I'm fine either way, but historically FF folks have been very
        strong in their opinion wrt shrink-to-fit
  Rossen: OK, let's give dholbert some time to look through it
  Rossen: if we can resolve on this later on in the call, great, if
          not, bring back next week

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

Consider reversing the resolution of #3847
------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6773

  emilio: We made system colors compute to themselves because wanted
          them to react to color-scheme
  emilio: but that's not behavior any agent has, and when you do that
          you get lacking contrast if color scheme changes but you
          didn't change the bgcolor
  emilio: Not quite clear to me what Blink is doing
  emilio: but, computing system colors to the keywords themselves also
          causes complexity
  emilio: With interpolation, issues open since we resolved that
  emilio: So can we undo that resolution?

  TabAtkins: A couple of points emilio made are present today regardless
  TabAtkins: e.g. complexity of interpolating color, currentColor
             resolves at used-value time
  TabAtkins: exact same case for system colors
  TabAtkins: Also has a point about needing to set system colors in
             pairs, and yes, you do, and spec says you should always do
             that
  TabAtkins: It's very easy to get messed up and have bad colors if you
             don't, in general
  TabAtkins: If we compute system colors and computed value time, then
             whenever color-scheme changes, in particular if you go
             across any embedding boundaries, shadow boundaries,
             they'll be messed up as well
  TabAtkins: They'll assume in light mode and responsibly use system
             colors, get wrong colors inheriting in
  TabAtkins: so I think the current specced behavior is the best
  TabAtkins: Chrome's behavior is weird and inconsistent right now, but
             once matches spec, I think it will be reasonable behavior
  TabAtkins: and won't save any complexity by changing it
  emilio: Not about setting colors in pairs, but about changing color
          scheme
  emilio: if ...
  emilio: if you make system colors compute to themselves,
          forced-color-adjust: preserve-parent-color is like forcing to
          resolve their values, which is pretty odd
  emilio: we're landing workarounds...
  emilio: I disagree that this doesn't introduce complexity
  emilio: preserve-parent-color is literally working around this
          behavior
  TabAtkins: preserve-parent-color is about forced-color-adjust, where
             we want SVG to be able to opt out of being forced-colored,
             but still be able to respond to system colors coming in
  TabAtkins: We have plenty of SVG in the wild that want to respond to
             outside color and set some of their own colors as well
  TabAtkins: to work in forced color mode, need some way to tell
             whether receiving system color vs other color
  emilio: Not true, FF behaves correctly right now [...]

  alisonmaher: preserve-parent-color was a workaround due to handling
               forced-colors mode, not about system colors computing to
               themselves
  emilio: To me, both are related. If don't preserve ??? then can't at
          used value time
  alisonmaher: In Chrome we do implement this workaround. We also
               haven't shipped system colors computing to themselves yet
  alisonmaher: Essentially piggybacking on top of, have an
               implementation where it computes to itself, so
               workaround with impl that hasn't shipped yet
  Rossen: So building on the capability but not exposed?
  alisonmaher: yeah
  emilio: We define system colors to compute to themselves
  emilio: you need to implement forced-colors at used value time and
          vice versa
  emilio: Complexity comes from making both forced colors and system
          colors compute at used value time
  fantasai: If we don't make the system colors compute to themselves
  fantasai: if you switch scheme, it won't have any effect - which is
            not expected
  emilio: Let's say have a dark background and background is Canvas
  emilio: If you just change color-scheme you get illegible text
  dbaron: If they don't compute to themselves, you run a restyle
  fantasai: If you have an element that is color-scheme dark, inside
            one with color-scheme light
  fantasai: are you going to have light or dark? or what's happening
            inside?
  fantasai: If you move it out, you'd expect it to stay on that
  fantasai: but it inherits different resolve colors depending on
            parent color scheme
  fantasai: to get colors you expect, you can't rely on system colors
            inheriting, have to re-declare them when declaring
            color-scheme

  <TabAtkins> From what I can tell, emilio, you're saying that if
              authors don't set colors in pairs, they can get bad
              results. Is that right?
  emilio: Need to restyle anyway, need to set at least the backgrounds,
          so can't rely on inheritance otherwise get broken behavior
  emilio: Always need to set in pairs, but even if you do, but if you
          change color-scheme without setting any color then behavior
          is broken if they compute to themselves
  emilio: because changing only foreground color and bg color doesn't
          change because not inherited
  <chris> "Authors may also use these keywords at any time, but should
          be careful to use the colors in matching
          background-foreground pairs to ensure appropriate contrast,
          as any particular contrast relationship across non-matching
          pairs (e.g. Canvas and ButtonText) is not guaranteed."
  <chris> https://drafts.csswg.org/css-color-4/#css-system-colors
  <chris> Also "The following system color pairings are expected to
          form legible background-foreground colors:"

  Rossen: Given the complexity of these different combinations and
          where Chromium implementation is, in its inconsistent state,
          I propose we continue to work on this issue in GH
  Rossen: and once more implementers as well as others have a stable
          conclusion, can bring it back for resolution
  Rossen: Going in circles here trying to define expected behaviors
  Rossen: as well as what everyone is talking about
  emilio: Yeah, agree, I think we're talking past each other a bit
  Rossen: ok, well thanks for opening issue
  Rossen: Let's move on to next issue

CSS Color
=========

Defer @color-profile to L5
--------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6765

  lea: Custom color spaces have not gotten same implementer interest of
       other features in L4
  lea: and complicate a lot of discussions due to custom color spaces
  lea: Also had some ideas that depend on L5 features
  lea: so suggestion is to defer to L5
  lea: but Tab raised that device-cmyl() depends on it
  lea: which is implemented only in print impls
  lea: Suggest is to also defer device-cmyk()
  TabAtkins: I agree with this, and there's a lot of interesting things
             to work on here
  TabAtkins: that could use time to bake without holding up L4
  chris: I also agree
  chris: Also have some feedback, have a descriptor called 'components'
         that doesn't appear to do anything because what it affects is
         in L5, so another reason to move
  Rossen: So proposed to move @color-profile and device-cmyk() to L5

  RESOLVED: Move @color-profile and device-cmyk() to L5

Expose Linear-light sRGB as CSS syntax?
---------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6087

  chris: Linear-light sRGB is sRGB without gamma function
  chris: already extended beyond 0 and 1
  chris: some hardware uses this to do HDR
  chris: used in WebGPU and Canvas
  chris: also SVG filters do all their work in this mode
  chris: We export the term for re-use, but don't expose it to authors
  chris: so question is do we want to do that
  smfr: WebKit supports adding this
  chris: Does anyone object?
  chris: Just notice that it has a much higher precision function than
         sRGB
  chris: so you will need a half-float to hold these values

  RESOLVED: Add srgb-linear color space

CSS Cascade
===========

Strong vs weak scoping proximity
--------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6790

  TabAtkins: Right now, scoping spec cascade-6 is intentionally
             ambiguous on exactly where scoping sits in cascade
  TabAtkins: offers two options: less strong that specificity (just
             stronger than order of appearance) and another that's
             stronger that specificity
  TabAtkins: Given it's currently ambiguous, makes difficult to do test
             implementation
  TabAtkins: Would like to do a test implementation, and prefer weak
             scoping
  TabAtkins: I've argued in the thread about why the weaker scoping is
             the better way to go, going for strong would be a mistake
             imho and make things less usable for authors
  TabAtkins: but for the moment, I think we should at least currently
             resolve to go with weak scoping
  TabAtkins: and revisit later
  TabAtkins: fantasai said in issue, she believes that related features
             have been released to make a decision
  TabAtkins: that would delay scoping feature by a year or two
  TabAtkins: and I don't think the input we'd get would be worth that
             level of delay

  fantasai: No problem if chrome wants to go ahead and do prototyping
            of weak scoping
  fantasai: Exactly how it works will be fundamental to how css is used
  fantasai: Need to be diligent and figuring it out
  fantasai: 6 months timeframe is reasonable for that
  fantasai: scoping feature is desired and useful
  <Rossen> +1 to fantasai point ^
  <TabAtkins> (I really, *strongly* think that going with "strong"
              scoping would be making a serious mess, but I argued that
              in volume in the thread already.)
  fantasai: More important to get it right, first time around - waiting
            6 months to a year is reasonable for the proportion of this
            feature
  fantasai: I suggest to resolve with something like: "the WG is
            leaning towards weak proximity and thinks it's the right
            way for prototyping"
  fantasai: but keep the issue open for discussion
  <miriam> +1

  RESOLVED: WG leans towards weak proximity at this time, and
            recommends this direction for prototyping to get more
            feedback
Received on Thursday, 11 November 2021 00:34:14 UTC

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