Declarative Shadow DOM
web.dev
web.dev
• Chrome is roughly planning to ship this in M88 (Q1 2021).
• There are no signals from Firefox or Safari, positive or negative.
• There were concerns earlier on from various spec and browser developers, but those seem to have generally been sorted out. But https://github.com/mozilla/standards-positions/issues/335 is still open and awaiting a response.
• As far as putting things into the WHATWG DOM and HTML specs is concerned, at least two implementers must be interested, so it won’t be being landed there just yet.
I invite corrections if I’ve missed anything or erred.
Are Chromium-based implementations considered independent implementations if they were developed independently? Like, if both Microsoft and Google work on it for Chromium in secret...
Functionally mobile safari is the only thing stopping google having complete control of the web platform, just as MS did in the days of IE4-6.
There are a bunch of standards that google has proposed that are horrific for user privacy, and I would fully expect all google properties to become dependent on them if they didn’t have to care about mobile safari.
It's better to compare Chrome/Edge/Opera as "distributions and customizations" of Chromium/Blink instead of mere as wrappers - the same way that Linux distributions aren't reduced to just "GNU/Linux kernel wrappers".
Maybe they change some of the defaults, but none of those various wrappers are shipping engines that are different.
Oh and meanwhile Microsoft is doing really good & helpful work to improve the web platform. In seemingly very very altruistic ways. (Which is how I feel Google is 98% of the time operating too!)
HTML Imports, for example, were something that everyone wanted, but Firefox developers looked carefully at it and pointed out some very serious problems that weren’t immediately obvious, where implementing HTML Imports would cause a lot of trouble down the track, limiting future extension possibilities. So they said, “let’s hold off on this, wait until we get ECMAScript modules and related loading stuff sorted out, then we can look into redesigning this”. They convinced the Chromium developers, and so they steadily removed it before it could grow too many roots to remove.
This is quite different from Safari’s implementation lethargy, which is typically just opaque.
Intuitively, I'm sure the whole Shadow DOM thing is way more powerful than that, but this is their 2nd-sentence headline example of what Shadow DOM "does."
Surely, there are reasons for all this complexity beyond stylesheet compartmentalization? Would I ever personally want to write the "raw" code to work with the Shadow DOM (not from the looks of it) unless I were a developer of some low-level framework that needs to be optimized to not manipulate the real DOM?
`<style scoped>`
However, it was abandoned partly because it "adds a lot of complexity to how the scoped style system works for Shadow DOM".
https://chromestatus.com/feature/5374137958662144
https://groups.google.com/a/chromium.org/g/blink-dev/c/R1x18...
There were other reasons at the time as well, as mentioned in the linked email: the feature wasn't owned, wasn't shipping in any browser, and was making it difficult to improve the Shadow DOM styling system which was shipped already.
That was also a long time ago, and I think browsers and standards groups have learned a lot about designing features to be backwards compatible and how to avoid certain implementation complexities.
Component-scoped styles is a very handy feature. It could be achieved just by leveraging selector specificity, but that's rather complex and a lot of people hate CSS so less cognitive overhead is better.
This is why I love Vue. It's basically the nightly version of HTML/CSS/JS. The syntax from this article is already familiar from Vue. It extends web standards, rather than replacing them, IMO.
I've seen it work on Chrome, Firefox and Edge. But at the time I discovered it, Chrome had already scheduled it for exclusion.
It was shipping in Firefox when I removed it from Chrome. It was moved behind a flag in Firefox shortly after and then support was removed.
You probably won't write the raw code yourself.
These web component APIs are generally low level and with few conveniences. The idea is that your Framework of Choice would do the raw code and you dear application developer would get it in some handy "cooked" way which matched your framework. (For example, maybe outputting isolated components could be simple boolean in your build configuration.)
Too many people think that the raw web component specs are meant to compete with frameworks like React etc. But that is huge misunderstanding. They're low level APIs which frameworks can build on.
That's quite a good reason. It'll be useful for embedding content in pages; if you have complete control over the page then that isn't especially helpful, but if you don't (many teams contributing to a site, accepting user defined content in to a page, enabling an admin to define page styles without breaking important elements, etc) then it's very handy.
My inner pessimist does wonder if Google are driving this because it'll somehow make it harder to block adverts, but for now it looks quite useful in for the obvious use cases.
The shadow DOM is critical to make sure that my extension's styles don't overwrite the page's styles and vice versa. And unlike iframes, it grants the ability to use js state management that extends beyond the shadow DOM root element. So, you can inject multiple shadow DOMs capable of "talking" to each other.
Neat, I guess, but that's only really useful for basic layout components? Anything more complicated needs JS for behaviour/interactive functionality?
I guess it speeds up first paint, but again it feels like you'd send up with components on the page that look functional, but aren't wired up to do what they are supposed to until the JS comes down and adds event listeners etc.
HTML could be so much more useful and time-saving if more functionality could be built without JavaScript.
Thanks to CSS tricks, such as using the `:checked` pseudo-class in invisible form elements (toggled with a visible `<label for="">` I can implement neat show/hide effects in websites without any script - my current server-side-rendered project has a reusable "tab control" that doesn't use any client-script at all. It's great because it will always just-work, even if the user has weird privacy/script settings.
I can distill what I want down to two simple things: I want more CSS pseudo-classes based on the live DOM state (and the ability to add arbitrary wrapper boxes around or inside any element) and more native HTML elements that can mutate the DOM without requiring any scripts.
Like it or not, but HTML+CSS is being used for all kinds of UI - and right now you absolutely need JS to support state-transitions in HTML, even if those states arguably shouldn't need any script because the same logic can be expressed without using a Turing-complete programming language.
I wish there is a movement for this. But unfortunately the Web Standard today is pretty much dedicated by Google. ( Although Apple and Mozilla still has some leverage )
It doesn't solve a much things. The Web Components spec is IMHO too complicated and doesn't really yield direct results for front end developers.