- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 7 Sep 2023 18:43:04 -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 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
predictability.
- 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?)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Sep/0003.html
Present:
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
Regrets:
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?
[silence]
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
close.
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
order.
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
problem?
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
know
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
results
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
that.
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
black/white
<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
comments?
fantasai: It may be nice to start with more restricted audience
trials to see if you get answers in those environments
first.
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
work
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
handled?
<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
change
<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
applicable.
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
issue
<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