Add DOM parser prototype

[aduth]

I'm not sure if this needs to be its own standalone prototype, but I'd started experimenting with a more iterative approach to identifying blocks in content. Instead of writing a full-fledged grammar/parser like that demonstrated at Automattic/wp-post-grammar, the idea here is to treat blocks more as decorated DOM nodes within a contenteditable parent which, when identified, could delegate their editor display and serialization logic to the corresponding registered block behaviors (#104).

In CodePen form: http://codepen.io/aduth/full/ygmwKK/

In other technical prototypes (e.g. TinyMCE Per Block), the approach had been to treat and control all of post's content as blocks, including paragraphs. This prototype differs in treating text (paragraphs) as baseline behavior. From a UX perspective, this doesn't necessarily mean we can't show block and inline controls consistently for blocks and text; we'd just need to treat paragraphs as an "inferred" block. The upside of this is that we can more easily accommodate selection across paragraphs, and don't yet need to put much thought into nested block content (e.g. floated content or, in case of a quote block, needing to treat inner paragraphs as nested text blocks).

The demo isn't meant to be very functional; it mainly serves to demonstrate DOM parsing and identification of blocks within content. I'd not expect the block borders to be shown in a real editor, and more serve as visual highlighting of sections which would have custom behavior.

The implementation could also likely be optimized; e.g. ideally findNodeBlocks could identify blocks in a single loop.

In the course of implementing this, one technical consideration I'd observed is that, if we're assuming a block syntax is to serve as a hint, with registered block behavior also expected to parse content between the boundaries, we might want to put some thought into conveniences to this end. A NodeList or array of child nodes, some of which could be not of the Element interface (e.g. #text, #comment), aren't particularly easy to work with. We might even consider enforcing that a block range could have a maximum of one node and/or ignore non-Element nodes.

[mtias]

DOM parsing scares me a little bit. But yes, can we have both this one and grammar as prototypes? I hope we can throw really long posts to it and measure performance.

[aduth]

DOM parsing scares me a little bit.

Is it primarily for performance reasons? We could probably compare them in isolation. I might actually think the unoptimized DOM parser here could already be faster, and perhaps faster yet if we were to avoid comment syntax in favor of data- attributes (where findNodeBlocks effectively becomes editor.querySelectorAll( '[data-block]' )

[mtias]

Not just that, all the reasons discussed before around other editors not having access to DOM parsing, or server parsing we may need to do for things like filtering gallery blocks, etc.

[aduth]

For the moment at least, the syntax being parsed is the same as in the formal grammar, just achieved in the browser through DOM APIs, primarily so we can retrieve and work with the actual DOM node associated with a block when preparing the editor (versus a raw string).

[dmsnell]

DOM parsing scares me a little bit.
Is it primarily for performance reasons?

DOM parsing is almost certainly going to be faster because the real parsing happens in the native code inside the browser.

Personally I don't mind making a DOM-based parser as long at it matches the spec grammar. this actually matches a pattern I foresee emerging: if we do a good job of writing a correct and formal grammar/parser then anyone is free to make an optimized implementation, which is what I see happening here.

It's impossible to do DOM parsing in PHP because the DOM doesn't exist in PHP, but the HTML does. if we have a fairly declarative grammar and a spec parser to transform post_content then I don't mind any conforming optimized or circumstance-specific implementations

[westonruter]

It's impossible to do DOM parsing in PHP because the DOM doesn't exist in PHP, but the HTML does.

Actually, the DOM can exist in PHP via DOMDocument. I've used this in WP, for example, as a more robust method for doing force_balance_tags: https://gist.github.com/westonruter/4b1fca6f20fbc95c3c34

[dmsnell]

Actually, the DOM can exist in PHP via DOMDocument

fair point @westonruter. I've even used that myself. what I meant to communicate is that the stateful DOM that exists in TinyMCE or any contentEditable is stuck in the browser. we can't transfer that binary DOM back and force via post_content and that in PHP we'd either have to create it through HTML parsing or if we're generating fresh data then print it out to HTML for transit.

DOMDocument parsing is also fairly permissive which makes me nervous, I think for similar reasons that make @mtias nervous: the parse becomes non-deterministic or at least unexpected at best.

[aduth]

Well, messed up that rebase. Or at least, the rebase is fine, but since I pushed it while the PR was closed, it's no longer associated. It can be found here for future reference:

https://github.com/WordPress/gutenberg/tree/add/dom-parser-prototype