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

> 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".)

No, script data ignores `<!--` and `-->` as well.  See https://html.spec.whatwg.org/multipage/syntax.html#script-data-state

What I'm proposing is to let an element implicitly begin a CDATA section.  e.g. treat `<my-script>~</my-script>` as `<my-script><![[CDATA[~]]></my-script>`.  It won't work if the script contains the literal `</my-script>` but that's probably okay.  But all of this seems like unwarranted complexity when the author is likely just going to use `src` attribute instead.

> Definitely. I think that any elements which opt-in to unusual parsing rules would either need a sentinel in their tag name (straw man: <voidelements-> vs. <need-closing></need-closing> vs. <script--esque> ... </script--esque>)

This is the only way.

> 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" }).

This would be racy if the script that contains the element definition loads asynchronously.

> Upgrading and parser extensions are complementary in this sense, not at all contradictory.

I disagree. Some custom elements having to be defined prior to the use and others being upgraded later would be super confusing for consumers of custom elements.

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