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.
Depending on the exact parsing strategy it might be genuinely required (such as if the parser switches from "property mode" to "rule mode" at some point), but in this case it was just because it's kinda confusing to do so.
We removed the restriction, but still warn against it due to readability issues.
> drops all resolved CSS rules on element, its siblings, its parent and all children.
Browsers optimize this, too - they try hard to keep up metadata structures that tell them whether they need to invalidate styling or not. (This is why mutating the stylesheet is so expensive - browsers have to freshly rebuild the supporting data structures. They could optimize that too, but it's a lot of effort for a rare case.)
So if there's no rules mentioning an [a] attribute in the page, el.setAttribute("a", ...) will generally not do anything.
(One of the benefits of shadow DOM is that the shadow trees are scoped away from the main tree and each other, so you can have more expensive rules in them without making the rest of the page slow. Yay for componentization!)
Saying "People have different opinions" about nazi bullshit is kindergarten-level analysis.
Nazis are bad. Racists are bad. Claiming these "opinions" are equivalent to any other is childish and immature. Grow up and realize you live in a society with other people, and the positions you advocate for (and encourage others to advocate for) have real consequences.
I mean, okay, maybe, but that just means that they'd be hosting a conference about "nazis suck" and hey, I'm okay with that. That's a message I can get behind.
"Just add native support for jQuery and call it a day"
"Just add native support for React and call it a day"
We can do lots of amazing things in the ecosystem, but often we're working around missing primitives in the platform. Just "adding native support" for today's hottest library doesn't fix things properly. It's better to figure out what problem they were solving, and then fix that problem more directly.
(jQuery is largely solving "DOM APIs suck". We've fixed that a little bit, with things like query() (née querySelector(), which was an awkward first attempt at it) and fetch(), but are still struggling to work through browser dev apathy at things like event registration or creating elements.)
(Figuring out what problem, precisely, React is solving is exciting and interesting. It's non-obvious - it's not just "some DOM things are slow", as there's lots of DOM things both fast and slow, and you don't need a fancy (read:slow) tree-diffing algo to fix those. There's something fundamental going on that we might be able to do better - maybe it's more fully separating the "display thread" that contains DOM from the rest of your JS, and letting you do a lot of DOM-ish manipulation in threads other than the display thread. Maybe that means actually using an even more lightweight display abstraction, so you can cheaply spam out updates without having to do expensive diffing first. There's a lot of possibilities here.)
Yeah, CSSNext here is basically the intersection of CSS variables and Sass variables - you can only use them in property values (like CSS), and you can only declare them at top-level (like Sass).
It's nice if you really want to utilize the current syntax, but it's less powerful than either option it's derived from.
If I'd done what everyone keeps saying I should have done and just used $foo, then Sass would have gotten angry at me, because we'd be sharing syntax for different features. We already tweaked CSS a little to avoid that in another case (when specifying grid line names in Grid, you surround the names with []; it was originally (), but Sass asked us to change it because they use that for their list syntax).
We could only have used $foo if we hewed very close to Sass's functionality - global macros that operate at the stylesheet's lexical level. That wasn't what we wanted to do, though, either at the time (considering only the variables use-case) or looking forward (to the use of custom properties as the generic "inject info into your page via the CSS engine", a la data attributes for HTML).
By avoiding global macros, we also get context sensitivity - we can actually offer APIs for this stuff that are smarter than "here's the string you set". When we add custom pseudoclasses, custom media queries, etc they'll all get their own useful APIs. Sass is stuck with string manipulation, because you can use a Sass var anywhere, so it's impossible to infer anything about it.
> He's the guy who wasted a decade writing an ASCII-art based "template layout module"[1], which he was never able to persuade a single browser vendor to implement. It eventually got demoted from a working draft to a "note", which is the W3C's polite term for standards fanfiction.
This is because it was absorbed into the larger and more fleshed-out Grid specification, which is nearly release-ready in multiple browsers. The ASCII art is actually really useful!
Properly, the --foo stuff is a Custom Property. You can use its value as a variable, with var(), but it's not the only use custom properties have. That's why the spec's full name is "CSS Custom Properties for Cascading Variables". But that's a horrible mouthful, so "CSS Variables" is what it's usually called. (Plus that's the shortname in the url.)
(There's also a large focus, in v1 here, on the variables use-case, because that's what I needed to sell it to the group at the time. The CSS Houdini Task Force is now expanding Custom Properties properly, so they can actually be used for random JS things without a ton of hackery.)
"i disagree with you, thus you must be lying about your experience and actually unworthy of doing your job, unlike me, the superior being" go get your diaper changed
Yeah, setting an explicit aspect-ratio is on the roadmap. The relevant people (me and fantasai) have too many other layout-related things on our plate atm to deal with it, but it'll show up in the next year or two.
CSS selectors always select "down the tree". Or, read in reverse (from right to left), evaluating them only requires information from further up the tree. In HTML, "further up the tree" corresponds exactly to "earlier in the text stream". This means that as soon as an element finishes parsing, we can find all the selectors that apply to it immediately, enabling better incremental display.
Of course, that's no longer always true today. In particular, selectors like :nth-last-child() depend on information from later siblings. Defining a combinator or equivalent mechanism that allows direct selection based on later siblings is thus not out of the realm of possibility. And selecting a parent vs an earlier sibling is almost identical - the parent's start tag is immediately prior to the first sibling (or text), so the distance between "thing you're selecting" and "thing it needs to know about to evaluate the selector" is only incrementally larger. So a way of selecting a parent based on children is probably fine too.
There are a few issues that have prevented us from doing so today. For one, it's slow. Using a single one of the "backwards" sibling pseudo-classes can kick your entire page into slow-selector mode, because it breaks optimizations. The same would be true of parent selectors, probably. For two, we have to prevent nesting - siblings usually aren't too far from each other, but the root can be very far from a descendant. (Also, siblings are usually walkable by traversing an array, while parent/descendant relationships are typically pointer-based and slower to traverse.) This makes it a bit clumsy to specify.
That all said, it's on the roadmap. I plan for it show up in Selectors 5.
(Oh, and note, the "cascade" in "Cascading Style Sheets" isn't about what you're referring to. It's about a "cascade" of values for a given property colliding on a single element, and figuring out which one "wins". Thus the Cascade module <https://drafts.csswg.org/css-cascade/>. It's not the best name, but we're stuck with it. ^_^)
Yup, that's the problem with having a language that evolved slowly over 20 years, while its problem space changed enormously. CSS was originally intended as a simple way of styling text documents on the web.
We're trying to fix vertical centering, at least. The alignment properties from the Align spec <https://drafts.csswg.org/css-align/> do consistent centering (and other alignment) across layout modes. Currently they only work in Flex and Grid, but they're defined to work in Block and Abspos as well.
Both, either. ^_^ Having wrapping behavior split the way it is today is wrong - either all of it should be in white-space, or none of it should be. (Moving it all out into a separate property is probably best, so white-space can keep just being about white-space itself.)