Support any extension preventing blur of editor (Fix #830)

[nmielnik]

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	yes
New tests added?	yes
Fixed tickets	#830
License	MIT

Currently, if any extension render an element on the page, if the user clicks on that element it counts as a click on an element outside of the editor, which causes the editor to blur and potentially hide the toolbar altogether.

This change set introduces a new getInteractionElements() method that any extension can implement. This allows extensions to let MediumEditor know that it has created HTML elements that, when clicked, should not count as external interactions, and thus should not cause the editor to blur when being interacted with.

[gpetrov]

I really like this one.

I wonder if it will be possible for an extension to have "design-time" html just for the preview and activation within the editor - and "run-time" html that will be the final html that is saved in the content.

This will allow "run-time" html to get "translated" to "design-time" for display in editor and back on save.

Or is this another feature request? :)

[nmielnik]

@gpetrov I don't fully understand the feature you're describing, but it sounds like it might be a separate feature request. Could you open a separate issue with more details of what you're describing and try to include an example?

[phiggins42]

@nmielnik / @gpetrov I have implemented that with a custom "block" system. each block is contenteditable=false, with an optional inner contenteditable=true region. it allows custom chrome/templating around, but does not persist the chrome when the editor is serialized. each block has a "type", and an extension to handle it's own rendering/serialization.

eg:

<div id="editor">
    <div data-block="$speciallist"><ul><li>item one</li></ul></div>
</div>

when you instantiate the editor, the $speciallist extension will draw a full rendered version of whatever special chrome, and the inner UL will be editable within the existing editable instance. so rendered is like:

<div id="editor">
       <div contenteditable=false data-block="$speciallist"><h3>This is a very special list!</h3><div contenteditable=true data-block-content><ul>...</ul></div></div>
</div>

where the chromed h3 is not editable or interactive in any way (though you can put buttons and any kind of UI in you desire) and when being serialized, only the inner data-block-content is returned in the markup.

the $speciallist extension delegates it's button events on the editor node, so moving the inner block around within the editor canvas doesn't require teardown/re-event-listening. the paste handler I've written does the same reduction during paste, so if you were to copy/paste within the editor you're really only copying the serialized portion, which is re-built after paste end.

a more clear usecase would be images. say all you want in the rendered output is

<div data-type="$image"><img src="......"></div>

but want to maintain extra metadata about the image, or provide cropping/rotate/resize UI ... the $image extension would build up all the chrome, handle all the interaction, but be transparent to the editor itself, and wouldn't appear in any persistable data (allowing you to change the design of the chrome without having to change any of the underlying data.

all of this, of course, breaks native undo/redo pretty badly. but it works.

anyway i think this is what he's talking about ...

[phiggins42]

to note, the original PR/code looks like it is talking about elements generated by an extension that are outside of the editable canvas (which, because of parentage, would in fact blur the editor when interacted with). my block solution puts the interaction elements inside the editor, and simply doesn't export them during serialize.

[phiggins42]

ie8 support dropped?

[nmielnik]

As far as I know, we've never supported IE8, and this is around for IE9 (which we still do support). This is also not the first place we've used Array.isArray().

[nmielnik]

Ok, I think I get what you fellas are saying, and that's definitely not being addressed by this PR. Would either of you mind opening a separate issue describing the feature request?

[gpetrov]

@phiggins42 this is exactly what I meant! I will write up another feature request about it @nmielnik
It will be awesome if such functionality comes in the Mediaum-Editor - we can then make rich UI extensions.

[coveralls]

Coverage increased (+0.03%) to 94.969% when pulling df7a633 on interaction-elements into bab8a7b on master.