Shadow DOM enabled in Firefox nightly | Hacker News Reader

Shadow DOM enabled in Firefox nightly

bugzilla.mozilla.org

114 pointsvelmu60 comments

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.

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...

I had never considered this before. Would Shadow DOM make browser plugins like Stylish useless against horribly layed out websites?

There has to be a work around for this issue...

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.)

https://developers.google.com/web/updates/2017/10/remove-sha...

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.

Maybe not related, but we can style frames in various shapes with css clip-path. It start to be reliable. https://developer.mozilla.org/en-US/docs/Web/CSS/clip-path

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).

Does any major frontend framework plan to use these native APIs? Seems like a good opportunity to enhance the performance of web apps to me.

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.

There are also a lot of existing web components libraries that have been developed in anticipation of first class support for Shadow DOM in all browsers. See https://en.m.wikipedia.org/wiki/Web_Components#Libraries

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.

Polymer is pretty integrated with shadow dom iirc, although last time I used it I had to use a bunch of polyfills.

You don't need any polyfills on Chrome, Safari, Opera and soon Firefox obviously. Edge is the only holdout.

Perhaps not as 'major', but Aurelia is intentionally aligned with web components and other standards:

https://aurelia.io/

Is it still a thing?

Not a major framework, but UIBuilder lets you use Web Components using JSX, just like React:

https://github.com/wisercoder/uibuilder

Angular supports this for quite some time.

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.

For custom elements, here's a list at https://custom-elements-everywhere.com/

With /deep/ deprecated and css @apply nowhere in sight I'm not sure I like styling stuff inside shadow boxes...

CSS Shadow Parts, aka ::part and ::theme is the answer there: https://meowni.ca/posts/part-theme-explainer/

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.

Any info on what this is?

https://developer.mozilla.org/en-US/docs/Web/Web_Components/...

It enables you to keep the markup structure, style, and behavior hidden and separate from other code on the page so that different parts do not clash.

https://developer.mozilla.org/en-US/docs/Web/Web_Components/...

See shadow dom section in here: https://github.com/w3c/webcomponents/ which specified most of docs are maintained in here: https://dom.spec.whatwg.org/

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

Use it now, the polyfills are really good for older browsers.

Hmm good to know I’ll definitely look into it!

They are?

Polymer has a tendency to get confused by its own loading process and go into infinite loops. Are there any other shadow DOM polyfills out there?

(And last I checked, Polymer was polyfilling the old proposal, not the one that is currently being implemented in browsers.)

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.

> I yet ever heard of infinite loops in loading. Do you have an open issue?

https://bugzilla.mozilla.org/show_bug.cgi?id=1256031 has an example of a page using polymer that runs into this problem.

Did anyone file an issue on the polyfills? We're not going to be aware of issues on Firefox's bug tracker...

Also, that's an old version of the polyfills, before Polymer 2.0, it might have been fixed on our end quite a while ago.

to an outsider, web development looks like hacks upon hacks upon hacks upon hacks upon ......

Unfortunately, this is what happens when you need to ensure backward compatibility with the lowest denominator...

this is pretty much how i feel about computing in general

if it works, it works, though.

Imagine you had a chat, and 30 videos in the chat.

30 play buttons 30 vulume sliders 30 pause buttons Etc

That's a lot in the DOM.

So intead you put the html5 video player components in shadowDOM and reference as needed. Only have them once then.

But they don't have the same state. Some of them are half run. Some of them have sound off. Some are paused or playing. One is selected.

Is the state separated from structure ?

State can be orchestrated from the parent document. Custom elements can implement their own APIs.

So what's the difference with a webcomponent ?

ShadowDOM and the other parts of the web components specs don't do any of that kind of de-duplication which you describe, sorry.

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.

[0] https://www.designedbyaturtle.co.uk/2015/how-to-enable-web-c...

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.

Which would you recommend? ShadyDOM?

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.

At least in chrome you can enable "Show user agent shadow DOM" in the Settings. I don't know about other browsers, sorry.

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.

What does this mean for a normal user?

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.

About time, dang

Reply on news.ycombinator.com