Re: [w3ctag/design-reviews] Early design review: Sanitizer API (#619)

Hi Lea, Thank you for the feedback! A quick round of replies:

__`javascript:`-URLs and expressiveness__: This is an open issue. My current thinking -- reflected in the current spec draft -- is that simplicity is key to get web devs to use the Sanitizer API and that consequently we should try hard to keep this simple and usable and to cover the basics first. This is corrobated by several authors from exisiting sanitizer libraries, who warned us that we'd almost instantly get into a "feature race", and that it's worth clamping down on feature requests in order to keep overall complexity at bay.

The way the current spec draft handles this is:
- There are no ways to specify content-dependent sanitization. Elements or attributes are allowed, or blocked, but the config provides no way to be more granular.
- There are a handful of cases that don't fit into this framework. In these cases, we'll add special case handling to the spec. This is a little unsatisfying, because this creates "magic" behaviour that a user couldn't re-create with a config.
- You mention `javascript:`-URLs, which are the perfect example. This is handled in [handle funky elements](https://wicg.github.io/sanitizer-api/#handle-funky-elements) (rules 2-4).

Several proposals for more expressive configs are discussed in https://github.com/WICG/sanitizer-api/issues/26 . We marked this issue as "v2".


__"unclear how authors can remove an element from the list of allowed elements"__: This is true, I'm afraid. The idea is that authors can either supply their own allow list (which makes most sense if they have a specific goal in mind, e.g. _only formatting_), or they supply a block list (with which they can effectively eliminate individual elements from the defaults). So I think the capability is there, but it's arguably laborious to discover it.

Exposing the default config is a good idea; we should do that.

Exposing a Sanitizer's config is something we've had early on, but then removed it for lack of a clear use case. We should reconsider this.

__general readability__: This is arguably a follow-on to the previous point. But I think this is also touched in the "very long default config" thought. I think of this as an editorial problem: The problem I'm having as spec editor is that I'm trying very hard to be unambigous, and to emulate the "algorithms" writing style of the HTML family of specs. This does, unfortunately, make the spec very dense and quite hard to read. This has come up repeatedly. For the specific audience of "spec imlementors" this is a good choice; but arguably not for anyone else.

I'm a bit at a loss of how to improve this. My current thinking is to continue specifying this as we currently do and to assume spec implementors are the primary audience of the spec, and to provide more & better additional, developer-focused documentation seperately.

If you know of any specs that do a particularly good job of providing dense & precise information, while still remaining very accessible to multiple audiences, I'll gladly take a look.


__`sanitizeToString` vs. serializing a DocumentFragment directly__: I agree. I have no experience with those parts of the spec universe, though, so I'm not sure whether this is easy to enact.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/619#issuecomment-811991818