New feature proposal: HTMLScriptElement.supports(type) method

[horo-t]

Currently there is no simple way to know what kind of types can be used for HTMLScriptElement’s type attribute.

There are several new feature proposals using the script element.

• https://github.com/WICG/import-maps
• https://github.com/WICG/resource-bundles/blob/main/subresource-loading.md

We can use the nomodule attribute to detect the module type support as this example shows.
But there is no unified method to detect such new features. (E.g.: WICG/import-maps#171)
If we have the HTMLScriptElement.supports(type) method which is like HTMLLinkElement.relList.supports(), we can easily detect such features.

The change of the spec will be like this.

[hiroshige-g]

When implementing supports(), should it reflect the actual behavior of <script> on that browser (e.g. returning true for non-standard type attribute values that are allowed in Chromium for legacy reasons)?

[hiroshige-g]

As for the spec change, it's better to split out the Step 8 of #prepare-a-script into a helper method and call it from supports(), to ensure the behavior of these two are the same (also it will further clarify the intention of supports()). In the current commit, they behaves slightly differently due to lack of leading and trailing ASCII whitespace stripped call in supports().

[domenic]

Another example is https://github.com/jeremyroman/alternate-loading-modes/blob/main/triggers.md#speculation-rules .

FWIW I am cautiously positive on this. Feature-detection interfaces are always a bit tricky, but we have positive experience so far with relList.supports(), and this proposal builds on a shared primitive even more so than relList.supports() does.

Any thoughts from other implementers? @annevk @hober

[annevk]

What are the non-standard type attribute values? I think it would be cleaner to build the API on top of https://html.spec.whatwg.org/#concept-script-type and only support "classic" and "module".

Limiting the type IDL attribute to known values is probably a breaking change at this point, so this seems reasonable overall.

[horo-t]

It sounds reasonable to me that support() only supports "classic" and "module".
What do you think? @hiroshige-g @domenic

[domenic]

I'm a bit torn. I like the simplicity of that. But then it's totally disconnected from the type="" attribute.

It does match the { type } option to new Worker() though, so maybe that's good enough precedent.

[hiroshige-g]

Supporting only "classic" and "module" sounds good, while it deviates from type attribute and DOMTokenList approach.

To align with WorkerOptions, we should do exact match, i.e. strings with leading/trailing white spaces and uppercases are not considered supported.
(relList.supports() allows uppercases but not whitespaces, <script type> attribute allows both though, but practically I don't expect this is problematic)

[horo-t]

Thank you. Disallowing uppercases sounds good to me. Updated spec change.

[horo-t]

I created a pull request #7008. Could you please review?

[domenic]

Another point in the design space that just occurred to me is to omit "classic" and use this only for types that have their own dedicated <script type=""> string. Since everyone can assume classic script support as a baseline.

I think I am OK either way, and maybe even slightly prefer keeping "classic" based on the arguments about symmetry with the Worker constructor, but I wanted to mention that possibility.

[annevk]

Ah interesting; I'm okay with either.

[domenic]

@guybedford would this be useful to es-module-shims in any way? In particular it would be a simple synchronous way to detect importmap support.

[guybedford]

Yes, it definitely would be useful. I wonder if this could extend to JSON / CSS module script support detections as well?

Just removing import maps from that list would be a huge benefit though.

[domenic]

I wonder if this could extend to JSON / CSS module script support detections as well?

I think that would require a different entry point, since they are all types of modules. Maybe something like import.meta.supportsType('css'). But I like the idea and wonder if we can get any implementer interest :). Probably worth a separate thread; I'll start one...

[domenic]

A separate note: I like putting this on HTMLScriptElement because it's specifically about what types are supported by <script>. E.g. you cannot use importmap or speculationrules in new Worker(url, { type }).

If we do ever extend workers with more types, we could introduce a separate Worker.supports('module').