Parser: Introduce <p>-as-text-block and soup block

[dmsnell]

Basic text blocks don't need much indication of what they are. In this
patch we augment the parser to treat a top-level <p> tag as a text
block (if it has a matching closing </p>).

Further, anything that isn't one of these or a well-formed block is
going into a new freeform block.

Finally, to support this work I have allowed for the parser to ignore
interblock characters since they shouldn't indicate separate blocks.

[ellatrix]

Is \r and \n somehow not included in \s for pegjs? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp#character-classes

[dmsnell]

actually no they weren't included. I'm not sure what \s actually gave us. I have updated with the proper definition of "whitespace" from JS though in 8fde722. we may want to throttle back on this too since it includes things like Unicode whitespace characters as well

[ellatrix]

That's an interesting addition, because I'm not sure if we should accept a text block with a code block in it. That's a job for validation I guess. cc @nylen.

[ellatrix]

(Not saying no <code>, but no <pre><code>.)

[dmsnell]

well I don't see how we can prevent it if we have something like TinyMCE in the picture of any kind of "do whatever you want" block. personally I'm wondering if it'a just a bad idea to break out of the block boundaries at all.

[ellatrix]

Works great!

[youknowriad]

I'm a bit concerned about introducing this special case in the grammar itself, I'd much rather opt for describing what legacy content a block can handle in the block API itself. See #590

Alos a good question is whether we should validate the content of the p or not to check for only text and formatting markup.

[dmsnell]

I messed up a rebase without realizing it. If you have the old version of this branch could you force push it? Thanks! never mind, git reflog to the rescue

@youknowriad I also have my reservations about what it implies when we strip out the block structure and make implicit assumptions about the other content. This PR was built on request though to explore the idea.

[nylen]

I'm a bit concerned about introducing this special case in the grammar itself, I'd much rather opt for describing what legacy content a block can handle in the block API itself. See #590

+1, while the grammar should parse and return a full tree of HTML nodes, deciding what to do with them should not be the responsibilty of the parsing layer

Also a good question is whether we should validate the content of the p or not to check for only text and formatting markup.

+1, when building software, you should validate your inputs... though this also should not be the responsibility of the parsing layer.

[dmsnell]

Closing because several of us don't think this is a good idea.