- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Apr 2023 15:39:57 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-nesting-1] Can we relax the syntax further?`, and agreed to the following:
* `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.`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> astearns: We looked at lookahead possibilities<br>
<fantasai> ... and discussion in this issue about relaxing syntax further to take advantage of lookahead proposed<br>
<fantasai> ... question of whether to do in this level and update current draft, or create new level for lookahead<br>
<fantasai> ... so that's what I wanted to get to first<br>
<fantasai> 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<br>
<fantasai> ... might have only one implementation, not more<br>
<fantasai> ... since we'll all be moving to the new option<br>
<fantasai> ... so there wouldn't be 2 impls of what's in the current draft, except as historical artifact<br>
<fantasai> ??: For Safari, we are on the path to release the current implementation<br>
<fantasai> ... so there will be two implementations<br>
<fantasai> astearns: Point is not two implementations of the limited syntax that requires recasting certain selectors<br>
<fantasai> jensimmons: idk if it matters if it's two levels or one level<br>
<fantasai> ... 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.<br>
<fantasai> ... and that's what I believe is not a wise thing to do<br>
<fantasai> ... if things had played out differently, might be reasonable to throw out text that wasn't shipping in any browser<br>
<fantasai> ... but in this case we have two shipping implementations<br>
<fantasai> ... nevermind about REC, but Chrome has already shipped and Safari is going to ship<br>
<fantasai> ... and doesn't seem wise to me to completely delete the spec text that describes what two browsers have done along this complicated path<br>
<fantasai> ... It could be a Note, could be somehting to say that this existed at some point, here's the description<br>
<fantasai> ... Once zero browsers have it in their implementation could delete it<br>
<fantasai> ... but going back on this path that was promised and act as if such implementations are off spec / non-compliant is not helpful<br>
<fantasai> astearns: not illegal, just not required once implementations update<br>
<fantasai> jensimmons: Fine that never required, Firefox is not required to do this implementation of course<br>
<fantasai> ... whatever written down should say that<br>
<fantasai> astearns: Could have a historical note saying, this is a thing that we had a long the way, and acknowledge it<br>
<fantasai> jensimmons: Yes, that's my preference over deleting it all<br>
<fantasai> TabAtkins: I'm fine with moving to historical appendix<br>
<fantasai> plinss: What's the benefit to authors?<br>
<fantasai> astearns: not memory-holing the previous discussion<br>
<fantasai> plinss: we have plenty of minutes, online discussions, not pretending it never happened<br>
<fantasai> astearns: Not talking about specifying, just having a note<br>
<fantasai> TabAtkins: I think it's useful to have a description of what some implementations are doing, at least until they disappear into obscurity<br>
<fantasai> scribe+ TabAtkins<br>
<dbaron> Scribe+ dbaron<br>
<dbaron> 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.<br>
<dbaron> astearns: I think we're talking about putting an informative note in the current draft, not making the draft a note.<br>
<dbaron> fantasai: I'm fine with having it in an appendix.<br>
<astearns> ack fantasai<br>
<astearns> ack dbaron<br>
<fantasai> 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<br>
<fantasai> ... because currently people land on the wrong version of a spec<br>
<fantasai> ... but sticking things in as a historical note is maybe a better way of describing history over time than separate documents<br>
<fantasai> astearns: I'm a fan of documenting how a decision has been arrived at<br>
<fantasai> ... instead of having to dig through minutes, or do discussion spelunking of your own<br>
<fantasai> astearns: Any other comments on what to do with the current draft of Nesting?<br>
<fantasai> plinss: Not strongly opposed to having this as a note in the draft<br>
<fantasai> ... not opposed to better changelog or history<br>
<fantasai> ... should we do this as a general policy<br>
<fantasai> ... personally this strikes me as, reluctant to say this, but I think the reality is that implementations shipped prematurely<br>
<fantasai> ... and this seems like a way of washing over the fact that they did that<br>
<fantasai> 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<br>
<fantasai> ... 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<br>
<fantasai> plinss: We have old versions of the spec, but I'm not going to die on this hill<br>
<astearns> ack fantasai<br>
<dbaron> fantasai: Keeping in appendix given multiple shipping impls is a good idea. Wouldn't be opposed to ? a section befor eth spec is concluded saying what browsers shipped.<br>
<dbaron> fantasai: ... then it's not implied that ? is what was intended by CSS WG. But I think appendix is a good idea.<br>
<TabAtkins> Sounds good to me<br>
<fantasai> 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<br>
<fantasai> plinss: My main concern is putting stake in the heart of Option 3<br>
<fantasai> ... and not going with that as the specced behavior<br>
<fantasai> 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<br>
<fantasai> ... but not going to to debate that semantic with you<br>
<fantasai> plinss: I just want that ampersand is no longer required in certain situations<br>
<fantasai> TabAtkins: yes, we are abandoning the spec text for that and going with the lookahead/reparse that was decribed in the issue<br>
<fantasai> 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<br>
<fantasai> TabAtkins: not relevant for us to discuss Apple's shipping schedule, WG is deciding for the future<br>
<fantasai> jensimmons: You should take nothing that I'm saying as anything about our plans or shipping schedules<br>
<TabAtkins> Can we please resolve and stop talkingv sideways about things that aren't the issue<br>
<fantasai> plinss: I'm interpreting that from your desire to keep this behavior in a spec somewhere<br>
<fantasai> astearns: I think it's time to move on<br>
<fantasai> astearns: We have a proposed resolution, any objections?<br>
<fantasai> RESOLVED: Keep the current spec parsing behavior in an Appendix, update the spec to use the lookahead option<br>
<fantasai> 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?<br>
<fantasai> TabAtkins: sure<br>
<fantasai> 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<br>
<fantasai> ... is super flexible except for two restrictions on future syntax<br>
<fantasai> 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<br>
<fantasai> ... 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<br>
<fantasai> TabAtkins: The second is protecting against misparsing as a rule<br>
<fantasai> ... rules can end earlier than a declaration: they go until a semicolon *or a {}-block*<br>
<fantasai> ... If parse as a rule, then there could be content after the {} which gets parsed as a new item<br>
<fantasai> ... to avoid that, if we ever do top-level {} in a property, we put it at the end<br>
<fantasai> ... Ideally we put it as the whole property value, since that hits invalid selector as soon as you get to the ": {" combination<br>
<fantasai> TabAtkins: If we adopt that future restriction, then we will have effectively future-compatible parsing<br>
<fantasai> ... 1. No semicolons in selectors<br>
<fantasai> ... 2. Nothing after {} in a declaration.<br>
<fantasai> 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)<br>
<fantasai> ... then could have some problem of it reparsing as a rule<br>
<fantasai> 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<br>
<fantasai> ... This avoids corner case of producing an unexpected parse<br>
<fantasai> ... This does mean that you can't have a selector tag name that starts with --<br>
<fantasai> ... but in HTML that's not a valid name anyway<br>
<fantasai> ... in rare case that you need this, you can use the "wrap in an :is()" trick from Option 3<br>
<fantasai> ... 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<br>
<fantasai> plinss: You could escape the dash?<br>
<fantasai> TabAtkins: no, because it'll still be an ident. Not based on raw text lookup<br>
<astearns> ack fantasai<br>
<fantasai> ... e.g. if you escape a custom (or not custom) property name, it's still recognized as such<br>
<plinss> q+<br>
<dbaron> 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?<br>
<fantasai> 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)<br>
<fantasai> ... so already not in a syntax space that we can get into<br>
<astearns> ack plinss<br>
<fantasai> plinss: In general, I'm happy with this. Just to confirm, you always try to parse as a declaration right?<br>
<fantasai> TabAtkins: yes<br>
<fantasai> plinss: Concern is if we add further symbols to selectors as combinators and/or start adding symbols to properties to do interesting tricks<br>
<fantasai> ... do we have possibilities of collisions? I think we're okay?<br>
<fantasai> 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<br>
<fantasai> ... something to keep in minde as we design any new thing in property names<br>
<fantasai> plinss: The real restriction is using braces in the property name part of the syntax?<br>
<fantasai> ... though I don't see us doing that much<br>
<fantasai> plinss: [missed too fast]<br>
<fantasai> TabAtkins: If we never touch curly braces in properties, we have to be careful, but otherwise we're good with anything<br>
<fantasai> astearns: Any other comments?<br>
<fantasai> astearns: Are you porposing putting these future restrictions into the draft? Or just adjusting parsing<br>
<fantasai> TabAtkins: These are restrictions we should document for us, maybe put it in the wiki<br>
<fantasai> ... not relevant to authors or implementers<br>
<fantasai> astearns: So we need resolutions on ???<br>
<fantasai> TabAtkins: I think we resolved on those last week, but if you think we need a separate resolution that's fine<br>
<fantasai> astearns: Happy to go with previous if that's sufficient<br>
<astearns> ack fantasai<br>
<fantasai> fantasai: I would like us to resolve on the restrictions we just discussed, and to put them in a <details> note in the spec<br>
<fantasai> TabAtkins: sounds fine to me, would but it into the Syntax spec<br>
<fantasai> astearns: ok, so in syntax spec, but linking back to nesting<br>
<fantasai> astearns: Proposed that we document these restrictions on future synax in Syntax, and link back to Nesting. Objections?<br>
<fantasai> 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.<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7961#issuecomment-1514955984 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 April 2023 15:40:00 UTC