whatwg / webidl

Web IDL Standard
https://webidl.spec.whatwg.org/
Other
410 stars 164 forks source link

Add `{{StringContext}}` extended attribute #1392

Closed lukewarlow closed 7 months ago

lukewarlow commented 8 months ago

Add a {{StringContext}} extended attribute that can be defined on DOMString and USVString.

This is to hook up the Trusted Types validation during the ES->IDL type conversion to avoid issues with its default policy.

See https://github.com/w3c/trusted-types/issues/248, https://github.com/w3c/trusted-types/issues/176

The actual logic of the string validation calls into HTML, and will be something similar to https://w3c.github.io/trusted-types/dist/spec/#html-validate-the-string-in-context.

(See WHATWG Working Mode: Changes for more details.)


Preview | Diff

lukewarlow commented 8 months ago

Fork of #841 will address review comments here

yuki3 commented 8 months ago

I think this looks reasonable, although I think we probably should note the overload limitations more explicitly.

@EdgarChen @petervanderbeken @yuki3 any of you want to take a look as well?

Looks good to me, too.

yuki3 commented 8 months ago

cc @natechapin as he's taking over the Blink-V8 bindings work (including interop work) from me.

petervanderbeken commented 7 months ago

I do think that we need to make [StringContext]-annotated strings not distinguishable from object, interface-like, callback function, dictionary-like and sequence-like. So we probably need to add another letter in the table, and use it in the string types row to explain that these are only distinguishable if the string type doesn't have a [StringContext] extended attribute.

lukewarlow commented 7 months ago

Based on discussions here, in Matrix and a video call we had with Koto and Daniel I'm going to go ahead and close this PR. If Daniel discovers a reason why the observable timing differences between IDL and call site aren't web compatible we can revisit this.