Allow customizing base URL of a shadow root

[dvoytenko]

It'd be very convenient in a number of applications to be able to customize base in shadow root, either via <base> tag or baseURI property. Shadow root are now used for embeds (e.g. Twitter embed) and it'd be good to have relative URL resolution scoped to shadow root.

[rniwa]

@hayatoito @annevk @domenic

[rniwa]

I can see that making a base element inside a shadow tree adjusting the base URI of everything inside the shadow tree, or exposing baseURI IDL attribute on ShadowRoot would be useful in some cases.

[hayatoito]

Yeah, we should allow <base> in a shadow tree. +1 for that.

As per the current spec, <base> is banned in a shadow tree.
http://w3c.github.io/webcomponents/spec/shadow/#inertness-of-html-elements-in-a-shadow-tree

However, as far as I know, the reason is simply that we do not have bandwidth to support this as a v1 feature.

Let's support this in v2 feature. We might want to update HTML Standard directly: https://html.spec.whatwg.org/#the-base-element

[annevk]

We discussed this before and could not come up with a satisfactory design back then: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20976#c23. (Note that if we go down this route anyway, if we overcome those obstacles somehow, we shouldn't repurpose the base element. We need something static that cannot change.)

[annevk]

Note also that the use case discussed in OP is something that probably warrants the sometimes-discussed isolated shadow trees. Those would have their own base URL due to being isolated.

[rniwa]

Maybe baseURI could be an option to attachShadow and a readonly IDL attribute on ShadowRoot?

[annevk]

Maybe, but see the bug I pointed to. It doesn't help when creating elements dynamically.

[rniwa]

One way to mitigate that might be adding createElement on ShadowRoot so that base URI, etc... could be appropriately adjusted at the construction time.

[annevk]

Meaning element constructors are broken-by-design?

[rniwa]

@annevk : This is why I wanted to make Document as the first mandatory argument for custom elements. That provides a way of scoped custom element registry, etc...

But really, there is no way to know whether a given element is created for a shadow tree or not without giving some information about it. Also, constructor shouldn't be doing something different based to which tree it belongs. e.g. img element only fetches its resource when src attribute is set. Anyhow, all these elements that do work before getting inserted into some tree is really an anti-pattern.

[dvoytenko]

Is there any adoption phase that's executed when an element is appended into shadow root? Can the affected values be efficiently recalculated? E.g. it could look like a smaller-scope update when the document's <base> is changed.

[annevk]

Appending is too late for <img>. @rniwa, that discounts that script might want to perform preloading and such too.

[rniwa]

@annevk : I don't think implicitly preloading scripts while it's not connected to a document is a good pattern because that can easily lead to unintentional / accidental fetches users of the elements didn't intend. It's much better to manually Fetch or do it when the element is inserted into a document. For example, link element supports preload attribute but it doesn't start preloading immediately when the attribute is added; it needs to be inserted into a document.