HTML vs. Modifier <menu {{menu}}> - who wins?

[gossi]

I'm exporting a {{menu}} modifier over at aria-voyager.

And received a bug report (hokulea/aria-voyager#170) about:

<menu {{menu}}>

with:

Error: Attempted to load a component, but there wasn't a component manager associated with the definition. The definition was: MenuModifier

Now, I get it that glimmer would also support a <menu> component, as syntactically this is correct. I was also under the impression, that HTML elements are sorta "protected" in a way they can't be overwritten with custom components, as this contrary to how the platform behaves.

To me, the code <menu {{menu}}> should work, as it is clear, that this is an HTML element with a modifier that happen to have the same name.

Is my understanding correct and this is a glimmer bug? Or is this a correct behavior, if so, what's the reason behind?

[NullVoxPopuli]

It is not a bug and is correct behavior.
Reason being that all variables in scope are fair game to use in any syntax position, otherwise we introduce an inconsistency in our templating language

though, it is fair to say that all elements are off limits... but we don't have a good track record for keeping that list up to date

• Update list of allowed elements #1569
• SVG element parsing regression for svg element tag names with camelCase: ReferenceError: radialGradient is not defined when converting to gts-component #1550
• <math> doesn't work #1593

(which is something we need to be better at -- because people are trying to be productive, and it's weird when our stuff doesn't work 😅 )

[gossi]

I think the correct behavior then is a bug. It is marketted as HTML first, but in reality it is scope first.

HTML should have precedence, as this is the consistend baseline. I wouldn't consider html as part of the scope here but the foundation, this sits on. Else we have sth like ember-dom (similar to react-dom).

As such, I consider this to be a bug.