Adds two core blocks beyond generic blocks

[dmsnell]

Adds image and quote blocks.
Meant for experimenting with possible parse ideas.

This directly embeds certain core block types into the spec parser. The
benefit is that we have tight coupling and integration of those block
types. The cost is that we have tight coupling and integration of those
block types.

There's a bit more flexibility in integrating this higher-level parser
into the string parser, but I think it may be just as easy to include a
JS pass over the parse tree to convert generic into more specific nodes.

This is pretty verbose now but I could imagine a basic DSL (or an
existing one) to compare tree structure and (choke) load data from HTML

[
  'core/image',
  or( !! caption,
    [ [ 'img', { src: [ 'url', types.url ] } ] ],
    [ [ 'figure', [
        [ 'img', { src: [ 'url', types.url ] } ],
        [ 'figcaption', 'caption' ]
      ]
    ] ]
  )
] >>> {
  type: 'core/image',
  url: '...',
  caption: [
    // subtree inside of caption tag, maybe blocks
  ]
}

^^^ that's just playing around, but the idea could be used to both load
and generate the serialized data

[dmsnell]

@nylen this isn't the prettiest but it is declarative and the transformation is explicit. as long as we stick with a straightforward logical expression and don't do anything stateful or complex it's kind of readable.

honestly I don't think this level of parsing is appropriate for String -> Blocks but should probably be carried out higher up String -> GenericBlocks -> SpecificBlocks just for performance and coupling issues. this would let us introduce a DSL or query language above without messing with the parser or its performance

[aduth]

Related discussion: WordPress/gutenberg#391

Understanding it's experimental, what would be the future for allowing plugin authors to extend this with their own blocks? Would your DSL idea allow for defining the structure of a block outside the grammar spec itself? Am I am a block implementer expected to be exposed to the grammar syntax in any way?

[dmsnell]

Understanding it's experimental, what would be the future for allowing plugin authors to extend this with their own blocks? Would your DSL idea allow for defining the structure of a block outside the grammar spec itself? Am I am a block implementer expected to be exposed to the grammar syntax in any way?

I think it's a dead end for plugin authors. I could plausibly see the core block types as part of the parse but I think we ultimately need two stages: a tight fast String > List of Blocks parser core and then another level which turns those building blocks into a list of blocks and specific blocks.

the DSL was mainly discussed because of the concept of storing data in HTML. if we do that we need a way to validate and extract that data and describing complex data types is hard without the DSL.

[nylen]

Sorry for the late comment here, but I think the responsibility of the parser should be just to parse a tree of HTML and block-delimiter nodes, then we should hand this off to a separate layer to confirm that what appears inside each block is actually valid. One big reason for this is to make it easy for plugin authors; another is that these do feel like separate tasks.

[dmsnell]

closing as no longer relevant