Gutenberg: Paragraph block fails validation and appears externally modified when content is valid

[tofumatt]

Describe the bug
A paragraph block that is edited as HTML appears externally modified even if the content is valid and what the visual editor would create. I originally thought this was related to me trying out a fix for #4413, but it appears in master as well.

To Reproduce
Steps to reproduce the behavior:

1. Create a new post
2. Create a paragraph block
3. Type some text
4. Set the paragraph block's size to L
5. Edit the block as HTML
6. Change the class from "has-large-font-size" to "has-larger-font-size"
7. Observe the block appears modified

Expected behavior
The paragraph block doesn't appear externally modified and the size changes.

Screenshots

Additional context
Gutenberg 3.5.0 with WordPress 4.9.8

[chrisvanpatten]

Seems like when you change the class, the attribute isn't also updated which causes the mismatch and parser confusion.

You end up with markup like so…

<!-- wp:paragraph {"fontSize":"large"} -->
<p class="has-larger-font-size">test</p>
<!-- /wp:paragraph -->

(I'm sure you know this, just putting it here for future searchers and readers!)

So I guess the question is here would the expected behavior be that the attribute is somehow changed automatically based on the class name? Seems like the block would somehow need to be able to parse that out?

And what would be the expectation if you change to a non-existent class name that doesn't match any size option? Should the size be removed entirely and the class applied as a custom class?

[tofumatt]

Good call, I totally should have included that and failed to do so. Thanks! 👍🏻

I think if you change to a non-recognised class, it should use custom class, yes.

[aduth]

So I guess the question is here would the expected behavior be that the attribute is somehow changed automatically based on the class name? Seems like the block would somehow need to be able to parse that out?

There are default sourcing options. Those which don't fall neatly within available sources (like this one) must always keep the markup and attributes in sync, lest risk the validation issues demonstrated here.

One note is whether the comment delimiters should be included in the "Edit as HTML" view, which could make these desyncs much more apparent when editing. This would be a separate enhancement task, however. The behavior as explained is expected.

I think if you change to a non-recognised class, it should use custom class, yes.

A custom class is assigned correctly as long as the expected value from the assigned size is respected as well.

For example, if at "Step 6" of the original instructions, the class is _added_ instead of replaced, the class is shown as additional class in Advanced settings.

Closing as working as intended.