Re: [whatwg/dom] Trusted types attributes (PR #1268)

otherdaniel left a comment (whatwg/dom#1268)

The solution outlined here is correct & self-consistent, and if all implementations agree I'll be happy.

I still think we can be simpler, though: The default policy introduces a seemingly concurrent operation. All operations, on all three categories of APIs outlined above, can be explained by serializing these operations.

Consider setAttributeNode:

As spec'ed here: First check structure; then run TT check; then re-check structure.
    - TT error => throws TypeException
    - structure error but no TT error => DOMException AttributeInUseError
    - structure error created in TT callback => DOMException AttributeInUseError
    - TT error *and* structure error =>TypeException
 
If instead, we spec it like so:
1. Let verifiedValue be value.
2. If verify is true: [... TT check; assign to verifiedValue ...]
3. If attr’s element is neither null nor element, throw an "InUseAttributeError" DOMException
4. [... old spec, but verifiedValue instead of value ...]

I think this would get us all of the same error conditions, but fewer operations. And IMHO easier to understand. And I like it, because explaining this behaviour in terms of serializing the checks and running the TT check gives us a guideline which we can apply to all similar cases.

There is one observable difference I can think of: If we have a structure error, and if the TT policy itself throws an exception, then in the first case we'd get AttributeInUseError, and in the second we'd get TypeException. I think that's okay.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1268#issuecomment-2656686537
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1268/c2656686537@github.com>