Allow attachShadow on <script> and <style>

[bjenik]

<script> and <style> can be made visible and interactive using display: block; and contenteditable - more details here https://bjenik.com/hackableeditor/. This request opens up the ability to enhance that interactivity with syntax highlighting and autocomplete by putting a more advanced editor like monaco in the shadow dom for those tags, which at the moment is prevented by the attachShadow allow list.

[bathos]

Both of these elements have special associated tokenizer states that would collide with the declarative syntax for shadow root. They also have existing initialization/change behaviors. For script in particular it seems like this use case, though cool, is probably not sufficient to justify a relatively high risk of introducing novel security issues and xss opportunities.

FWIW, it is possible currently to create novel contracts around elements like this. For example one can have a custom element that has a slot that expects a script element as its child or which places one in the shadow itself.

[WebReflection]

Yet another winning case for built-in extends:

customElements.define(
  'js-highlighted',
  class extends HTMLScriptElement {
    connectedCallback() {
      console.log('There you go!');
    }
  },
  {extends: 'script'}
);

// try it
document.head.innerHTML = '<script is="js-highlighted"></script>';

Works already with all browsers but WebKit based, but there's a ~2K polyfill you can use through feature detections for that in case you target those too (see ungap custom-elements).

Hope this helps 👋

[bjenik]

@bathos I understand that my request is a bit out there and one would need to carefully consider security implications, specifically for <script> maybe less so for <style>. I also understand that because my request is relatively obscure, while at the same time being costly, it may not get a high priority or even make the bar of "we should do this". The question basically comes down to if the spec is more of a goalpost that one would want to push forward (my direction not necessarily being the first priority obviously) or if it is more of a minimal subset of things that different browser vendors agree on being necessary. I assume you can judge that much better than I could.

@WebReflection maybe I'm missing or misunderstanding something, but my goal is to affect what the element renders as - and from all the documentation I could find, that is still done with shadow dom for custom elements like so:

    constructor() {
        super();
        shadow = this.attachShadow({mode: 'open'});
    }

which still seems to fail for the same reason. Let me know if I overlooked something.

[WebReflection]

ShadowDOM you a needed only to sandbox styling or protect the content from undesired access, it’s a specification a part, not something strictly related to custom elements. So with builtin you can do anything you’d do with shadow DOM except you won’t have guards for styles and inner tree.

but maybe that’s not what you’re after 🤷‍♂️

[annevk]

I suppose it's worth asking what @whatwg/components thinks about this, but personally I'm not super keen on extending this list of elements. In fact, if we could change things retroactively I'd probably have only supported custom shadow trees on custom elements.

[bjenik]

@annevk I like that line of reasoning. Only allowing it on custom elements seems perfectly sensible to me - the part of allowing it on some but not others is what's weird to me, especially without clear explanation why these elements and not others. I guess having a plan to either eventually deprecate it fully (if the standard allows that option), having a clear line of what and why or opening it fully could be a good result of that discussion. And you can use my request as the ultimate pointed extreme of "well - now there's a crazy guy who wants it on <script> and <style> - probably not a good idea, but what is our line and why?".

[WebReflection]

worth mentioning, and AFAICT from devtools, Blink itself represents inputs and others through internal Shadow DOM, so I am not sure why only browsers internals should be able to do so, considering how powerful that's been proven to be for any kind of element (think future polyfills too, for possibly new elements, otherwise impossible to gracefully enhance when not known yet ... the next/future video-like element, as example).

Custom Elements have explicit reserved tag names that cannot be used, I don't see a huge issue in adding explicit elements that cannot be used through attachShadow, starting from a meaningful error when that's used within these elements.