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

[CSSWG] Minutes Telecon 2022-06-15 [css-text-decor] [css-color]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 15 Jun 2022 18:33:21 -0400
Message-ID: <CADhPm3uwLoqpozsL5UcPB7bBAhNW0De34S59ZNvwQg6nSPHXBA@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 Text Decor

  - There were several images added to issue #7251 (Composition of
      Inset Shadows), but none of them were an exact match for
      fantasai's proposal. More images will be added and discussion
      will continue on GitHub

CSS Color

  - RESOLVED: Move color-contrast() to CSS Color Level 6 (Issue #7310:
              Is color-contrast() ready to ship?)
  - RESOLVED: color-mix() and gradient non-sRGB interpolation are
              "ready to ship", add to Snapshot 2022 (Issue #7310)
  - RESOLVED: color-mix() returns color() for sRGB mixes (Issue #6206:
              Clarify serialization of color-mix())
  - RESOLVED: Specified style maintains calculations, computed style
              computes everything as far as possible (but maintains
              currentColor's identity), resolved color resolves through
              to absolute color (Issue #6168: What should the behavior
              of the CSS Color 5 color functions be when passed
              'currentcolor' as <color>)


Agenda: https://lists.w3.org/Archives/Public/www-style/2022Jun/0009.html

  Adam Argyle
  David Baron
  Tantek Çelik
  Daniel Clark
  Emilio Cobos Álvarez
  Elika Etemad
  Robert Flack
  Simon Fraser
  Mason Freed
  Megan Gardner
  Chris Harrelson
  Brian Kardell
  Jonathan Kew
  Rune Lillesveen
  Chris Lilley
  Peter Linss
  Jen Simmons
  Miriam Suzanne
  Alan Stearns
  Bramus Van Damme
  Lea Verou

  Daniel Holbert

Scribe: fantasai

CSS Text Decor

Composition of Inset Shadows
  github: https://github.com/w3c/csswg-drafts/issues/7251

  astearns: Some additional discussion and a few attempts at mockups
  astearns: Trying to figure out what to do wrt text-shadow inset and
            text decorations
  Sebo: Discussing paint order and compositing fill/stroke/shadow
  Sebo: lot of discussion around that
  Sebo: My point of view was that composition should be done so that
        the inset shadow is between fill and stroke
  Sebo: but fantasai said that this could lead to some performance
        issues ...

  scribe: emilio

  fantasai: Not performance issue
  fantasai: One issues is that the stroke comes between the text and
            the text-decoration, so if you have a strike through you
            are going to stroke text then strike-through, so if you
            want to shadow between text and fill you are going to also
            need to shadow the text decoration
  fantasai: the point of shadows is to create an inset / outset effect
  fantasai: so you if you have text and decorations with their shadows
            it looks super weird
  fantasai: For text that's decorated makes more sense to shadow text +
            decoration at the same time
  fantasai: so you we can't shadow between fill and stroke
  fantasai: That is also an issue because if you don't strike together
            a semi-transparent shadow will look darker on the decoration

  smfr: For outset shadows I agree we want to composite + shade text
        and decoration together
  smfr: Does any of the illustrations in the example match what
        fantasai is proposing?
  fantasai: I don't think any of them are
  smfr: Can we get an illustration of what the behavior should be?
  <fantasai> https://github.com/w3c/csswg-drafts/issues/7251#issuecomment-1145287101
  fantasai: If we ignore the stroke on the second one that's the effect
            you'd get
  fantasai: If you consider the stroke because the text decoration has
            its own independent stroke, but the shadow effect in that
            comment is what you'd get
  smfr: So you want stroking behavior of first line and shadowing
        behavior of the second?
  fantasai: Yes
  <astearns> I think it would be weird to have a stroke on the
             decoration but no shadow cast by that stroke
  fantasai: I think most cases would have either stroke or text-decor
  fantasai: The top rendering doesn't quite work
  fantasai: You still have two things that are cut out but flat
  fantasai: The second one seems like you pushed the text into the
            canvas which is somewhat consistent with the effect
  fantasai: It's also consistent between inset and outset shadows
  fantasai: There's cases where drawing the inset shadow between fill/
            stroke looks better but the effect is that when you have
            decorations it'd look wrong
  smfr: If we stroke using top and shadow using the bottom one it's
        going to look very weird too
  fantasai: Let's say you have strokes that are similar color for
            shades of yellow/orange
  fantasai: You cut that out and shade it behind the canvas
  smfr: Maybe Sebo or fantasai can illustrate the behavior in a drawing
  smfr: if it's hard to do in a drawing tool it's possibly hard to do
        programmatically too
  astearns: Hard to do for me in a drawing tool doesn't mean hard to do
            in a drawing tool :)
  fantasai: We can try to work on that tomorrow
  astearns: Whenever we can have them it'd be great to have pictures of
            what fantasai is trying to express

  smfr: One more question and one more statement. Inset shadows are
        going to require masking on the text, so lots of texts with
        inset shadows are going to get pretty expensive
  smfr: and authors can have very small text with very large blur radius
  smfr: so not sure we need some limits here
  astearns: If you have a shadow with a big offset does it mean that
            the shadow appears in another line? That sounds tricky
  smfr: Potentially? Good point

CSS Color 5
  scribe: fantasai

Are these features ready to ship?: Is color-contrast() ready to ship?
  github: https://github.com/w3c/csswg-drafts/issues/7310

  <chris> We believe the color-contrast() function needs significant
          modification to make it future-compatible and to make it work
          as intended, and propose deferring this feature to CSS Color
          Level 6 so that we can work on it without holding back the
          rest of CSS Color 5.
  chris: Had a breakout about color-contrast(), partly prompted by an
         FO about using WCAG2.1's algorithm
  chris: That is known to give bad results frequently, particularly in
         dark mode
  chris: Figures of around 40% being wrong
  chris: There's work to develop a new one, but not ready, not
         normatively referenced in WCAG3
  chris: Also complaints about syntax and so on
  chris: On the one hand browsers have it working reliably, on the
         other hand it often gives the wrong answer
  chris: We don't want to ship something that is interoperable, but is
         harmful to the Web platform
  chris: So we want to shift this to the next level

  astearns: Any arguments for not deferring?
  lea: I completely agree with deferring it, unfortunately
  lea: one thing from breakout we wanted feedback from implementers
  lea: breakout was me, Chris, Adam, and fantasai
  lea: Would help if we could ship color-contrast() without a specified
       algorithm, could use the best available algorithm
  lea: We're concerned that implementers would be against doing
       something that changed over time

  <fantasai> https://github.com/w3c/csswg-drafts/issues/7361
  fantasai: If we went this route, could ship a subset of functionality
  fantasai: but need to make some syntactic changes to make
            future-compatible first
  astearns: I would worry slightly about defaulting to best available,
            and then people expecting current results, and then getting
            different results when have a better algorithm
  lea: Yes, that's the worry
  chris: Yes, concern that it will continue to do what it did earlier
  chris: Also the target contrast values have different meanings
         depending on the contrast algorithm
  chris: so I don't think it makes sense to use a mystery algorithm
         that works differently later on
  chris: It's not small progressive change, it's a major change
  smfr: I agree with those concerns
  smfr: also don't want push the burden of choosing algorithms to web

  fantasai: I think if we wanna push for something sooner we'd need to
            go for something very minimal
  fantasai: If it solves things like github labels or so then good, but
            everything else would need to be deferred
  fantasai: If that's something that people thing it's important
            (having black / white text) maybe we can have a very
            minimal function
  chris: Even "black or white on this color", WCAG 2.1 gets wrong
         substantially a lot of the time
  chris: I don't think it's worth doing

  jensimmons: It's very hard to teach authors that what they were doing
              with a thing earlier, and failing them, it's very hard to
              unteach that
  jensimmons: We might have a year of it working poorly, people say
              "this sucks, don't use it" for the next 5 years
  jensimmons: Super hard to get people to change their habits

  lea: I think the idea behind shipping minimal white/black is not that
       WCAG is good enough, but it is more likely to be able to
       change it
  lea: I think that was the thinking behind it
  fantasai: Yes, we would swap in better algorithm as soon as we have it
  astearns: Putting aside whether to do simple version at all, sounds
            like we generally agree that the more complex
            color-contrast() function needs to be deferred
  astearns: Can we resolve on that?

  RESOLVED: Move color-contrast() to CSS Color Level 6

  astearns: I think we could continue discussing possibility of smaller
            subset of functionality in an issue
  astearns: but might be better to continue work on the function that
            we want, and put that out as quickly as we can
  chris: Now that we've resolved that, my focus is on remaining bits in
         Interop 2022
  chris: color-mix(), interpolation, etc.
  chris: so let's move on to other issues

Clarify serialization of color-mix()
  github: https://github.com/w3c/csswg-drafts/issues/6206

  chris: Agreement in general, remaining issue is should things like
         hsl come out as themselves, come out as rgb, or use the
         color() function which retains more precision
  chris: Emilio said it would be harder to ship, but could see the
         value of it, so not sure where we are on that
  emilio: That's still my opinion
  emilio: Slight preference to serialize as input color
  chris: I can see arguments both ways
  chris: I have a slight preference for serializing as color()

  jensimmons: Any visual difference in the result?
  chris: There could be, but very slight
  chris: if only 8-bit, and do mix of a mix, lose some precision and
         could result in banding
  emilio: That's also an implementation detail
  emilio: No reason why colors can't be more precise than 8-bit
  chris: That's not what implementations do
  chris: Spec mandates are higher precision for newer color spaces
  chris: of course can implement at higher precision
  chris: but concerned we'll get some degradation
  jensimmons: Screens are getting better, and color precision going
              better, seems we should go with higher precision

  fantasai: Can be confusing to give two hsl colors and get a different
  fantasai: From the precision argument I don't see why we won't just
            encourage implementations to have more precision
  fantasai: I don't understand why you'd have different precision on
            color() vs rgb()
  chris: Not just giving two colors, you specified color space to mix
         in and you get back in that color space
  chris: Shouldn't be that surprising
  chris: wrt precision, implementations have been stuck on 8-bit for a
         long time
  chris: but we've also written for other color spaces need 10-bit or
         12-bit, or 16-bit for xyz
  chris: so implementations going into those color spaces need more
  chris: We did say that if you're giving a 0255 value in rgb you can
         get decimal places when you serialize
  chris: but saying hope that everyone upgrades from 8-bit... harder
         than requiring upgrade for new stuff

  emilio: I agree with fantasai
  emilio: We use 8-bit colors for space-efficiency
  emilio: so you can store an RGB color in one integer
  emilio: but if we need more precision for this feature, we can
  emilio: If we implement high-precision sRGB we would do it both for
          color() and rgb()
  emilio: There's no point in having two different representations for
          the same color space
  astearns: Just having higher precision for rgb() and color() wouldn't
            be sufficient, because color() can give you color spaces
            that are higher precision
  fantasai: If I mix 2 rgb colors in xyz space, do I get a color in rgb
            or xyz space?
  chris: xyz space
  fantasai: If I mix 2 rgb colors in rgb space, I get rgb space back
  chris: yes
  astearns: So that you can plug that function into another property
            and not lose precision
  fantasai: If color(rgb) has a particular precision, no reason for
            rgb() to have different precision

  emilio: ...
  emilio: Given you need to return a color in ?? color space, I don't
          think it we serialize as color() or rgb()
  emilio: maybe color() is more consistent with other color space
  emilio: I'd be fine serializing as color() if easier for e.g. WebKit,
          for us it would be the same

  astearns: I'm hearing a lot of, yeah, either way is fine I guess
  astearns: So should we pick serializing as a color() function?
  chris: You're going to get color() function anyway in any of the
         other color spaces
  chris: If you just happen to pick srgb, need to pick what to do there
  chris: imho more consistent to say get a color() function back
  astearns: So proposed resolution is to serialize as a color() function
  <chris> +1

  lea: It's not always [missed]
  lea: it's not always possible to serialize everything as color()
       function, there are functions only available in their own
       function e.g. lab() lch()
  chris: That's true, but you won't see them in rgb() form either
  lea: So does proposed resolution affect only mixing in rgb()?
  lea: because right now that is the only color available both in
       functional notation and a color() function, and these are
       distinct color formats
  lea: color() function has 10-bit and I think it can go beyond the 0-1
  lea: I'm not sure if browsers want to use 10-bit format every time
       someone mixes in sRGB
  lea: Want to get clarity if this resolution is only about sRGB or
       about every color space ... which is not even possible
  chris: If you choose to mix in sRGB then you'll get in sRGB color
  lea: So interpolation token in sRGB, then interpolation token
  lea: does the syntax allow both?
  lea: You specify which color space you interpolate is "in
       <colorspace>", in gradients or color-mix() or whatever
  lea: does that mean that "in rgb" is same as "in sRGB" ?
  chris: You can't say "in rgb"
  chris: We don't have a color space called "rgb"
  lea: Are you sure?
  chris: Yes
  <fantasai> -> https://www.w3.org/TR/css-color-4/

  emilio: Is there any good reason why lab colors can't be specified in
          color() notation?
  chris: Because color() started out as predefined rgb spaces
  chris: it's a lot shorter for lab/lch to have their own functions
  chris: We do have an open issue about throwing everything into
         color() function
  chris: but that would just take existing syntax and make it longer
  emilio: Benefit is that color-mix() would have consistent output

  jensimmons: Want to get through these issues so can start shipping
  astearns: Proposed resolution is that we serialize as a color()
            function for color-mix that is being mixed in rgb
  <lea> confirmed that there is no `in rgb`, only `in srgb`, yay
  lea: No rgb, only sRGB, so makes sense to return color()
  astearns: Any objections to this resolution?

  RESOLVED: color-mix() returns color() for sRGB mixes

What should the behavior of the CSS Color 5 color functions be when
    passed 'currentcolor' as <color>
  github: https://github.com/w3c/csswg-drafts/issues/6168

  chris: I think we solved this in the issue, iterated the text with
  emilio: For context with the group, it behaves like calc() - doesn't
          go away in specified style
  emilio: Goes away in computed style if possible, but preserves
  emilio: but this is only observable in typedOM because
          getComptedStyle returns resolved colors

  RESOLVED: Specified style maintains calculations, computed style
            computes everything as far as possible (but maintains
            currentColor's identity), resolved color resolves through
            to absolute color

  chris: I believe this also resolves item 5 on the agenda,

Are these features ready to ship?
  github: https://github.com/w3c/csswg-drafts/issues/7310

  chris: Would love to see the interpolation for gradients shipping,
         can we resolve and say it's ready to ship?
  chris: color-mix(), relative color syntax, and interpolation of
         gradients in non-RGB color spaces
  astearns: No more issues on color-mix()?
  chris: No
  astearns: relative color syntax?
  chris: No, and people liked it. I talked about it last week
  astearns: interpolation of gradients?
  chris: Uses the same syntax as color-mix(), "in colorspace"

  astearns: Any objections to marking these ready to go?
  emilio: So, color-mix() I'm fine saying current spec is shippable.
          We've gone through it a lot
  emilio: The gradient one is relatively straightforward, would love to
          sanity-check it but seems reasonable assuming interpolation
          token gets preserved everywhere and no fancy computed style
          shenanigans, just only affects rendering
  emilio: about relative color syntax, less enthusiastic because only
          one implementation
  emilio: and their implementation seems to have same interop concerns
          as color-mix() where we had differences between WebKit / gecko
  emilio: so not so sure about it ready to ship
  astearns: We should have a high bar to say ready to ship, regardless
            of where spec in the process
  [discussion about relative color syntax]
  emilio: Keep the token in specified and computed style, only affects
  emilio: If so, that seems reasonable
  <fantasai> +1
  emilio: I think straightforward enough, doesn't need super deep review
  emilio: relative color syntax is trickier
  chris: gradient is doing color-mix(), just doing it in all possible
         percentages. It's the same calculation
  emilio: Think it's probably fine. I would like more feedback on
          relative color syntax
  emilio: but gradient interpolation seems straightforward

  fantasai: Happy with emilio's proposal to resolve on color-mix() +
            gradients but not yet on relative colors
  astearns: declare color-mix() and non-rgb gradient interpolation as
            ready to ship
  astearns: objections?
  <chris> high five!

  RESOLVED: color-mix() and gradient non-sRGB interpolation are "ready
            to ship", add to Snapshot 2022


  astearns: Reminder that we have a scroll animation call tomorrow
Received on Wednesday, 15 June 2022 22:34:01 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 15 June 2022 22:34:02 UTC