W3C home > Mailing lists > Public > www-style@w3.org > March 2022

[CSSWG] Minutes Telecon 2022-03-16 [css-color] [css-color-adjust] [css-syntax] [css-text] [css-flexbox] [css-pseudo]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 16 Mar 2022 19:05:53 -0400
Message-ID: <CADhPm3t4rLWVCD5Ma+ZSMfwfCNJJ2o=cYwYuHegEPbCZJihqSw@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 Color & Color Adjust
------------------------

  - After last week's conversation on issue #6773 (Make system colors
      fully resolve (but flag they were system colors) thus reversing
      the resolution of #3847), several people reread the original
      issue and conversation and contributed additional thoughts on
      github. There is still disagreement between what authors expect
      and what might be the best behavior for users so discussion will
      return to github.

CSS Syntax
----------

  - RESOLVED: Use HTML restrictions for custom idents (Issue #7129:
              Custom property names too permissive, require namespacing
              rules)
  - RESOLVED: Illegal characters in an ident can be escaped (Issue
              #7129)
  - RESOLVED: Invalid ident characters are treated as DELIM tokens
              (Issue #7129)

CSS Text
--------

  - RESOLVED: Republish css-text level 4 (Issue #6900: Republishing CSS
              Text 4)

CSS Flexbox
-----------

  - TabAtkins and fantasai will review the issue reported on issue
      #6777 (Column wrap intrinsic size algorithm can make inline
      min-content > max-content) and add comments or proposed changes
      to the issue.

CSS Pseudo
----------

  - There were interesting use cases for issue #6641 (Custom properties
      on :root) as well as good arguments against special casing.
      Discussion will continue on the issue to formulate a concrete
      proposal.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2022Mar/0005.html

Present:
  Rachel Andrew
  Adam Argyle
  Rossen Atanassov
  Tab Atkins Bittner
  David Baron
  Mike Bremford
  Oriol Brufau
  Tantek Çelik
  Emilio Cobos Álvarez
  Elika Etemad
  Robert Flack
  Simon Fraser
  David Grogan
  Jonathan Kew
  Rune Lillesveen
  Chris Lilley
  Peter Linss
  Alison Maher
  Ben Mathwig
  Morgan Reschenberg
  Jen Simmons
  Alan Stearns
  Miriam Suzanne

Regrets:
  Lea Verou

Scribe: dbaron

Admin/Future Meetings
=====================

  Rossen: We're due for a long call at some point soon, agenda
          accumulating. Maybe longer.
  Rossen: Based on poll about TPAC from last week, seems like folks are
          ready for a hybrid face-to-face. So perhaps should think if
          we want to host a face-to-face this coming summer.
  Rossen: Could be similar location to TPAC, that location seemed
          favorable. Don't want to have conversation now. Think about
          it.
  Rossen: TAG is going to have a 2-places-in-world face-to-face meeting
          in person next week, we'll see how it works.
  <miriam> 🥳

  Rossen: Also, a quick congrats to folks involved with layers and
          seeing them shipped across all major engines. Remember
          presentation from Miriam and Jen a few years ago in Spain.
          Big accomplishment going this quickly from idea to
          shipping... now we just need to go to REC. Interested in tips/
          learnings from your experience.

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

Make system colors fully resolve (but flag they were system colors)
    thus reversing the resolution of #3847
-------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6773

  fantasai: We delayed this to give me a chance to reread the whole
            conversation... which I did. What I understand about this
            issue is that it was raised because switching color scheme
            shouldn't cause system colors to change when they're
            inherited. I think behavior of having system colors switch
            along with color scheme makes sense. Why would you switch
            color scheme if you're not changing colors?
  fantasai: Then an argument that making forced-color-adjust: none with
            18 different combinations of colors is unwieldy. I'd take
            that as "too hard to implement".
  fantasai: Then there were arguments about resolving system colors at
            used value time: (1) makes some transitions issues go away
            and (2) setting forced-color-adjust:none on subtree reverts
            to colors that author specified. If we take this change
            then forced-colors would work only on non-inherited colors.
            That could cause contrast problems.
  fantasai: There's arguments in both directions.

  emilio: There's another argument for ... color-scheme doesn't behave
          like you want it to behave. But regarding
          forced-color-adjust:none, that seems like a better behavior.
          At least, we were proposing adding a new value just to do the
          thing you get when you resolve system colors at computed
          value time. We were planning to make that default in SVG,
          which is the obvious place to use forced-color-adjust:none.
          So I'm not sure the behavior for forced-color-adjust:none
          with used value time forcing is better.

  <fantasai> https://github.com/w3c/csswg-drafts/issues/6773#issuecomment-1069295596
  TabAtkins: In first part of fantasai's response, fantasai argues
             against inheriting a color not respecting a color scheme.
             I think you should reconsider. I switched to emilio's
             viewport because if an inherited system color respects a
             change in color scheme... this leads to the a11y problem
             of text color and background color not being set as a
             pair. If background is transparent... will be bad when you
             use your text color with other background color.
  TabAtkins: If you use the system colors explicitly, inherited text
             will by default wrong if it respects color scheme changes.
             I think that's a mistake.

  fantasai: The color-scheme doesn't switch at a boundary randomly...
            the author has to explicitly say they're switching the
            color scheme. Why are they changing it if they're not
            making other color changes too? I'd expect author to use
            these things in coordination.
  <tantek> +1 fantasai
  <Rossen> fantasai, what about tools? F12 is supporting forced-colors
           effect for debugging/testing
  fantasai: On the flip side, forced-color-adjust: none problem: if you
            have a subtree where you want the colors to be the ones I
            specified and you set forced-color-adjust:none, and the
            browser only turns off forced-color-adjust for some of your
            colors, that's not expected behavior. You tried to turn it
            off and it doesn't turn it off. (You might not notice
            depending on your colors.)
  fantasai: I think the difference here is there's no good use case for
            an author setting color scheme and not setting other
            colors, but there are reasons the author should expect that
            setting forced-color-adjust:none actually turns it off.
  fantasai: I think contrast issue you're concerned about is ???
  TabAtkins: I think you're off... when author sets
             forced-color-adjust.. ??? ... either author is setting
             some colors and letting others through which violates a11y
             guidelines, or they're setting all the colors and it
             doesn't matter.
  fantasai: They know what color is inheriting through.
  TabAtkins: There's no guarantee they know what the colors are from
             the outside, if forced-color is happening, or if they're
             distributing a component.
  TabAtkins: So the inherited color is potentially a mystery. They're
             potentially mixing it with known colors (bad), or
             overriding all. I think people still do the bad case, and
             we should give a more-likely-accessible result.
  <fantasai> Plenty of authors write pages where they set the
             background on lots of elements, but only set the text
             color on the root
  <fantasai> This is normal and expected, and it's not a problem.
  <TabAtkins> (This convo did happen in the issue, we're re-arguing it.)
  <fantasai> But it *is* a problem if you set `forced-color-adjust:
             none` on an element.
  <fantasai> because the color you've inherited is no longer the one
             you expected.

  Rossen: Sounds like we're probably not ready to resolve, but let's
          hear from fantasai and emilio.
  emilio: [we can hear him but he can't hear us]
  fantasai: It's normal and common for authors to set text colors on
            root element, and set background colors on other elements
            without resetting the text color. There's no problem with
            it, because you know what color is inherited because you
            control the whole page. This doesn't hold for components,
            but not all pages are component-based.

  emilio: So I was going to argue the same thing as TabAtkins... that
          doing it at computed value causes contrast issues by default.
          Specifying color-scheme may not end up in a color scheme
          change... may specify normal. It's not clear that authors
          will realize their colors are wrong.
  <TabAtkins> Right, even in color-scheme changes authors can't
              necessarily predict the color that they'll receive. So
              no, this is bad *even in an entirely first-party
              situation*.
  Rossen: Continue discussion in github issue, bring back for
          resolution next week.
  <tantek> +1 Rossen

CSS Syntax
==========
  scribe: fantasai

Custom property names too permissive, require namespacing rules
---------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/7129

  TabAtkins: i18n WG raised issue about custom idents, which allow any
             Unicode codepoint above a certain codepoint
  TabAtkins: There are some concerns about e.g. bidi characters
             corrupting the display of the code
  TabAtkins: Also argument for consistency in what characters allowed
             across languages
  TabAtkins: JS follows UAX?? rules for characters allowed in idents
  TabAtkins: HTML allows a different but largely compatible range of
             characters
  TabAtkins: In one of my Tweets, I showed off using weird Unicode rules
  TabAtkins: e.g. different emoji are valid or invalid
  TabAtkins: I agree with i18n feedback, reasonable to partially
             restrict these
  TabAtkins: e.g. no reason to allow bidi override chars in CSS idents
  TabAtkins: so I suggest adopting either HTML rules or JS rules
  TabAtkins: Don't have a strong opinion on which to go for
  TabAtkins: Otherwise I'd go with HTML rules by default

  fantasai: I think this is fairly reasonable, but I don't know the
            differences between the rules so I don't have an opinion on
            those yet
  TabAtkins: JS rules are a bit more strict, they disallow chars that
             look like punctuation
  TabAtkins: HTML gives exact codepoint ranges
  TabAtkins: Reason I'd go with HTML is to guarantee being able to
             write selectors for custom elements, without ever having
             to escape
  fantasai: That sounds reasonable, let's go with that
  Rossen: Makes sense, any downsides to it?
  TabAtkins: Any change to make more restrictive, could potentially
             make some stylesheets invalid
  TabAtkins: Potentially breaking code that works
  Rossen: And with HTML rules we'd have fewer breakage
  Rossen: seems like path of least destruction
  Rossen: Anyone would like to argue against the change entirely?
  Rossen: If not any objections?
  Rossen: Taking the silence as a no

  RESOLVED: Use HTML restrictions for custom idents

  TabAtkins: Got 2 sub-issues
  TabAtkins: One is whether to allow illegal characters to be escaped
             in an identifier
  TabAtkins: JS doesn't allow that, you can escape for readability but
             not to avoid the identifier restrictions
  TabAtkins: but CSS has traditionally always allowed escapes for
             everything, so don't see a strong reason to disallow
  TabAtkins: So I would prefer to go with illegal chars can be escaped
  <faceless> +1 from us too
  fantasai: I strongly agree with that
  Rossen: Any objections for allowing illegal characters to be escaped
          in an ident?

  RESOLVED: illegal characters in an ident can be escaped

  <dbaron> That doesn't allow nulls in idents, does it?

  TabAtkins: Next question is how do we handle the illegal characters
  TabAtkins: Do we censor them into e.g. U+FFFD
  TabAtkins: or drop them entirely?
  TabAtkins: I'd prefer to drop them, because it would more clearly
             result in invalid code
  TabAtkins: so if we allow to work but censored it wouldn't prevent
             use in source text, which was the goal of i18n
  TabAtkins: so would prefer to exclude from the ident production
  <fantasai> +1
  <tantek> +1 TabAtkins
  Rossen: [missed]
  TabAtkins: No, would not be changing existing rules for censoring
             rules. Currently lone surrogates etc. do that
  TabAtkins: Those are in there for UTF-8 well-formedness and C
             compatibility
  TabAtkins: They have a reason to be censored out at technical low
             level
  TabAtkins: these restrictions are for human reasons, so would
             restrict differently

  fantasai: So should we resolve that they would make the production
            invalid? (That's what was proposed right?)
  TabAtkins: Yes
  <TabAtkins> --(╯°□°)╯
  TabAtkins: if you put this ^ as a custom property name, the degree
             sign is not a valid character
  TabAtkins: so it would make an ident, a delim, a parenthesis, and
             a ???
  TabAtkins: That's definitely not an ident, because it's multiple
             tokens not an ident token
  * fantasai didn't quite catch that, what is the degree sign
             considered now?
  <TabAtkins> the degree sign isn't a valid ident char under the HTML
              rules, so this would produce an ident, a delim containing
              the degree sign, an ident, a delim, and finally an ident

  <bmathwig> Is there a practical use case for doing something like
             that? Seems more like a developer having fun rather than
             good quality code.

  TabAtkins: Proposed resolution is that it would break into multiple
             tokens
  fantasai: What kind of token are these invalid characters going to be?
  TabAtkins: DELIMs, one codepoint at a time
  TabAtkins: Characters without a specific role are generally handled
             as DELIM
  TabAtkins: and we only use certain DELIMs in certain places

  RESOLVED: Invalid ident characters are treated as DELIM tokens

CSS Text 4
==========
  scribe: emilio

Republishing CSS Text 4
-----------------------
  github: https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-1064818560

  fantasai: Proposal is to republish css-text level 4
  fantasai: Changes are that I merged css-text 3 and I added percentage
            values to letter-spacing and word-spacing that we resolved
            on 4 years ago
  Rossen: Any reason not to do it?
  fantasai: Don't think so

  RESOLVED: Republish css-text level 4

CSS Flexbox
===========

Column wrap intrinsic size algorithm can make inline min-content >
    max-content
------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6777

  dgrogan: So... background is that all engines have shipped the same
           intrinsic sizing algo for years
  dgrogan: but the algorithm is bad
  dgrogan: fantasai specified a new one in 2015 but nobody implemented
           it
  dgrogan: Authors really want it
  dgrogan: but there's a big compat risk here
  dgrogan: but we want to ship it along everyone else so that authors
           just fix sites once
  dgrogan: We started implementing it and found this issue where min
           can be > max
  dgrogan: Details are in the issue, there's a few possible things we
           can do
  dgrogan: One is flooring max to min
  dgrogan: or in this case making min the max content

  fantasai: I'm really excited you're working on this
  dgrogan: Yeah authors really want this and current algorithm is bad
  TabAtkins: I see the problem, not sure what the best solution is but
             that's wrong
  TabAtkins: fantasai and me will review asap

  iank: We might be testing the new thing in our canary channels and be
        more concrete about the compat risks
  iank: We might have to go back for the old thing if we get tons of
        reports
  iank: We might also want to do this incrementally, first for
        single-row flexboxes and so on

CSS Pseudo
==========

Custom properties on :root
--------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6641

  delan: There's a lot of content out there where a bunch of custom
         properties are specified on the :root
  delan: Historically that's been fine for highlight pseudos because
         they inherited from the element
  delan: As spec'd now each highlight pseudo has a separate inheritance
         tree so it'll break that pattern
  delan: So there's a compat issue in that but I don't think that's a
         huge issue because we've determined that some breakage is
         acceptable for these highlight pseudo
  delan: but there's two complications for this, one is that authors at
         least they'd have to switch their stylesheets to `:root,
         :root::selection, delan:` etc
  <TabAtkins> :root, :root::selection, :root::highlight, ... { /* set
              up all the custom props here */ }
  delan: It's also a bit of a performance issue because we might end up
         with a bunch of property blobs
  delan: There's another option which is using `@property` with an
         initial value
  delan: It's a lot more verbose and it should work
  delan: I guess question is "is that good enough"? Or can we simplify
         it somehow for authors?

  fantasai: Wondering about two things we could possibly do. One of
            them is making highlights inherit from the root by default
  fantasai: which might be a reasonable thing to do?
  fantasai: Or specifying that variables are special and they inherit
            from the originating element
  <fantasai> probably can't inherit from :root for all properties, but
             for variables might be OK
  delan: I think the first idea seems cleaner
  delan: I worry if there are any unintended side-effects
  fantasai: I think the idea is "if you're on the root selection" the
            variable properties would inherit from the root to
            `:root::selection`
  fantasai: I wonder if we want to make this work for every element

  TabAtkins: Inheriting from originating element appeals, but assuming
             we want to inherit from a single place could address a
             larger concern
  TabAtkins: ....
  TabAtkins: Argument for root, animations can play into that don't
             want to play into other places in the tree
  TabAtkins: Few other suggestions, but if we are going to inherit all
             the highlights from a single place should do in a way that
             addresses larger concern
  TabAtkins: either use initial value from register Properties
  TabAtkins: or a more ergonomic way to set initial values that doesn't
             have animations apply to it

  emilio: Want to point out that ::backdrop has the same issue,
          ::backdrop doesn't inherit from :root
  emilio: It hasn't come up often, but it has come up sometimes
  emilio: I would rather avoid inheriting from multiple places, because
          that's messy
  emilio: very special-casy
  emilio: We do something like that for ::first-line, and it's a
          massive pain. Don't wish that to anyone
  <TabAtkins> like `@root { /* only custom props here */ }`

  Rossen: Where do we go from here?
  delan: Agree with emilio in general
  delan: I think especially highlight inheritance, but a lot about
         highlight pseudos, is full of special cases
  delan: Would prefer to avoid adding more
  delan: So maybe it's fine?
  delan: Tab does have an interesting point though, that there's a
         general problem to be solved. Not sure
  Rossen: I'm a bit lost on where we're going from here. What would you
          like to see, delan?
  delan: Leaving aside the more general issue of how we can use
         variables in non-element contexts
  delan: for the core issue, I think consensus was that the best
         workaround so far is using custom property registrations with
         initial values
  delan: I guess the question I'm unsure about is do we think that is
         too annoying and unergonomic? No one had an opinion on that in
         the thread
  delan: do we think that's already too annoying?
  <emilio> having an `@root` or `@document {}` rule that applies to the
           whole document makes sense to me fwiw
  Rossen: for developers?
  delan: Yeah
  TabAtkins: Lea expresses that she find that's too unergonomic to be
             worthwhile and would prefer something else here
  <TabAtkins> Also I'm not 100% sure off the top of my head how
              @property interacts with being nested in @media and
              @supports.
  <TabAtkins> (to be fair, both of these require waiting for support.
              but this is simpler than @property, yeah)

  argyle: I have lots of experience with custom properties, and it's
          very tedious to ...
  argyle: I have a library called openprops with 350 properties
  argyle: I'm not going to hand-author 300 @property rules so that they
          can drop into highlight pseudos
  argyle: so some kind of higher level place to find these would be
          great
  argyle: Would be annoying to convert all my simple props and waiting
          for browsers to even support that

  emilio: Mentioned on IRC, but having @document or @root or whatever
          to apply properties to the initial style makes a lot of sense
  fantasai: one advantage of inheriting from their originating element
            is that if you need to set variables deeper in the tree you
            can do that
  fantasai: and then they'd behave as you expect, you might need to
            change your ::selection rules a bit
  emilio: That was the thing I was thinking about. From an author's
          perspective, what you want is inheriting from originating
          element
  emilio: Higher-level thing works for some cases, but might also be
          more confusing
  <TabAtkins> I think we'd define @document in cascade?
  <fantasai> Tab, but it wouldn't inherit that's the problem

  Rossen: Sounds like we need more discussion, suggest we take it back
          to the issue
  Rossen: Maybe you all can start formalizing the various ideas, would
          be great
  Rossen: and maybe next time we can be closer to a resolution
  <argyle> 👍🏻
  delan: Sounds good

  Rossen: Everyone please have a thought about potential F2F, and we'll
          talk again next week
Received on Wednesday, 16 March 2022 23:07:35 UTC

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