- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 Jun 2022 18:33:21 -0400
- 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>)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Jun/0009.html
Present:
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
Regrets:
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
tool
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
sooner
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
authors
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
color
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
precision
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
increase
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
right?
chris: yes
[missed]
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
outputs?
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
range
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
space
lea: So interpolation token in sRGB, then interpolation token
interchangeable?
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
https://www.w3.org/TR/css-color-4/#color-interpolation-method
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
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
currentColor
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,
https://github.com/w3c/csswg-drafts/issues/7302
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
rendering
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
Reminders
=========
astearns: Reminder that we have a scroll animation call tomorrow
Received on Wednesday, 15 June 2022 22:34:01 UTC