- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Apr 2023 16:03:59 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-nesting] Problem with mixing properties and selectors`, and agreed to the following:
* `RESOLVED: Close no change`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> scribenick: fantasai<br>
<fantasai> astearns: We have this one issue, so I want to set aside the question of feature detection and down-compat<br>
<fantasai> ... and also set aside question of Option 3 vs other SASS-like syntaxes<br>
<fantasai> ... and go directly to, are we on the right path on a SASS-like syntax<br>
<fantasai> ... or should we consider some other type of syntax?<br>
<fantasai> astearns: What I would like to do is look at the argument being made in this issue around the drawbacks of a SASS-like syntax<br>
<fantasai> ... and make the strongest case that we can, without arguing against anything yet, without coming up with counter-arguments, just going with the strongest argument we can for "we're on the wrong path" and see if anyone on the call agrees we should be looking at alternatives at this point<br>
<fantasai> ... plinss, does this sound like a fair way forward?<br>
<fantasai> plinss: yes, but we have to discuss the drawbacks of existing SASS<br>
<fantasai> astearns: I'm suggesting we identify the drawbacks, but don't argue them<br>
<fantasai> ... come up with the strongest presentation of the drawbacks, before we tear them apart<br>
<fantasai> ... no no counter-arguments yet<br>
<fantasai> astearns: Issue is about SASS-like syntax vs something else (such as an at-rule)<br>
<fantasai> ... plinss has identified 4 drawbacks for a SASS-like syntax<br>
<fantasai> astearns: Issues with error-recovery<br>
<fantasai> astearns: Restrictions on future-syntax<br>
<fantasai> astearns: Doing something SASS-like, but not actually SASSy (concatenation)<br>
<fantasai> astearns: Ideal syntax requires changes to parser model<br>
<fantasai> astearns: With that summary, is there anything someone wants to add that would strengthen this list of concerns?<br>
<fantasai> plinss: Want to clarify my position<br>
<fantasai> ... I didn't like the proposed direction<br>
<fantasai> ... but because I have concerns<br>
<fantasai> ... I like how we're going, but I also think the at-rule approach has merits because it doesn't have the drawbacks<br>
<fantasai> ... My other concern is that, I think we look at both issues, and we've said "it's not great but it's not that, but if it's an at-rule or SASS-like, we chose SASS-like"<br>
<fantasai> ... I'm not sure we've actually looked at all the issues together, and asked, in aggregate, are we still on the right path<br>
<fantasai> ... Rather than looking at each decision in isolation<br>
<fantasai> ... I think the issues are manageable, any one of them is not a reason to reject; but together might be enough<br>
<fantasai> ... I'm leaning towards at-rule because it's safer<br>
<fantasai> ... once we go down path of SASS-like syntax, we're stuck with its drawbacks forever<br>
<fantasai> astearns: Of everyone on this call, is there anyone who has the same concerns?<br>
<plinss> https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1496776853<br>
<fantasai> SebastianZ: Thread is long, can we point to the comment summarizing the concerns?<br>
<fantasai> astearns: We can get into that, but we risk running into an isolated argument<br>
<fantasai> SebastianZ: I can see the point that plinss is outlining<br>
<fantasai> ... these are problems<br>
<fantasai> ... and error-recovery is the most important one<br>
<TabAtkins> q+ about error recovery<br>
<fantasai> ... which would be no problem if we went the at-rule route<br>
<TabAtkins> Zakin, shut up<br>
<fantasai> plinss: Just want to confirm that everyone understands the issues, e.g. what do I mean by error-recovery problem<br>
<fantasai> astearns: OK, let's going to details of error-recovery<br>
<fantasai> ... but keep going with approach of making the strongest possible case<br>
<fantasai> astearns: In my opinion, the worst bit of error-recovery problem is, the current proposal allows for rules to be dropped in error-recovery in a mixed selector-and-property syntax<br>
<fantasai> ... that would not otherwise be dropped<br>
<fantasai> ... so the order in which you declare your properties and nested selectors<br>
<fantasai> ... can cause parts of the stylesheet to be ignored<br>
<fantasai> plinss: If you have a rule that's dropped, it can eat a following declaratoin<br>
<fantasai> ... normally within a declaration block, we're in declaration recovery<br>
<TabAtkins> q+<br>
<fantasai> ... if we mix with rules, they have different error-recoery behavior<br>
<astearns> ack TabAtkins<br>
<fantasai> ... if you're recovering from a declaration, but you're parsing a rule, you're going to eat the next declaration<br>
<fantasai> TabAtkins: went through details of error-recovery<br>
<fantasai> ... if talking about eating of things unexpectedly, there are two potential ways<br>
<fantasai> ... One is an old browser seeing nesting code<br>
<fantasai> ... firstly, this will wreck your stylesheet anyway<br>
<fantasai> ... You can construct an artificial scenario where optional things are nested, but it's very narrow and strange<br>
<fantasai> ... usually necesary rules are written there, if you lose them your page is broke<br>
<fantasai> ... The fact that the following declaration might get eaten in addition to rules being dropped, you have a problem anyway<br>
<fantasai> TabAtkins: the other concern is in a browser that does understand nesting, what can happen if you have invalid rule followed by a declaration<br>
<fantasai> ... or invalid declaration followed by a rule<br>
<fantasai> ... details in the post<br>
<fantasai> ... but with parsing change that's already in the Syntax spec<br>
<fantasai> ... where a nested rule -- if you see a semicolon in the prelued (before {}), we immediately stop and throw it out<br>
<fantasai> ... with that change, it's a stable, predictable amount of things being thrown out<br>
<fantasai> ... if we parse an invalid rule, we read until we get to the semicolon after the rule<br>
<fantasai> ... restart, try to parse as a rule, and then [missed]<br>
<fantasai> ... The other way around, invalid declaration followed by invalid rule<br>
<fantasai> ... we first parse until invalid declaration ends (;) , then restart as a rule but abort on the semicolon again anyway<br>
<fantasai> ... and then parse the rule afterwards<br>
<fantasai> ... There's a small corner-case around custom properties, because you can put anyting in them and might have something that looks like a rule inside, or [missed2]<br>
<fantasai> ... but even an at-rule based syntax will interfere with custom properties in that way, so either way we have a problem<br>
<fantasai> ... if you do something weird enough<br>
<fantasai> TabAtkins: so in a nesting-capable browser, there's very little possibility of eating a following declaration by accident<br>
<fantasai> ... and in nesting-incapable browser, you have major problems anyway; and you should be putting your declarations at the top anyway, which avoids all such problems<br>
<fantasai> astearns: wanted to avoid counter-arguments ...<br>
<fantasai> ... SebastianZ, enough explanation?<br>
<fantasai> SebastianZ: yes<br>
<fantasai> plinss: I'd like to counter<br>
<fantasai> ... Nothing Tab said that's incorrect, except we differ on relative importance<br>
<fantasai> ... Obviously if someone buys into nesting and they go all-in, yes the entire stylesheet is b0rked and need not go into details<br>
<fantasai> ... but CSS is designed for progressive enhancement<br>
<fantasai> ... a lot of websites, it isn't a single person writing a stylesheet; all aggregated together<br>
<fantasai> ... you might have one person sprinkling a little nesting here and there<br>
<dbaron> Scribe+ dbaron<br>
<fantasai> ... and they are very likely to not read the spec and know that nested rule should go last<br>
<fantasai> ... and might end up dropping a significant amount of a declaration<br>
<jensimmons> q+<br>
<fantasai> ... and it's also entirely possible that they won't see that, because they're on a modern machine, and not on old low-powered device<br>
<TabAtkins> Again the nested rule is *also* getting dropped. Page is already broken.<br>
<fantasai> ... so I think the likelihood is higher than Tab thinks<br>
<fantasai> plinss: Wrt browsers that do support nesting, I agree that the current approach is robust except wrt custom properties<br>
<fantasai> ... my concern is what happens in the future? If we want to add some new capability, new combinator or other strange syntax<br>
<fantasai> ... might restrict ourselves from what we'd do otherwise, or have a risk of some problems<br>
<astearns> ack fantasai<br>
<fantasai> astearns: that's example of how things are tangled up<br>
<dbaron> fantasai: I wanted to address question of downlevel clients and progressive enhancement<br>
<dbaron> ... I think authors will adapt practice of putting nested rules after declarations, generally what they do already. Not too concerned about that case.<br>
<dbaron> ... Usually not going to be doing this in progressive enhacement way, and if so follow best practice.<br>
<dbaron> ... more likely to see nested rules inside of @-rules.<br>
<dbaron> ... unlikely to see progressive enhancement of bare nested rules followed by a declaration. Not too worried about that case.<br>
<matthieudubet> q+<br>
<fantasai> astearns: when I see ppl using PostCSS examples, I immediately found declarations following after rules, it's common<br>
<fantasai> plinss: I agree the risk is small, percentage is low, and web is vast<br>
<fantasai> ... can still affect millions of people<br>
<astearns> ack jensimmons<br>
<fantasai> jensimmons: I have a question, because even though this issue is very long, there's not a simple, clear explanation that I could find of what gets eaten.<br>
<fantasai> ... so here's the question<br>
<fantasai> ... could someone very simply explain what gets eaten?<br>
<TabAtkins> here's the maximum dangerous situation: `<new-wacky-property-syntax>: {...} more-stuff;`. If they write this invalidly, or use in a Nesting-capable browser that doesn't understand the new syntax, what's the maximum damage?<br>
<fantasai> ... perhaps focused on borwsers that do support nesting<br>
<fantasai> plinss: in a browser that does support nesting, very little chance of things getting mis-eaten, except custom properties<br>
<fantasai> ... bigger concern is down-level clients<br>
<fantasai> ... becaue what gets eatin is a rule and the following declaration<br>
<fantasai> ... if I start a rule, followed by a declaration, and the browser doesnt' understand that the rule is a rule and parse it as such<br>
<fantasai> ... it will go into declaration error-recovery, and eat the rule *and* the next declaration (up to the semicolon)<br>
<fantasai> jensimmons: And in browsers that do support nesting, something that gets eatn?<br>
<matthieudubet> q-<br>
<fantasai> astearns: only in custom properties where the custom property value is using a brace<br>
<fantasai> jensimmons: So if using nesting, and the thing they nest is something that doesn't make sense e.g. mispell the selector<br>
<matthieudubet> q+<br>
<TabAtkins> Damage is: since decl parsing failed, we restart as rule. We parse until the {}, and stop. Then we'll start parsing the stuff *after* the {} fresh. It's *theoretically possible* for this to be mistaken as a valid declaration or rule, rather than the suffix of an invalid declaration. But as long as we (the CSSWG) only design top-level {}-in-declarations to be the whole value, this isn't a problem.<br>
<fantasai> ... what happens to the rules after that nesting thing?<br>
<fantasai> astearns: I believe we're ok. Malformed thing gets dropped, and in browser that supports nesting everything after the dropped rule is retained<br>
<fantasai> ... right?<br>
<fantasai> plinss: I don't think there's a situation where we drop a rule [...]<br>
<fantasai> ... what gets dropped is a declaration that doesn't need to be dropped<br>
<fantasai> jensimmons: in browsers that don't support nesting<br>
<SebastianZ> q+<br>
<fantasai> plinss: right. Also in browsers that do, but in that case much more of a corner case. But in downlevel browsers much more common<br>
<fantasai> jensimmons: so in Nesting-supported browsers, would only have a problem in malformed case or a particular strange custom property value<br>
<fantasai> TabAtkins: After nesting is supported, it's not possible to eat a following declaration after anything invalid<br>
<fantasai> ... but if something is in valid, we might parse as a rule and the leftover stuff (that we didn't get to) could maybe be interpreted as a declaration<br>
<fantasai> ... but we shouldn't need to introduce such constructs<br>
<fantasai> plinss: Something that would have been interpreted as a preceding rule, you wind up with the tail end of that interpreted as another declaration or rule.<br>
<fantasai> ... agree that's a corner case<br>
<fantasai> plinss: In the future, we might end up introducing problems<br>
<fantasai> TabAtkins: we need two restrictions, one which is already in the spec, to avoid that<br>
<astearns> ack matthieudubet<br>
<fantasai> matthieudubet: If we mandate in the nesting syntax to have declarations first, then style rules, so you can't mix, don't we get rid of the issues?<br>
<fantasai> matthieudubet: since we know we can't mix, we don't have the issue<br>
<fantasai> matthieudubet: this is similar to Option 4, two blocks, but you don't write the braces<br>
<fantasai> matthieudubet: declarations first, and style rules after<br>
<fantasai> plinss: There's no rule for behavior that will change existing browers<br>
<fantasai> ... so even if we say it's invalid to put a declaration later, an older browser will be in declaration mode<br>
<fantasai> matthieudubet: but there's less risk of this happening, because nobody would want to write such a thing (since not supported in new browsers either)<br>
<fantasai> ... it's the same error-recovery, but you mitigate the risk of having this in actual style sheets<br>
<jensimmons> q?<br>
<fantasai> plinss: I think that's a valid approach... not sure that restriction on the SASS-like syntax is worth the benefit<br>
<fantasai> ... but it is a viable path<br>
<astearns> akc SebastianZ<br>
<emilio> q+<br>
<fantasai> SebastianZ: So if I understnad correctly, authors could put semicolon after the rule, and the next declaration wouldn't get eaten<br>
<fantasai> TabAtkins: correct<br>
<astearns> ack SebastianZ<br>
<fantasai> SebastianZ: So just for clarification, one could use that to support all the browsers that don't support nesting<br>
<jensimmons> q+<br>
<fantasai> ... of course they're still skipping the nested rule, but at least we don't have the next declaration gettin eaten<br>
<astearns> ack emilio<br>
<fantasai> plinss: We could mandate a semicolon after nested rules, to force doing that everywhere<br>
<fantasai> emilio: I think I like the declarations to be forced before<br>
<fantasai> ... especially since the behavior of interleaving is the same as if they were sorted before anyway<br>
<fantasai> ... if that satsifies everyone, then I think it's best<br>
<fantasai> ... mostly because that way we don't have the weird problem of explaining<br>
<fantasai> ... you put this after the nested rule, but the browser created an anonymous rule that put all teh declarations first<br>
<fantasai> ... and acts as if you had written it before<br>
<fantasai> ... so I think that might be nice<br>
<TabAtkins> that's the parser switch that all the impls hated before...<br>
<astearns> ack jensimmons<br>
<fantasai> +1 emilio, this clarifies the cascade<br>
<fantasai> jensimmons: I dont' like the idea of requiring that declarations go before nested rules<br>
<fantasai> ... like plinss says, people jam CSS into things all over the place<br>
<fantasai> ... it will make things less useful<br>
<emilio> q+<br>
<fantasai> ... and I always prefer to go for the better choice long-term and deal with limitations short-term when redesigning language<br>
<fantasai> jensimmons: wrt transition, my sense is that majority of authors won't use Nesting for 3-4 years<br>
<fantasai> ... those who do use it sooner, what I have been seeing is that they're using a preprocessor to do it<br>
<fantasai> ... so writing their own CSS nested, and then using some automated stack to process it back out into old-school CSS<br>
<fantasai> ... similar to using SASS<br>
<fantasai> ... I think that might really take off, the tools ppl build for that will be popular<br>
<TabAtkins> in particular, "no properties after rules" means at some point we need to decide we're "in rules". This requires some way of detecting "oh i tried to parse this as a prop but failed, looks like a rule" that won't misfire in weird cases.<br>
<fantasai> ... and they will preprocess it for older browsers<br>
<TabAtkins> the end result is actually *at least* as complex as today, possibly more<br>
<fantasai> ... I don't think there will be an epidemic of ppl writing progressive nested rules, they're too lazy to do that<br>
<fantasai> ... they already don't think about progressive enhancement nearly enough<br>
<astearns> eck emilio<br>
<fantasai> emilio: Reason I think this restriction is nice, not just for parsing, but let's say you don't know how nesting is specced<br>
<astearns> q+<br>
<TabAtkins> q+<br>
<fantasai> ... you put media query inside and then more declarations at the bottom<br>
<fantasai> ... that won't work like you expect<br>
<astearns> ack emilio<br>
<astearns> q--<br>
<fantasai> ... because the declarations are shifted up, and in some cases not a problem but I'm sure it will confuse people<br>
<fantasai> jensimmons: You mean, they dont' cascade as expected?<br>
<fantasai> emilio: right<br>
<fantasai> ... the rules inside the @media will be later in cascade order than the declarations outside @media but after it<br>
<fantasai> ... I would find it confusing if I didn't know internally how it works<br>
<fantasai> ... same for dropping bare declarations inside MQ and stuff, which we resolved they would be put into an anonymous rule at the front<br>
<fantasai> ... if you don't know that they get moved, it's super confusing<br>
<jensimmons> q-<br>
<fantasai> ... that they apply as if they're at the top<br>
<jensimmons> q+<br>
<fantasai> ... so I think that would be a good restriction not just for the transition<br>
<matthieudubet> yes it's also more obvious that the anonymous rule is after any declarations<br>
<matthieudubet> than*<br>
<fantasai> ... I think it's more understandable for anyone using nesting without knowing the details of the spec<br>
<astearns> q- later<br>
<fantasai> TabAtkins: no declarations allowed after rules is exactly a parser-switch of the kind the WG disliked<br>
<fantasai> ... and there's two ways we could possibly do it<br>
<fantasai> ... 1. We parse as today, you'll parse declarations properly but throw them out<br>
<fantasai> ... but this means some garbage rule might be ????<br>
<emilio> q+<br>
<fantasai> ... 2. We do a stronger parsing switch, where we have a mode switch that changes how things are parsed<br>
<astearns> s/garbage rule might be ????/garbage comment might be parsed as a rule/<br>
<fantasai> ... this is more dangerous, might be possible to trigger this mode unexpectedly<br>
<fantasai> ... and that's more complicated for us to be careful around in the future<br>
<fantasai> ... so I don't think there's any actual benefit for instituting a parser switch<br>
<astearns> q- later<br>
<astearns> zakim, close queue<br>
<Zakim> ok, astearns, the speaker queue is closed<br>
<fantasai> TabAtkins: [something that went around too many times to capture]<br>
<astearns> ack TabAtkins<br>
<fantasai> plinss: I think we're getting off into the weeds of trying to mitigate these issues, all I'm asking for is a sanity check<br>
<fantasai> ... if we look at all these issues, is it worth continuing down this path?<br>
<fantasai> ... if so, we can continue to hash out the issues<br>
<fantasai> astearns: Has anyone on the call been convinced that we should reconsider the path that we're on?<br>
<astearns> ack jensimmons<br>
<fantasai> ... if plinss is the only one, then perhaps we close this issue and open new issues about each individual small issue within the SASS approach<br>
<fantasai> jensimmons: I think the fact that declarations that come after a rule are earlier in the cascade being earlier in the cascade<br>
<fantasai> ... should add to the list<br>
<fantasai> ... I'm more concerned about that that the other things<br>
<fantasai> ... I don't believe we should throw out the declarations that come after the rules<br>
<TabAtkins> ("declarations after rules" is an issue with any syntax, it's not specific to any one unless we totally prevent mixing syntactically)<br>
<fantasai> ... I would prefer we investigate making the cascade *not* resorted<br>
<fantasai> ... if that's absolutely impossible, then we have to teach it as "it's going to be confusing in the cascade, so sort to the top, this is the best practice"<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to support emilio's point<br>
<jensimmons> q+<br>
<plinss> q+<br>
<astearns> ack emilio<br>
<fantasai> emilio: I think the general approach we're taking is preferable as well<br>
<fantasai> ... regarding Tab's comment<br>
<fantasai> ... we have similar parser switches, e.g. @import rules not allowed after other rules<br>
<fantasai> ... could easily implement as keep parsing as before, but throw out the declarations<br>
<fantasai> ... user-wise, as a CSS author, I would prefer if this worked<br>
<fantasai> ... and declarations were directly in the cascade<br>
<fantasai> ... but if we're not doing that, which is also reasonable if we're concerned about perf or something, I think the restriction is not a huge deal<br>
<TabAtkins> (note that Sass allows decls after rules, with exactly the same behavior as what we're specifying - all glommed together into the parent rule, preceding nested rules)<br>
<fantasai> ... we can discuss in another issue at another point in time<br>
<fantasai> astearns: I wanted to ask again, given the cluster of issues around the SASS-like syntax, are we convinced we're on the wrong path and should investigate alternative syntaxes?<br>
<emilio> TabAtkins ugh, I think that's dumb :/<br>
<fantasai> jensimmons: I think we're still going in the right direction, especially considering what we've heard from authors about what they want<br>
<emeyer> I don’t know if we’re going the wrong direction, but I do think more investigation is needed.<br>
<fantasai> astearns: My proposal is that we close this issue no change<br>
<fantasai> ... and take each of these concerns and move them to other existing issues or new issues<br>
<fantasai> ... so that we can work through solutions to these issues as much as we can in the framework we have<br>
<emeyer> +1 to astearns’ proposal<br>
<fantasai> ... would that be acceptable, plinss ?<br>
<emilio> TabAtkins: but ok, I guess if authors are fine with that and sass doesn't have a lot of reports about that behavior... fine?<br>
<fantasai> plinss: Yes. I just wanted us to look seriously at the big picture. Satisfied to go with the group consensus<br>
<fantasai> ... But if we later find more issues, and suggest to go back and reconsider, we should reconsider<br>
<fantasai> ... not say "despite new information, not going to reconsider"<br>
<fantasai> ... at-rule we could deploy now, without working through these issues<br>
<fantasai> ... but I'm not going argue this point anymore until new information comes up<br>
<fantasai> astearns: proposed to clsoe this monster issue no change<br>
<fantasai> ... and follow through on each individual issue on separate issues<br>
<fantasai> ... any objections?<br>
<fantasai> +1<br>
<fantasai> RESOLVED: Close no change<br>
<fantasai> ACTION: astearns to make sure smaller issues are followed up on<br>
<fantasai> plinss: one other caveat, there might be someone else in the larger group that shares concerns, so maybe poll everyone?<br>
<fantasai> astearns: I'll add a comment to the issue, here is what we resolved and why, and ppl can comment<br>
<fantasai> plinss: I just want to make sure we make the right decision in the right way<br>
<fantasai> INSERT replacing "ack fantasai" with -<br>
<TabAtkins> new room topic?<br>
<fantasai> fantasai: Stepping back to Plinss's question, I think we are on the right path. Considering developer ergonomics vs the downsides of this approach<br>
<fantasai> fantasai: I think the best we can do is continue on this path and try to address the issues as we can<br>
<fantasai> fantasai: I also wanted to support emilio's point about the cascade effects being confusing<br>
<fantasai> fantasai: I think we should either make declarations after rules invalid (as emilio suggested) or sort them in the cascade as specified somehow (as jensimmons suggested)<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-1505543632 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 April 2023 16:04:02 UTC