So from my cursory reading, I seem to understand that the is attribute is parsed like an attribute but will not show up in getAttribute or hasAttribute calls. It will instead fill an [[is slot]] to explain what custom element we see.
This is funny and problematic, because we are currently sanitizing the attribute list, but not the is slot and the slot might remain after sanitization.
By it not being a real attribute, it also bypasses our policy on custom elements. I think our stance is roughly that custom elemetns are potentially dangerous but allowed because we can't really know and the developer must allow them explicitly in their element list.
The is attribute/slot is violating this.
Aside: Various people have strong opinions that "is" was a mistake and I have feelings too. But either way, we should handle it as long as "is" is a thing in Gecko and Chrome.
So from my cursory reading, I seem to understand that the
isattribute is parsed like an attribute but will not show up ingetAttributeorhasAttributecalls. It will instead fill an[[is slot]]to explain what custom element we see.This is funny and problematic, because we are currently sanitizing the attribute list, but not the is slot and the slot might remain after sanitization.
By it not being a real attribute, it also bypasses our policy on custom elements. I think our stance is roughly that custom elemetns are potentially dangerous but allowed because we can't really know and the developer must allow them explicitly in their element list.
The
isattribute/slot is violating this.Aside: Various people have strong opinions that "is" was a mistake and I have feelings too. But either way, we should handle it as long as "is" is a thing in Gecko and Chrome.