`permission` should not be a void element

[zcorpan]

Since the PEPC content is controlled by the user agent, and it should have no child elements, the parsing model will not include content or the end tag (similarly to the input element parsing model).

Adding a new void element for HTML parsing can result in new mXSS issues. Consider e.g. https://research.securitum.com/mutation-xss-via-mathml-mutation-dompurify-2-0-17-bypass/ but instead of the form tags you use a <permission> tag before <mglyph>. The onerror script would now execute in browsers where permission is a void element (assuming a sanitizer that allows math).

There might be other similar cases; generally, changes to the HTML parser carry some XSS risk.

I would suggest no changes to the HTML parser here. Require the end tag.

[marcoscaceres]

Agree. Further, I think it makes sense to have children like button etc.

[remypar5]

It could support 2 different forms:

1. A void element, which lets the browser handle everything. This leads to a single, recognizable user flow for any website, enhancing the user's experience regarding handing out permissions. This would mean that UX designers have fewer options customizing it.

2. A container element which only allows a button[type="permission"] so UX designers can tailor its appearance to their app's UX.

Personally I like the void element better as it enforces a recognizable flow for the user.

[DanielHerr]

How about adopting the fallback content approach used by <canvas>, <video>, <audio>, <progress>, <meter>?

Something like this:

<permission type="notification">
 <button onclick="Notification.requestPermission()">Notify Me<button>
</permission>

[marcoscaceres]

Yeah, you would absolutely need fallback for legacy user agents and any browser that doesn’t support the element.

[andypaicu]

That fallback approach seems very appealing to me. And practically this would mean that the permission element is not a void element but rather has hard-coded user-agent-defined contents.