What DOM content category do custom elements belong to?

[JanMiksovsky]

A user of one of our component library has filed an issue indicating that a popular HTML minifier is not minifying HTML with a custom element as expected. The specific repro case concerns a <button> that contains a custom element. The report suggests that perhaps the minifier only supports a whitelist of element types inside a button.

I'm less concerned with this specific issue than the general problem of tools (preprocessors, validators, etc.) that currently make assumptions about where certain element types are permitted. In order to facilitate the filing of issues/PRs on those tools, it might help to have some some definitive statement relating custom elements to the kinds of content defined in other HTML specs.

I don't know what the correct content categorization for custom elements would be. Perhaps flow content? That is, they can appear essentially anywhere in the body. Or perhaps they should be defined as a new content type ("custom content") that's a proper subset of flow content.

To be clear, I don't have any opinion here. I'm just looking for a statement on this point to help convince tool maintainers to accommodate custom elements.

Does the custom elements spec already contain such a statement? I looked but couldn't find one.

[JanMiksovsky]

Er, scratch the suggestion of flow content. A paragraph should clearly be able to contain a custom element, and as I read the spec, a <p> can only contain phrasing content. Generally, it would seem that it's impossible to tell from the outside what sort of content category a existing custom element would belong to.

[domenic]

@zcorpan might be able to help us with this one. Would appreciate his thoughts. Though this might depend on whether we make custom elements parse like template or not.

[zcorpan]

Phrasing content seems like a good fit right now, but if we switch custom elements to do template-like parsing then it can be script-supporting element instead (with the caveat that we probably don't want to allow custom elements in head...)

[annevk]

We should maybe have a section similar to other elements for custom elements but the name and attribute part is instead something generic that can be filled in by the developer.

That should probably be part of https://w3c.github.io/webcomponents/spec/custom/#custom-elements and https://w3c.github.io/webcomponents/spec/custom/#semantics can be merged into that.

[domenic]

Yeah, I thought about that, but not sure how well it will work... I agree we need to merge semantics into https://w3c.github.io/webcomponents/spec/custom/#custom-elements but not so sure that the infobox will work that well. Worth a try I guess.

(with the caveat that we probably don't want to allow custom elements in head...)

I think we do. <custom-linky-thing> is a reasonable custom element. E.g., <vb-script src="..."></vb-script> which transpiles on the fly or something.

[annevk]

@domenic can we allow them in head compatibly? That sounds like another risky parser change.

[domenic]

Someone really needs to make a decision on all these risky parser changes... :-/. Not getting a lot of traction internally either on making a decision, besides the same kind of vague reluctance everyone is exhibiting here.

Maybe we should just go with the default and say that all custom elements parse as <asdf>, and not do any parser changes. Probably implementers will be most comfortable with that. You can use is="" for other cases.

[annevk]

I can certainly see why. It's quite a bit of work and the benefit is not that high. Especially the "make it parse like <template> proposals"...

[domenic]

I looked at the infobox idea a bit. I'm not sure it's worth it. We'd get something like:

• Categories: flow content
• Contexts in which these elements can be used: where flow content is expected
• Content model: flow content
• Tag omission in text/html: neither tag is omissible
• Content attributes: global attributes; any attributes relevant to the element's functioning
• DOM interface: supplied by the author

I think it'll be reasonable enough to just put custom elements in the various content model sections.

[annevk]

It looks pretty great to me. We could also make it clear that custom element developers could put further conformance constraints on their elements if they want to. Not sure if we'll ever get validators for it, but who knows.

[domenic]

I ended up making them flow content, phrasing content, and palpable content. They also have a content model of "transparent". Seems reasonable.

• https://w3c.github.io/webcomponents/spec/custom/#custom-elements-core-concepts
• https://w3c.github.io/webcomponents/spec/custom/#html-content-model-updates

[JanMiksovsky]

Thanks for addressing this.