Remove and prevent DOM access in attributes parsing

[aduth]

In an effort to avoid tying block parsing to the DOM, we should not expect block implementers to provide custom matchers for attribute parsing.

Examples:

• https://github.com/WordPress/gutenberg/blob/29462aa/blocks/library/image/index.js#L35
• https://github.com/WordPress/gutenberg/blob/29462aa/blocks/library/quote/index.js#L18-L30

Instead, we should decide between:

• Expecting these attributes to be serialized in the block comment
• Providing additional matchers to satisfy the need required by these blocks

To discourage taking advantage of matchers currently receiving the DOM node, we could consider adding an internal flag, and picking only keys from the block attributes property whose values are an allowable matcher.

[youknowriad]

I think the duplication for the examples above is acceptable, thus, I'd go for the first proposal for now.

[nylen]

If we're not using HTML as the source of truth then why are we even using HTML at all? Don't we lose most of the benefits of serializing to HTML if we don't respect edits to the HTML content from other sources?

I'd very much prefer that we avoid duplicating information here. So far this means that we need a way to match patterns inside class names. Anything else we're already aware of?

[aduth]

Other benefits of serializing to HTML include viewability, portability, and long-term meaningfulness (should the block's implementing plugin later be uninstalled). But I would agree that to the extent possible, it should be a goal to respect edits made externally and avoid duplication. The original Editor Technical Overview highlights these objectives well, though doesn't make entirely clear whether duplicating in the comment block is necessarily as bad as in post meta, since it's technically within markup of the post, and both visible and editable by external editors (assuming they know how to).

So far this means that we need a way to match patterns inside class names. Anything else we're already aware of?

Currently that seems to be all. Of the blocks we've implemented, those with comment attributes include two relying on classname (quote, image) and one which will eventually depend on server-rendering (embed).

https://github.com/WordPress/gutenberg/blob/master/post-content.js

[aduth]

Maybe they don't need to be class names though. Specifically for images there are implications here on backwards compatibility with alignright etc classes, but it sure would be easier to parse (and equally possible to style) with data attributes, like data-style="2".

[nylen]

I don't have a strong preference for how/where this data is stored, class names seems the most straightforward or obvious way but data-wp-quote-style is also a good option.

Elaborating a bit on my previous comment, here is the sort of breakage I imagine from not treating HTML as the source of truth:

• User creates a quote block with a given style.
• User changes the quote style using an external editor - the REST API, Calypso, or any number of other possibilities.
• User verifies that the site displays as expected.
• User edits the post using the Gutenberg editor. The old style is restored from the comment attributes with no warning of what happened, and if/when the post is saved, the user's previous changes are overwritten.