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.
I guess minification is still a good idea? Or is this now irrelevant with gzip everywhere?
WebKit Supports Nested CSS
71–80 of 183 posts
Re: WebKit Supports Nested CSS
#72Awesome to finally have nesting. The way I see it, this took 10 years longer than it should have. I feel the only big thing missing from the vanilla stack for me right now is a template element that multiple html files can share. Just like how you make a blog header in Jekyll or Hugo and it adds it on all your blog posts get the header. I haven't found an easy way of doing that if I have a bunch of html pages.
well, the classic solution has always been to use an iframe :p
I don't know if that's actually an ok method or not, but I thought of that and looked around for it with little luck
Re: WebKit Supports Nested CSS
#73man 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.
Yup. But currently they offer more as variables and nesting. Templates, Subroutines, etc.
Value manipulation (like color changes) are possible in css, but complicated to write and read.
Re: WebKit Supports Nested CSS
#74I 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.
Re: WebKit Supports Nested CSS
#75Earlier quoted context omitted.
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…
I agree - I love esbuild, but Vite is great and will generally give you what you want and more with minimal hassle. The development server and hot reloading are excellent.
I did recently find one thing that didn’t work out of the box in Vite, though. I needed to write a web worker, but Vite didn’t package it into a single .js file, so I had to call esbuild directly to do that.
Re: WebKit Supports Nested CSS
#76Maybe I am an outlier... but I really don't like nested style documents like those founds with SASS, LESS, PostCSS. When the number of nested selectors becomes too great it can become very difficult to reason about. I would never use this without some kind of lint rule enforcing a maximum depth of selector nesting. I agree with the other commenters ITT taking the position flat CSS looks cleaner than nested documents.
I generally only nest one level down, and at most two. Any more and, as you say, it becomes very convoluted, particularly when it comes to specificity. However, alongside pseudo elements, the killer feature for me is that nesting enables namespacing for components, which (a) leads to much simpler class names that makes CSS much easier to read and (b) stops a great deal of repetition of the class on the wrapper element.
Re: WebKit Supports Nested CSS
#77Earlier quoted context omitted.
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; }
Yes it's terrible. Not just that you have to type ".page form" 3 times, but that you don't have a convenient way to group together these bits of style that clearly are meant to go together
Imagine those three rules in a 200 line CSS file.
Re: WebKit Supports Nested CSS
#78Awesome to finally have nesting. The way I see it, this took 10 years longer than it should have. I feel the only big thing missing from the vanilla stack for me right now is a template element that multiple html files can share. Just like how you make a blog header in Jekyll or Hugo and it adds it on all your blog posts get the header. I haven't found an easy way of doing that if I have a bunch of html pages.
That's what an iframe is? I guess there could be a partial element that works like but if it's referencing HTML, what about JavaScript or CSS it includes? That's exactly what iframe handles.
Re: WebKit Supports Nested CSS
#79Earlier quoted context omitted.
> tell browser vendors to fix their damn engines Parsing performance of the type they're talking about is an algorithmic fact, not an implementation problem. Your suggestion is like telling engineers to fix the laws of physics.
The fact that the article raises the possibility of this limitation being removed in the near future means that it's not a law of physics, only a matter of finding a better algorithm. Even if it were a law of physics, engineers can often circumvent laws of physics using smart caching and other tricks. We've been waiting for this feature for decades already. It would have been better if they'd just invested a couple o…
This was a hot topic in discussions and they simply damage control it here for a larger auditory, and in an excellent political way.
The problem is really law of physics-ey. But performance impacts (even naively implemented) were never presented for public evaluation.
Re: WebKit Supports Nested CSS
#80Earlier quoted context omitted.
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…
Yeah I agree. Most of my CSS files end up feeling like a big, append-only list of selectors for seemingly random stuff. Its so hard to tell if there are selectors in there that are no longer in use. I really like the look of nested selectors for this reason - because I can group my selectors by component.
You could always use tailwind - the problem of CSS classes no longer in use is the exact use case for it.