"Validate the string in context" takes any value and calls "Get Trusted Type compliant string" which requires a TrustedType or a string

[mbrodesser-Igalia]

https://w3c.github.io/trusted-types/dist/spec/#html-validate-the-string-in-context

https://w3c.github.io/trusted-types/dist/spec/#get-trusted-type-compliant-string-algorithm

Should https://w3c.github.io/trusted-types/dist/spec/#html-validate-the-string-in-context try to stringify the value before passing it to https://w3c.github.io/trusted-types/dist/spec/#get-trusted-type-compliant-string-algorithm?

In any case, when https://w3c.github.io/trusted-types/dist/spec/#html-validate-the-string-in-context 's value has no stringifier, https://w3c.github.io/trusted-types/dist/spec/#html-validate-the-string-in-context should presumably throw an exception.

[mbrodesser-Igalia]

Alternatively, perhaps https://w3c.github.io/trusted-types/dist/spec/#html-validate-the-string-in-context could be adapted to take either a TrustedType or a string. Then https://github.com/whatwg/webidl/pull/1392 would require adaptation too.

CC @lukewarlow since it might affect above PR.

[mbrodesser-Igalia]

Tried to learn from an existing spec: https://dom.spec.whatwg.org/#dom-node-textcontent takes a value and calls https://dom.spec.whatwg.org/#string-replace-all which expects a string. However, the stringification of value to string is not specified. Did I miss anything?

CC @domenic

[lukewarlow]

Yeah you're right the "html" algorithm probably needs updating. I'm not sure what the correct way to do it is though.

[annevk]

(For textContent stringification follows from IDL and it only accepting a string.)

[lukewarlow]

That makes sense, and because this is before full type conversion it's just a raw value so we should be handling it.

[mbrodesser-Igalia]

(For textContent stringification follows from IDL and it only accepting a string.)

Why does it follow from IDL? See e.g. https://jsfiddle.net/jmfdasgp/.

[lukewarlow]

Because the IDL says it's a nullable DOMString so by the time the setter steps are running the value is already either null or stringified.

[mbrodesser-Igalia]

Because the IDL says it's a nullable DOMString so by the time the setter steps are running the value is already either null or stringified.

Agreed.

Where is the conversion from other objects, e.g. from a div element (e.g. https://jsfiddle.net/jmfdasgp/), to a DOMString specified? The IDL for the div element, https://html.spec.whatwg.org/#the-div-element, contains no stringifier and neither do its ancestors.

[lukewarlow]

contains no stringifier and neither do its ancestors.

The Object type itself has its own stringifier which is what is being used.

[lukewarlow]

I'm thinking to solve this we could change Get trusted type compliant string to take any type, and then after step 1 insert a new step that stringifies the value (and throws if it can't stringify, I'm not sure any JS type can't be stringified though?)

[petervanderbeken]

Can this be closed? We're going to be using unions (like DOMString or Trusted*), right? So WebIDL argument conversion will pass either a WebIDL DOMString value or a platform object that implements the right Trusted* type.

[lukewarlow]

Yep you're right. I'll close this out. (The algorithm will be removed by a draft PR I have)