Intent to Ship: HTMLScriptElement.supports(type) method

154 views
Skip to first unread message

Tsuyoshi Horo

unread,
Sep 21, 2021, 11:21:37 PM9/21/21
to blink-dev

Contact emails

ho...@chromium.org

 

Explainer

https://github.com/horo-t/explainers/blob/main/script_element_supports.md

 

Specification

https://html.spec.whatwg.org/multipage/scripting.html#dom-script-supports

 

Design docs

https://github.com/horo-t/explainers/blob/main/script_element_supports.md

 

Summary

Provides a unified way to detect new features that use script elements.

 

 

Blink component

Blink>HTML>Script

 

TAG review

https://github.com/w3ctag/design-reviews/issues/674

 

TAG review status

Issues addressed

 

Risks

Interoperability and Compatibility

This method provides a synchronous way of feature detections. But for unsupported browsers, developers need to use an asynchronous way as discussed at https://github.com/WICG/import-maps/issues/171.

 

 

Gecko: Worth prototyping (https://github.com/mozilla/standards-positions/issues/576)

 

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-September/031979.html)

 

Web developers: Positive The developer feedback on the spec issue (https://github.com/whatwg/html/issues/6472) was positive.

 

Ergonomics

No known ergonomics risks.

 

 

Activation

No known activation risks. This method is easy to use.

 

 

Security

No known security risks.

 

 

Debuggability

Developers can call this method from DevTools's console.

 

 

Is this feature fully tested by web-platform-tests?

Yes

 

DevTrial instructions

https://github.com/horo-t/explainers/blob/main/script_element_supports_how_to.md

 

Flag name

ScriptElementSupports

 

Requires code in //chrome?

False

 

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1245528

 

Sample links

https://horo-t.github.io/explainers/script_element_supports_sample.html

 

Estimated milestones 

DevTrial on desktop 95

DevTrial on android 95

DevTrial on Webview 95

 

 

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5712146835963904

 

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/evk2qgsekYk/m/WtdE_XplBQAJ

Ready for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/-sE2GpCrG6Y/m/UsHXyVW-CAAJ

 

 

This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,
Sep 23, 2021, 6:06:42 AM9/23/21
to Tsuyoshi Horo, blink-dev
LGTM1

On Wed, Sep 22, 2021 at 5:21 AM Tsuyoshi Horo <ho...@chromium.org> wrote:

 

Design docs

https://github.com/horo-t/explainers/blob/main/script_element_supports.md

 

Summary

Provides a unified way to detect new features that use script elements.

 

 

Blink component

Blink>HTML>Script

 

TAG review

https://github.com/w3ctag/design-reviews/issues/674

 

TAG review status

Issues addressed


It should be noted that there was disagreement between the TAG and the spec authors on the naming. 
While I lean towards the call the spec authors made, the need for better JS feature detection is something I repeatedly hear both from the TAG and others. Orthogonal to this intent, this seems like something we should eventually tackle.

 

Risks

Interoperability and Compatibility

This method provides a synchronous way of feature detections. But for unsupported browsers, developers need to use an asynchronous way as discussed at https://github.com/WICG/import-maps/issues/171.


Is it worthwhile to document the desired code patterns we want developers to use? (e.g. test is `supports()` exists and fallback to the async method otherwise)
 
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-Vi%2BhCDOA2y0%2BfUU-dt60_ySvSY0-MjDyGTMi8oHcrm9A%40mail.gmail.com.

Daniel Bratell

unread,
Sep 23, 2021, 1:50:17 PM9/23/21
to Yoav Weiss, Tsuyoshi Horo, blink-dev

LGTM2

/Daniel

Alex Russell

unread,
Sep 23, 2021, 3:15:12 PM9/23/21
to blink-dev, Daniel Bratell, blink-dev, Yoav Weiss, Tsuyoshi Horo
LGTM3

Would like to see a concrete plan for expanding this method to other media-loading elements (<link>, <style>, etc.)

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Domenic Denicola

unread,
Sep 23, 2021, 3:24:29 PM9/23/21
to Alex Russell, blink-dev, Daniel Bratell, Yoav Weiss, Tsuyoshi Horo
On Thu, Sep 23, 2021 at 3:15 PM Alex Russell <sligh...@chromium.org> wrote:
LGTM3

Would like to see a concrete plan for expanding this method to other media-loading elements (<link>, <style>, etc.)

<link> already supports this via linkEl.relList.supports("foo"). The different API shape is necessary because rel="" can contain multiple space-separated tokens, and it also generalizes with other DOMTokenLists that benefit from supports() like iframeEl.sandbox.supports("foo").

<style> currently only supports CSS, but I agree that if we were to ever add multiple stylesheet languages to the platform then we'd want an API like this on HTMLStyleElement.
 

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/545e1e7f-7285-41fa-b16a-6918021593b8n%40chromium.org.

Tsuyoshi Horo

unread,
Sep 23, 2021, 11:42:57 PM9/23/21
to Domenic Denicola, Alex Russell, blink-dev, Daniel Bratell, Yoav Weiss
Thank you very much for LGTMs!

 

Risks

Interoperability and Compatibility

This method provides a synchronous way of feature detections. But for unsupported browsers, developers need to use an asynchronous way as discussed at https://github.com/WICG/import-maps/issues/171.


Is it worthwhile to document the desired code patterns we want developers to use? (e.g. test is `supports()` exists and fallback to the async method otherwise)

Yes. Sure. I  updated this doc to explain how to detect the importmap support without HTMLScriptElement.supports(type) method.

 

Yoav Weiss

unread,
Sep 24, 2021, 1:13:53 AM9/24/21
to Tsuyoshi Horo, Domenic Denicola, Alex Russell, blink-dev, Daniel Bratell
On Fri, Sep 24, 2021 at 5:42 AM Tsuyoshi Horo <ho...@google.com> wrote:
Thank you very much for LGTMs!

 

Risks

Interoperability and Compatibility

This method provides a synchronous way of feature detections. But for unsupported browsers, developers need to use an asynchronous way as discussed at https://github.com/WICG/import-maps/issues/171.


Is it worthwhile to document the desired code patterns we want developers to use? (e.g. test is `supports()` exists and fallback to the async method otherwise)

Yes. Sure. I  updated this doc to explain how to detect the importmap support without HTMLScriptElement.supports(type) method.

That's great! It would be similarly great if that finds itself into developer-facing documentation (MDN, web.dev, etc). Searching around, I can't find any for neither this nor import maps :/
Reply all
Reply to author
Forward
0 new messages