Meeting minutes
<chris> https://
<chrishtr> Vote link for "isVisible" naming: https://
Composition of Inset Shadows
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
<astearns> github: https://
github: https://
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
<miriam> present_
Sebo: but fantasai said that this could lead to some perf issues ...
fantasai: not perf issue
<emilio> 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
<emilio> ... the point of shadows is to create an inset / outset effect
<emilio> ... so you if you have text and decorations with their shadows it looks super weird
<emilio> ... for text that's decorated makes more sense to shadow text + decoration at the same time
<emilio> ... so you we can't shadow between fill and stroke
<emilio> ... that is also an issue because if you don't strike together a semi-transparent shadow will look darker on the decoration
<emilio> smfr: for outset shadows I agree we want to composite + shade text and decoration together
<bradk> Issue link, please? Sorry, I arrived late
<emilio> ... does any of the illustrations in the example match what fantasai is proposing?
<bradk> Thanks
<emilio> fantasai: I don't think any of them are
<emilio> smfr: can we get an illustration of what the behavior should be?
https://
<emilio> fantasai: if we ignore the stroke on the second one that's the effect you'd get
<emilio> ... 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
<emilio> smfr: so you want stroking behavior of first line and shadowing behavior of the second?
<emilio> fantasai: yes
<astearns> I think it would be weird to have a stroke on the decoration but no shadow cast by that stroke
<emilio> fantasai: I think most cases would have either stroke or text-decor
<emilio> ... the top rendering doesn't quite work
<emilio> ... you still have two things that are cut out but flat
<emilio> ... the second one seems like you pushed the text into the canvas which is somewhat consistent with the effect
<emilio> ... it's also consistent between inset and outset shadows
<emilio> ... 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
<emilio> smfr: if we stroke using top and shadow using the bottom one it's going to look very weird too
<emilio> fantasai: let's say you have strokes that are similar color for shades of yellow/orange
<emilio> ... you cut that out and shade it behind the canvas
<emilio> smfr: maybe Sebo or fantasai can illustrate the behavior in a drawing tool
<emilio> ... if it's hard to do in a drawing tool it's possibly hard to do programmatically too
<emilio> astearns: hard to do for me in a drawing tool doesn't mean hard to do in a drawing tool :)
<emilio> fantasai: we can try to work on that tomorrow
<emilio> astearns: whenever we can have them it'd be great to have pictures of what fantasai is trying to express
<emilio> ... I'm having a hard time following
<emilio> smfr: one more q 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
<emilio> ... and authors can have very small text with very large blur radius
<emilio> ... so not sure we need some limits here
<emilio> astearns: if you have a shadow with a big offset does it mean that the shadow appears in another line? That sounds tricky
<emilio> smfr: potentially? Good point
Is color-contrast() ready to ship?
<emilio> github: https://
<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 give sthe 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: breakbout 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
https://
<argyle> this? https://
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 ppl 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
<emilio> fantasai: I think if we wanna push for something sooner we'd need to go for something very minimal
<emilio> ... if it solves things like github labels or so then good, but everything else would need to be deferred
<emilio> ... 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, ppl 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?
RESOLUTION: 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
[css-color-5] Clarify serialization of color-mix()
github: https://
<bradk> I just shared a rendering that I **think** is what fantasai was proposing
<bradk> Shared in WebEx
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
<bradk> Ok
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 degradataion
jensimmons: screens are getting better, and color precision going better, seems we should go with higher precision
<emilio> fantasai: can be confusing to give two hsl colors and get a different color
<emilio> ... from the precision argument I don't see why we won't just encourage implementations to have more precision
<Zakim> chris, you wanted to react to fantasai
<emilio> ... 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 htis 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 a nother 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 colorspace 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 gues
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
https://
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: no rgb, only sRGB, so makes sense to return color()
astearns: any objections to this resolution?
RESOLUTION: color-mix() returns color() for sRGB mixes
[css-color-5] What should the behavior of the CSS Color 5 color functions be when passed currentcolor as <color>
github: https://
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
RESOLUTION: 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,
Ready to Ship Color Stuff
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
github: https://
astearns: no more issues on color-mix()?
chris: no
astearns: relative color syntax?
chris: No, and ppl 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
emilio: I think straigthforward 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 straightforwad
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!
RESOLUTION: color-mix() and gradient interpolation are ready to ship
RESOLUTION: colr-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
Meeting closed.