- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 5 Oct 2023 18:54: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 Syntax
----------
- RESOLVED: At top level, if you see a rule that looks like a custom
property, we consume as a rule and throw it away as
invalid (Issue #9336: Dashed-ident rules and error
recovery)
- TabAtkins will look into using a more generic term than 'nested'
for the flag for mixed declaration+rule contexts
CSS Text
--------
- RESOLVED: Straw poll for naming between -wrap and -allow. Values
are wrap|nowrap (Issue #9102: Move "balance | stable |
pretty" out of text-wrap)
CSS UI
------
- RESOLVED: Values will be fixed | content (Issue #7542: Allow
<textarea> to be sized by contents)
- The group will run a poll on form-sizing vs field-sizing, with
values content and fixed
CSS Grid
--------
- RESOLVED: Drop align-tracks, justify-tracks from Masonry spec
(Issue #8207: Masonry - align-tracks / justify-tracks
potentially not desirable for accessibility)
CSS Masking
-----------
- RESOLVED: mask-border properties will match border-image wrt
animatability (FXTF issue #529: Interpolation of
mask-border properties)
- RESOLVED: mask-type is not a longhand of mask (FXTF issue #528: Is
mask-type a longhand of mask?)
FXTF
----
- The group will update “Animatable” lines to “Animation type” in all
propdef tables (FXTF issue #521).
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Oct/0000.html
Present:
Tab Atkins
Stephen Chenney
Elika Etemad
Robert Flack
Chris Harrelson
Ian Kilpatrick
Vladimir Levin
Alison Maher
ChangSeok Oh
Florian Rivoal
Alan Stearns
Miriam Suzanne
Lea Verou
Regrets:
Yehonatan Daniv
Jonathan Kew
Khushal Sagar
Bramus Van Damme
Sebastian Zartner
Chair: astearns
Scribe: fantasai
Scribe's scribe: TabAtkins
CSS Syntax
==========
Dashed-ident rules and error recovery
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9336
TabAtkins: We resolved the fundamental grammar ambiguity between
properties and declarations in nesting by deciding we
would start by parsing as a declaration, and if it was
invalid, go back and parse as a rule
TabAtkins: recently tweaked to make more efficient
TabAtkins: works pretty fine, but a wrinkle about custom properties
TabAtkins: custom properties are very hard to make invalid
TabAtkins: anything you write in a custom property will always be
valid
TabAtkins: so if you write --foo: [anything] that's a valid custom
property
TabAtkins: in order to avoid a behavior change for authors
TabAtkins: if it looks like custom property, we treat it as a custom
property during rule parsing
TabAtkins: if you have 'display:hover', can quickly tell it's not a
valid display
TabAtkins: issue is that I didn't condition that check on being in a
nested context
TabAtkins: so as written, if you have a top-level style rule starting
with --foo:whatever, it will try to consume a custom
property declaration
TabAtkins: it will eat everything up to the next top-level semicolon
TabAtkins: lose the rest of the stylesheet from that point forward
TabAtkins: I didn't think about this case, so proposal is to
condition that check for "does this look like a custom
property" to check whether in a nested context or not
TabAtkins: if not nested context, we let it parse as a rule
TabAtkins: but will do rule-parsing and end at next curly brace
TabAtkins: this means that behavior-wise, this brings us back to how
this case would have acted before my recent change to
allow nesting to work
TabAtkins: i.e. if you write a style rule --foo:whatever, it will
only eat one style rule
TabAtkins: I've checked this with Emilio during TPAC
fantasai: So what this means is that parsing behavior for style rules
with a custom ident is different in top level vs nested
fantasai: So if we have custom idents at beginning of selector, will
we be in trouble?
TabAtkins: In both cases, if you try to write a rule with
--foo:something, you would end up with something invalid
TabAtkins: if it wasn't a valid custom property, you won't get a rule
TabAtkins: The difference in parsing behavior is, if it's nested
it'll consume as a declaration
TabAtkins: whereas at top level it'll consume as a rule
TabAtkins: in both cases, can't be a rule
TabAtkins: we took as an implicit restriction on ourselves that if
you have a style rule that wants to start with a dashed
type selector, you have to spell it differently e.g. wrap
in :is()
TabAtkins: considered that to be fine because that's not a valid
custom element name in HTML or XML (I think?)
TabAtkins: very difficult to have a type selector that looks like
that, can work around
TabAtkins: error recovery is different in both cases, but either way
the rule is invalid and won't work
TabAtkins: and I think that's enough consistency
<fantasai> ok, sgtm
astearns: My question is, defining it as working normally in nested
context vs defining it as doing different thing in top-level
astearns: would that be exactly the same? I'm worried nested context
are about CSS nesting, not a regular declaration block...
TabAtkins: The switch used in Syntax is "is it mixed with
declarations"
astearns: Ok, and nested context is that type of context
TabAtkins: Yeah
TabAtkins: Flag is called "nested" but in practice used for mixed
cases
astearns: Might want a different term
TabAtkins: I'll look into it
ACTION: TabAtkins to look into using a more generic term than
'nested' for the flag for mixed declaration+rule contexts
<RRSAgent> records action 1
TabAtkins: Proposal is, at top level, if you see a rule that looks
like a custom property, we consume as a rule and throw it
away as invalid
RESOLVED: At top level, if you see a rule that looks like a custom
property, we consume as a rule and throw it away as invalid
CSS Text
========
Move "balance | stable | pretty" out of text-wrap
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9102#issuecomment-1735801461
fantasai: A bunch of ideas were thrown around
fantasai: I think the two main contenders are text-wrap-mode and
text-wrap-allow
fantasai: A bunch of other options but none seem to get traction
<fantasai> https://front-end.social/@jensimmons/111138016628140950
fantasai: Jen Simmons posted on mastadon to guess what -mode would do
fantasai: And generally people guessed correctly
fantasai: But we didn't run text-wrap-allow test
fantasai: So that's where we're at. I think either should work, don't
have a strong opinion
fantasai: Should we think about it more or straw poll? comments?
<vmpstr> what are the text-wrap-allow values?
astearns: I'm slightly more happy with -allow than -mode, but could
live with either
florian: No strong pref, neither's great nor terrible
florian: prefer wrap and nowrap, not auto and nowrap
florian: one is consistency with flex.
florian: Other is we can't rename text-wrap property, too long and
used
florian: if that's true we probably need to do the same with the
values themselves
<miriam> +1 slight vote for allow
<TabAtkins> also slight pref for -allow
astearns: Anyone have concerns with -allow being a boolean
essentially? Tim's concern
astearns: Right now it's a bool but we might have more modes in the
future
astearns: I think it's ok that -allow doesn't as strongly imply on/off
florian: Even beyond boolean we'll have grades of how much to allow
fantasai: My one concern with -allow is we got some feedback on -mode
and not on -allow
fantasai: so just don't know if it's intuitive or not
fantasai: Not that it's bad, just not as much info on it
fantasai: I'm interested in getting a straw poll to see what the WG
feels like
lea: I'd be fine with a straw poll
lea: I suggested a process for async polls, was wondering about
trying it for the first time in this specific issue if people
agree
<lea> https://github.com/w3c/csswg-drafts/issues/9438
lea: Me or someone else could try to post a poll like this and see
where people stand
florian: I'm not against trying a new process, but I'd rather not do
it on something fairly urgent that people want to unblock
shipping on
lea: Sure, but because this is APAC and lots of regrets, might not
have sync quorum anyway, so might speed things up
fantasai: I think CSSWG could be better at this than the Advisory
Board
astearns: I'm happy with the async straw poll and coming back next
week
astearns: You think a week is sufficient?
lea: Yeah, maybe even less
astearns: Nice to have a weekly call to discuss and ratify though.
astearns: So how about we do that. I'm happy to set up the poll, or
Lea can?
lea: I can post it and even add votes that have been expressed
already?
TabAtkins: I think as long as it's clear someone had a preference
it's okay to write in their vote
fantasai: I think it needs to be clear *between these two options*,
not necessarily just a pref for one of the existing ones
fantasai: Also we should make it clear that wrap/nowrap is the value
lea: I think we can't decide on values before name
florian: You might have missed the earlier discussion; we can't
change the shorthand for compat. If we're stuck with the
shorthand value naming, we should probably keep the keywords
in the longhand
fantasai: I think it's unlikely that people are using a lot of
text-wrap:wrap, most like just text-wrap:balance, so might
be changeable, but for consistency with rest of CSS that
uses this concept, using wrap/nowrap as the pair is
important
florian: yeah
astearns: If we had a time machine we'd do no-wrap but we don't
lea: The thing is, not all values work with every name
florian: We're not trying any name, just -mode and -allow. And wrap/
nowrap works with those
lea: Wait are we only doing those two names?
astearns: Yes, convo narrowed to those two
fantasai: I didn't see people advocating for more than those
fantasai: You had a white-space-wrap suggestion but it wasn't really
about white space in several writing systems
lea: Yeah that ship might have sailed. I'm fine with not doing
white-space-wrap if nobody else wants it
astearns: So action Lea to make the async poll for text-wrap-mode and
text-wrap-allow
astearns: Can either wait on values or just resolve to say the values
are wrap/nowrap
<lea> +1 for wrap | nowrap
<TabAtkins> +1 to wrap/nowrap
astearns: Objections to resolving?
<TabAtkins> [none]
RESOLVED: Straw poll for naming between -wrap and -allow. Values are
wrap|nowrap
<lea> Straw poll posted in
https://github.com/w3c/csswg-drafts/issues/9102#issuecomment-1747785298
CSS UI
======
Allow <textarea> to be sized by contents
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7542
iank: Put on agenda again because some discussion about current name
and values and suggestions for other ones
iank: so agenda to bikeshed these
iank: I've seen a few variations. A lot keep 'form-sizing' but use
'content' instead of 'auto'
iank: another suggestion was normal | auto?
TabAtkins: Don't think we should go with generic keywords, later
suggestion is better
<TabAtkins> content | fixed
iank: So 'form-sizing: content' and also 'field-sizing: content'
TabAtkins: Based on the suggestions in the thread, I suggest
'content' and 'fixed'
TabAtkins: Weak pref, but sound reasonable
TabAtkins: and even if the precise definition is wonky, it's easy to
guess what the behavior is
TabAtkins: unlike auto / normal / default / legacy
<astearns> +1 to -sizing & content
lea: How does this interact with width/height?
iank: This changes how you resolve the intrinsic values
iank: If you specify 'width: 100%', during intrinsic sizing might
behave as min-content/max-content
iank: If you specify 'width: 100px', won't get a behavior change
TabAtkins: This makes form contents use the content-based sizing
rules that normal non-replaced elements do
TabAtkins: form controls by default have weird intrinsic sizing due
to legacy
iank: This also disables the compressibility quirk
iank: This quirk gets around the fact that form control elements have
a fixed intrinsic size
iank: if you set e.g. width: 100%, the min-content size will be zero
iank: this will opt you out of that behavior
iank: It existed because there wasn't a good intrinsic size before
lea: Does it have other effects? e.g. Chrome doesn't allow visible
overflow
iank: This only affects intrinsic sizing
<TabAtkins> compressibility thing:
https://drafts.csswg.org/css-sizing/#min-content-zero
miriam: I'm liking 'content', but curious how it interacts with the
sizing *-content keywords
miriam: They're doing slightly different things in different places,
will it be confusing?
iank: I don't think so, we suspect people already using min-content/
max-content on these form controls already
iank: If you use this, set 'form-sizing: content', then this'll
change how *-content behave, make them follow the content
florian: This is actually a good relationship, because it ties the
*-keywords to be based on the contents
iank: Any preferences on form sizing vs field sizing
astearns: Slight preference for field, because form means other
things too
miriam: Same
lea: Also form-sizing feels like it affects <form>
<lea> control-sizing?
iank: We got similar feedback on Twitter
<TabAtkins> huh. I wouldn't have thought about field-sizing. Like
input fields?
<TabAtkins> I guess, sure.
fantasai: We don't use "field" in a lot of other places
fantasai: What about input-sizing?
fantasai: This is all about input elements
iank: Also affects textareas, select, etc.
<TabAtkins> iank: That might be a little confusing since it also
affects textarea and select
iank: So input might not be great
<lea> fixed reminded me, what about something-layout to match
table-layout as a precedent ?
iank: Talking about these elements on MDN, "field" appears a lot, so
I think it would match ppl's expectations
miriam: We also do have <fieldset> which refers to same idea
<TabAtkins> I wouldn't have thought of "field", but I suppose it
makes sense, and we don't have any other concepts using
that term in CSS so I think it's clear to use
<TabAtkins> (I do prefer form-sizing tho)
<lea> nah, I think -layout would be a bad idea here. auto | fixed
might be good for the values though (same as table-layout)
<iank> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input
("field appears 29 times")
<iank> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input
("control" appears ~70 times)
florian: I think I like form better here, but just to be complete, we
have a term for elements that can have native appearance,
and we call them "widget".
florian: I don't think it would be very helpful here, so my
preference still goes to "form"
fantasai: Seems like fixed|content for values. Any alternatives for
fixed? Seems like we're happy for content
<lea> input-sizing
florian: Someone suggested legacy?
astearns: Should we resolve on 'fixed' and 'content'?
lea: There were many arguments in the thread about legacy being bad
lea: another would be 'auto' and 'fixed', which would match
'table-layout'
iank: pretty strong to keep 'content'
astearns: Proposed 'content' and 'fixed' as values for this property,
any objections?
RESOLVED: Values will be fixed | content
fantasai: Should we run a poll for these names too?
<TabAtkins> +1 to another poll
<lea> TabAtkins: sync or async?
<TabAtkins> async again
florian: not a fan of input-sizing because <input>
<chrishtr> form-sizing?
POLL: 1. form-sizing 2. field-sizing 3. input-sizing
<florian> 1
<miriam> 2
<TabAtkins> 1,2
<astearns> 2
<fantasai> no strong opinion
<lea> abstain, I think
<vmpstr> (abstain)
<iank> 2,1
<chrishtr> 2,1
<iank> (no strong opinion however)
<schenney> (abstain)
<changseok> 1
<flackr> 2
[discussion of poll results]
<TabAtkins> Since there's no active disagreement I'm fine with a
straight majority, fwiw
<TabAtkins> We don't need a strong consensus when it's not
controversial for the group
<dholbert> 2
fantasai: I think it would be useful to poll authors on the two
names, to see if there's a strong drift one way or another
lea: if we're pressed for time...
TabAtkins: We're not that pressed that a week is critical
astearns: fFster to resolve on the call, after getting poll results
[discussing poll mechanics]
[proposed to have a poll using Lea's mechanism, but add in an emoji
option]
[also discussing running polls over twitter / mastodon]
astearns: So we will run a poll on form-sizing vs field-sizing, with
values content and fixed.
astearns: We'll be able to also evaluate Lea's proposed async poll
system
<lea> 2nd Straw poll posted!
https://github.com/w3c/csswg-drafts/issues/7542#issuecomment-1747805436
CSS Grid
========
Masonry - align-tracks / justify-tracks potentially not desirable
for accessibility
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8207
iank: Mats's spec for Masonry had a feature align-tracks/
justify-tracks which allowed you to align individual tracks
iank: Personally I haven't seen developers ask for this
iank: and it leads to some accessibility problems
iank: If you look at the examples and try to count from 1 - 33,
you're jumping all over
iank: also a bunch of issues wrt spanning items
iank: so the proposal is to drop this sub-feature
fantasai: We're OK with dropping. If it seems that we need to do
something like this in the future, we can explore it then
dholbert: Seems fine to me, too
astearns: Proposal is to drop align-tracks/justify-tracks from
Masonry spec
astearns: Objections?
RESOLVED: Drop align-tracks, justify-tracks from Masonry spec
CSS Masking
===========
Interpolation of mask-border properties
---------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/529
ntim: The properties are marked as discretely animatable, but that's
inconsistent with border-image which is animatable by computed
style
ntim: I know mask-border was based off border-image, so I was
wondering why the inconsistency?
<TabAtkins> +1 to matching border-image
fantasai: I suspect (haven't checked) is that animatable lines
weren't added in the source, and Bikeshed defaults them to
discrete
fantasai: But yes it makes sense to make them consistent
<TabAtkins> (I could just make it an error at this point; that didn't
make sense before.)
<fantasai> TabAtkins, yes please
astearns: Proposed to change mask border properties to match
border-image
RESOLVED: mask-border properties will match border-image wrt
animatability
Is mask-type a longhand of mask?
--------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/528
ntim: I noticed that mask-type has a prefix mask-
ntim: It looks like a longhand of mask, but idk if it should be or not
fantasai: Looking at the dfn now I think it shouldn't be
fantasai: The property is set on a mask *element* and says whether
the mask is based on luminance or alpha
fantasai: I think that's not an appropriate longhand for the mask
shorthand
ntim: I wonder if the name is appropriate, then?
fantasai: It is - we don't always have the situation where the prefix
indicates a shorthand.
fantasai: I can't think of a different name
fantasai: Also this is an SVG property so unsure we can even change
it at this point
miriam: I agree on intuition, mask- feels like a longhand of mask,
but there are several mask- properties that are not part of
the shorthand
miriam: so it's not a lone standout
ntim: Even mask-border is part of mask
fantasai: Yeah all the rest are on the element using the mask. This
is the only one that's not that.
fantasai: It defines the mask, not applies it
ntim: Would prefer to rename if it's compatible, but seems maybe it's
not?
astearns: Seems resolution is no, mask-type is not a longhand of mask
<fantasai> https://developer.mozilla.org/en-US/docs/Web/CSS/mask-type#browser_compatibility
fantasai: I think mask-type is shipping in all browsers
astearns: Could leave it open if people want to look into renaming,
but doesn't seem likely
RESOLVED: mask-type is not a longhand of mask
FXTF
====
Update “Animatable” lines to “Animation type” in all propdef tables
-------------------------------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/521
fantasai: A lot of these don't have active editors, is it ok for us
to do a drive-by edit to fix this?
astearns: Yes, I decree it
fantasai: And at some point we need to figure out republishing
fantasai: but that's for another day
astearns: [summarizes upcoming discussions]
lea: aren't we also talking about CSS4 CG soon?
astearns: End of the month
Meeting closed.
Received on Thursday, 5 October 2023 22:54:39 UTC