man I can't wait to not need LESS/SCSS anymore. the less I need to compile/transpile before handing stuff off to the browser, the better in my book.
WebKit Supports Nested CSS
51–60 of 183 posts
Re: WebKit Supports Nested CSS
#52I'm losing track of what CSS can do. Do we have inheritance already? Pseudocode of what I mean: .info { font-size: 8px; } .news extends .info { color: black; } So news are displayed in an 8px black font.
nope. you've got a couple of options -
.info {
font-size: 8px;
}
.news {
color: black;
}
asdf
.info {
font-size: 8px;
}
.news {
color: black;
}
asdf
.info, .news {
font-size: 8px;
}
.news {
color: black;
}
asdf
Re: WebKit Supports Nested CSS
#53:is(article) & That looks hacky at best. The excuse of parsing performance is responsible for so much weird syntax in web standards today. The standards are literally being dragged around by browser vendors' priorities. I wish they would do it the other way around for once: come up with the cleanest, easiest-for-humans syntax as possible, and tell browser vendors to fix their damn engines. Perhaps this will lead to t…
I agree it's a big mistake to not make the nesting rules compatible to Sass/Less.
> Because of limitations in browser parsing engines, you must make sure the nested selector (.bar in the above example) always starts with a symbol.
How hard can it be.. I know that is always easy to say from the outside but in this case I don't understand why the refuse to implement it. Just labelling it as a performance problem doesn't say much because why should it impact performance to check whether there appears another rule with an opening "{" after it.
Re: WebKit Supports Nested CSS
#54I'm losing track of what CSS can do. Do we have inheritance already? Pseudocode of what I mean: .info { font-size: 8px; } .news extends .info { color: black; } So news are displayed in an 8px black font.
nope. you've got a couple of options - .info { font-size: 8px; } .news { color: black; } asdf or maybe .info { font-size: 8px; } .news { color: black; } asdf or even .info, .news { font-size: 8px; } .news { color: black; } asdf but you've got to use LESS/SCSS for true 'extends' type functionality. vanilla CSS is more focused on inheritance.
Out of these, only the last one seems somewhat okish to me. But it would be annoying to add another selector everytime you add a class that uses the rule.
If that is all we have, then I will just stick to css variables:
:root {
--info-font-size: 8px;
}
.info {
font-size: var(--info-font-size);
color: grey;
}
.news {
font-size: var(--info-font-size);
color: black;
}Re: WebKit Supports Nested CSS
#55Whenever I see nested CSS, I always think the non-nested version is cleaner. Then again, I'm lucky enough to often work with my own 'hand-crafted', semantic html, and not some div soup generated by a tool.
I generally agree and wince at anything deeply nested, but there's no question that the biggest benefit here by far will be pseudoclasses. Especially when you wanna do something to children elements based on a pseudoclass .page form border: 2px solid #223; border-radius: 0.15rem; & button { background-color: red; transition: background-color 0.15s ease; } &:hover button { background-color: blue; } } seems way cleaner…
Am I missing something… isn’t it just a simple substitution?
.page form {
border: 2px solid #223;
border-radius: 0.15rem;
}
.page form button {
background-color: red;
transition: background-color 0.15s ease;
}
.page form:hover button {
background-color: blue;
}Re: WebKit Supports Nested CSS
#56I am supportive of this. Ofc, parent selector would still be nice, but I understand the problems solving that performantly. As a highlight, Nested CSS doesn't support nested selectors if they both begin with letters, so the "&" is used as divider. I highly recommend web-dev's check out the last section of the article*: https://webkit.org/blog/13813/try-css-nesting-today-in-safar... [*: even though, IMO, in this insta…
We have a parent selector. It's called :has(), and Firefox is the only holdout at this point.
Re: WebKit Supports Nested CSS
#57I am supportive of this. Ofc, parent selector would still be nice, but I understand the problems solving that performantly. As a highlight, Nested CSS doesn't support nested selectors if they both begin with letters, so the "&" is used as divider. I highly recommend web-dev's check out the last section of the article*: https://webkit.org/blog/13813/try-css-nesting-today-in-safar... [*: even though, IMO, in this insta…
Do you know about the `:has()` pseudo-selector? It is basically a parent selector, and has decent browser support already!
Re: WebKit Supports Nested CSS
#58Couldn’t `this` just be a reserved keyword instead of `&`? All these symbols, CSS has become so Perly.
Re: WebKit Supports Nested CSS
#59Earlier quoted context omitted.
What's the difference between this and SCSS nesting? It seems pretty full-featured to me. What's missing?
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;
}
}
.some-class {
color: red;
}
.some-class__child {
color: blue;
}Re: WebKit Supports Nested CSS
#60Earlier quoted context omitted.
What do you use now? I'm currently using Create-React-App for one of my projects and some parts of it are really frustrating. For example, you can't create a Web Worker script without ejecting, or using some tool that intercepts and alters the CRA Webpack configuration. Should I just bite the bullet and figure out Webpack (or another bundler) from the basics? I feel like that will be inevitable at some point anyway.
IMO, ESBuild is the best option these days. It’s not as magic or batteries included as Webpack, but there’s very little kept secret from you during the compilation process. It’s fast too! Another tricky alternative is to just use TypeScript’s compiler. Combined with the new import maps spec, you can target most modern browsers and skip bundling all together.
I'd actually recommend Vite over Esbuild directly. It uses Esbuild under the hood, at least for production builds, but during development it uses the native import syntax with some optimisations to bundle dependencies together somewhat. This gives you a really quick development build, and then a well-optimised but still pretty quick production build.
But I think the real benefit is that it's much easier to get right than Webpack ever was. You don't need to start by configuring a thousand different plugins, rather, you just write an index.html file, reference the root CSS and JS file from there, and then it can figure out the rest, including all the optimisation/minification details, applying Babel, autoprefixing, using browserslist, etc. If it doesn't recognise a file (e.g. because you're importing a .vue or .svelte file) then it'll recommend the right plugin to parse that syntax, and then it's just a case of adding the plugin to a config file and it'll work.
I'm a big fan of Parcel, which is a very similar tool for zero-configuration builds, but Vite feels significantly more polished.