getPropertyType/getAttributeType when null namespaces are passed.

[fred-wang]

cc @smaug---- @mbrodesser-Igalia @lukewarlow

elementNs and attrNS are optional nullable arguments defaulting to the empty string, so we should test what happens when null values are used:

optional DOMString? elementNs = ""
optional DOMString? attrNs = ""

• For attrNS, a null value is explicitly handled in Get Trusted Type data for attribute. This case is covered by "getAttributeType with full namespace info" cases of TrustedTypePolicyFactory-getAttributeType-namespace.html because attribute.namespaceURI is null here, but maybe a more explicit test with a null argument would help.

• For elementNs, the step retrieving the "element interface for localName and elementNs" is similar to step 7 of DOM's create an element. Probably this is not very explicit, but I understand this falls back to the Element interface for null namespace, similarly to createElementNs(null, "foo"). However, we don't have any tests for that (see There's a lack of test coverage over the namespace aspect of getPropertyType #429).

[fred-wang]

For elementNs, the step retrieving the "element interface for localName and elementNs" is similar to step 7 of DOM's create an element. Probably this is not very explicit, but I understand this falls back to the Element interface for null namespace, similarly to createElementNs(null, "foo"). However, we don't have any tests for that (see #429).

So checking on Chromium and WebKit, an explicitly null elementNs seems to fallback to the HTML namespace.

[koto]

This seems to be resolved in the spec via #557, and in WPT via web-platform-tests/wpt#48769. @fred-wang, do you agree this can be closed now?

[fred-wang]

Right, we can close it now.