Script element document conformance requirements on attributes are incomplete and confusing

[domenic]

What is the issue with the HTML Standard?

The script element is complicated. It has two "controlling" attributes, src="" and type="", and then 8 other attributes.

There are various attempts in the spec to disallow misusing the attributes. For example, saying that many different attributes cannot be used with import maps or data blocks. Or, saying that module scripts may specify the async attribute, but must not specify the defer attribute.

These attempts are not complete. For example, there are no restrictions on the blocking="" attribute, even though it only works in some cases. The only restriction on fetchpriority="" is on data blocks, but it should also be disallowed on import maps. Etc.

I'm not sure on the exact best way to address this. We could try adding more one-off rules, e.g. fixing the above two issues and any others I missed. But something more systematic would be ideal.

It would be pretty cool if we could end up with a table, kind of like the one for the input element: https://html.spec.whatwg.org/#the-input-element . However I'm not sure what the rows of the table would be. Maybe it would work to have them be {external classic script, inline classic script, external module script, inline classic script, import map, data block}?

Another approach would be to try to reorganize to be attribute-centric. E.g., when we describe the nomodule attribute, we describe exactly when it is allowed and disallowed. We don't spread that information out in multiple places. So in this version, you can read straight down a list of attributes, each getting one paragraph, with the first part of the paragraph describing the attribute and the second part describing its usage restrictions.

[annevk]

I think organizing by type of script would give the most value if we had to pick one. "What attributes can I use for my inline script? Does async help with my inline script?" Both would be best.

A table putting type of script against attributes seems like it could provide that.

Note that for input we also separately list for each type what attributes are conforming and which are not. There is quite a bit of "duplication" there.

[sideshowbarker]

Another option to consider: State the requirements in form of an algorithm.

That’s the way the checks and error messages for script attributes are implemented in the HTML checker.

https://github.com/validator/validator/blob/main/src/nu/validator/checker/schematronequiv/Assertions.java#L2877-L2953

I recognize that stating document-conformance requirements in the form of an algorithm wouldn’t normally be the first choice — but given the requirements in this particular case are relatively complex, then no matter how those requirements are stated, they’re going to be harder for developers to follow than typical document-conformance requirements are.