dom
dom copied to clipboard
whatwg
Add attribute validate steps.
When handling attribute change, validate the value before setting it.
Attribute append now also takes a value, and sets it only after handling the changes (this should be side-effects free, as no callbacks in handle attribute change get passed the attribute node - whose value is not yet set).
See #789 for the background. This PR doesn't allow the validate steps to change the value, only to possibly reject setting it.
:boom: Error: 500 Internal Server Error :boom:
PR Preview failed to build. (Last tried on Jan 15, 2021, 7:33 AM UTC).
More
PR Preview relies on a number of web services to run. There seems to be an issue with the following one:
:rotating_light: CSS Spec Preprocessor - CSS Spec Preprocessor is the web service used to build Bikeshed specs.
:link: Related URL
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator at
[no address given] to inform them of the time this error occurred,
and the actions you performed just before this error.</p>
<p>More information about this error may be available
in the server error log.</p>
<hr>
<address>Apache/2.4.10 (Debian) Server at api.csswg.org Port 443</address>
</body></html>
If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.
Friendly ping, this seems to be the most efficient way we can prevent attribute node bypasses in Trusted Types by rejecting the value without potentially calling the default policy on all attr mutations.
I think this makes sense, but we should add a note explaining this setup somewhere close to where it's relevant.
This should have implementor interest now given Mozilla's positive standards position on trusted types as a whole.
I wonder if we want an arbitrary extension point for this or just call into Trusted Types directly. With an arbitrary extension point we have the risk of running into ordering issues so we tend to avoid those these days, even though the DOM has some precedent for it (mainly historical).
I wonder if we want an arbitrary extension point for this or just call into Trusted Types directly.
I don't have a strong preference here. As long as it is possible to guard attribute mutations done by the DOM APIs, the actual algorithms can be defined in either spec. This PR was the only necessary integration point of TT with DOM.
What might be problematic is not technical, i.e. can DOM call out to specs that are currently at FPWD? Waiting until CR is probably not very useful to the authors here, especially with shipped implementations.
That's not really an issue, especially for integration points. And in fact, we tend to prefer referencing the latest editor's draft.
https://github.com/whatwg/dom/pull/1247 and https://github.com/w3c/trusted-types/pull/418 supercede this one. Unfortunately handling the attr mutation in DOM happens now after setting the new value, so I had to add an explicit new step to the algorithms.