Document.write and such as names are misleading

[annevk]

The Document class does not have a static write property. I think we should make this Document.prototype.write or at least something that does not suggest a misleading thing (and which well might conflict in the future).

Via whatwg/webidl#841 (comment).

[koto]

Thanks, that's a good point. We're taking the data from the context object in steps 1.1 and 1.2 here, so it should be easy. There is still a potential collision as we're using the DOM local names for Elements for simplification.

[annevk]

I guess elements will always be lowercase? However, you probably want to distinguish SVG script from HTML script?

[koto]

There's probably no conflict possibility for static vs regular operations. In WebIDL 2.5.3:

The identifier of a static operation also must not be the same as the identifier of a regular operation defined on the same interface

There's a similar restriction for attributes:

The identifier of an attribute must not be the same as the identifier of another interface member defined on the same interface. The identifier of a static attribute must not be "prototype".

I looked into our implementation, and it doesn't seem like we have the information to distinguish between prototype / static readily avaliable in the exception state. We actually (contrary to the spec) always use the constructor name, so:

data:text/html,<meta http-equiv="content-security-policy" content="require-trusted-types-for 'script'"><script>addEventListener('securitypolicyviolation', (e) => alert(e.sample));s=document.createElement('iframe');s.srcdoc = 'aaa'</script>

alerts HTMLIframeElement.srcdoc

It sounds like this might actually be a good outcome - if we always use the constructor name, that suggests to the authors that the sample contains the information about the sink in IDL (which is what the checks will hook on to), regardless on whether it's static or on the prototype.

[annevk]

I didn't realize IDL forbids conflicts, but I don't think it's a good idea to standardize on this rather misleading naming either.

cc @domenic

[domenic]

+1, as a web developer I find it supremely confusing when browser developers start talking about static methods and properties (like Document.write or HTMLIFrameElement.srcdoc) which do not exist.

At the very least, please use a different separator than "." A space would be a huge improvement.

[koto]

Agreed that we should not confuse - if changing the separator to a space, or anything else really makes it so devs are not confused that the value is the identifier of the IDL interface and not the ES object, I'm all for it. Space it is.

[koto]

Changes to the spec:

• referred to IDL's this value identifier instead of object constructor name to signify we're closer to IDL.
• removed special casing for elements (e.g. svg => SVGElement)
• used space instead of a dot, so HTMLIFrameElement srcdoc will be the value passed to the default policy, and later to CSP violation.
• eval violations continue to use eval.
• used "HTMLScriptElement src" and HTMLScriptElement text for violations when preparing a script. Added a todo for SVG scripts.
• in CSP violation samples used | instead of a space to separate the sample prefix (sink name) from the payload (the string value).

It's much better now, thanks all!