On XML and Node spans

[Txuritan]

I'm looking to replace the current HTML parser that's being used in a project of mine and I came across this one. It looks like it would be a nice replacement, and by my estimates, would bring the final binary size down by about 16%.

There's two things stopping me from trying it out:

1. The ability to parse simple XML (from an EPUB) which would require the the ability to parse the XML doc type and possible namespace attributes.
2. The tracking of Node spans, as in the offset the where Node starts and stops at in.

Would these be something you'd consider adding or accepting a pull request for?

[lomirus]

1. The ability to parse simple XML (from an EPUB) which would require the the ability to parse the XML doc type and possible namespace attributes.

This one is a good suggestion. For the present parsing method, it should be implemented XML parsing without too much work, and XML itself is also widely used. But on the other hand, there are still some differences between XML & HTML, and this lib's name is html_editor after all. Maybe we can add a method named like parse_xml() or you have other better ideas?

2. The tracking of Node spans, as in the offset the where Node starts and stops at in.

I am sorry that this suggestion would not be approved. Simplicity is for what that I created the repository. I have tried some other rust libraries before to parse the html like kuchiki or scraper. When I tried to print out the formatted output of simple four-line html by some of these libs, it just printed out 2000+ characters, which made me astonished and confused. Because for such a simple test case, all I wanted is just to get the clear DOM tree without recursion or any other extra information. Then let's go back to the original topic, tracking of node spans, and putting them into the result will make pollution to the tree, and this may be against with the purpose of this project. I am afraid I cannot do that.

[Txuritan]

The biggest change that I can see would be parsing or ignoring the XML prolog (which i just leaned is its name) This could be handled like the HTML doctype, as in check for <?xml and ?> and emit a prolog or doctype node. I did run some of XML files from a EPUB showed that the current parser can handle namespaced attributes and XML doctypes without any changes. I don't think this would warrant the addition of a new function specifically to handle a XML prolog.

As for the node spans, thats fine with me; my project will most likely require more complex changes than these and as I wasn't sure what changes you'd like to implement or leave out.

[lomirus]

Add xml doctype parsing in v0.5.0