Issue #74 - add the fn:parse-html function - #259

Possibly there should be an html-version option as per Serialization spec and XSLT. And possibly allow automatic detection of HTML 5 vs quirks mode vs XHTML with validation?? I like simple, but i am not confident hard-wiring HTML 5 (as opposed to XHTML 5 or XHTML 1.1) is necessarily the way to go. Of course, the HTML 5 spec says what to do with these too, but the proposed prose here seems explicit that only HTML 5 is accepted. Nonetheless i'm very pleased to see this.

@liamquin I've incorporated your suggestions into the spec. Thanks!

Could I ask what are the implications of

Add an .editorconfig file to allow editors and IDEs to indent the XML source documents consistently.

We've always had a problem with multiple (human) editors using multiple (software) editors causing whitespace changes that disrupt change marking and conflict resolution. I don't know what an .editorconfig file does: is it going to help with this problem or make it worse?

Could I ask what are the implications of

Add an .editorconfig file to allow editors and IDEs to indent the XML source documents consistently.

We've always had a problem with multiple (human) editors using multiple (software) editors causing whitespace changes that disrupt change marking and conflict resolution. I don't know what an .editorconfig file does: is it going to help with this problem or make it worse?

An editor config file allows you to specify the encoding, line ending, indentation style, etc. for files in the project. This allows you to have different rules for different language extensions, or even different files. The settings are documented in https://editorconfig.org/.

I added it because my IDE (IntelliJ IDEA) was defaulting to 4 characters indentation of the elements instead of the 3 that the files use. As such, I've added a rule in the editor config to make that consistent. I've not extended it to other settings such as encoding, line endings, or removing trailing spaces.

The XDM node mapping for the HTML DOM is now complete. I've incorporated @michaelhkay's notes from the issue, except for the point about if case normalization is needed.

I think I'd have a marginal preference for putting method-specific additional parameters in their own key:

 parse-html($html, method:="tagsoup",  method_params:=map{'nons': true()})

instead of

 parse-html($html, method:="tagsoup", nons:=true())

Conflating the two together means you can't have a parameter with the same name as our options and means we can't safely add any new optionsin the future because someone might be using them as method parameter names.

A higher-level comment is that, while I don't object to the options provided, I'd have been equally happy if the function said that the input string is parsed with the HTML5 parsing algorithm, full stop.

I think I'd have a marginal preference for putting method-specific additional parameters in their own key:

Sounds reasonable to me, not just because TagSoup has a method option, too: https://www.mankier.com/1/tagsoup#--method

I think the comment about dropping various 2.6.x things is related to the agendas. I've made those changes for the next agenda.

I think we need greater clarity as regards error handling. The proposed spec says:

A dynamic error is raised [[err:FODC0011] if the content of $html is not a well-formed HTML document.

But I'm not sure the concept of a "well-formed HTML document" is well defined.

Specifically, there seem to be differences between implementations of the HTML5 parsing algorithm (both in browsers, and in free-standing libraries) as to how much recovery is attempted. For example the proposed test case test-003 include the ill-formed SVG fragment:

<svg style="overflow: clip; width: 100px; height: 100px">
  <rect width="200" height="200" fill="green">
</svg>

(note the missing end tag for rect). Browsers and parsing libraries appear to differ on how they handle this (validator.nu reports an error, JSoup takes silent recovery action).

We could take several paths:

• be prescriptive one way or the other
• make it a user option
• make it implementation-defined

I think this is probably a case for pragmatism; implementations are going to want to use existing parsing libraries, and if these differ in their behaviour, it's probably best to leave things implementation-defined.

There are no easy answers here; the HTML5 spec has a lot of fuzziness. For example, most of the requirements it places on "user agents" are not applicable because they only affect rendering and interaction, but the construction of a DOM from lexical HTML is also described as a function of a "user agent".