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!)
"So if there's no rules mentioning an [a] attribute in the page, el.setAttribute("a", ...) will generally not do anything."
That's true in general but there are exceptions as usual. Changing @href may trigger not only [href] rules but also :link ones. And :link rules are always present at least in default style sheet. @value triggers :empty. And so on.
But if someone in some library in galaxy far far away (small library used by your application) will add that [a] rule then magically you will get a spike on innocuous el.setAttribute("a", ...) calls in your code.
That's one of points of having transactional yet explicit DOM update mechanism. We have jQuery, Angulars, React, Ember, Vue, (you name it) that definitely need such thing. Sites/webapps that do not use one of those are quite rare these days.
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.
Grow up and argue with people's ideas instead of banning them from conferences unrelated to said ideas. You stop bad ideas from proliferating by showing how they're wrong, not by acting like children and banning what you don't like.
Something is "bad" as you've decided, and you're going to actively take it upon yourself to enforce consequences for those who believe in the "bad" thing.
Think about that for a minute - then remember that interracial marriages used to be banned, and a person with your operating principles would have actively made it worse for those people to enforce the norm.
But this is different! You say - missing entirely the point.
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.
Yes, I am perfectly okay with discriminating against Nazis.
Since when is ALL discrimination bad? I discriminate against shitty people all the time, and so do you. Don't even pretend you don't, no one will believe you.
>and so do you. Don't even pretend you don't, no one will believe you.
You're projecting a bit. I try hard -- consciously -- not to shut down and shut out people who need grace as much as I do (either more or less externally-visibly).
Your own code of ethics is not universal. There are people who think and operate differently from you.
Which is exactly the point of not discriminating whenever it's avoidable.
"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.)
DOM APIs didn't suck too badly. They weren't great, but they were usable.
The problem was that every old browser had its own API and feature set. Jquery abstracted over all that, including bugs in specific versions of browsers and continually is updated to handle the case of a browser claiming to implement a feature but lying.
Really if all browsers had the same API and feature set, there'd be no need for jQuery as it is today; you'd have a very different library.
