I’m using the Floki HTML parser as part of an application. I use it for rewriting custom attributes on <a> tags in HTML fragments. For that purpose it works great.

I recently had the need in my app to support something like Phoenix functional components and I borrowed the <.tag_name> format.

While I only supported self-contained “component tags” all was well.

However, I later modified my parser to support container component tags <.tag_name>...</.tag_name> and ended up with a problem that I have traced back to the Floki pre-processing stage.

In short, Floki (or MochiWeb) is eating the closing </.tag_name> so that it isn’t in the output when it hits my parser (which then barfs on the lack of a closing tag).

Using Floki on a self-contained “component tag” is fine: <li><.foo />Bar</li>

iex(7)> Floki.parse_fragment("<li><.foo />Bar</li>")
{:ok, [{"li", [], ["<.foo />Bar"]}]}

But on a container tag it does not work: <li><.foo>Bar</.foo>Baz</li>

iex(8)> Floki.parse_fragment("<li><.foo>Bar</.foo>Baz</li>")
{:ok, [{"li", [], ["<.foo>Bar", "Baz"]}]}
iex(9)>

The closing <./foo> is not in the output.

I mean, <. is not legal HTML so I have every sympathy with Floki for not doing what I want. But it seems pretty close and I wonder if it could do it. Unfortunately it looks like Floki is delegating parsing to MochiWeb which is a mass of (to me) incomprehensible Erlang code.

Anyone have any hope for me?