Rename the SVG <script> async/defer feature

[foolip]

The type="module" support makes more sense as part of JS modules:
#676

[ddbeck]

https://github.com/web-platform-dx/web-features/pull/676/files#r1517665897 says you're removing svg.elements.script.type.module from this feature. I think it's fine to remain (so the alias still makes sense), so I'm approving as is, but if you think it shouldn't be in the feature after all, I'd like to hear a little more about why.

[Elchi3]

If you leave it in, you are creating situation 4 for MDN: #654 (comment). MDN doesn't have its own page for this BCD key, so it might not be a problem.

[foolip]

There are a few things to contemplate here.

The feature "SVG <script> works like HTML <script>" is very contingent on how browsers evolved. It feels much more contingent-y than most features, and eventually won't be considered a feature at all. Note how I dropped the modules part from the name of this feature to make it shorter, but that didn't really make sense...

On the contents of this feature, I don't think modules and defer should be in a single feature. They are actually mutually incompatible, and an HTML validator will say:

A script element with a defer attribute must not have a type attribute with the value module.

The remaining question is whether async + defer makes sense as a feature, either just for SVG or for HTML+SVG. Caniuse has split it differently:
https://caniuse.com/script-async
https://caniuse.com/script-defer

I'm leaning towards matching that, and either treating SVG support as a (future) note or having "in SVG" features as suggested in #676 (review).

[ddbeck]

The feature "SVG <script> works like HTML <script>" is very contingent on how browsers evolved. It feels much more contingent-y than most features, and eventually won't be considered a feature at all. Note how I dropped the modules part from the name of this feature to make it shorter, but that didn't really make sense...

Hmmm. I feel that something like this should be allowed to (co-)exist? Spitballing here, but maybe we'd be better served by a few (partly overlapping) groups:

• SVG script equivalency
• SVG script async
• SVG script defer
• JS modules

The first one would probably be short-lived (we'd acquire some irrelevance guideline, like BCD), while the others would persist for a long time.

[foolip]

The JS modules part of this features was extracted in #676.

The identifier for this will continue to bug me, in particular the number 2, so I've updated this to svg-async-defer. But should we even have this feature, or should we put back JS modules and rename it to svg-script-parity or something?

[ddbeck]

@foolip can you show example YAML for that? I'm not quite sure what you mean.

[foolip]

@ddbeck I mean like #700.

[ddbeck]

Thanks, @foolip. Very helpful to understand the options here. I guess looking back on what I said in #677 (comment), I think my preferences on this are now:

• Split this PR in two, as in svg-script-async and svg-script-defer. (Reasoning here that web developers won't be looking for both async and defer, they'll just be wondering why the one they tried to use isn't working.)
• Drop Rename and restore the SVG <script> parity feature #700 and the "equivalency" angle entirely. I see now that "equivalency with HTML" is not a feature. It's why async and defer should work in SVGs, but I have a hard time seeing it as a thing one could use. As if you'd want the option to insert a script tag into either HTML or SVG dynamically or something? It's too weird.

[ddbeck]

And on a meta issue: I've sent a message to François to look into spam controls on the repo—I don't have the necessary privileges in the web-platform-dx org.

[foolip]

@ddbeck sounds like we're on the same page, I don't think this amounts to a coherent feature.

[foolip]

Reopening just to serve as a reminder to split into smaller features.

[foolip]

I'll close this and open an issue instead.