@std/xml: support a "lax-mode" to allow parsing html

[lowlighter]

XML is basically a stricter version of HTML, so most of the work is already done and it shouldn't require too much refactoring

Parsing HTML is a quite common use case (like when scraping websites, parsing web pages, etc) but since the data is external we can't expect them to be exact html

Parsing html without requiring a full virtual dom library (like jsdom / happy-dom /linked-dom) would be quite nice for general use case, but also for tests validations when testing http documents serves

There are already precedent of having a more leniant parsing in other libs

• quick-xml (Rust): check_end_names(false)
• libxml2 XML_PARSE_RECOVER / lxml recover=True
• htmlparser2 and fast-xml-parser in the JS ecosystem
• jsr:@libs/xml (which i maintain and like to rely on @std/xml now rather than a compiled wasm version of quick-xml)

What would be required:

• Supporting unquoted attribute values: <root foo=bar> (value ends at whitespace, >, or /)
• Valueless attributes <input disabled> (same as disabled="")
• Unclosed / mismatched elements: </name> auto-closes intervening open elements (stray closing tags are ignored, elements still open at EOF are auto-closed instead of throwing)
• Duplicate attributes: first occurrence wins instead of throwing.

Btw the sync parse does not offer any way to recover the xml processing instructions nor the doctype atm

cc @tomas-zijdemans

[0f-0b]

It will be a whole lot easier to just add a standalone HTML parser to @std/html, than to add a lenient mode to @std/xml and have it parse HTML.

HTML is a weird language where <b>a<i>b</b>c</i> is interpreted as “abc” (plus a parse error to be fair, but as you noted, external data can't be assumed to be valid HTML).

[tomas-zijdemans]

Thanks. I'll have a look

[tomas-zijdemans]

For HTML parsing, the best way forward would probably be to build @std/html/unstable-parse

I do not think it's a good idea to add a "lax" mode to @std/xml. I was a lot back and forth on using strict or lax when building it, but I settled with keeping it fast and predictable. "Lax" becomes a slippery slope, though you could argue for adding a recover option (for those 4 listed items only).

Your point on ´sync´ not exposing processing instructions.. I'm sorry. That's a clear oversight on my part, and a good find! This would be a braking change, so I'll need to wait for this PR to be merged before I tend to it.