Possibly make the HTML parsing two part about dtcoretext HOT 2 CLOSED

Splitting the parsing from the rendering is an excellent idea, though I've been thinking about a different approach than building a DOM tree: have the parser emit a stream of bytecodes to be read by a simple interpreter to build the attributed string. You could easily store the intermediate form to a file, send it over the wire, etc. Making it a documented format would make it easier to write all kinds of tools to feed data to an iOS app (and having your own simple representation means your code remains simple and memory-efficient.)

This would also simplify your unit testing. You could test the intermediate representation coming out of the parser, then have a few simple tests of the tool that converts the intermediate representation to an attributed string. It makes for a better separation of concerns and easier debugging.

My concern about the DOM tree comes down to memory usage (there are still plenty of 3G phones and 2G iPod Touches out there) and efficiently serializing and deserializing. I don't want to store the actual bytes from an OS X-encoded attributed string as I don't want to bet the two implementations will stay in sync. (Also, it would be nice for folks in Linux and Windows land to have a way to export rich text data in an easily processed format. It would be a major help in my field -- mobile learning tools.)

I'm willing to work on this on a branch if it doesn't conflict with work you're already doing. Kindly let me know.

from dtcoretext.

The existing method works well by having a "fleeting DOM" i.e. have a stack of DTHTMLElements. The stack could be removed and the copying for inheritance could be avoided by using the parent pointer consequently. But for now I am closing this issue because it is not something that can be immediately addressed.

from dtcoretext.