Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Paragraph block fails validation and appears externally modified when content is valid #8950

Closed
tofumatt opened this issue Aug 13, 2018 · 3 comments
Labels
[Feature] Paste [Type] Bug An existing feature does not function as intended

Comments

@tofumatt
Copy link
Member

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
2018-08-13 20 56 06

Additional context
Gutenberg 3.5.0 with WordPress 4.9.8

@tofumatt tofumatt added [Type] Bug An existing feature does not function as intended [Feature] Paste labels Aug 13, 2018
@chrisvanpatten
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Member

aduth commented May 31, 2019

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.

image

Closing as working as intended.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Paste [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

3 participants