In general I think it'd be OK as far as the frontend is concerned to keep the browser element (in addition to some of the other subclassed XUL elements) in the XUL namespace. That said, I'd like to see how hard it would be, and if there would be potential benefits, to make them chrome HTML elements instead.

I asked about this a while back (https://mozilla.logbot.info/content/20190315#c16093906-c16094034):

bgrins>
Is there such a thing as a "chrome privileged HTML element"? just as an example, if we wanted to make <xul:browser> an <html:browser> or similar, but make it not observable to web pages?

bz>
Not observable in what sense?
Let me try, actually. So a web page can clearly have an element named <browser> in it. The web page can observe the following things about it:
1) Various general DOM bits (localName, attributes, etc). You'd want this to keep happening.
2) Any interesting behaviors it has. You could condition those on the NodePrincipal() in the implementation so they only happen when the node is in a system doc.
3) What interface it implements. You could condition this on the principal as well and when not system just implement HTMLUnknownElement

You'd have to inherit from HTMLUnknownElement, which is a bit weird, but... You could then hide the relevant constructor on non-system scopes so you don't have window.HTMLBrowserElement around. So I think the answer is "yes" to the question you asked, with the steps above.

There's also a secondary question about if we want to change the public API of the browser Custom Element to more closely match webview or mozbrowser (which could be done with or without changing the current element's namespace).