Re: [heycam/webidl] Added a definition of {{StringContext}} extended attribute. (#841)

> We could have that language in the other specs instead, possibly added via an extended attribute.

OK.  I'd like to understand what the problems are with that.

> The move to IDL type mapping is to avoid having type unions and branching on the types in each operation. 

I'm not quite following this, sorry.  Can you explain further what you mean here?

> and what we think is the best way to implement TT

That _really_ depends on how type conversion is implemented and how generic or special-cased it is.  For example, the type conversion code may well not have the attribute/operation involved available to it (as trusted types requires), because they are not needed in that code right now.

That said, I would really like to avoid diving into implementation specifics, which differ greatly across engines, I suspect, and sort out the conceptual right place to have this live.  Now that I think I understand the setup (though I thought that before too!), it seems like the possible places to put this are:

1) Inside DOMString/USVString conversions, and thread through the information those need, like which operation/attribute the conversion is for.  This could happen _before_ or _after_ conversion to an IDL value.  Looks like this PR does it "before".
2) At the places where args to operations or setters are converted.  That would correspond to https://heycam.github.io/webidl/#es-overloads step 11.5 and step 15.5, and https://heycam.github.io/webidl/#dfn-attribute-setter step 6.
3) After conversion but before invoking the spec-described steps.  That would correspond to https://heycam.github.io/webidl/#dfn-create-operation-function step 2.1.8 (well, after 2.1.5 and before 2.1.8), and the https://heycam.github.io/webidl/#dfn-attribute-setter step 7 (or rather beween steps 6 and 7).
4) At the front of the spec-described steps, whether via extended attribute or manually.  Manually seems undesirable.

Now I have my own opinions of how these various options compare, but I'd love a summary of what you view as the tradeoffs and what led to choosing option 1 with the "before" behavior, especially if this is already written down somewhere.  In terms of author-observable behavior, there are three different behaviors here: "option 1 with 'before'" is one, "option 1 with 'after'" and "option 2" are another, I think (in that they behave identically), and "options 3"/"option 4", which also behave identically.

Note that I did read through the two issues listed in the original PR, but there is a _lot_ of back-and-forth in there and it wasn't clear to me exactly why we landed on this outcome.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/841#issuecomment-586354298