Re: [webcomponents] Should parser extensibility be a design goal? (#113)

> One way to mitigate this problem would be let any element that has - in its name appear anywhere template element could appear.

Hmm, what are the pros and cons of this vs. letting elements with - appear anywhere a div can appear? I don't really have an opinion either way, but it's probably worth enumerating.

> For script and style, I don't think we necessarily want the exact same parsing rule that takes care of <!--, -->, etc... since they're mostly historical artifacts. For those use cases, we may want to allow contents to be parsed as CDATA.

Could you clarify a bit? From what I recall of CDATA, it involves ugly `<![[CDATA[` `]]>` pairs and is an XHTML-only thing. Whereas for script, the main magic is that it waits for the character sequence `</script>` to appear. Which of those models are you proposing? (I think this is just me not understanding the phrase "parsed as CDATA".)

> Note that upgrading makes even less sense once we allow the parser behavior depend on element definition since we wouldn't know how to parse an element until the definition is available, and we certainly don't want to make the parsing rule racy.

Definitely. I think that any elements which opt-in to unusual parsing rules would either need a sentinel in their tag name (strawman: `<voidelements->` vs. `<need-closing></need-closing>` vs. `<script--esque> ... </script--esque>`) or we could just error upon trying to define an element with an unusual parsing rule that already exists in the document, i.e. throw for `document.registerElement("script-esque", { parsingType: "cdata" })`. Upgrading and parser extensions are complementary in this sense, not at all contradictory.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/113#issuecomment-111727111