Sanitizer API: Catch-all for replacing custom elements with children

[SheepTester]

What is the issue with the HTML Standard?

In the Sanitizer API spec, the sanitizer configuration only allows for defining an allowlist of elements that can be replaced with their children (replaceWithChildrenElements), while for keeping elements, it supports either an allowlist (elements) or blocklist (removeElements).

That means that the configuration doesn't allow for allowing any custom element to be replaced with its children. I understand that keeping custom elements can be dangerous, but from what I can tell, replacing custom elements with their children should be fairly harmless because it avoids constructing the custom element, and I don't think it leads to the same situation as with html/svg/math.

The use case for replacing custom elements with their children is for sanitizing rich text from the user's clipboard. When copying from sites like MDN, GitHub, or Gemini, the web page's custom elements can get included in the clipboard HTML. By default, all custom elements are removed entirely even if there's normal content inside them.

Anyways, this doesn't seem to be a blocker because I think extracting all custom-element-looking tags from the HTML suffices, but it's a little contrived:

wrapper.setHTML(html, {
  sanitizer: {
    // ...
    replaceWithChildrenElements: [
      // ...
      ...new Set(html.matchAll(/<([a-z][a-z0-9]*-[a-z0-9-]+)/g).map(match => match[1]))
    ]
  }
})

I'd like to know if this was an intentional design choice, and whether sanitizing HTML from the clipboard is an intended use of the Sanitizer API.

[annevk]

I don't think we ever really considered an inverse of sorts of replaceWithChildrenElements. So the idea is it would cause every element to be replaced with its children, except for the listed elements?

But yeah, some kind of regular expression matching could also work for cases like this.

cc @mozfreddyb @evilpie @otherdaniel

[evilpie]

If we allowed some kind of RegExp syntax that would have the advantage that we could still reject configs where replaceWithChildrenElements overlaps with elements or removeElements.

[mozfreddyb]

The RegExp referenced by OP is not suggested syntax. The workaround provided by OP is to use a regex and looks for substrings that appear to be custom elements in the input variable html and then write them into the config.

This might work in some cases but is obviously brittle for two reasons

• doesn't match the valid custom element names per spec.
• will also match non-elements when a substring matches in comments, attributes etc.

Instead, I'd use Document.parseHTML() combined with a TreeWalker that can selectively handle the elements that the Sanitizer had to keep.

But I digress, we shouldn't talk about the workaround here, but how the use case from OP: Should we allow replacing custom elements with their children with our API? I think yes, that would be nice...

[otherdaniel]

My reading of the proposal here is that the underlying behaviour -- replacing a custom element with its children -- is already there, but there is no way to "select" all custom elements. IIRC, we discussed this in the context of allow & remove, where this default behaviour can be selected by picking either allow-lists or remove-lists. But there's indeed nothing of the sort for replacing.

I think we had at some point an "allowCustomElement" boolean, which we later dropped. In that spirit, we could have a boolean for replacing custom elements by default. Alternatively we could extend ElementNameNamespace to allow a value that matches all custom elements, and then adapt the various algorithms to handle it accordingly. I'd be fine with either approach.

---

I'd like to know if this was an intentional design choice, and whether sanitizing HTML from the clipboard is an intended use of the Sanitizer API.

Right now, the clipboard sanitizer is entirely seperate from the Sanitizer API. Also, the clipboard sanitizer is unspecified unspecified, and I believe largely undocumented. It was certainly my hope that at some point we could specify clipboard sanitization in terms of Sanitizer API.