- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 20 Oct 2022 05:45:02 -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.
=========================================
Meeting Schedule
----------------
- There will be an extended meeting on Wed Oct 26, 2022 from 7:00am –
10:00am PT
CSS Values 3
------------
- RESOLVED: Close no change (Issue #7431: Restrict none/auto/normal
from <custom-ident>)
Media Queries
-------------
- RESOLVED: Properly define resolution of media type and top-level MQ
(Issue #7595: Merge error handling section into
evaluating section)
- RESOLVED: Clarify the spec text to reflect intended unknown
mechanics (Issue #7595)
- RESOLVED: Replace "replace by not all" with "evaluates to false",
open a separate issue on serialization (Issue #7595)
CSS Contain
-----------
- RESOLVED: content-visibility applies to elements that can have size
containment (Issue #7658: Should content-visibility apply
to elements when size containment has no effect?)
CSS Overflow
------------
- RESOLVED: For overflow:auto and size containment, 1st phase sizes
without scrollbars, 2nd pass adding scrollbars doesn't
change the size (because it is fixed). Clarify (Issue
#7875: overflow: auto incompatible with size containment
and container queries)
CSS Nesting
-----------
- The discussion for issue #7834 (Syntax Invites Errors) began by
reviewing the four proposals and the feedback gathered on them:
https://github.com/w3c/csswg-drafts/blob/main/css-nesting-1/proposals.md
- The voting indicated options 1 & 3 and the group affirmed interest
in those options. There was also a desire to investigate option 4
further, but the group ran out of time to discuss further on the
call.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Oct/0007.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins
David Baron
Emilio Cobos Álvarez
Erika Etemad
Robert Flack
Simon Fraser
Brad Kemper
Jonathan Kew
Una Kravets
Vladimir Levin
Daniel Libby
Peter Linss
Alison Maher
Eric Meyer
François Remy
Morgan Reschenberg
Florian Rivoal
Khushal Sagar
Jen Simmons
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Lea Verou
Regrets:
Chris Harrelson
Chris Lilley
Chair: astearns
Scribe: fantasai
Scribe's scribe: vmpstr
Administrative
==============
astearns: Reminder that we have a multi-hour format next week
fantasai: Publishing?
<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2022OctDec/0033.html
<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2022OctDec/0026.html
<fantasai> Values 3 CR update
<fantasai> and Box Model 3 PR ?
<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2022OctDec/0034.html
<fantasai> Values 4 WD ^
astearns: Let's try to do those async, and get to publishing next week
lea: Want to make sure we get to the nesting syntax discussion today
lea: since it's shipping
<argyle> the eng on chrome's side spent a very small amount of time
on that work (@nest), and is anticipating changes
CSS Values 3
============
Restrict none/auto/normal from <custom-ident>
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7431#issuecomment-1178237576
TabAtkins: I filed the issue, happy to withdraw
fantasai: Would've been nice to make it excluded, but I understand
there's compat risk
astearns: Proposed resolution is to close no change
<TabAtkins> I didn't file the issue actually, Elika did. (But it
happened as a result of us discussing it together.)
RESOLVED: Close no change
Media Queries
=============
Merge error handling section into evaluating section
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7595
gsnedders: We currently don't have interop with some types of errors
around invalid media features
gsnedders: because essentially we don't define clearly how any of
this is meant to work
gsnedders: There were proposals to put this into Interop 2023
gsnedders: need to know what exactly we'll be testing
gsnedders: A few sections
gsnedders: First, we don't define how to evaluate media type or the
top-level media query at all
gsnedders: and we just say that an unknown media type is treated as
not matching
gsnedders: whereas unknown media feature [logic]
gsnedders: Suggest to define how to evaluate MQ with handwavy
definition of media types matching if appropriate
TabAtkins: Agree
florian: I agree, media type is not properly defined, but that's not
hard. Can be more specific than mentioned
florian: since most deprecated by now
florian: so only two cases where we differ from screen
florian: for top-level MQ, what it ought to be is fairly obvious but
we should write it down
gsnedders: Proposed resolution is to define how to evaluate media
query and media type
gsnedders: in somewhat obvious way
astearns: any objections?
<TabAtkins> I think we should keep it undefined, to keep things
interesting.
RESOLVED: Properly define resolution of media type and top-level MQ
gsnedders: Next, unknown media name or ???
gsnedders: results in value of unknown
gsnedders: but we don't say what exactly is given unknown
gsnedders: an MF name or MF value doesn't have a value
gsnedders: Currently FF and Chrome differ
gsnedders: FF makes the entire MQ unknown if any media feature name
or value is unknown
gsnedders: whereas Chrome only makes that specific one unknown
florian: Chrome is right, the whole point of this logic is doing this
TabAtkins: [agrees]
gsnedders: I can justify both behaviors from current spec text
florian: We'll clarify, the intention is 100% clear to the spec
editors, so we just need to fix the test
RESOLVED: Clarify the spec text to reflect intended unknown mechanics
gsnedders: Final bit is, MQ whose value is unknown must be replaced
with "not all"
gsnedders: but not clear what it means to replace an MQ
gsnedders: maybe need to define MQ serialization?
TabAtkins: I think that's right, but...
TabAtkins: I think it's a serialization issue
gsnedders: I think we need to say that unknown MQ evaluates to false,
and serializes to "not all"
florian: Makes sense to me
emilio: We don't have this thing to support ... with generalized
enclosed
emilio: Is that a compat requirement?
florian: Part where unknown MQ evaluates to false, that is absolutely
desired intent
florian: whether accidentally replaced with "not all" with no effect
on serialization or whether was intended to talk about
serialization, then I don't know
gsnedders: I think it goes back to CSS2
gsnedders: It could literally just be copy-pasted from earlier level
with no thinking
<TabAtkins> MQ has a bunch of legacy weirdness that I didn't replace
emilio: We don't implement this update to the spec, but if we did
we'd probably want to be consistent with @supports
emilio: and @supports when you throw something random at it, you
serialize that
emilio: rather than a false statement
florian: Should we say, gets evaluated as false? or does that lose
something important?
emilio: I think so, but not sure how that maps. I think spec said
this had to be some value with 3-way state...
florian: When you propagate unknown ...
emilio: That was not the desired behavior, and we changed it. Unknown
just evaluates as false
emilio: so probably we want to be consistent, and unknown evaluates
as false?
TabAtkins: We very specifically want @supports unknown to be false,
because if you can't parse it you definitely don't support
it
TabAtkins: but for MQ, whether you are that type of media or not, you
don't know if you can't parse the MQ
<fremy> +1 to what TabAtkins just said
florian: I think that the "gets replaced by not all" is an ancient
and imprecise way of saying evaluate as false, and we should
replace this and not talk about serialization
gsnedders: With prior resolution, very few if anything will result in
the whole MQ being unknown
TabAtkins: Not necessarily true, e.g. combine with and and you'll get
unknown propagate up
gsnedders: Yes, nevermind
astearns: Should we resolve, or need more time?
emilio: Fine as long as we're all on the same page
florian: Instead of "replace by not all" say "evaluates to false"
gsnedders: Define serialization of unknown MQ to be "not all", is
that still the intention?
florian: Let's open a separate issue for serialization, since might
have compat concerns
florian: Want to look into that offline
RESOLVED: Replace "replace by not all" with "evaluates to false",
open a separate issue on serialization
<gsnedders> florian: are you gonna be able to make these MQ edits in
the nearish future (as in weeks), or should someone else
do so if we want it in the spec soon?
CSS Contain
===========
Should content-visibility apply to elements when size containment
has no effect?
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7658
florian: The content-visibility property is said to apply to elements
to which layout containment can apply
florian: to keep simple, there's a hidden value and an auto value
florian: when you turn on hidden, it turns on all four types of
containment
florian: but there exist elements for which layout containment can
apply but size containment doesn't
florian: if you're on such an element, content-visibility doesn't do
what you expect because can't get the 4th type of containment
florian: similar issue with 'auto'
florian: so I think we should change the applicability of
content-visibility
florian: to elements to which size containment can apply
vmpstr: I agree, when we wrote layout containment I didn't realize it
was possible to have only one of size/layout containment
vmpstr: I would have hoped the condition for containers being the
same, switching content-visibility to track size containment
makes sense to me
fremy: I actually have one question, when we say doesn't apply,
constants will still be visible?
florian: yes, property doesn't take effect
fremy: For visible, should be obvious, you're the author you try to
understand why
fremy: but for auto it's tricky, because you might not notice it
doesn't apply
florian: Interesting point, and probably should do something to that
florian: but not strictly about this issue
florian: because we're changing what it applies to, but already have
case where it doesn't apply to some boxes
fremy: Why do you need size containment for content-visibility?
fremy: oh, because we don't want to relayout ...
astearns: Proposed to have content-visibility to apply to elements
that can have size containment (only requirement)
astearns: objections?
RESOLVED: content-visibility applies to elements that can have size
containment
CSS Overflow
============
overflow: auto incompatible with size containment and container queries
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7875
oriol: When have overflow auto, only scrollbars when overflowing
oriol: but that can affect sizing
oriol: According to spec, there are 2 ways of handling these
oriol: one behavior, if element is intrinsically sized
oriol: then inner size of element will be intrinsic size, and
scrollbar added onto that
oriol: this makes the element bigger
oriol: other behavior is when element is extrinsically sized
oriol: inner size is reduced to make room for scrollbar without
affecting outer size
oriol: Blink has implemented
oriol: firefox and webkit only do this in inline axis
oriol: Having said this, behavior is problematic in different ways
related to containment
oriol: examples in the issue
oriol: There's an optimization that browsers can apply
oriol: when descendant changes size, we don't have to compute size of
size-contained element and its ancestors
oriol: but if this element has overflow:auto and intrinsically sized,
then adding the scrollbar can cause the outer size to grow
oriol: so we cannot apply this optimization
oriol: and then browsers are broken because they assume they can
apply the optimization, and it looks bad
oriol: can get scrollbars floating outside the element, or have
sudden changes in size ...
florian: I think they're broken, but for a different reason
florian: I think spec is correct
florian: because contain:size is defined to work in 2 phases
florian: in the first phase, you size as if empty
florian: not going to get scrollbars
florian: but then you fix that size
florian: then you're no longer intrinsically sizing
florian: so when you're adding content into the fixed size, you are
no longer intrinsically sized
florian: at that point, you need ot add the scrollbars inside
<iank> I agree with florian
florian: I think that's the bug in the implementations
florian: so Chrome is putting the bottom scrollbar outside, as if
intrinsically sizing, but we're not
oriol: I guess this argument would apply even without size
containment, in the normal case you have 'width: max-content'
then you could say the same
oriol: during first phase you do intrinsic size, and then element
gets is size computed, and then you do final sizing
fantasai: Is the example with max-content with or without size
containment? If it doesn't have it, we don't fix the size
so we get weird results with scrollbars if you have normal
element with normal sizing
oriol: In grid layout, if grid container has width:max-content, then
first you run track sizing algo with indefinite size
oriol: and then when you know this size you fix the grid container
and lay out again
oriol: regardless of size containment or not
oriol: so maybe the behavior of scrollbars added on top, reduce the
inner size, maybe this wording may need to be different or
maybe I didn't explain it well
oriol: but the same argument would apply in both contained an
non-contained one
iank: I think this is two problem
iank: I agree with florian, initially size it without scrollbars
present and then it will overlay content if you overflow in
that direction
iank: I think that's straightforward, should get a resolution
iank: more general problem of sizing things in the presence of auto
scrollbars
iank: is complicated
iank: we have our layout engine a little state machine that will go
through and basically add scrollbars [missed]
iank: still bugs trying to get rid of
iank: but that's a separate issue
florian: Might be complications in various layout modes, I think for
contain case the spec is clear
florian: about the 2 phases
oriol: So final outer size does not depend on whether it gets
scrollbars or not?
florian: Correct
oriol: Then we have circularity problem with Container Queries
astearns: If you want to present an additional problem, that should
be in the issue or separate issue
astearns: we do need to get to next item
[discussion of resolution to take]
florian: I think the spec specifies this correctly
florian: could be clearer, but it's there
oriol: I think it needs to be clarified with interaction with spec
prose in css-overflow
oriol: Because overflow says to recalculate sizes
astearns: So one proposal is to clarify that when things are
initially sized under size containment, they're sized
without scrollbars
florian: That's clear
florian: it's the other part that's less clear
florian: once you add the content, size containment says you keep the
size fixed
florian: and just because you have scrollbars, doesn't change that
fact
<iank> I'm fine with that.
astearns: Proposal is to clarify that in 1st phase size without
scrollbars, and in 2nd pass scrollbars don't change the size
RESOLVED: For overflow:auto and size containment, 1st phase sizes
without scrollbars, 2nd pass adding scrollbars doesn't
change the size (because it is fixed). Clarify
CSS Nesting
===========
scribe: emeyer
Syntax Invites Errors
---------------------
github: https://github.com/w3c/csswg-drafts/issues/7834
astearns: fantasai has suggested we should focus on this call on
whether we replace the text in the specification with
option 3, and then have further discussion later on
proposal 4.
<TabAtkins> +1
<lea> +1
<bramus> SGTM
<astearns> https://github.com/w3c/csswg-drafts/blob/main/css-nesting-1/proposals.md
astearns: We have four options with pros and cons, and some poll
results
astearns: Most positions are between options 3 and 1, with a
smattering of 2 and 4.
<lea> I have added some vote counts under the table
fantasai: Many considerations here. We have problems with the current
syntax, which requires a lot of ampersands that are hard to
remember where they're needed
fantasai: we also want portability of the code structures is a
concern with the current syntax
fantasai: there was another concern about confusion over spaces, but
that seems minor
fantasai: Our options are: always prefix, nest into blocks, use a
switch to change modes
fantasai: We explored many possible syntaxes. Lea?
lea: Option 3, you can nest without ampersands for most selectors
lea: except the only descendants you need ampersands is element
selectors
lea: The advantage is there's no parser switch, and it's also much
less verbose than current syntax
lea: If you have a descendant selector that start with an element,
you do need to ampersand that
lea: Compatibility with Sass is not a concern here, because it's a
one-time cost
lea: In general, the closer we can get to the Sass syntax, the
better; developers like it
lea: People find the current syntax quite noisy
lea: We might also be able to relax syntax in the future, if we can
figure out a way to do so
astearns: Ampersands not required, but allowed, yes?
(collective affirmation)
fantasai: Devs seem split 50/50 on use of ampersands or not
fantasai: As far as the proposal, the basic rule for nesting a
selector is that you can't start with a letter
<dbaron> (I think it's a letter or a dash?)
<lea> dbaron: yes
TabAtkins: While I initially supported option 1, having looked
through the details, option 3 is very good
TabAtkins: It most of the time gives you the ability to write like in
Sass, with one awkward exception that's easy to tell apart
TabAtkins: Most of the time you can use an ampersand to nest and it
works out fine
TabAtkins: The rule for whether you need it or not is very clear, and
this does allow us to be close to Sass
jensimmons: There are a lot of things about option 3 I really like,
but the one thing I feel is a non-starter from my
perspective is that not all selectors are treated the same
jensimmons: Authors have to know that nesting is easy most of the
time, except in this one case
jensimmons: I understand the mitigations, the problem is teaching
authors that this one selector type is weird, and the
syntax isn't consistent across all selector patterns
<lea> Clarification: I didn't say element selectors were rare *at
all*. Element selectors where the parent selector is inserted
later (e.g. strong &) is rare.
argyle: When you go to paste and forget the &, that's a problem, but
syntax highlighters are there to help authors
argyle: Option 1 is the most portable because it's unambiguous
argyle: The community outside the WG has already passed the WG, which
may be why a lot of people didn't seem to case about the
verbosity
argyle: Option 1's simplicity is appealing for tooling and to machines
argyle: Teaching option 1 is easy, because it's very consistent
argyle: Teaching 3 or 4 gets muddy and complicated
argyle: I did like the idea that most of the suggestions of 3 and 4
build on option 1, so I like the idea of going with option 1
and then in Level 2, we could use 3 and 4
argyle: This would let us unblock engines that already do option 1 now
<fantasai> 4 doesn't build on 3 or 1 or anything
<fantasai> and also doesn't have any exceptions
<TabAtkins> 3 has exactly one exception, same as 1 (and imo of the
same complexity). 4 has no exceptions. It was the 2
variants that had slightly more complex requirements.
<argyle> correct, 4 doesn't build on 1, my bad
fremy: I'm glad that we aren't considering option 2. I'm mixed
between 1 and 3, and agree with the points mentioned before
fremy: I'm kind of okay with 1, would be fine with 3, the consistency
of 1 feels better
fremy: If I had to choose, I'd probably say 1, but wouldn't be mad if
we choose 3
fremy: I see myself converting nested rules into scoped rules, which
we aren't really addressing
fremy: Having a syntax incompatible with :scope is annoying and a
downside
fremy: You should be able to copy and paste anything and not have to
rewrite anything
<argyle> memorizing idents shouldn't be a requirement to nest
effectively..
lea: Replying to jensimmons, I didn't say element selectors are rare,
but that element selectors where the ampersand comes later are
rare
<fantasai> lea mentioned that `strong &` is rare, but `& strong` is
fairly common and can be done with & as today
miriam: Both proposals have weird edge cases
miriam: in option 1, you have to learn when to use or not use @nest
miriam: in option 3, you have to learn when to use ampersands with a
descendant
miriam: In my mind it's a little easier to teach, because I can teach
that you always have to start with a symbol
miriam: I do see Adam's point that 1 and 3 are interoperable if we
want them to be
miriam: I don't know if that's an interesting approach to take, but
it is possible
<fremy> miriam, we could just replace `@nest` with `&` and say that
if there are one at the start and one later one, the one
later one wins
astearns: I think it's intriguing to do 1 and then allow 3 in the
future
<jensimmons> I wish we had time to talk about option 4. If we ended
up like 4 best, there's no need to debate 1 vs 3, etc.
<fremy> jensimmons I agree, we will have more time next week
<bradk> I agree with the idea that #3 still allows you to do #1
astearns: We need to take this back to the issue and come back to
this next week with another scoped-time discussion
astearns: Please do discuss further in the issue.
Received on Thursday, 20 October 2022 09:45:44 UTC