Discussion: MIME-typing the Document / Document Fragment?

[danburzo]

Filed under Bigger Fish To Fry But:

Working on the copy-paste issues, it occurred to me that in a world dominated by Slate-based rich text editors, it would pose a problem to copy and paste between editors with incompatible schemas.

To that end, I'm opening a discussion on whether a Slate Editor should mark its identity in some way (as sort of MIME type), and that information can be serialized in data-slate-fragment.

[ianstormtaylor]

Sounds like a smart idea to me!

Paste/Drop being a backdoor for non-conforming documents to sneak in is probably the hardest issue for us to solve well—one of the big tradeoffs for having total flexibility. Open to any ideas that help make that simpler!

Having a simple mime type for the document sounds like a good way to test for it!

[justinweiss]

I've already seen some examples of this in the wild, so it might be time :-) I think this will be an even bigger problem when we use schema to decide between blocks and inlines, since node type won't match between editors.

Here's the strategy I'm considering:

• Add contentType as a prop to Editor, default of 'application/x-slate-fragment' (like it is today)
• move getEventTransfer to editor.getEventTransfer and setEventTransfer to editor.setEventTransfer so they have access to editor props, specifically contentType. This also matches what happened with findDOMPoint, etc.
• When setting fragment transfers, set them with the editor's contentType. When getting fragment transfers, only use it if the content type matches the one on the editor. Otherwise, act as if it's not there.
• Deprecate the global getEventTransfer and setEventTransfer.
• Deprecate data-slate-fragment and replace it with a data-slate-embedded-transfer, that uses the Edge-style 'SLATE-DATA-EMBED::' format. That way we can set contentType instead of always assuming the text in the attribute is a fragment.

Does that make sense? Anything seem to be missing?

[ianstormtaylor]

@justinweiss sounds awesome.

• move getEventTransfer to editor.getEventTransfer and setEventTransfer to editor.setEventTransfer so they have access to editor props, specifically contentType. This also matches what happened with findDOMPoint, etc.

When we move these, let's rename them to getDOMEventTransfer I think, for clarity and symmetry with the other DOM helpers.

[Nantris]

Any news on this? Slate is a lot more popular these days.

[justinweiss]

This was something I had planned to take on after https://github.com/ianstormtaylor/slate/pull/2933, but then 0.50 landed. Since our main implementation is still pre-refactor, upstreaming work hasn't been a priority.

I haven't looked into the current state of copy / paste post-refactor, but I don't think this would be hard to layer on.