And as for what it is, you know how a given web page has global css/query selector scope? Shadow dom is like a membrane in there, where styles and other things don't go in (unless you explicitly poke a hole). It's like a whole new document that you can nest inside an existing document. It's encapsulation inside browsers
I wasn't aware of being able to explicitly allow in some css.
It sounds like a powerful way to make reusable components where some css can't be overridden because it would break the component (eg. Layout, shape) while allowing other parts to be overridden (colour, size, font, etc.)
This is exciting, it would hugely simplify a product I work on that we have to embed with an iframe. If we could use this instead that would be a lot of scrolling and message passing and resizing code that could just go away
I yet ever heard of infinite loops in loading. Do you have an open issue?
The webcomponentsjs package has polyfilled the v1 Web Components specs for over a year. Polymer 2.x was the version that used the new specs instead of the older v0 specs.
By habit, they’ve decided to ignore any prior implementation of this pattern, and chose a completely new, unintuitive nomenclature (compare: “polyfill”).
Androids Toolkit is much more powerful because it allows custom layouting engines.
If web components was just a port of the Android toolkit we'd have canvas with accessibility, CSS grid as library not in the browser, and usable recycler views.
The whole point is that you get many more features.
On Android, every element just knows its children, attributes, can process events, and can draw itself to a canvas or describe itself to a screenreader.
This means designing a new layout is just another element that then knows how to position its children.
An element that can change opacity slowly of its elements, or filter the text, is also just another element.
You can do everything with it and still be accessible.
And I'm not sure if you've ever tried implementing a RecyclerView on the web? It's absolute horror. Either you have to entirely hijack scrolling and thereby kill flinging and smooth scroll of the browser, or you have to use a lot of JS to at least make it seem real.
Currently using the similar `DOMImplementation.createHTMLDocument()`: https://developer.mozilla.org/en-US/docs/Web/API/DOMImplemen... : Styles and scripts of the main document doesn't apply to it. It allow to do some tricky stuffs, the main doc can retrieve values of sub documents, and we aren't forced to display it. It can act in the shadow too, allowing parallel computing. Is it the great beginning of «in browser javascript multi threading»?
>Styles and scripts of the main document doesn't apply to it.
Ugh. I look forward to being unable to use custom JS / CSS to fix websites that have banners that cover half the page, or `max-width`s on their body to constrain themselves to tablet sizes on desktop monitors...
It used to be possible to write "shadow-piercing" CSS selectors, but this capability was removed for making it too easy to violate the encapsulation. (And indeed, I saw it frequently used to accommodate misuse of the Shadow DOM API.)
It sounds like "Shadow Parts" will let you target subcomponents in some Shadow DOMs, once it's implemented, but I'm afraid that's probably not going to help you with misbehaving websites.
Still definitely possible for browser plugins to do anything they want to Shadow DOM. For open shadow roots, javascript can crawl them. If handling closed shadow trees is necessary, just patch Element.prototype.attachShadow and keep a WeakMap from the Element instance to its shadow root.
What is the difference between this and working with a frame? I guess one could be the security policy (this being more flexible than a blank frame document which is automatically of different origin), but is there anything else?
It is using iframes, that can be sanboxed in many ways. The security policy apply for external domains, if declared in header. It is a way to create a whole valid DOM quickly, it is identical as creating it by hand. Then we can use window postMessage, or simply from the main document retrieve stuffs in the children DOM with like `frame007.contentDocument.documentElement...`
EDIT: I misunderstood the parent comment; it's not talking about Shadow DOM.
---
> It can act in the shadow too, allowing parallel computing. Is it the great beginning of «in browser javascript multi threading»?
Unless something has recently changed, this is not true.
Shadow DOM elements are still part of the same JavaScript execution environment as the Light DOM; there's no concurrency at that level.
If you want browser multi-threading, we've had WebWorkers for years and they keep getting better (OffscreenCanvas and module support being current examples).
The way I see Shadow DOM is that it's an environment for an encapsulated web component or embedded app to run within. Most frameworks can be mounted to the DOM at a single spot, so should be pretty compatible, I would think.
IIRC, Angular already ships with its own similar polyfill, so I'd guess it tries to fallback to native if possible. React doesn't really concern itself with styles anyway, though I guess they might need/want to make sure they're not standing in the way of using the shadow DOM.
Of the less-major ones, I only know that Polymer uses it - which makes sense, since this is one of the APIs it was explicitly created to push.
It does, but emulated by default, you have to explicitly add ViewEncapsulation.NATIVE to your component decorator, or NONE if you wish/are forced to disable it.
Um, what? I have a shadow DOM experiment from 2016 that's worked on Firefox since then... (an over-engineered webcomic tracker, I use it almost every day)
Is this about a better API or something?
Edit: Ohh, I must have enabled it in about:config manually back then. It's existed since at least Jan 2015 [0], but was disabled by default until this just now in Nightly.
Thanks, didn't know about part and theme - and again, I'm not sure if I like it. For example angular puts [innerHTML] into a shadow container - let's assume we are talking about arbitrary localized text from a cms, heavily sanitized, with basic html elements allowed only. With both deep and apply going the way of the dodo, I'm not sure when will we have part and theme support, but heck, this again, just like css variables, need an effort on the 3rd party's side (to add part descriptors and chain prefixers - gosh, those prefixers sure smell bemish), which may or may not happen.
All I need is a fail safe way of modifying style inside shadow containers without the 3rd party adding support for it (right now we are modifying an angular material based site, because, you know, before the release the most important thing is that how these elements animate or how their drop shadow look), fail safe meaning that it should not be possible to accidentally overwrite stuff inside shadows (like generic link styling).
But probably it's a conflict of interest... everyone wants perfectly contained elements (because css is scary) but wants to retain maximum customizability without modifying the upstream package, plus we don't want shadow contained css to be duplicated. Not sure if there's a good solution for that.
Has anyone here had an excellent experience with webcomponents? I used them on a project recently and it felt subpar to React components, partially due to the number of immature libraries we needed to use to account for incomplete support (we were porting React components to WebComponents)
I'm hopeful that the day will come when WebComponents provide a superior experience to the megabytes of JS that are imposed on a user's experience, but seeing how long it took IE to die I'm pessimistic
They solve different (and even complementary) use cases. Web Components allow you to easily share things like date pickers without having to wait for those things to standardise and be implemented in browsers, whereas React gives you a clean and easy to follow application architecture where your view is simply the output of a function that takes application state as input.
Is there a way to modify web component in browser dev tools?
I tried it on the new chrome manage bookmarks page to reduce the whitespace but I could only edit a single instance; I couldn't adjust the whole page the way you can with normal CSS.
Yes, that's what I'm talking about. I enabled that setting, edited the css in the shadow dom, and it only changed the appearance of the component I was in, not all the other components of the same type.
As far as I can tell, shadow-dom and web components are anti-tinker in that they don't allow users to play with the underlying definitions in order to learn how to use those technologies themselves. I think that will be a big barrier to adoption.
Have the polyfills got any better recently? Last I looked, they had a list of performance issues or only partially supported the spec. Made it really hard to consider them for a serious production app.
The polyfills have been used in many large production sites for a while now. The Web Components v1 specs instigated a rewrite of some of them that may have improved perf, and definitely reduced size.
Absolutely nothing. Some websites might be faster. Some might be slower. Users will attribute any difference to their internet connection, not the technology. A handful of developers will do something somewhat interesting with it, the rest of us will continue building shopping carts and blogs like we always have.
reply