- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Jan 2023 18:40:53 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `CSS Nesting Syntax`, and agreed to the following:
* `RESOLVED: Adopt Option 3`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Topic: CSS Nesting Syntax<br>
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/8249<br>
<chris> resolving two color issues in <10min is unprecedented<br>
<fantasai> TabAtkins: I'm willing to summarize what I believe plinss's position is, he can correct<br>
<fantasai> TabAtkins: fear is that the direction the spec is specifying will overly constrain future CSS<br>
<fantasai> TabAtkins: certain new syntactical things in properties or selectors<br>
<fantasai> TabAtkins: proposal is instead to have a dedicated syntax to mark things as a selector<br>
<fantasai> TabAtkins: that way all future syntactical developments would still be allowed<br>
<lea> q?<br>
<fantasai> TabAtkins: and future developments for selectors, which might currently conflict with properties, would also be allowed<br>
<fantasai> TabAtkins: because you have a glyph to mark it as a selector<br>
<fantasai> TabAtkins: related is the 8251 issue, where dbaron discusses the things that trigger selector processing and not currently used by selectors<br>
<fantasai> TabAtkins: this issue accepts mixing of properties and selectors in grammar space<br>
<fantasai> TabAtkins: issue is, we've already discussed previously, what peter is suggesting<br>
<fantasai> TabAtkins: this was Option 1, you had to start with & or @nest or various variants thereof<br>
<fantasai> TabAtkins: This was rejected by WG for verbosity and for copy-paste limitations<br>
<fantasai> TabAtkins: core issue is, WG has looked over that syntax direction and rejected it in the past<br>
<jensimmons> q+<br>
<fantasai> TabAtkins: so I would like to re-affirm that decision, that we're not going to use a dedicated marker syntax of some kind to denote selectors and separate them from properties<br>
<fantasai> TabAtkins: but rather go with current approach of mixing the space<br>
<lea> q+<br>
<fantasai> TabAtkins: make sure the Syntax spec creates a clear dividing line<br>
<TabAtkins> fantasai: I think something Tab didn't emphasize is the core part of Peter's concern for forward compat<br>
<TabAtkins> fantasai: The real effect of forwards compat isn't as - we'r enot limiting as much as it seems like we are<br>
<TabAtkins> fantasai: What we're allowing for the future is anything that's invalid, regardless fo whether it's currently property or selector<br>
<TabAtkins> fantasai: The space of "what is invaidl junk" is actually really broad even with our current proposal<br>
<Rossen_> ack fantasai<br>
<Zakim> fantasai, you wanted to react to ntim<br>
<fantasai> https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1362033982<br>
<TabAtkins> fantasai: The ony thing we can't expand into is a super-limited syntax space that I can't imagine us actually doing<br>
<fantasai> #stuff starting with a symbol { anything in this block } valid-property: value;<br>
<TabAtkins> fantasai: We cant' start with a symbol, *and* has a curly-brace block *and* is followed by something tha tlooks like a property<br>
<TabAtkins> fantasai: This is the only thing you can't define in the future is a cool new feature<br>
<TabAtkins> fantasai: If it doesn't look like that it's invalid - whether a property or style rule, we throw it out<br>
<TabAtkins> fantasai: And in th efuture we can call it valid either way<br>
<TabAtkins> fantasai: So for concern abou tpainting us into a corner, it's acutally a very small corner and the rest of the space is open<br>
<fantasai> plinss: Just want to clarify a couple points, most of what Tab said is accurate<br>
<fantasai> plinss: it's not necessarily required to have a solution that prefixes every single rule<br>
<fantasai> plinss: also fine to create a new scope<br>
<fantasai> plinss: just nested brackets or whatever, that also solves the copy-paste problem<br>
<fantasai> plinss: just want something that delineates the syntax space<br>
<fantasai> plinss: we did resolve not to do this in the past, but I'm not sure that took everything into account<br>
<fantasai> plinss: not locked by previous decision<br>
<astearns> +1 to not taking older @nest decision as final<br>
<fantasai> jensimmons: I did hear plinss's concerns, and we've discussed exhaustively<br>
<fantasai> jensimmons: but despite downsides, I see all the momentum going towards Option 3 including from webdevs<br>
<Rossen_> ack jensimmons<br>
<fantasai> jensimmons: There was a lot of conversations after ?? meeting, and I appreciate dbaron, fantasai, TabAtkins investigating what we would limit ourslves<br>
<TabAtkins> s/??/final December/<br>
<plinss> q+<br>
<fantasai> jensimmons: but it seems we're not really limiting ourselves, so I think should move forward<br>
<fantasai> jensimmons: want a path that moves us forward and is realistic and acceptable<br>
<Rossen_> ack lea<br>
<fantasai> lea: A lot of things I wanted to say were mentioned by fantasai, still have a lot of space for expansion<br>
<fantasai> lea: but we could expand that space even further by reserving some characters<br>
<Rossen_> ack plinss<br>
<fantasai> plinss: I'm not sure I buy fantasai's argument<br>
<fantasai> plinss: it's not infinite, but there are cases where we wanted to do something but couldn't because shows up in the wild as some weird hack<br>
<fantasai> plinss: I think it'll be limiting<br>
<fantasai> plinss: example is custom properties, couldn't have done that if we had done this first<br>
<fantasai> plinss: I don't want us to get into that situation<br>
<TabAtkins> fantasai: Lets take the custom property eample<br>
<Rossen_> ack fantasai<br>
<Zakim> fantasai, you wanted to respond<br>
<TabAtkins> fantasai: say initial hypthen switched us to selector parsing<br>
<TabAtkins> fantasai: we could do it<br>
<Rossen_> Zakim, close queue<br>
<Zakim> ok, Rossen_, the speaker queue is closed<br>
<TabAtkins> fantasai: You'd throw it out as an invalid selector today<br>
<TabAtkins> fantasai: And that means we can reinterpret it later<br>
<TabAtkins> fantasai: Have you really looked at what the limiting case is?<br>
<TabAtkins> fantasai: The ocnditions are really strict. anything that's currently invalid and gets thrown out, we can reinterpret<br>
<TabAtkins> fantasai: have to keep in mind that the parsing in the nested context isnt' the same as top-level, we truncate at top-level semicolon even in selecto rparsing<br>
<lea> *Nesting itself* is a case where past syntax limits us in what we can do syntactically (going back, maybe we should have used something other than a colon for pseudos), but it's not an insurmountable problem, we are designing around it. We'll design around these issues in the future too, if they come up.<br>
<TabAtkins> fantasai: So there's very limited - can't think of anything you want to do that'll cause a problem<br>
<lea> q?<br>
<lea> q+<br>
<fantasai> plinss: we could solve this with lookahead<br>
<fantasai> plinss: also concerned that we have stuff that's valid for selectors and can't re-use for properties<br>
<fantasai> plinss: selectors can be really really really long, especialy with lists of selectors<br>
<argyle> q+<br>
<fantasai> plinss: thing at the end that changes selector or property, could get into situation that we cant solve without a lot of lookahead<br>
<fantasai> Rossen_: I've closed the queue, 2min past the hour<br>
<lea> regarding exploring lookahead, I tried. Here's a summary: https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1362739063<br>
<fantasai> Rossen_: Strong arguments in both directions<br>
<fantasai> Rossen_: alan proposed we make nesting an additional call, can make it as soon as next week e.g. 1hr before the main CSS call<br>
<fantasai> Rossen_: but right now we don't seem to have consensus<br>
<lea> +1 to Nesting breakout<br>
<fantasai> Rossen_: or we can take a resolution and ask Peter to file a formal objection<br>
<fantasai> TabAtkins: I would prefer to get the formal objection filed now if it's going to be filed, would rather not be in limbo<br>
<lea> let's try to avoid a FO as much as we can, the TAG is already overworked :(<br>
<fantasai> TabAtkins: fantasai and I explored the syntax space carefully, we don't think there's a real limitation there<br>
<astearns> have to drop<br>
<fantasai> TabAtkins: so I don't think further discussion will yield anything useful<br>
<lea> we need a Nesting breakout even regardless of the FO, don't we? So let's schedule that<br>
<fantasai> Rossen_: ok, we'll try to have a call for nesting, whether this topic is part of it or not is TBD<br>
<fantasai> Rossen_: I will call for objections, and then have a resolution that seems supported by rest of group<br>
<fantasai> Rossen_: Any objections?<br>
<fantasai> plinss: I clearly object. More than happen to have the long call or breakout or sub-breakout or whatever<br>
<fantasai> plinss: happy to let Tab and fantasai convince me that I'm wrong<br>
<fantasai> plinss: and to change my mind<br>
<oriol> I'm more on Peter's side on this topic<br>
<fantasai> plinss: but shy of that, or changing the processing rules, I sustain my objection<br>
<fantasai> Rossen_: It does seem this has been discussed over and over, and I hear support for this from many people<br>
<fantasai> Rossen_: so suggest we resolve this, or take up as additional changes to the current resolution<br>
<fantasai> plinss: We've resolved on Option 3 with this issue open<br>
<fantasai> plinss: still saying we can discuss at the breakout call, so what's point of resolving?<br>
<fantasai> Rossen_: we resolved to discount other options, not to adopt Option 3<br>
<fantasai> [some discussion of what we resolved or didn't]<br>
<fantasai> jensimmons: would be helpful to take the temperature of the room<br>
<lea> fwiw, I agree with plinss that lookahead should be explored more. But not primarily for futureproofing (I think there's enough syntax space that we're not painting ourselves into a corner), but primarily for syntax ergonomics. I'm not convinced it's an unsolvable problem.<br>
<fantasai> fantasai: straw poll, and then close discussion until next week?<br>
<fantasai> Rossen_: A = support Option 3, and B = not support it<br>
<argyle> A<br>
<jensimmons> A<br>
<ydaniv> A<br>
<TabAtkins> A<br>
<fantasai> A<br>
<oriol> B<br>
<bradk> A<br>
<SebastianZ> A<br>
<miriam> A<br>
<plinss> B<br>
<dholbert> A<br>
<GameMaker> A<br>
<flackr> A<br>
<davidleininger> A<br>
<futhark> A<br>
<florian> A<br>
<lea> I find the question unclear, so I'm not voting.<br>
<lea> A<br>
<Rossen_> A<br>
<fantasai> Rossen_: pretty strong signal here, let's go ahead and record this as a resolution. We will try to get the extra nesting discussions, Peter I'm hoping you can proceed with next steps if you want to pursue formal objection or wait until next week<br>
<fantasai> plinss: happy to discuss on breakout call, but want to actually get to it<br>
<fantasai> Rossen_: we've never had a rule that we can't re-open previous resolutions :)<br>
<fantasai> plinss: that's been teh arugment several times<br>
<fantasai> florian: from the other angle, if you do file an FO and are subsequently convinced, you can retract it<br>
<fantasai> plinss: if discusisng in a week, don't need to file an objection today<br>
<fantasai> Rossen_: We'll schedule for next week then<br>
<fantasai> jensimmons: please schedule for next week, it's quite importnat to us<br>
<fantasai> RESOLVED: Adopt Option 3<br>
<fantasai> Rossen_: I appreciate everyone staying longer than usual, we don't almost ever, but this is an important topic to many<br>
<fantasai> Rossen_: we'll schedule an additional meeting next week<br>
<fantasai> Meeting closed.<br>
<Rossen_> Zakim, end meeting<br>
<Zakim> As of this point the attendees have been Rossen_, flackr, SebastianZ, khush, bramus, ydaniv, rachelandrew, bradk, emilio, chrishtr, alisonmaher, TabAtkins, futhark, plinss, chris,<br>
<Zakim> ... morgan, fantasai, jensimmons, (chat, only, for, the, beginning), masonf, emeyer, miriam, dholbert, vmpstr, lea, smfr, oriol, GameMaker, jfkthame<br>
<Zakim> RRSAgent, please draft minutes<br>
<Zakim> I am happy to have been of service, Rossen_; please remember to excuse RRSAgent. Goodbye<br>
<RRSAgent> I have made the request to generate https://www.w3.org/2023/01/11-css-minutes.html Zakim<br>
<jensimmons> Hey — did the minutes of the last issue get posted to GitHub? I don't see them.<br>
<jensimmons> dbaron — does the new bot close minute taking for the last issue & post those to Gitbhub when "end meeting" is triggered?<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1379326665 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 January 2023 18:40:55 UTC