Repository navigation
@std/xml: support a "lax-mode" to allow parsing html #7212
Description
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/xmlnow 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 asdisabled="") - 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
Activity
0f-0b commentedon Jul 4, 2026
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/xmland 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 commentedon Jul 6, 2026
Thanks. I'll have a look
tomas-zijdemans commentedon Jul 6, 2026
For HTML parsing, the best way forward would probably be to build
@std/html/unstable-parseI do not think it's a good idea to add a "lax" mode to
@std/xml. I was a lot back and forth on usingstrictorlaxwhen building it, but I settled with keeping it fast and predictable. "Lax" becomes a slippery slope, though you could argue for adding arecoveroption (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 breaking change, so I'll need to wait for this PR to be merged before I tend to it.