171–180 of 183 posts
So you don't need to use nesting in your code if you don't want to, but can still take advantage for smaller minified css files using a transpiler.
Sanity has prevailed! Great work from the WebKit team, leading the way here. Not to mention great solve on the `color: blue` fiasco. Balances an edge-case compromise nicely, and leaves it open to future improvements. Bravo.
Fwiw, while I deeply appreciate WebKit supporting the proposal as well, the editors of the Nesting spec are Googlers and the Chrome impl happened at the same time.
Earlier quoted context omitted.
unpopular opinion I'm sure from reading everyone here, but to me nesting css is syntactic poison - or maybe syntactic sucrose or something that gives you cancer you use too much of it? Anyway programmers given nesting just do it all the time which ends up leading to stuff like article.news section.preamble h1 and probably a few other selectors after that all nested giving you a wonderful high priority for your style…
I agree with you. I worked in several codebase that used SCSS and due to those little hacks popping up in review, every time we ended up putting a "rule" in place to stick to two levels of nesting at most, or 3 if you're using the third nesting-level for pseudo-selectors (:hover :before etc). And this rule very rarely had to be broken, as it was extremely easy to avoid being too clever with nesting. (Of course, if th…
Earlier quoted context omitted.
Historically the webkit team has pushed the web possibilities a lot. Just take a look at the amount of APIs that you had to add the `webkit` prefix, for example. Not sure if you work with browsers, but constantly you meet something that they implemented first. I honestly think that developers are very wrong when they think that Safari/webkit is slowing the web down. Yes, some things like lack of notifications etc are…
It's not just getting those features implemented, but also shipping those to the user. Safari is the only browser that doesn't have autoupdate and has versions tied an operating system in 2023 and that's one of the biggest problems. While you can be happy only supporting say the last version of all other browsers, Safari requires you to give it years before the marketshare of the new versions are enough that you can…
https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-a...
Earlier quoted context omitted.
> Hard to see the use-cases for sass in 2024 Modules make writing CSS much less of a naming game. Anything you can do to reduce one of the 2 hardest problems in CS is worth it.
Or build a design system with good names and take advantage of the global nature of standard CSS.
Earlier quoted context omitted.
Relevant links on this: https://twitter.com/LeaVerou/status/1580215877705687040 , a poll about this specific matter (with links to other relevant polls which on the surface contradict this one). https://github.com/w3c/csswg-drafts/issues/7834#issuecomment... , on this exact matter (chosen as a convenient starting point, after matters were already settled, but the whole issue is about it). By the time this poll was do…
It's not a lot of code to implement, but it greatly simplifies usage by eliminating ambiguity: - Easier for human readers (the "&" is an unmistakable visual indicator) - Easier for human writers (fewer decisions; there's Only One Way To Do It) - Easier for syntax colouring
Earlier quoted context omitted.
It's not a lot of code to implement, but it greatly simplifies usage by eliminating ambiguity: - Easier for human readers (the "&" is an unmistakable visual indicator) - Easier for human writers (fewer decisions; there's Only One Way To Do It) - Easier for syntax colouring
I agree with the rest, but requiring & won’t make it easier for syntax highlighting, because that & can be anywhere in the selector, not just the start; the & affects nothing in determining whether it’s a rule or a property.
Perhaps controversial, I know. I realize this eliminates use cases like
em {
color: green;
li & {
color: red;
}
}
Compare:
li {
color: blue;
}
em {
color: green;
li & {
color: red;
}
}
em {
color: green;
}
li {
color: blue;
& em {
color: red;
}
}
Earlier quoted context omitted.
Yeah... the only difference _in terms of nesting_ that I'm aware of is exactly as discussed in the blog post: you must start a nested section with a symbol. Sass itself has a huge amount of features... is the expectation that we should just adopt a Sass implementation into the browser or something?
The other difference is that SCSS nesting can also be used for string concatenation, as in BEM classes. Such as: .some-class { color: red; &__child { color: blue; } } Which compiles to .some-class { color: red; } .some-class__child { color: blue; }
Earlier quoted context omitted.
I agree with the rest, but requiring & won’t make it easier for syntax highlighting, because that & can be anywhere in the selector, not just the start; the & affects nothing in determining whether it’s a rule or a property.
I'm saying the "&" should be required _at the start_. Perhaps controversial, I know. I realize this eliminates use cases like em { color: green; li & { color: red; } } It's okay not to support these use cases. They're confusing because they break encapsulation; the rule that appears to be nested inside (in this case, color: red) is affected by an element on the outside (in this case, ). Compare: li { color: blue; } e…
On your example: nesting is not about the sort of encapsulation you think it is—that’s incidental at best. It’s perfectly reasonable to say “this chunk of styles is about elements; and when they’re inside , do this”. The specific example you’ve given is also unrealistic with all three rules touching the same property in this way and two mutually exclusive (that is, li and em cannot both match, in any DOM), and I wouldn’t want it written with nesting at all, but rather like this, for much-increased clarity: li {
color: blue;
}
em {
color: green;
}
li em {
color: red;
}
I am not a big fan of nesting. I have yet to see a codebase where nesting makes CSS more readable. Even with BEM, I find it easier to reason about (and debug) the vanilla style. However, I must admit that `&:hover{}` does have a certain appeal. Also, I am very happy that nesting can be done without tooling in the future. It's a feature that many people love.
I agree, for some reason my brain sees the non-nested versions of CSS as more readable. Although we seem to be in the minority here. Very open to trying out nesting and perhaps my brain will 'flip' to eventually prefer it.
furthermore I suspect a very large % of people do not realize you can actually edit and save your CSS directly with Workspaces.