[ericmj]

lexbor walks the stack of open elements for many tokens during tree construction, for example to look for a p element in button scope on every div or ul start tag, and for most end tags. Input that nests elements thousands deep takes time quadratic in its size to parse: nested <div> takes 225 ms at 100 KB and 964 ms at 200 KB with the pinned lexbor (Apple M5 Max). lexbor/lexbor#437 fixes the p check upstream, and the end tags remain.

:max_depth raises once more elements than the limit are open, where <html> is at depth 1 for documents and the top-level nodes are at depth 1 for fragments. It wraps the tree builder's token callback, so it doesn't need a lexbor change. To install the callback, from_document and from_fragment now call lexbor's chunk functions, which is what lxb_html_document_parse() and lxb_html_document_parse_fragment() do internally.

Without the option the output doesn't change: 200,000 random tag-soup documents and 200,000 fragments produce the same HTML as main, and the same holds with max_depth: 10_000. With max_depth: 512, 100 KB of nested <div> raises after 0.1 ms, and inputs that stay under the limit, such as 500 nested <span> followed by 25,000 </x>, parse in under 10 ms. Ordinary HTML parses at the same speed with or without the option.