[CSSWG] Minutes Telecon 2023-09-06 [css-color] [css-syntax] [css-pseudo] [css-contain]

  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

  - There was a new proposal for addressing issue #9166
      (`contrast-color()` MVP in Level 5) which was designed as an in
      between option for the existing proposals which gives browsers
      some room to experiment toward an algorithm while giving authors
  - Some concern was expressed that this new proposal will cause
      browsers to diverge their results so far that authors are unhappy
      or be so restricting that the browsers will only use white/black.
  - In order to have this proposal work as an experiment toward an
      algorithm, it needs to be there from the beginning so it's a
      default behavior which is what we'd want an algorithm to be if
      it's successfully developed.

  - RESOLVED: Function returns dark/light by default and the 'max'
              keyword for black/white (Issue #9166: `contrast-color()`
              MVP in Level 5)

CSS Syntax

  - RESOLVED: Don't add to CSS right now due to lack of use cases/user
              voices to add it (Issue #9293: Numeric separators)

CSS Pseudo

  - RESOLVED: Disallow the use inside container blocks (Issue #9280:
              Support for highlight pseudos declarations inside
              @container media queries)

CSS Contain

  - RESOLVED: Change the line about selection to link to the selection
              API instead of highlight pseudo element (Issue #9277:
              Should CSS highlights make content relevant to the user?)


Agenda: https://lists.w3.org/Archives/Public/www-style/2023Sep/0003.html

  Rossen Atanassov
  Tab Atkins-Bittner
  Stephen Chenney
  Elika Etemad
  Simon Fraser
  Daniel Holbert
  Dael Jackson
  Ian Kilpatrick
  Vladimir Levin
  Eric Meyer
  ChangSeok Oh
  Florian Rivoal
  Alan Stearns
  Lea Verou

  Oriol Brufau
  Robert Flack
  Chris Harrelson
  Jonathan Kew
  David Leininger
  Chris Lilley
  Miriam Suzanne
  Bramus Van Damme
  Sebastian Zartner

Chair: Rossen

Scribe: dael

  Rossen: I had one topic to cover before we get going
  Rossen: Do we have any additional changes to the agenda?
  iank: oriol mentioned on the list he'd like to be present for the
        Contain issue
  TabAtkins: I guess that would mean pushing to next week since this is
             not Europe friendly
  Rossen: I can do that. Anything else?

CSS Color

`contrast-color()` MVP in Level 5
  github: https://github.com/w3c/csswg-drafts/issues/9166#issuecomment-1688124086

  lea: Last week we decided we do want to add to spec contract-color
       for most common use case. Getting a suitable text color for
       arbitrary background color. Question is should UA return only
       white/black and make their own algorithm. Or return color is up
       to UA and the UA returns something guaranteed to be readable
  lea: Argument from Nicole is that leaves more room to UAs for
       innovation. Sometimes max contrast is not as readable for
       everyone. Some people tend to prefer lower contrast
  <TabAtkins> I can represent Nicole/Chrome on this issue
  lea: Argument for black/white it's more predictable so authors can
       use more reliably. Also it guarantees it's more likely to be
       readable. Also because it's either black or white authors can
       add shadow, etc. as an ingredient to do what they want
  lea: More versatile, more predictable.
  lea: We started expressing opinions last time but ran out of time.
       And TabAtkins requested an extra week to discuss in Google
  Rossen: fantasai, anything you want to add?
  fantasai: I'm pretty closely matched to Lea

  TabAtkins: We had a discussion. Me, Nicole, some of the canvas
             implementors. New proposal which is essentially the
             preference from Lea but with a bit of flexibility. You
             give an input, get an output that's very light or very
             dark. Within some delta-e distance of white/black.
             Something that allows a little bit of play but still very
  TabAtkins: Also with a keyword switch, proposing 'max', that locks
             you into black or white so you can get predictable output
  TabAtkins: I think this maintains the nice benefits of pure black/
             white but also allows some additional quality for browsers
             without distinct differences we were worried about
  TabAtkins: I think this should still be okay. And can allow just
             black/white if implementors want simple

  <lea> though it should be <color> || max? I think
  <TabAtkins> not too stressed on the ordering, i think our previous
              grammars did put the <color> first to make things
              slightly more consistent/parseable
  <TabAtkins> `<color> && max?`

  florian: I'm glad I let TabAtkins go first. Was in favor of just
           black/white. A little concerned if there's something smarter
           people will use it in interesting ways and someone will have
           to reverse engineer to match. But maybe if you limit the
           delta it won't happen too much
  florian: Perhaps reverse risk where some browsers aren't smart and
           authors don't bother specifying max before applying effects,
           and then the browser(s) that were trying to be smart might
           need to revert to pure black and pure white, but then we're
           not worse off than where we started. Not entirely sure it's
           worth it, but you seem to think it would be

  lea: I like new proposal. Authors can get black/white with max
       keyword, but if they want something just looking nice they can
       get that. I think it should be possible to put values in either
  Rossen: [reads IRC on syntax]
  Rossen: Seems like new proposal from TabAtkins is winning solution
          here. Other opinions?
  TabAtkins: I propose lea and chris tell us the reasonable variation
  <astearns> I am skeptical there are quality-of-implementation tweaks
             that will make this switch worth it (I expect you would
             need to know *what* the color will be used for to make
             effective tweaks). But I will not object.

  fantasai: Authors typically particular about hue and less about
            brightness. If you end up with navy blue text on cream
            would author be happy? If Chrome gives navy blue but Safari
            gives dark maroon and FF does charcoal gray, I feel like
            authors will be unhappy
  TabAtkins: Our hope is distance from black and white is small enough
             that you can't have enough variation to clash on the page.
             And if they are unhappy you can say max.
  fantasai: They may not be unhappy because looks good where they test
  TabAtkins: Our hope is with the maximum divergence all results should
             be generally acceptable
  fantasai: Let's say gray. People are sensitive to warm or cool. If
            some UA pick warm and some cool people will have
            sensitivity to what. What's benefit to allow gray be warmer
            or cooler? How far off can you be to get a benefit and no
  TabAtkins: Point is we want to experiment. We think this ability is
             valuable. There's a lot of work in experimentation and
             theory to figure out what's best. The hope is we
             eventually can write an algorithm. Hope is give authors
             something predictable for now that lets us play around to
             find the right spec
  fantasai: And you're arguing this should be default? We should create
            this difference in hue because that's a better default?
  TabAtkins: Yes. We believe the little bit of exploration will be
             acceptable as a default even if it's slightly different
             across browsers

  lea: At first I quite liked proposal, but thinking more one issue is
       that if one browser gives always black/white and other does dark/
       light then the authors that want dark/light can't do anything
       with the values
  lea: Even with relative color trying to think what math to use get
       light or dark on browsers that do black/white. I can do it with
       always black/white
  lea: Also, remember in graphic design more common to want white text
       on a bright color bg. If the color is so light it needs dark
       text it's more common to want not black. Current proposal
       doesn't let you distinguish and mix and match
  TabAtkins: White is a valid light color
  florian: But author can't ask for it
  lea: What I'm saying is I want white if it would work and a dark
       color instead of black. Can't spec that intent I don't know if
       that's as wide spread as I remember. No way to spec that
  TabAtkins: That can't be done in any syntax we discussed except
             listing explicit colors. Unless browser is smart enough to
  lea: If it returns white and black you can use max
  <lea> what I was referring to: lch(from var(--color)
        clamp(.2, l, 1) c h)

  florian: If as an author you want to manipulate you put in 'max'. If
           you want to tweak ask for the predictable thing
  florian: I'm skeptical that the distance from white/black is small
           enough to be useful but not so large it can be bad
  TabAtkins: We're hoping it's not. Remember the failure case if we're
             wrong is we change the default to black/white
  <astearns> +1 to florian's last point
  <fantasai> +1 to florian's point

  Rossen: I'd like to start getting to a resolution if we can
  fantasai: I have concerns about interop and suitability of automatic
            algorithm. I don't think it should be default, but I
            understand chrome has ideas to experiment. I don't think
            experiment is harmful if not shipping. I would prefer to
            spec black/white, add a note we're experimenting with other
            values, and let chrome experiment as a prototype
  fantasai: If they get buy-in from dev community that they want the
            new behavior we can move. I don't think I'd want to spec UA
            magic at this point
  TabAtkins: Issue with current channels is it's by definition people
             clued into the topic. If people are clued in they can do
             color manipulation on their own. We believe there is play
             to offer the general dev audience and there's not room in
             the channels we have for that
  florian: One of the downside of fantasai's comment is Chrome wants a
           signal from authors that will mess with colors that they're
           going to do that. If we do the way fantasai suggested we
           don't have that signal. But you can maybe look for authors
           doing more with it
  lea: I think what fantasai described makes sense. Worried about
       interop when leaving to UA. If Chrome experiments and gets
       results authors like we can add additional behavior for it.
  lea: and/or we can introduce additional assurances to make sure
       result is predictable. Has to maintain same hue or something,
       but reduces innovation. I don't know what experiments they have
       in mind
  TabAtkins: We don't know yet either. We'll play to see what gets good

  lea: Why not ship the simple version now, experiment, and add the new
       one later?
  TabAtkins: If it is something else it's by definition not going to be
             the first thing people reach for when they don't know what
             they want. The hop here is we can make the default good
             for people who just want a good text color. People who
             know color theory and want to play should be able to do
  TabAtkins: The goal here precludes a switch for later. If this will
             be worthwhile it needs to be a default
  Rossen: And TabAtkins what you're saying is the additive
          behavior...what's the difficulty there? If we resolve on
          black/white now and add the 'max' keyword to do more?
  TabAtkins: The 'max' keyword forces you into black and white. All
             other values will be slightly less contrast-y. Also, it's
             that if you don't know how colors work, which most people
             don't, you're not going to reach for an optional keyword?
  lea: Doesn't that depend on name?
  TabAtkins: All optional keywords are treated as less default
  fantasai: I see TabAtkins's point
  <lea> TabAtkins: yes, optional keywords are used less often; but my
        point was that whether authors that don't know about color
        theory reach for the keyword depends on the keyword name. Like,
        the keyword doesn't need to be worded in such a way that it
        depends on color theory

  schenney: florian made an excellent point. If you wish to experiment
            having the default be to play and the max keyword it makes
            it ridiculously easier to experiment. You get good signal.
            If you only have black/white it's very hard to infer what
            people want. For that reason the proposal from TabAtkins is
            best for a long term answer
  florian: I'm not too hot for the proposal, but there is a chance it's
           useful and low risk if we define the distance short enough.
           If it's too far we'll get feedback and maybe we end on
  <TabAtkins> yeah we're thinking that, like, an #eee or an #eef rather
              than a pure #fff, very short distance
  Rossen: Let's see if we can resolve on TabAtkins's proposal. Other

  fantasai: It may be nice to start with more restricted audience
            trials to see if you get answers in those environments
  Rossen: How does that change the proposal?
  fantasai: I think I would feel more positive about it if there were
            positive signals in a restricted community
  TabAtkins: We know for a fact that very often people reach for
             slightly off-white and off-black. That's from color design
             bible. Do #111 or #eee. That suggests we should be
             slightly off white/black for this. But it doesn't tell us
             exact value
  florian: Black and white are valid answers too if experiment isn't
           conclusive we can ship black/white
  <fantasai> those are both neutral grays...
  <fantasai> but ok
  lea: What TabAtkins is saying is true. It is common designers use
       off-white instead of white. Text size, font, weight, etc...the
       CSS function can't know it's context
  TabAtkins: A lot of these factors could be inferred
  lea: Are you suggesting we spec a color function that's different
       based on what property it's in? That's not how color functions
  TabAtkins: I'm saying it could and we'll figure out to what extent we
             may want them to differ
  <astearns> Returning a single non-b/w color based on the input color
             is one thing. Returning several different colors from one
             input color based on where the function is used is VERY
             different. You should make that explicit in the proposal
             if that is the case.
  <TabAtkins> When the output space is wide, the difference matters
              more. When the output space is a small radius around
              black/white, we believe it's probably fine.

  Rossen: We've talked for 30 minutes and I think we're starting to
          circle. We can try and resolve or go back to the issue to
          discuss more since this is a newer proposal.
  TabAtkins: The exact proposal is new, but we have been discussing
             this area since NY F2F
  lea: Agree. What about a straw poll?
  Rossen: What are the options?
  lea: 1. function returns black/white by default
  lea: 2. function returns dark/light by default and the 'max' keyword
       for black/white
  <fantasai> 0, defer to jensimmons who unfortunately isn't here...
  <schenney> 2
  <TabAtkins> 2
  <florian> 2 (not a very strong opinion)
  <iank> 2
  <astearns> 1
  <lea> 1
  <smfr_> 2
  <changseok> 1
  <vmpstr> 2
  <Rossen> 2
  <dholbert> abstain (no strong preference)
  <emeyer> Abstain

  <fantasai> Also! IIRC we'd resolved to require the "this is for text"
             vs "this is for background" keywords, is that being
  <lea> fantasai: not for the MVP
  <fantasai> lea, so which are we assuming? text or background?
  <lea> fantasai: provided color is bg
  <TabAtkins> input is background, output is text

  Rossen: We've got a clear signal for option 2
  Rossen: One of the things I didn't hear during discussion since this
          is a11y related- by returning black/white we are forcing more
          often higher contrast than user may prefer. Option 2
          addresses this well.
  Rossen: Objections to function returns dark/light by default and the
          'max' keyword for black/white

  RESOLVED: Function returns dark/light by default and the 'max'
            keyword for black/white

  [agenda wrangling]
  [waiting for Chris on #8543]

CSS Syntax

Numeric separators
  github: https://github.com/w3c/csswg-drafts/issues/9293

  TabAtkins: Raised the topic that JS allows _ for numeric separators
             for numeric literals. If you have a large number with many
             digits it's hard to read. Suggestion is add them to CSS
             syntax as well
  <iank> we can also change those units
  TabAtkins: I think this is safe to do. 1_000 is a dimension with
             value 1. We have a few places with _ prefix but it's not
             followed by digits. It's internal stuff.
  TabAtkins: Arguments against is not very valuable. Large and small
             numbers show up a lot in JS and precision is important.
             Much less the case in CSS. large numbers the important
             thing is they're big. Being able to tell a 6 vs 7 digit
             number apart for your page isn't common in practice.
  TabAtkins: Same with decimals. Pixels are limited to 1/64th or
             1/60th. Much less than JS precision.
  TabAtkins: Basic argument against is we just don't need it. I'm
             inclined to go no change due to low need. But I think it's
             safe if someone wants to have it and I'm happy to make the
  <iank> +1 to no change - doesn't seem super valuable.
  <astearns> +1 to no change
  <smfr> +1 to no change
  <iank> (unless strong desire from community)
  <fantasai> +1 to Tab's analysis
  Rossen: Proposal is raise awareness but don't add to CSS right now
          due to lack of use cases/user voices to add it
  <emeyer> +1 to no change (the only time I’ve ever seen long numbers
           is in z-index and precision wasn’t needed)
  Rossen: Objections to resolving no change?

  RESOLVED: Don't add to CSS right now due to lack of use cases/user
            voices to add it

CSS Pseudo

Support for highlight pseudos declarations inside @container
    media queries
  github: https://github.com/w3c/csswg-drafts/issues/9280

  Rossen: If we need emilio we may have to push
  schenney: I think that Emilio's comment was around impl complexity
  schenney: Question in my mind is do we want to support declaration of
            new highlight styles inside @container MQs. Different
            highlight if container has 200px vs 500px? I think not.
            Then crossed my mind do we want different highlight styles
            in any MQ?
  schenney: Particularly interested in use cases because I can't think
            of where you would change highlights beyond printing
  Rossen: Even for print I'm struggling to justify that.
  <fantasai> proposed resolution wfm
  schenney: Maybe if you're scaling font you want underlines to change,
            but that's covered in font units. Regardless of ease of
            implementation it requires a use case. I'd propose we do
            not allow new highlight styles to be defined
  Rossen: Sounds reasonable. Anyone have a use case?

  dholbert: You said no MQ or just container?
  <TabAtkins> I think MQ is too far, that's pretty static and widely
  schenney: I would be happy to exclude from all MQ. If that's too far
            we can resolve on Container and I'll follow-up with other
  <TabAtkins> I mean, just styling different colors into the highlights
              based on a MQ is important
  dholbert: I can imagine mobile for different highlights. Maybe
            prefers-contrast as well
  dholbert: Seems like there could be a case based on MQ. Restricting
            for container query seems reasonable

  Rossen: I'd argue for restricting for all and relax the restriction
          if a use case arises
  <emeyer> +1 to Rossen’s point
  schenney: Let's resolve on container queries. I can open a new issue
            on all MQ and I'll take the time to go through them all and
            think about it more
  Rossen: Yeah. I really wish we could resolve on all MQ. Let's not
          invent solutions for problems we don't have. There's already
          enough complexity. Unless there's a strong use case and I
          didn't hear any
  dholbert: I think reduce-contrast may want different colors
  TabAtkins: The MQ case to have different colors based on color scheme
             are removed from dynamic styles enough that it doesn't
             seem reasonable to cut them out. In very rare cases MQ
             should be disallowed on a CSS Feature
  Rossen: Okay. Proposal: Disallow the use inside container blocks. TBD
          on if further restrictions are needed
  schenney: I'll follow up with an issue to confirm on other cases
  Rossen: Objections?

  RESOLVED: Disallow the use inside container blocks

CSS Contain

Should CSS highlights make content relevant to the user?
  github: https://github.com/w3c/csswg-drafts/issues/9277

  vmpstr: In contain 2 spec we have text what 'relevant to the user'
          means. One point is if element or content is selected it's
          relevant and then links to a highlight pseudo
  vmpstr: I think that's misleading. Instead I think it should link to
          the selection API which goes into details on how a selection
          acts. I think it's more appropriate
  <TabAtkins> +1 to this
  <schenney> +1
  Rossen: Sounds reasonable
  Rossen: What do other folks think?

  schenney: Clarification: if there's target text it will be scrolled
            to and will open up? That's the only other pseudo that came
            to mind as potentially useful.
  schenney: If we have target-text from URL target is that considered
            user relevant already?
  vmpstr: Yeah, that should be. For content-visibility:auto where
          relevance matters the skipped contents are still available to
          features like tab order navigation and find in page.
  schenney: Okay, so I think we're good with the proposal
  Rossen: Other opinions?
  vmpstr: Proposal: Change the line about selection to link to the
          selection API instead of highlight pseudo element
  Rossen: Objections?

  RESOLVED: Change the line about selection to link to the selection
            API instead of highlight pseudo element

  Rossen: Thanks for calling in. Next week if TPAC. For those
          traveling, safe travels. For those being remote, please send
          requests for issues and time zones that we need to be aware
          of for agenda planning

Received on Thursday, 7 September 2023 22:43:40 UTC