- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 23 May 2023 01:34:48 -0400
- To: W3C style mailing list <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 Nesting
-----------
Relaxing the Syntax Further
https://github.com/w3c/csswg-drafts/issues/7961
- RESOLVED: Keep the current spec parsing behavior in an Appendix,
update the spec to use the lookahead option
- RESOLVED: Document restrictions on future syntax in Syntax, linking
back to Nesting:
1. No semicolons in selectors
2. Nothing after {} in a declaration.
3. --ident always kicks off declaration (not rule) parsing
- RESOLVED: Close Issue #8251 as no longer relevant.
Require `div&`, disallow `&div`, for Sass compat
https://github.com/w3c/csswg-drafts/issues/8662
- RESOLVED: type selector remains required first; &div is invalid
Feature detection for nesting
https://github.com/w3c/csswg-drafts/issues/8399
Discussion will continue in GitHub.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Apr/0009.html
Logs: https://www.w3.org/2023/04/19-css-irc
Present:
Tab Atkins
Emilio Cobos Álvarez
David Baron
Oriol Brufau
Elika J. Etemad
Robert Flack
Peter Linss
Cassondra Roberts
Jen Simmons
Alan Stearns
Sebastian Zartner
Scribe: fantasai
CSS Nesting
===========
astearns: Agenda bashing?
TabAtkins: Not sure if 1st one is part of last week's decision, but
otherwise don't have opinion on the order
astearns: This question is about are we adapting current level of spec
to lookahead
fantasai: There was an issue raised by emilio about the cascade, about
how declarations occuring after nested rules are sorted
before them
fantasai: I think that one is pretty important
Relaxing the Syntax Further: Publication Strategy
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7961
astearns: We looked at lookahead possibilities
astearns: and discussion in this issue about relaxing syntax further
to take advantage of lookahead proposed
astearns: question of whether to do in this level and update current
draft, or create new level for lookahead
astearns: so that's what I wanted to get to first
TabAtkins: As plinss said in the comments at the bottom, there doesn't
seem to be a path for the current spec to reach REC
TabAtkins: might have only one implementation, not more
TabAtkins: since we'll all be moving to the new option
TabAtkins: so there wouldn't be 2 impls of what's in the current
draft, except as historical artifact
??: For Safari, we are on the path to release the current
implementation
??: so there will be two implementations
astearns: Point is not two implementations of the limited syntax that
requires recasting certain selectors
jensimmons: idk if it matters if it's two levels or one level
jensimmons: when we last discussed, ppl were talking about deleting
all of the current text about what to do without lookahead
and how the ampersand will function etc.
jensimmons: and that's what I believe is not a wise thing to do
jensimmons: if things had played out differently, might be reasonable
to throw out text that wasn't shipping in any browser
jensimmons: but in this case we have two shipping implementations
jensimmons: nevermind about REC, but Chrome has already shipped and
Safari is going to ship
jensimmons: and doesn't seem wise to me to completely delete the spec
text that describes what two browsers have done along this
complicated path
jensimmons: It could be a Note, could be something to say that this
existed at some point, here's the description
jensimmons: Once zero browsers have it in their implementation could
delete it
jensimmons: but going back on this path that was promised and act as
if such implementations are off spec / non-compliant is
not helpful
astearns: not illegal, just not required once implementations update
jensimmons: Fine that never required, Firefox is not required to do
this implementation of course
jensimmons: whatever written down should say that
astearns: Could have a historical note saying, this is a thing that
we had a long the way, and acknowledge it
jensimmons: Yes, that's my preference over deleting it all
TabAtkins: I'm fine with moving to historical appendix
plinss: What's the benefit to authors?
astearns: not memory-holing the previous discussion
plinss: we have plenty of minutes, online discussions, not pretending
it never happened
astearns: Not talking about specifying, just having a note
TabAtkins: I think it's useful to have a description of what some
implementations are doing, at least until they disappear
into obscurity
fantasai: In terms of process, unwise to put things that were on the
REC track into a NOTE. We created a new status called
discontinued draft. Keeps things on patent policy.
astearns: I think we're talking about putting an informative note in
the current draft, not making the draft a note.
fantasai: I'm fine with having it in an appendix.
dbaron: My reaction to putting the old thing in a historical appendix
is that maybe that is spec versioning done right, where what
we normally do is spec versioning done wrong
dbaron: because currently people land on the wrong version of a spec
dbaron: but sticking things in as a historical note is maybe a better
way of describing history over time than separate documents
astearns: I'm a fan of documenting how a decision has been arrived at
astearns: instead of having to dig through minutes, or do discussion
spelunking of your own
astearns: Any other comments on what to do with the current draft of
Nesting?
plinss: Not strongly opposed to having this as a note in the draft
plinss: not opposed to better changelog or history
plinss: should we do this as a general policy
plinss: personally this strikes me as, reluctant to say this, but I
think the reality is that implementations shipped prematurely
plinss: and this seems like a way of washing over the fact that they
did that
TabAtkins: benefit to users is that at least one version of Chrome and
Safari are shipping with a behavior that is not what's in
the spec we want
TabAtkins: and it's good to have documentation on what's doing, people
can understand that it's legacy behavior and it's how it
works
plinss: We have old versions of the spec, but I'm not going to die on
this hill
fantasai: Keeping in appendix given multiple shipping impls is a good
idea. Wouldn't be opposed to ? a section before the spec
is concluded saying what browsers shipped.
fantasai: ... then it's not implied that ? is what was intended by CSS
WG. But I think appendix is a good idea.
<TabAtkins> Sounds good to me
astearns: So conclusion seems to be that we will update the draft to
use the more relaxed syntax, and we will put the limitations
we're removing from draft into an informative appendix
plinss: My main concern is putting stake in the heart of Option 3
plinss: and not going with that as the specced behavior
jensimmons: If you want to think about it that way you can, but I do
not believe we're putting a stake in the heart of Option 3,
I believe we're continuing to evolve Option 3 in the
direction that authors want
jensimmons: but not going to to debate that semantic with you
plinss: I just want that ampersand is no longer required in certain
situations
TabAtkins: yes, we are abandoning the spec text for that and going
with the lookahead/reparse that was decribed in the issue
plinss: Desire to keep the ampersand behavior, it sounds like Safari
might not implement the lookahead option, and I hope that's
not the case
TabAtkins: not relevant for us to discuss Apple's shipping schedule,
WG is deciding for the future
jensimmons: You should take nothing that I'm saying as anything about
our plans or shipping schedules
<TabAtkins> Can we please resolve and stop talking sideways about
things that aren't the issue
plinss: I'm interpreting that from your desire to keep this behavior
in a spec somewhere
astearns: I think it's time to move on
astearns: We have a proposed resolution, any objections?
RESOLVED: Keep the current spec parsing behavior in an Appendix,
update the spec to use the lookahead option
Relaxing the Syntax Further: Parsing Strategy
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7961
astearns: There are other parts of this issue, TabAtkins you have a
long comment on the ways in which we're going to be able
to loosen restrictions, would it be productive to go into
details?
TabAtkins: sure
TabAtkins: Using the behavior described in the issue, where we first
parse as declaration, see if it's valid, and then go back
and parse as rule
TabAtkins: is super flexible except for two restrictions on future
syntax
TabAtkins: One restriction is that we never put a semicolon in the
prelude of a rule; which is already the case for at-rules,
which will end the block early
TabAtkins: as long as we never put a semicolon as part of a selector
we're good; and I doubt we'll ever want to do that
TabAtkins: The second is protecting against misparsing as a rule
TabAtkins: rules can end earlier than a declaration: they go until a
semicolon *or a {}-block*
TabAtkins: If parse as a rule, then there could be content after the
{} which gets parsed as a new item
TabAtkins: to avoid that, if we ever do top-level {} in a property,
we put it at the end
TabAtkins: Ideally we put it as the whole property value, since that
hits invalid selector as soon as you get to the ": {"
combination
TabAtkins: If we adopt that future restriction, then we will have
effectively future-compatible parsing
TabAtkins: 1. No semicolons in selectors
TabAtkins: 2. Nothing after {} in a declaration.
TabAtkins: We don't control custom properties, and you screw up a
var() statement (which is the only thing that can be
invalid in a declaration)
TabAtkins: then could have some problem of it reparsing as a rule
TabAtkins: The fix for that is, if the parser sees something that
looks like a custom property, it is guaranteed to parse
as a declaration. We will not reparse as a rule.
TabAtkins: This avoids corner case of producing an unexpected parse
TabAtkins: This does mean that you can't have a selector tag name
that starts with --
TabAtkins: but in HTML that's not a valid name anyway
TabAtkins: in rare case that you need this, you can use the "wrap
in an :is()" trick from Option 3
TabAtkins: that's the one case where ppl might need to worry about it,
and it would not be relevant to the Web only some weird
esoteric language
plinss: You could escape the dash?
TabAtkins: no, because it'll still be an ident. Not based on raw text
lookup
TabAtkins: e.g. if you escape a custom (or not custom) property name,
it's still recognized as such
fantasai: The first 2 make sense to me. The last one... we had some
discussions about custom selectors or something like that...
will that interfere?
TabAtkins: No. We can't have custom selectors that are just an ident
without a prefix anyway, because they will clash with type
selectors (at a grammar leve)
TabAtkins: so already not in a syntax space that we can get into
<fantasai> wfm
plinss: In general, I'm happy with this. Just to confirm, you always
try to parse as a declaration right?
TabAtkins: yes
plinss: Concern is if we add further symbols to selectors as
combinators and/or start adding symbols to properties to do
interesting tricks
plinss: do we have possibilities of collisions? I think we're okay?
TabAtkins: Depending what we do, possibility of clash exists, but in
practice it's hard to design a syntax that would be both
a valid declaration and a valid rule
TabAtkins: something to keep in mind as we design any new thing in
property names
plinss: The real restriction is using braces in the property name part
of the syntax? ... though I don't see us doing that much
plinss: [missed too fast]
TabAtkins: If we never touch curly braces in properties, we have to be
careful, but otherwise we're good with anything
astearns: Any other comments?
astearns: Are you porposing putting these future restrictions into
the draft? Or just adjusting parsing
TabAtkins: These are restrictions we should document for us, maybe put
it in the wiki
TabAtkins: not relevant to authors or implementers
astearns: So we need resolutions on ???
TabAtkins: I think we resolved on those last week, but if you think we
need a separate resolution that's fine
astearns: Happy to go with previous if that's sufficient
fantasai: I would like us to resolve on the restrictions we just
discussed, and to put them in a <details> note in the spec
TabAtkins: sounds fine to me, but it would go into the Syntax spec
astearns: ok, so in syntax spec, but linking back to nesting
astearns: Proposed that we document these restrictions on future synax
in Syntax, and link back to Nesting. Objections?
RESOLVED: Document restrictions on future syntax in Syntax, linking
back to Nesting:
1. No semicolons in selectors
2. Nothing after {} in a declaration.
3. --ident always kicks off declaration (not rule) parsing.
Consider dividing syntax differently
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8251
TabAtkins: I think this one is moot given previous resolutions, but
if dbaron has anything to discuss
dbaron: I'm fine with moot
astearns: Anyone else with concerns?
astearns: no change?
RESOLVED: Close as no longer relevant.
TabAtkins: changes already made in other issues
Require `div&`, disallow `&div`, for Sass compat
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8662
TabAtkins: In previous version of Nesting, we relaxed restriction to
starting with a tag selector in order to allow & at the
front
TabAtkins: which was required for previous parsing solutions
TabAtkins: SASS uses & as a textual substitution, so if you write
&div, you're asking SASS to append the letters "div",
so if your parent selector was ".foo" you get ".foodiv"
TabAtkins: having this mismatch would be an annoying upgrade story for
them, because this sort of concatenation is very heavily
used due to object-oriented class naming patterns
TabAtkins: On the other hand, putting additional type selectors on the
compound selector is exceedingly rare
TabAtkins: she's heard the request only a few times
TabAtkins: So this is very low priority for them
TabAtkins: upshot of all this, is I suggest we remove the relaxed
restriction that allows type selectors to not be at the
front
TabAtkins: restoring us to previous restriction, which requires the
tag selector in front
TabAtkins: then you can write div& but not &div
TabAtkins: which protects that syntax space for SASS and related
languages
TabAtkins: This also helps with some degree of migration
TabAtkins: if they know it's an error, they can autocorrect to the
right form
TabAtkins: I was initially uncertain of specifying this, if there is
already usage of &div in Chrome or Safari
TabAtkins: but apparently Chrome's implementation never relaxed that
restriction so &div has been invalid this whole time
TabAtkins: so at least for Chrome, this isn't an issue, so making this
invalid again would be fine
TabAtkins: unclear about Safari I couldn't test
TabAtkins: So I propose to revert the syntax restrictions
matthieu: [missed]
matthieu: We don't have the same behavior as Chrome, so it would be a
breaking change for us
astearns: Given that there is likely not that much content targetting
Safari's current implementation, would you be ok with this
change?
matthieu: Pretty sure there are zero websites targetting it, so won't
break the Web
<emilio> +1 to keep that restriction, fwiw on Firefox's impl I never
implemented it either
jensimmons: Curious to know what miriam thinks about this issue
miriam: I think this is a good idea, for the reasons Tab listed
miriam: I am not on the internals of everything that Natalie is
conerned about here, but was part of the conversation with
Tab and agree this is the direction to go to minorly limit
a problem
oriol: I'm opposed to the restriction, but not clear to me how exactly
it's helping. In SASS the behavior is something else, and ppl
are using that behavior, if they switch to Nesting they will
have to adapt somehow anyway
oriol: I'm not sure whether it's invalid or it means something
different, if it is that relevant to people
TabAtkins: As much as possible, SASS tries not to interpret valid CSS
differently as how browsers would interpret it
TabAtkins: It is helpful if we put it as invalid syntax, so it is
definitely not something that would mean something in
the browser
TabAtkins: It's not strictly necessary, because they'll have compat
pain anyway, but a long-term goal here, is that as long as
author is not using SASS-specific features, they want to
emit native CSS in the future
TabAtkins: being certain about using CSS-compatible syntax or invalid
syntax that is SASS-interpreted is a goal
emilio: If we ever expose the final selector somehow, it would be
weird if this couldn't be serialized in anyway
emilio: so I support not allowing &div
emilio: In particular, if devtools wanted to show the final selector
that this element matched, you want to see something useful
emilio: if you write &div, you can't just expand it
emilio: so I would prefer to avoid this special case
astearns: Other comments or concerns?
TabAtkins: Proposed to remove relaxation of type selector rules,
keep current rule that type selector must be first in a
compound selector
astearns: objections?
RESOLVED: type selector remains required first; &div is invalid
Feature detection for nesting
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/8399
astearns: We have a feature-detection story, question is how to detect
browsers that support nesting vs don't support nesting?
astearns: Is that what's remaining in this issue?
TabAtkins: unsure... someone else should take this
SebastianZ: We need some way to migrate and have fallbacks for old
browsers
SebastianZ: so the question is how to allow feature-detection, and at
the same time do it so that all the browsers don't fail
completely
SebastianZ: Of course they don't support nesting, but we need some way
to handle that case
matthieu: We need more than just selector(&)?
SebastianZ: selector(&) does work, but it focuses on style rules.
Doesn't target whether other rules can be nested, or
media rules, or something else
astearns: Given that we have not much time yet, does it make sense
to continue the discussion of this upgrade strategy in this
issue, or should there be a separate issue just on the path
we want authors to take when they don't know whether the
browsers supports nesting or not?
SebastianZ: I think there's an issue targetting the author
experience... not sure which one it was
astearns: Since this feature is titled Feature Detection, should we
close this issue and find or create an issue about the
author experience?
SebastianZ: Hard to say
SebastianZ: you want feature detection for author so that they can
migrate to nesting, so they're both entangled
ACTION: astearns to find path forward for this author-experience
issue, whether to continue with this issue or make a new one
Meeting closed.
Received on Tuesday, 23 May 2023 05:35:01 UTC