Re: [whatwg/webidl] Add `{{StringContext}}` extended attribute (PR #1392)

@annevk commented on this pull request.

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?

> @@ -10259,6 +10261,36 @@ that does specify [{{SecureContext}}].
     </pre>
 </div>
 
+<h4 id="StringContext" extended-attribute lt="StringContext">[StringContext]</h4>
+
+If the [{{StringContext}}] [=extended attribute=] appears on {{DOMString}} or {{USVString}}, it
+modifies how the value is converted to the IDL type, causing additional value validation to
+adhere to the context the string is used in.
+
+The [{{StringContext}}] extended attribute must [=takes an identifier|take an identifier=]. The [=identifier=]
+must be one of "<code>TrustedHTML</code>", "<code>TrustedScript</code>" and "<code>TrustedScriptURL</code>".

Missing Oxford comma.

> @@ -11092,8 +11139,16 @@ Note: The HTML Standard defines how a security check is performed. [[!HTML]]
             1.  If the argument at index |i| is declared with a [=optional argument/default value=],
                 then append to |values| that default value.
             1.  Otherwise, append to |values| the special value “missing”.
-        1.  Otherwise, append to |values| the result of [=converted to an IDL value|converting=]
-            |V| to IDL type |type|.
+        1. Otherwise:
+            1.  If |type| is an IDL type [=extended attribute associated with|associated with=] the
+                [{{StringContext}}] extended attribute, then set |V| to the result of performing
+                [=validate the string in context=], passing [=this=], |V|, the {{StringContext}}
+                extended attribute [=identifier=], and the [=identifier=]
+                of the [=operation=] or [=extended attribute=] of the first entry in |S|.

But what if that overload doesn't have a StringContext annotated type?

I guess what this means is that you cannot meaningfully have overloaded StringContext types (or at least not all variants one might imagine to be possible). That seems reasonable, but I wonder if we need to make that more explicit in some way.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1392#pullrequestreview-1933937040
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1392/review/1933937040@github.com>