(Native) Black-box custom element's contents to HTML5 parser

[Yuri Sulyma]

I will explain what I mean.

I'm working on a project which involves a large collection of documents which are mostly HTML, but make extensive use of custom elements (lowercase). In the past, these custom elements were implemented by coding the documents in XML, and using XSLT to transform that into HTML code. This looks something like

<p>Google is based in <x:annotate><x:text>America</x:text><x:info>America is a country</x:info></x:annotate></p>

which becomes

<p>Google is based in <a class="annotate-text" data-annotate="uniqid123">America</a>
<!-- rest of document -->
<div class="annotate-info" id="uniqid123">
America is a country
</div>

which we script so that when you hover over the <a>, the <div> pops up.

With the advent of Web Components, we are trying to convert the XML into HTML5 Custom Elements, so the above would look more like

<p>Google is based in <x-annotate><x-text>America</x-test><x-info>America is a Country</x-info></x-annotate></p>

with the implementation provided by document.registerElement, etc.

This works fine when <x-info> contains only inline elements. However, a few of them contain more extensive content, like

<p>Google is based in <x:annotate>
  <x:text>America</x:text>
  <x:info>
    <p>America is a country. Here are some other examples of countries:</p>
    <ul>
      <li>Canada</li>
      <li>Ireland</li>
      <li>...</li>
    </ul>
  </x:info>
</x:annotate>
</p>

(whether it is appropriate to put that much detail in an annotation is debatable, but that's the codebase I'm working with).

This works fine in the XSLT "throw a div at the end of the page, and link them together with a unique ID" surgery approach.  However, in HTML5, the parser auto-closes the surrounding <p> as soon as it sees the block elements inside <x-info>, and mangles the markup. So far it seems my only option is to resort to div-surgery again, which is exactly the kind of backend preprocessing we were hoping to avoid by ditching XSLT.

Is there any way to get around this behavior? If not, would the W3C consider amending the HTML5 parser behavior in regards to Custom Elements? It seems to me that custom elements ought to be a "black box" to their surrounding content.