-
Notifications
You must be signed in to change notification settings - Fork 709
[css-nesting] request to pick up the css-nesting proposal #2701
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Couldn't be more in favor of this. Every developer uses css nesting and has forever through sass/less/stylus/postcss/etc, and it seems like the spec is in a solid place. Not having to pre-compile nesting anymore would be fantastic. |
Yes please. I wonder if this could also solve developers' requests for scoping. Two birds with one stone. I.e. instead of having nesting as merely syntactic sugar for the equivalent selectors, making it an alternative to preprocessors, make these rules have higher priority than non-scoped rules. To clarify with an example, given the following CSS: #foo p { color: red }
.bar {
& p { color: green }
} and the following HTML: <div id="foo">
<div class="bar">
<p>foo</p>
</div>
</div> The paragraph would be green. I know that we are dead set against introducing any new specificity rules, but it seems that scoping is such a huge problem that developers are avoiding the cascade altogether (see also CSS in JS which apparently half of devs use now?), We need to give them tools to avoid these problems, and it doesn't look like minor changes will do it. @tabatkins seemed to understand the problem well in a series of recent tweets, perhaps he can elaborate here too. |
@LeaVerou See https://www.w3.org/TR/2014/WD-css-scoping-1-20140403/#scope-atrule ? I think if it's affecting the cascade in such a way, it should be more explicit. Nesting has traditionally been just syntactic sugar. |
+1 on nesting, and also +1 on being explicit with an @scope. For Lea’s example, I would be surprised if the specificity was not equivalent to |
Agreed, haven't seen the |
Clap clap. Look forward to using css-nesting in browsers directly without any pre-compiling. Even though css-nesting looks like a syntactic sugar, it means the enhancement of coding efficiency and code maintainability for CSS, you know, which is what developers are gladly pursuing for. And sometimes, writing style could affect people's thinking processes. And |
|
Oh, the pronoun @fantasai thanks for your details and relevant link :) |
Please also see the existing ticket #998 . |
I also want nesting, it'd be a useful feature. Regarding https://tabatkins.github.io/specs/css-nesting/ : I'd prefer a syntax like that of Sass https://sass-lang.com/guide#topic-3 where it's not necessary to add the ampersand. In Sass, the ampersand is available (but not required - that's what I want). https://sass-lang.com/documentation/file.SASS_REFERENCE.html#parent-selector One of their examples:
is equivalent to this:
|
My spec explains why that's not a viable possibility. (Browsers don't want unbounded lookahead in their CSS parsers.) It also privileges the descendant combinator, which isn't ideal. |
If I understand you correctly it is a viable/possible option but it would require unbounded lookahead in CSS parsers. From your draft: "this drawback is generally considered unacceptable among popular implementations of CSS." Are there sources for this? Is it a performance issue?
Can you elaborate? Thanks in advance! As for most feature wishes: The main objective (speaking for myself) is to get the feature, the rest is just details. I'd strongly prefer not being required to prepend an ampersand to every single nested rule, and I hope that spec writers and implementers find a way to avoid that (perhaps it could be prototyped and tested and perhaps the perf impact is not really noticeable), but I'll sure take the feature even with that tedious requirement. |
The sources are that this group is full of browser developers, and they've expressed that exact sentiment.
Potentially, but it also just rules out certain nice classes of parsers. Bounded lookahead is very convenient and has well-known performance characteristics. |
The syntax should be nice for its users. I don't think I should have to care about whether the parser is nice or not 😀
I think that the syntax should be very convenient for its users / for web developers. The potential performance hit should get verified before the API makes amends - the actual perf hit in real-world stylesheets might be negligible. |
@tobireif, have you experimented with nesting in a manner that reflects the current spec? While it isn’t 1:1 like Sass, I eventually preferred it because it was easy to scan and explicit without adding many characters (typically only one, #main {
color: black;
& a {
font-weight: bold;
}
@nest main > & {
color: navy;
}
} You can experiment with it here: https://preset-env.cssdb.org/playground (I hope everyone will forgive my sharing that link, as I try hard not to seem like a salesperson.) |
@tobireif I sympathize with the usability concerns you are expressing (especially since usability is my research area). However, in this group we tend to take implementor concerns very seriously into account. Specs that are not implementable are just pointless fantasy documents. If you want to argue that the ampersand should not be required, a technical argument about how to implement that within bounded lookahead would be more effective than a philosophical argument. Also do note that the current spec does not prevent making the ampersand optional in the future, if a good way to implement that performantly comes up. |
@tabatkins Can we allow relative selectors to this? That would reduce the characters needed, and descendants could be specified as |
That's theoretically possible, sure; no grammar problems with it. But it means that now there's 3 nesting forms: if you're nesting with a combinator, use it directly (but you can use The current rules are simpler - when you nest, you need to produce a full new selector with a |
Alternatively, the only ambiguous case is when the selector starts with an element selector, right? If it starts with an id, class, pseudo-class, or pseudo-element, we know immediately. |
I don't see strong reason to change the current spec. |
I would like to see a discussion from the authoring perspective on Nesting vs Scoping and whether one is better or both are needed or what. It's clear to me that people don't like repeating selectors, but it's less clear to me whether the desire for nesting is related to manipulating the cascade as well (which is poorly done via nesting, and better done via scoping) or the current specificity effects are exactly what's desired and only a syntactic manipulation is wanted. As a review: Nesting merely adds up the specificities of the selectors which are chained together. (It's just a syntactic manipulation, which can be done with a preprocessor.) With Scoping, “The specificity of selectors inside the @scope rule is calculated locally: the selector specifying the scoping element is ignored. However, because scoped styles override non-scoped styles, style rules inside the @scope will override rules outside of it.” (If multiple |
The Working Group just discussed The full IRC log of that discussion<dael> Topic: request to pick up the css-nesting proposal<dael> github: https://github.com//issues/2701 <dael> TabAtkins: The proposal is relatively simple. Wrote a spec a few years back. I'm fine but it's a syntax nicity where we didn't get it past hte community. If that's changed we can move it forward <dael> fantasai: leaverou comment talks about wanting different specificity handling or the cascade. That's not syntactic only where you can do it wwith a preprocessor. There was @scope proposal before. I don't know if that's wanted still. I want to see more of that discussed. Do we want to effect cascade, if yes how. If we do this we should find out what's desired. <dael> TabAtkins: I strongly believe nothing new on specificity. b/c nesting is in every preprocessor in existance doing so would be a major behavior change. <dael> fantasai: No, not with same syntax. <dael> TabAtkins: Second reason is it wouldn't be same as @Scoped and it would produce thigns that some ways resembe but some way don't. @Scoped wasn't popular and doesn't do what people want for scoping. <dael> leaverou: I agree with TabAtkins, people are used to using nesting for preprocessors. I dsiagree with my earlier comment. I think scoping is useful, Not sure usability of scoping prop. It shouldn't hold nesting back. <dael> TabAtkins: Happy to have that separate. <dael> astearns: Objections to working on a purely syntactic nesting proposal <dael> astearns: One concern is if you can do it in a preprocessor why do it, but even the preprocessor authors are asking us to do it. <dael> chris: preprocessor expands to a ton of stuff and we don't want that expansion <gsnedders> It's one less reason to use a preprocessor, IMO. <gsnedders> And that's a good thing. <fantasai> s/wanted still/wanted or something different/ <dael> astearns: Maybe an issue that we want to avoid the exposion of conbinations that can happens <bkardell_> better for authors, better for network, very slightly worse for processing perf maybe? <dael> florian: For OM representation yes, but effect that's unavoidable <dael> TabAtkins: CSS style rules gain a child. OM doesn't explode <dael> chris: That's a big advantage <dael> leaverou: Huge advantage you can fo hover or focus styles on a one off <dael> TabAtkins: Originally a proposal to do rules inside style attribute and this doens't have that. You need only one token of look ahead. <dael> astearns: Obj to resolving we want to move forward with pure syntactic nesting? <dael> TabAtkins: And I want the impl to say if they actually don't want it. <tantek_> I'm too confused to comment on this last minute on the call <dael> dbaron: If you're discussing changing what's in proposal it would be good to have that written to share around <dael> TabAtkins: Entire proposal is linked in the issue to a spec on my personal github. It's laid out with no odd changes <dael> TabAtkins: We can go to next week <dael> astearns: We're over time. I don't hear obj. I think we are going to move forward, but let's give people time and we'll come back. <dbaron> I think for Gecko implementation it's probably worth asking heycam and emilio rather than me. |
Happy to see this moving forward into deeper discussion! But as I review @tabatkins draft, here are some issues that jump out to me:
Points 1 and 3 of that list can probably be discussed as proper issues as soon as [css-nesting] is converted to a proper draft spec. Point 2 is more of a head's-up for anyone getting excited about Sass nesting coming to CSS. |
The draft currently specifies it as the latter, and I find it very unlikely that we'd change off from that. Changing would require either actually expanding under the hood (with the attendant multiplicative blowup), or implementing the careful actually-matched-path logic that we explicitly rejected forcing implementors to use for
Agreed, I can add a section to the intro about this.
Intentional, as I don't want to privilege the descendant combinator, and I personally think it's less clear what's going on.
Yeah, very intentionally not allowed. It causes parsing issues, for one (you can't arbitrarily split up an ident and be guaranteed that both halves are still idents), and it's grammatically ambiguous with tagname selectors.
Yeah, I think I need to change that to sort the declarations to the front. Otherwise I have to reflect the relative ordering of declarations and rules in the OM, which'll be nasty and not compatible with my current plans of just adding a |
(Literally any feature of any language can be mis-used, right?) |
You're totally right, and I agree. 😀👍 What I think is important about the "potential disadvantages" that some pointed out it's that maybe we could use them to improve (if it's possible) this feature to discourage them —not sure how that could be possible. |
Perhaps allow only one level of nesting? Probably too draconian ... |
@isellsoap A lot of the "misuse" of existing nesting is based on the fact that it's compiled down to non-nested CSS. These issues go away if nesting is supported natively and never has to be flattened. |
But the specificity of nested selectors, in the end, is the same, isn’t it? So
is the same as writing
At least I hope I understood native CSS nesting correctly here. For me this means that the nesting obfuscates the specificity by a lot. With compiled and flattened CSS selectors (if we were to use Sass nesting), at least in the end I can look at what the browser actually has to deal with. It’s more explicit that way. I’m not sure if I can get across what I actually mean. 🤔
I know and I certainly didn’t intend to generate that impression with my comment. |
Yeap, my only idea was to limitate the level of nesting... but doesn't make sense to add a feature with arbitrary limitations like that. Linters will cover that, as they are doing today. Despite my initial rejection to the idea of adding native support for nesting, I realize that the issues I mention in previous comments would be a problem if (1) you agree that "flat" specificity is a good thing and (2) you work in long-lived and or large codebases where many people with different levels of experience add code; in short-lived —or those that don't require much change— or small codebases I don't thing that nesting would be an issue —at least that's my experience. |
Thanks for fulfilling this request! I will be closing this issue. Here is a PR to add this spec to the repository: #2878. For those interested, here are new issues capturing further discussion of css nesting:
|
That's cool and all but we want a parent selector. |
This might be off-topic for this issue about selector nesting. Could your desired selector |
You could file a new ticket at https://github.com/w3c/csswg-drafts/issues/new . |
I worry that the use of I don't have a better syntax suggestion, but I also don't see this as necessary. But, obviously as a Less contributor, I'm biased. Most "best-practice" style-writing I've seen suggests not really nesting at all, but to use single class identifiers in a BEM-way, like: .component {
&--header { }
&--body {}
&--button {
&:hover {} //etc
}
} This keeps things organized and provides single class matching for the browser. I do get why adopting that form (partial class appending) would be rejected by a CSS spec, because CSS is looking to define complete selector matching, but that just points to a preprocessor still being relevant, which points to a potential conflict around |
@matthew-dean That's a really good point, but this is a closed issue. Could you file a new issue, starting the subject line with |
Add @media to draft. Like this .foo {
color: red;
@media (min-width: 20rem) {
color: blue;
@media (max-width: 30rem) {
color: green;
}
}
} |
@exdeniz The comment that closed this issue has |
Why is it still a draft and not a recommendation? It's not enabled by default in preprocessors because of it. Many devs use other syntaxes (less, scss) exclusively for the ability to nest style rules. This is a very important issue. |
+1 on this. This feature would be extremely useful and allow me to get away from using LESS/SCSS which causes significant overhead in my development process. |
Any ideas on the estimates on nesting being a recommendation? |
Easy there. Let's get a First Public Working Draft (FPWD) first, then iterate via multiple WDs, then write tests and go to Candidate Recommendation (CR), then Proposed Recommendation (PR), then Recommendation. It's a multi-year process. |
Well, this topic is 2 years old, the entire concept idea is even older. I am aware it's not a simple "build and release to all the major vendors" job, but am wondering if it's actually progressing, or is stalled due to anything? Is there a roadmap or something showing progress on this specific spec? |
Anything new on the western front? I think that the general basis should be
as
|
https://tabatkins.github.io/specs/css-nesting/
The CSS Nesting module introduces the ability to nest one style rule inside another, with the selector of the child rule relative to the selector of the parent rule. This increases the modularity and maintainability of CSS stylesheets.
This is a followup to #998, and a long-time request from developers.
Has this been discussed in an agenda yet? If not, could this please be added to a future agenda?
Tweets lifted from @chriscoyier, @LeaVerou, @auchenberg, and @SaraSoueidan. Specification by @tabatkins.
The text was updated successfully, but these errors were encountered: