• 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.
Alas Firefox has been rather joining up on the axis of "we refuse to implement basic stuff" bandwagon.
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!)
A lot of the time Firefox’s reticence to implement things is because they don’t think it’s the right thing to implement.
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.
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...
no, because that would have meant that IE6 would have been able to "standardize" anything due to the number of "browsers" that were ie wrappers. Alternatively you could look at the numerous browsers on osx and iOS that are essentially wrappers for a basic [NS|WK]WebView - that would allow any of those to count as an alternate implementation.
So if Mozilla decides maintaining gecko isn't worth it, and switches to blink too, then it's basically just Safari and Chrome, and both would have to agree on standardization?
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.
I think it's worth distinguishing between "shell" browsers that simply wrap an encapsulated rendering engine (such as those IE6/MSHTML-based browsers from decades ago) and other browsers like Chromium/Edge/Opera which have a different level of integration with the rendering engine - because those browsers are able to tweak and extend - or disable - the engine's features on a granular scale.
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".
That’s not how open-source collaboration works. If it’s a web platform feature (like in this case), development happens in the open. Everything else would be a scandal.
With the disclaimer that I might be getting old, and I have done absolutely no research on my own about this whole shadow DOM thing: why would you go through all this trouble to "[provide] a way to scope CSS styles to a specific DOM subtree and isolate that subtree from the rest of the document."
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?
Surely, there are reasons for all this complexity beyond stylesheet compartmentalization?
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.
I'm developing a browser extension that injects a little popup window onto webpages using content scripts.
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.
<style scoped> was a very interesting idea, in practice it had a number of issues though like poor fallback (the styles become global in browsers without support which breaks pages) and implementation complexity because the root of a tree no longer defines the styles.
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.
It's alive and well in Vue.js single-file components (SFC). Once built, it is implemented by using data attributes in the CSS selectors.
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.
Stylesheet encapsulation is a godsend for my particular use case. I work on a web chat product that's placed on various sites - CSS scoping solves 90% of our deployment issues.
> 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?
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.
I agree: CSS selectors are already supposed to provide extreme flexibility in assigning CSS props, and give you means to organize scopes etc to implement Shadow DOM compartment policies, among all the other things.
In theory, yes, but in practice it's a different story. Early on in a project's life, avoiding these pitfalls is easy. But as a project grows both in team and codebase size, those quick CSS hacks to get some functionality out the door accumulate. After some time, you will begin to run into issues where some components in the tree aren't rendering the way you expect because some other component(s) are applying styles using a selector that may have worked at the time, but is now too broad. Even if your app is 100% CSS in JS, though easier to avoid, you may run into these issues. I'm all for this feature.
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.
>HTML could be so much more useful and time-saving if more functionality could be built without JavaScript.
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 )
The web today: as a platform for user interfaces and general-purpose content display, is far, far removed from HTML's "intended use case" as a means of sharing simple documents.
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.
So it provides a way to reuse CSS scoped for web components without needing JS?
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.
I think it is important that this (or something similar) lands in modern browsers. The hard requirement on Javascript to use custom elements has been a big deterrent for me to get too heavily invested in web components. This is the missing piece of the puzzle that was going to be <link rel="import">. We should look to Javascript as a tool to progressively enhance web content rather than leaning on it so heavily.
I think what they're saying is since the article says this "Shadow DOM provides a way to scope CSS styles to a specific DOM subtree and isolate that subtree from the rest of the document." if we could just make CSS namespace aware maybe we don't need the Shadow DOM after all.
But even then, what do you mean by “namespace”? Like, if we’re talking XML namespaces, CSS has that. But I don’t think that’s what’s meant. But I haven’t the foggiest idea what is meant (hence the request for clarification).
• 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.