And herein lies the flaw of custom elements: that they don't use a declarative mechanism for exposing their presence in HTML to browsers. Instead, they must be declared by subclassing from built-in element representation classes (using ES6+ class syntax which nobody seems to be using anyway). Now the browser must 1. have JavaScript 2. have JavaScript enabled 3. synchronously execute the subclassing/registration script code text before proceeding with parsing (which browsers do anyway, but at least didn't have to in order to even parse HTML as intended).

Not only that: content of custom elements is treated as fallback content (taken when a particular custom element is not available). However, that content is still subject to HTML parsing and tag omission rules, and tag omission is contextually dependent on the parent element's content model (which a custom element doesn't have since there's no way to register such using the JavaScript API).

There was (?) even the sacked mechanism of "customized built-in elements" which would allow authors to define custom attributes and behaviours for standard HTML elements. Except it doesn't work like that with HTML's enumerated attributes such as `selected` which can have shortforms like `<div selected>` where `selected` is the attribute value not the attribute name, requiring the values of all enumerated attributes be unique among all attributes in a DTD (as in SGML) or at least on a given element.

Sometimes I wonder why the HTML spec authors just had to make every blunder imaginable when there's a very rich theory of formal language and markup languages (eg. SGML and others) dealing exactly with these kind of problems.

Just tried in firefox and as mentioned above they are not block elements but inline:

    <foo>foo</foo>
    <bar>bar</bar>
    <div>div1</div>
    <div>div2</div>

Results in:

    foo bar
    div1
    div2