[CSSWG] Minutes Nesting Breakout 2023-04-19 [css-nesting-1][css-syntax-3]

   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
   - 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
   - RESOLVED: type selector remains required first; &div is invalid

   Feature detection for nesting
   Discussion will continue in GitHub.


Agenda: https://lists.w3.org/Archives/Public/www-style/2023Apr/0009.html
Logs: https://www.w3.org/2023/04/19-css-irc

   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
   ??: 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
   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
   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
   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
   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

   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 ": {"
   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
   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
   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
   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
   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
   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
   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
   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