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

Use raw format when setting Editable content #667

Merged
merged 2 commits into from
May 5, 2017
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion blocks/components/editable/index.js
Original file line number Diff line number Diff line change
Expand Up @@ -228,7 +228,7 @@ export default class Editable extends wp.element.Component {
}

content = wp.element.renderToString( content );
this.editor.setContent( content );
this.editor.setContent( content, { format: 'raw' } );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain what are the benefits of raw content? I think performance, but I don't expect this setContent to be run a lot of times.

I guess my concern is. Are we really "ok" to skip the TinyMCE validation? What if we decide to add some content filtering https://www.tinymce.com/docs/configure/content-filtering/#valid_elements I'd prefer if we let TinyMCE perform this task for our selves.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re performance: I don't have a scenario in mind where we would be setting a lot.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we really "ok" to skip the TinyMCE validation?

Yes, I think we should be fine with this. We shouldn't allow invalid content to enter the editor state in the first place. In fact, thinking on this some more, I found an obvious issue on master:

  1. Insert Heading block with some content
  2. Insert Text block with some content
  3. Merge Text block into Heading block
  4. Switch to Text mode
  5. Observe serialized Heading block includes undesired <p> tag

The current behavior is really only giving us the illusion that it's helping in the context of the visual editor. We shouldn't need to leverage TinyMCE to ensure that we cleanly merge two blocks.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can be convinced, but this adds a lot of things for us to do. Not only when merging but also when parsing. We should provide helpers maybe to do this filtering, because it can be a difficult task to do and we should leverage this in a unified way.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What specific things are you thinking that this will leave for us to do? And in what ways does TinyMCE's sanitization help with this that doesn't just display nicely in the editor, but also fixes the underlying broken content?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think each time we use an Editable we'd want to provide valid_elements to say which tags, attributes etc... this Editable allows (We'll need good defaults). if we use TinyMCE's valid_elements setting for this, there's not much left for us to do.

But I can be convinced that the content should have already been sanitised in the block attributes and I'm thinking, we could offer a helper to do this sanitization outside of TinyMCE.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I can see how we might want some sort of element validation, but I don't think it'll be in the direction of...

  1. Try setting invalid HTML to Editable
  2. TinyMCE cleans it up
  3. TinyMCE passes back clean HTML to us

...but rather more like...

  1. Editor state is always valid
  2. User manages to enter invalid markup into Editable
  3. It's cleaned up when markup is converted back into an element before being updated in state (related, Try avoiding parse to get content of Editable #523)

}

getContent() {
Expand Down
2 changes: 1 addition & 1 deletion blocks/library/heading/index.js
Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,7 @@ registerBlock( 'core/heading', {
blockType: 'core/heading',
attributes: {
nodeName: 'H2',
content: content[ 0 ]
content: content[ 0 ].props.children
}
};
const blocks = [ heading ];
Expand Down