Are `getAttributeType` and `getPropertyType` methods neccessary?

[lukewarlow]

This has been raised elsewhere but worth making a standalone issue for it.

In #381

Even better would be to remove both methods, since it is unclear if they are needed.

In Mozilla's standards position https://github.com/mozilla/standards-positions/issues/20#issuecomment-1853427823:

First and foremost, there is some functionality (e.g., getPropertyType, getAttributeType that seem a bit odd and their usage in the wild isn't clear to us.

I (implementing in WebKit) have also questioned if they're actually useful when reading the spec. After more time I think they could be valuable.

[tosmolka]

FYI, usage of getAttributeType API in DOMPurify:

• https://github.com/cure53/DOMPurify/blame/b3b441e6589f49c506b4840aea3421aa83c62f52/src/purify.js#L1296C40-L1296C40
• https://github.com/cure53/DOMPurify/pull/699

[lukewarlow]

As a rough test of what it would be like I did a quick local patch of htmx to make it pass trusted types requirements and have come across a few places where getAttributeType is useful.

Example below:

           forEach(mergeFrom.attributes, function (attr) {
                if (shouldSettleAttribute(attr.name)) {
                    const type = trustedTypes.getAttributeType(mergeTo.tagName, attr.name);
                    if (type === "TrustedHTML") {
                        mergeTo.setAttribute(attr.name, htmxPolicy.createHTML(attr.value));
                    } else if (type === "TrustedScript") {
                        mergeTo.setAttribute(attr.name, htmxPolicy.createScript(attr.value));
                    } else if (type === "TrustedScriptURL") {
                        mergeTo.setAttribute(attr.name, htmxPolicy.createScriptURL(attr.value));
                    }
                }
            });

That being said I'm not sure if this is something that couldn't just be achieved with a small userland code snippet. The polyfill of these functions isn't very big and most people probably only need a very small subset?

[mozfreddyb]

I think the html and DOMPurify examples are good presentations of real world use cases: Whenever you have code that is assigning attributes on elements in a generic way (e.g., templating) you want to make sure that this assignment works properly ans safely. Asking the TT API for which enforcement is in place and being able to call an appropriate TT constructor seems only reasonable.

Looking at this again, the alternative is indeed that a script is writing their list of TT-controlled HTML themselves, as {element, attribute, type} triple, where element is an HTML element, attribute an attribute and type would be a Trusted Type (TrustedHTML etc.).

With software evolving, I'd assume that it would be nice for developers to rely on the platform to have its back and co-evolve rather than having to hand-roll this list and keep it up to date. The overhead for the web platform as a somewhat simple list lookup seems relatively low but the benefits of co-evolving this with HTML rather than have pages break if new XSS sinks arise seems preferable to me.

[lukewarlow]

Given the above comment I'm going to go ahead and close this issue out as there's a valid use case for them.

[mozfreddyb]

Sorry, to clarify. My comment had lots of "I" and not a lot of "we" intentionally. I'd like to hear @smaug----'s and @petervanderbeken's take on this too :)

[lukewarlow]

Just found Chromium also has a getTypeMapping function shipped to stable which isn't in the current spec at all. https://github.com/w3c/trusted-types/issues/432 we should similarly decide if we can remove it or if we can keep it and it needs speccing.

[mozfreddyb]

I've asked around internally. There's agreement to keep getAttributeType and getPropertyType. I think we can close it and discuss getTypeMapping in #432.