- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 16 Mar 2022 19:05:53 -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 & Color Adjust
------------------------
- After last week's conversation on issue #6773 (Make system colors
fully resolve (but flag they were system colors) thus reversing
the resolution of #3847), several people reread the original
issue and conversation and contributed additional thoughts on
github. There is still disagreement between what authors expect
and what might be the best behavior for users so discussion will
return to github.
CSS Syntax
----------
- RESOLVED: Use HTML restrictions for custom idents (Issue #7129:
Custom property names too permissive, require namespacing
rules)
- RESOLVED: Illegal characters in an ident can be escaped (Issue
#7129)
- RESOLVED: Invalid ident characters are treated as DELIM tokens
(Issue #7129)
CSS Text
--------
- RESOLVED: Republish css-text level 4 (Issue #6900: Republishing CSS
Text 4)
CSS Flexbox
-----------
- TabAtkins and fantasai will review the issue reported on issue
#6777 (Column wrap intrinsic size algorithm can make inline
min-content > max-content) and add comments or proposed changes
to the issue.
CSS Pseudo
----------
- There were interesting use cases for issue #6641 (Custom properties
on :root) as well as good arguments against special casing.
Discussion will continue on the issue to formulate a concrete
proposal.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Mar/0005.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins Bittner
David Baron
Mike Bremford
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Simon Fraser
David Grogan
Jonathan Kew
Rune Lillesveen
Chris Lilley
Peter Linss
Alison Maher
Ben Mathwig
Morgan Reschenberg
Jen Simmons
Alan Stearns
Miriam Suzanne
Regrets:
Lea Verou
Scribe: dbaron
Admin/Future Meetings
=====================
Rossen: We're due for a long call at some point soon, agenda
accumulating. Maybe longer.
Rossen: Based on poll about TPAC from last week, seems like folks are
ready for a hybrid face-to-face. So perhaps should think if
we want to host a face-to-face this coming summer.
Rossen: Could be similar location to TPAC, that location seemed
favorable. Don't want to have conversation now. Think about
it.
Rossen: TAG is going to have a 2-places-in-world face-to-face meeting
in person next week, we'll see how it works.
<miriam> 🥳
Rossen: Also, a quick congrats to folks involved with layers and
seeing them shipped across all major engines. Remember
presentation from Miriam and Jen a few years ago in Spain.
Big accomplishment going this quickly from idea to
shipping... now we just need to go to REC. Interested in tips/
learnings from your experience.
CSS Color & Color Adjust
========================
Make system colors fully resolve (but flag they were system colors)
thus reversing the resolution of #3847
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6773
fantasai: We delayed this to give me a chance to reread the whole
conversation... which I did. What I understand about this
issue is that it was raised because switching color scheme
shouldn't cause system colors to change when they're
inherited. I think behavior of having system colors switch
along with color scheme makes sense. Why would you switch
color scheme if you're not changing colors?
fantasai: Then an argument that making forced-color-adjust: none with
18 different combinations of colors is unwieldy. I'd take
that as "too hard to implement".
fantasai: Then there were arguments about resolving system colors at
used value time: (1) makes some transitions issues go away
and (2) setting forced-color-adjust:none on subtree reverts
to colors that author specified. If we take this change
then forced-colors would work only on non-inherited colors.
That could cause contrast problems.
fantasai: There's arguments in both directions.
emilio: There's another argument for ... color-scheme doesn't behave
like you want it to behave. But regarding
forced-color-adjust:none, that seems like a better behavior.
At least, we were proposing adding a new value just to do the
thing you get when you resolve system colors at computed
value time. We were planning to make that default in SVG,
which is the obvious place to use forced-color-adjust:none.
So I'm not sure the behavior for forced-color-adjust:none
with used value time forcing is better.
<fantasai> https://github.com/w3c/csswg-drafts/issues/6773#issuecomment-1069295596
TabAtkins: In first part of fantasai's response, fantasai argues
against inheriting a color not respecting a color scheme.
I think you should reconsider. I switched to emilio's
viewport because if an inherited system color respects a
change in color scheme... this leads to the a11y problem
of text color and background color not being set as a
pair. If background is transparent... will be bad when you
use your text color with other background color.
TabAtkins: If you use the system colors explicitly, inherited text
will by default wrong if it respects color scheme changes.
I think that's a mistake.
fantasai: The color-scheme doesn't switch at a boundary randomly...
the author has to explicitly say they're switching the
color scheme. Why are they changing it if they're not
making other color changes too? I'd expect author to use
these things in coordination.
<tantek> +1 fantasai
<Rossen> fantasai, what about tools? F12 is supporting forced-colors
effect for debugging/testing
fantasai: On the flip side, forced-color-adjust: none problem: if you
have a subtree where you want the colors to be the ones I
specified and you set forced-color-adjust:none, and the
browser only turns off forced-color-adjust for some of your
colors, that's not expected behavior. You tried to turn it
off and it doesn't turn it off. (You might not notice
depending on your colors.)
fantasai: I think the difference here is there's no good use case for
an author setting color scheme and not setting other
colors, but there are reasons the author should expect that
setting forced-color-adjust:none actually turns it off.
fantasai: I think contrast issue you're concerned about is ???
TabAtkins: I think you're off... when author sets
forced-color-adjust.. ??? ... either author is setting
some colors and letting others through which violates a11y
guidelines, or they're setting all the colors and it
doesn't matter.
fantasai: They know what color is inheriting through.
TabAtkins: There's no guarantee they know what the colors are from
the outside, if forced-color is happening, or if they're
distributing a component.
TabAtkins: So the inherited color is potentially a mystery. They're
potentially mixing it with known colors (bad), or
overriding all. I think people still do the bad case, and
we should give a more-likely-accessible result.
<fantasai> Plenty of authors write pages where they set the
background on lots of elements, but only set the text
color on the root
<fantasai> This is normal and expected, and it's not a problem.
<TabAtkins> (This convo did happen in the issue, we're re-arguing it.)
<fantasai> But it *is* a problem if you set `forced-color-adjust:
none` on an element.
<fantasai> because the color you've inherited is no longer the one
you expected.
Rossen: Sounds like we're probably not ready to resolve, but let's
hear from fantasai and emilio.
emilio: [we can hear him but he can't hear us]
fantasai: It's normal and common for authors to set text colors on
root element, and set background colors on other elements
without resetting the text color. There's no problem with
it, because you know what color is inherited because you
control the whole page. This doesn't hold for components,
but not all pages are component-based.
emilio: So I was going to argue the same thing as TabAtkins... that
doing it at computed value causes contrast issues by default.
Specifying color-scheme may not end up in a color scheme
change... may specify normal. It's not clear that authors
will realize their colors are wrong.
<TabAtkins> Right, even in color-scheme changes authors can't
necessarily predict the color that they'll receive. So
no, this is bad *even in an entirely first-party
situation*.
Rossen: Continue discussion in github issue, bring back for
resolution next week.
<tantek> +1 Rossen
CSS Syntax
==========
scribe: fantasai
Custom property names too permissive, require namespacing rules
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7129
TabAtkins: i18n WG raised issue about custom idents, which allow any
Unicode codepoint above a certain codepoint
TabAtkins: There are some concerns about e.g. bidi characters
corrupting the display of the code
TabAtkins: Also argument for consistency in what characters allowed
across languages
TabAtkins: JS follows UAX?? rules for characters allowed in idents
TabAtkins: HTML allows a different but largely compatible range of
characters
TabAtkins: In one of my Tweets, I showed off using weird Unicode rules
TabAtkins: e.g. different emoji are valid or invalid
TabAtkins: I agree with i18n feedback, reasonable to partially
restrict these
TabAtkins: e.g. no reason to allow bidi override chars in CSS idents
TabAtkins: so I suggest adopting either HTML rules or JS rules
TabAtkins: Don't have a strong opinion on which to go for
TabAtkins: Otherwise I'd go with HTML rules by default
fantasai: I think this is fairly reasonable, but I don't know the
differences between the rules so I don't have an opinion on
those yet
TabAtkins: JS rules are a bit more strict, they disallow chars that
look like punctuation
TabAtkins: HTML gives exact codepoint ranges
TabAtkins: Reason I'd go with HTML is to guarantee being able to
write selectors for custom elements, without ever having
to escape
fantasai: That sounds reasonable, let's go with that
Rossen: Makes sense, any downsides to it?
TabAtkins: Any change to make more restrictive, could potentially
make some stylesheets invalid
TabAtkins: Potentially breaking code that works
Rossen: And with HTML rules we'd have fewer breakage
Rossen: seems like path of least destruction
Rossen: Anyone would like to argue against the change entirely?
Rossen: If not any objections?
Rossen: Taking the silence as a no
RESOLVED: Use HTML restrictions for custom idents
TabAtkins: Got 2 sub-issues
TabAtkins: One is whether to allow illegal characters to be escaped
in an identifier
TabAtkins: JS doesn't allow that, you can escape for readability but
not to avoid the identifier restrictions
TabAtkins: but CSS has traditionally always allowed escapes for
everything, so don't see a strong reason to disallow
TabAtkins: So I would prefer to go with illegal chars can be escaped
<faceless> +1 from us too
fantasai: I strongly agree with that
Rossen: Any objections for allowing illegal characters to be escaped
in an ident?
RESOLVED: illegal characters in an ident can be escaped
<dbaron> That doesn't allow nulls in idents, does it?
TabAtkins: Next question is how do we handle the illegal characters
TabAtkins: Do we censor them into e.g. U+FFFD
TabAtkins: or drop them entirely?
TabAtkins: I'd prefer to drop them, because it would more clearly
result in invalid code
TabAtkins: so if we allow to work but censored it wouldn't prevent
use in source text, which was the goal of i18n
TabAtkins: so would prefer to exclude from the ident production
<fantasai> +1
<tantek> +1 TabAtkins
Rossen: [missed]
TabAtkins: No, would not be changing existing rules for censoring
rules. Currently lone surrogates etc. do that
TabAtkins: Those are in there for UTF-8 well-formedness and C
compatibility
TabAtkins: They have a reason to be censored out at technical low
level
TabAtkins: these restrictions are for human reasons, so would
restrict differently
fantasai: So should we resolve that they would make the production
invalid? (That's what was proposed right?)
TabAtkins: Yes
<TabAtkins> --（╯°□°）╯
TabAtkins: if you put this ^ as a custom property name, the degree
sign is not a valid character
TabAtkins: so it would make an ident, a delim, a parenthesis, and
a ???
TabAtkins: That's definitely not an ident, because it's multiple
tokens not an ident token
* fantasai didn't quite catch that, what is the degree sign
considered now?
<TabAtkins> the degree sign isn't a valid ident char under the HTML
rules, so this would produce an ident, a delim containing
the degree sign, an ident, a delim, and finally an ident
<bmathwig> Is there a practical use case for doing something like
that? Seems more like a developer having fun rather than
good quality code.
TabAtkins: Proposed resolution is that it would break into multiple
tokens
fantasai: What kind of token are these invalid characters going to be?
TabAtkins: DELIMs, one codepoint at a time
TabAtkins: Characters without a specific role are generally handled
as DELIM
TabAtkins: and we only use certain DELIMs in certain places
RESOLVED: Invalid ident characters are treated as DELIM tokens
CSS Text 4
==========
scribe: emilio
Republishing CSS Text 4
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-1064818560
fantasai: Proposal is to republish css-text level 4
fantasai: Changes are that I merged css-text 3 and I added percentage
values to letter-spacing and word-spacing that we resolved
on 4 years ago
Rossen: Any reason not to do it?
fantasai: Don't think so
RESOLVED: Republish css-text level 4
CSS Flexbox
===========
Column wrap intrinsic size algorithm can make inline min-content >
max-content
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6777
dgrogan: So... background is that all engines have shipped the same
intrinsic sizing algo for years
dgrogan: but the algorithm is bad
dgrogan: fantasai specified a new one in 2015 but nobody implemented
it
dgrogan: Authors really want it
dgrogan: but there's a big compat risk here
dgrogan: but we want to ship it along everyone else so that authors
just fix sites once
dgrogan: We started implementing it and found this issue where min
can be > max
dgrogan: Details are in the issue, there's a few possible things we
can do
dgrogan: One is flooring max to min
dgrogan: or in this case making min the max content
fantasai: I'm really excited you're working on this
dgrogan: Yeah authors really want this and current algorithm is bad
TabAtkins: I see the problem, not sure what the best solution is but
that's wrong
TabAtkins: fantasai and me will review asap
iank: We might be testing the new thing in our canary channels and be
more concrete about the compat risks
iank: We might have to go back for the old thing if we get tons of
reports
iank: We might also want to do this incrementally, first for
single-row flexboxes and so on
CSS Pseudo
==========
Custom properties on :root
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/6641
delan: There's a lot of content out there where a bunch of custom
properties are specified on the :root
delan: Historically that's been fine for highlight pseudos because
they inherited from the element
delan: As spec'd now each highlight pseudo has a separate inheritance
tree so it'll break that pattern
delan: So there's a compat issue in that but I don't think that's a
huge issue because we've determined that some breakage is
acceptable for these highlight pseudo
delan: but there's two complications for this, one is that authors at
least they'd have to switch their stylesheets to `:root,
:root::selection, delan:` etc
<TabAtkins> :root, :root::selection, :root::highlight, ... { /* set
up all the custom props here */ }
delan: It's also a bit of a performance issue because we might end up
with a bunch of property blobs
delan: There's another option which is using `@property` with an
initial value
delan: It's a lot more verbose and it should work
delan: I guess question is "is that good enough"? Or can we simplify
it somehow for authors?
fantasai: Wondering about two things we could possibly do. One of
them is making highlights inherit from the root by default
fantasai: which might be a reasonable thing to do?
fantasai: Or specifying that variables are special and they inherit
from the originating element
<fantasai> probably can't inherit from :root for all properties, but
for variables might be OK
delan: I think the first idea seems cleaner
delan: I worry if there are any unintended side-effects
fantasai: I think the idea is "if you're on the root selection" the
variable properties would inherit from the root to
`:root::selection`
fantasai: I wonder if we want to make this work for every element
TabAtkins: Inheriting from originating element appeals, but assuming
we want to inherit from a single place could address a
larger concern
TabAtkins: ....
TabAtkins: Argument for root, animations can play into that don't
want to play into other places in the tree
TabAtkins: Few other suggestions, but if we are going to inherit all
the highlights from a single place should do in a way that
addresses larger concern
TabAtkins: either use initial value from register Properties
TabAtkins: or a more ergonomic way to set initial values that doesn't
have animations apply to it
emilio: Want to point out that ::backdrop has the same issue,
::backdrop doesn't inherit from :root
emilio: It hasn't come up often, but it has come up sometimes
emilio: I would rather avoid inheriting from multiple places, because
that's messy
emilio: very special-casy
emilio: We do something like that for ::first-line, and it's a
massive pain. Don't wish that to anyone
<TabAtkins> like `@root { /* only custom props here */ }`
Rossen: Where do we go from here?
delan: Agree with emilio in general
delan: I think especially highlight inheritance, but a lot about
highlight pseudos, is full of special cases
delan: Would prefer to avoid adding more
delan: So maybe it's fine?
delan: Tab does have an interesting point though, that there's a
general problem to be solved. Not sure
Rossen: I'm a bit lost on where we're going from here. What would you
like to see, delan?
delan: Leaving aside the more general issue of how we can use
variables in non-element contexts
delan: for the core issue, I think consensus was that the best
workaround so far is using custom property registrations with
initial values
delan: I guess the question I'm unsure about is do we think that is
too annoying and unergonomic? No one had an opinion on that in
the thread
delan: do we think that's already too annoying?
<emilio> having an `@root` or `@document {}` rule that applies to the
whole document makes sense to me fwiw
Rossen: for developers?
delan: Yeah
TabAtkins: Lea expresses that she find that's too unergonomic to be
worthwhile and would prefer something else here
<TabAtkins> Also I'm not 100% sure off the top of my head how
@property interacts with being nested in @media and
@supports.
<TabAtkins> (to be fair, both of these require waiting for support.
but this is simpler than @property, yeah)
argyle: I have lots of experience with custom properties, and it's
very tedious to ...
argyle: I have a library called openprops with 350 properties
argyle: I'm not going to hand-author 300 @property rules so that they
can drop into highlight pseudos
argyle: so some kind of higher level place to find these would be
great
argyle: Would be annoying to convert all my simple props and waiting
for browsers to even support that
emilio: Mentioned on IRC, but having @document or @root or whatever
to apply properties to the initial style makes a lot of sense
fantasai: one advantage of inheriting from their originating element
is that if you need to set variables deeper in the tree you
can do that
fantasai: and then they'd behave as you expect, you might need to
change your ::selection rules a bit
emilio: That was the thing I was thinking about. From an author's
perspective, what you want is inheriting from originating
element
emilio: Higher-level thing works for some cases, but might also be
more confusing
<TabAtkins> I think we'd define @document in cascade?
<fantasai> Tab, but it wouldn't inherit that's the problem
Rossen: Sounds like we need more discussion, suggest we take it back
to the issue
Rossen: Maybe you all can start formalizing the various ideas, would
be great
Rossen: and maybe next time we can be closer to a resolution
<argyle> 👍🏻
delan: Sounds good
Rossen: Everyone please have a thought about potential F2F, and we'll
talk again next week
Received on Wednesday, 16 March 2022 23:07:35 UTC