Re: [WICG/webcomponents] [dom-parts] Declarative API for defining DOM parts (Issue #990)

Would these be `Node.PROCESSING_INSTRUCTION_NODE`s?

I'm not particularly fond of borrowing from XML in syntax that looks like a blend between PHP (`<?=...?>`) and custom elements (`<my-tag>`). Could this not be done without introducing a new node type to HTML that resembles custom elements? 

My (admittedly ignorant) instinct is to have a set of attributes (I know, `part` is taken) where a patent element has an attribute that lists which parts it contains and the children use a corresponding attribute to declare which part they fulfill. This wouldn't work for text or attribute nodes, but it would be more familiar and pre-existing syntax that doesn't require a new node type. 

Using attributes instead of a new node type would also make this much easier/possible to polyfill (also a benefit of an attribute on the parent element since it'd be more efficient for querying).

If not, I suggest just adding processing instruction nodes to HTML as a separate proposal first. Introduce the new node type before some specific processing instructions.

Just my two cents on the matter. I'm not going to pretend like I know the HTML parser in nearly enough detail to know if a new node type is better than attributes here. I'm just thinking about this as someone who writes some polyfills and who recognizes the barrier that introducing a new node type might add compatibility issues.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/990#issuecomment-1585138983
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/990/1585138983@github.com>