WebKit is on fire lately, awesome.
We only need an autoupdate feature for Safari. Badly. It’s the only not evergreen big browser, to my knowledge.
WebKit Supports Nested CSS
111–120 of 183 posts
Re: WebKit Supports Nested CSS
#112Nested rules is just a syntax sugar. In Sciter, 10 years ago, I came up with style sets: @set Main { :root { ... } // root element that has this set applied .bar { ... } article { ... } :root > article { ... } } main { style-set: Main; } // main element with the set applied This solution solves two problems: 1. Modular/componentized style definition - same goal as in nesting styles, but without introduction of new sy…
> Nested rules is just a syntax sugar.
But this syntax can also be used in minified CSS. I'm sure minifiers will have a fun time with this in 5 years when most of the major browsers support it.
I've seen all sorts of examples of stylesheets that would benefit from this, Tailwind Typography being a good one because it styles all sorts of nested elements but only inside of `.prose`. Eliminating tens or hundreds of `.prose` selectors by wrapping them all in a single `.prose { }` would make it smaller; not sure exactly how much smaller though.
This sounds like a fun case study.
Re: WebKit Supports Nested CSS
#113Sanity 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.
What is the `color: blue` fiasco?
Writing from memory here, please correct as required, but one of the major concerns with scss style syntax was that it was "undesirable" for interpreters to differentiate between tag names and properties due to legacy CSS token-parsing techniques and the performance concerns around "infinite" lookahead ("controversial"). `color` is one example (possibly the only example) of CSS property / tag name overlap which makes the scss style syntax `tag { color:hover { color:blue } }` slightly ambiguous and potentially tricky to parse.
Re: WebKit Supports Nested CSS
#114Earlier quoted context omitted.
I’m looking forward to the day when we can get back to no compiling/transpiling web development.
I'm afraid TypeScript support in browsers is very far away, if it ever happens.
JSDoc type annotations look good though, and TS can work with them: https://www.typescriptlang.org/docs/handbook/jsdoc-supported...
Re: WebKit Supports Nested CSS
#115> Back in December, we wrote an article detailing three different options for CSS Nesting. > Web developers responded to the poll with great clarity. Option 3 won in a landslide. Yup, pretty much. The only thing I really wish won however was making the beginning "&" always required for nesting. Instead you're able to omit it if there's any other symbol. Example from article: main { .bar { ... } #baz { ...} :has(p) {…
> Hard to see the use-cases for sass in 2024
Possibly mixins, loops, and variables, which, unlike CSS variables, can be used in media queries.
Re: WebKit Supports Nested CSS
#116This is great! The only reason I use SCSS is for the nesting. It should have been implemented 10 years ago, but better late then never.
It's great that parts of SCSS are getting superseded by CSS. Nesting is great to avoid selector repetition. Custom properties (CSS variables) and CSS functions give us tools to avoid magic numbers and to encode layout relationships. New sets of selectors and container queries let us decouple and re-use declarations more. CSS Houdini gives us further power in extending CSS functionality. Of course there are things tha…
> SCSS are getting superseded by CSS.
Reminds me of how Coffeescript died out because its best ideas got integrated into Javascript.
What I want to know is: how the hell did this take so long? Nesting is such an obviously useful feature to have in CSS, and once I'd experienced it in SASS I never wanted to be without it. Why did it take 10+ years for this to be introduced to CSS, especially when other browser-based technologies like JS have evolved enormously in that time?
Re: WebKit Supports Nested CSS
#117I don't know anything about WebKit development processes or community management, so please forgive me if I say something wrong. Isn't it interesting how the engine has been implementing new features and generally running on a lot of steam coincidentally since the EU's Digital Markets Act (which will force other web engines on iOS) went into effect? Or maybe the dev process and community interactions has always been…
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 very annoying, and they could've been implemented. But I still prefer this approach over the Blink one, where they develop half-baked ideas just to track you better.
Re: WebKit Supports Nested CSS
#118Couldn’t `this` just be a reserved keyword instead of `&`? All these symbols, CSS has become so Perly .
Couldn't be a custom HTML element? So there'd be a naming clash.
Re: WebKit Supports Nested CSS
#119> Because of limitations in browser parsing engines...
I'm happy about this feature, but they don't really elaborate on what these "limitations" are, except a passing reference later on to "making the parsing engine slower".
Anyone know what the issue is exactly? Why can't they implement it the other way without making the parsing engine slower?
Re: WebKit Supports Nested CSS
#120Earlier 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; }
You are forgetting that it will also make files smaller.
I tested here, and it reduced from 172b to 160b, on minified versions. Bigger files will have a bigger reduction on file size.