Conversation
noamr
force-pushed
the
zcorpan/upstream-sanitizer-api
branch
from
223a4d1 to
d2034e5
Compare
|
@zcorpan @evilpie @mozfreddyb @otherdaniel |
|
Amazing, thanks for working on this. The built-in safe default configuration is pretty integral to the API, where did I go? For anyone else looking at this, the gist of the changes are in dynamic-markup-insertion.html. |
Oh you're right I had it on my todo list and forgot. Getting to it. Thanks! |
Done. |
| <p>The <dfn>built-in safe baseline configuration</dfn> is the result of <span data-x="parse a JSON | ||
| string to an Infra value">parsing</span> the following JSON string:</p> |
There was a problem hiding this comment.
I think we should use this style for all of the built-in configs, since IMO the JSON is more readable.
There was a problem hiding this comment.
This seems very strange to me. We've always used tables or lists for this kind of data. Using pseudo-code seems contrary to our usual style.
There was a problem hiding this comment.
Yea perhaps we should stay consistent here. I don't feel strongly about this though. @zcorpan are you ok with me reverting this back to tables with links?
There was a problem hiding this comment.
OK. Tables are maybe even better for readability.
There was a problem hiding this comment.
Done, I think. PR preview is broken though.
|
I thought as part of moving this into the HTML standard we'd also address the parser integration issue? |
This is a huge PR so I thought doing it in two stages, the first one being a purely technical upstream, would be easier to review? Open and happy to incorporate the stream-while-parsing changes in this PR if you and @zcorpan are ok to review that in one go. |
|
I prefer doing the parser integration in a follow-up PR. |
| <li><p>If <var>element</var> is a string, then return a new | ||
| <span>SanitizerElementNamespace</span> dictionary with its <code | ||
| data-x="dom-SanitizerElementNamespace-name">name</code> member set to <var>element</var> and its | ||
| <code data-x="dom-SanitizerElementNamespace-namespace">_namespace</code> member set to the |
There was a problem hiding this comment.
Do we really need to use _namespace instead of namespace everywhere? I though that was only necessary in IDL to make the parser happy.
There was a problem hiding this comment.
We don't. So the dictionary member in the IDL is _namespace but when the dictionary is looked up it's namespace? Does that work with WebIDL generation etc?
There was a problem hiding this comment.
Right, the underscore is just escaping in IDL syntax.
|
I think these three PRs would be good to merge before merging into the HTML standard: |
Since some security sensitive changes rely on "sanitizing while parsing", and that in turn relies on the current post-processing sanitizer being upstreamed, I don't think we should delay upstreaming any further. Can we race it? If any of these go in before the upstream PR is in I'll incorporate them into the HTML PR. |
4 participants
Convert the incubated spec in https://wicg.github.io/sanitizer-api/ to the HTML format and make it part of the HTML standard.
(See WHATWG Working Mode: Changes for more details.)
/canvas.html ( diff )
/comms.html ( diff )
/dom.html ( diff )
/dynamic-markup-insertion.html ( diff )
/embedded-content-other.html ( diff )
/form-elements.html ( diff )
/imagebitmap-and-animations.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/interaction.html ( diff )
/microdata.html ( diff )
/parsing.html ( diff )
/rendering.html ( diff )
/system-state.html ( diff )
/timers-and-user-prompts.html ( diff )
/web-messaging.html ( diff )
/webstorage.html ( diff )
/workers.html ( diff )