Ckeditor5: Acknowledge inline elements

[Reinmar]

So far we didn't consider inline elements in the model. Blocks could only contain text. It changed since we introduces support for line breaks (<br>s).

It caused a couple of bugs. Most notable ones are:

• https://github.com/ckeditor/ckeditor5/issues/1083
• https://github.com/ckeditor/ckeditor5/issues/1024

So far we managed to resolve #1024 in a quite clear way. #1083 was fixed in an ugly way, though (@scofalik explained that in https://github.com/ckeditor/ckeditor5-typing/pull/156) and works with <softBreak> elements only. We need a more general and bulletproof solution.

PS. There's a chance that the issues which one might experience with inline widgets are related to this – we don't handle any other node than text in ckeditor5-typing.

[scofalik]

The documentation for ContainerElement is a bit misleading at this moment. It says:

 * There might be a need to mark `<span>` element as a container node, for example in situation when it will be a
 * container of an inline widget:
 *
 *      <span color="red">foobar</span>     // attribute
 *      <span data-widget>foobar</span>     // container

But it doesn't mention any other additional steps, so it looks like all you need to do is create ContainerElement with span name. Which is not true -- that span will behave like any other ContainerElement. For starters, you might need to overwrite this.getFillerOffset property so an empty span won't get a bogus br. But I don't know if it will get a ZWS then? 🤔

[jodator]

Some issues that I've found so far:

• the &nbsp handling - they're added around widget
• the ZWS (probably?) added if inline widget is at the end of block
  
• ~copy&paste: you cannot copy selected IW~ bug or missing Clipboard
• selection with mouse: click after the IW, expand selection over the widget to the beginning of a text -> error model-nodelist-offset-out-of-bounds
• ~pasting selection with IW inside allows the IW to inserted directly in root (is not wrapped by paragraph)~ I cannot reproduce - maybe bug
  
  
  
  • DOM selection is rendered over IW - looks better if disabled in CSS:
    
    css placeholder::selection{ display: none; }
  
  
• findOptimalPositon() is buggy: I've selected IW and inserted table> the header was split
• ~The ctrl+x to work when selection contain IW~ bug in sample
• ctrl + → behavior needs to be reviewed/fixed - right now it omits inline widget if surrounded by spaces but acknowledges it if it is inside a word:

What's work OK:

• caret navigation around IW
• inline styles: is disabled on IW, the attribute breaks before and after IW
• works similarly inside table as in root:
  

[jodator]

After F2F talks we concluded that in order to make inline widgets usable we need to:

1. Introduce the isInline schema object type that will allow to mark elements to be treated as text.
   
   
   
   • softBreak and $text will be marked as isInline also.
   
   
2. the view to model selection conversion must be fixed because DOM selection on Chrome is wrongly mapped to the model (model-nodelist-offset-out-of-bounds error).
3. Check why the fake selection is not rendered for inline widgets

[Reinmar]

2. the view to model selection conversion must be fixed because DOM selection on Chrome is wrongly mapped to the model (model-nodelist-offset-out-of-bounds error).

Step 1.

How to convert this view selection:

<p>Foo<widget>bar[</widget>x]</p>

To this model selection:

<paragraph>Foo<widget name=bar>[</widget>x]</paragraph>

I think we can use editing.mapper.on( 'viewToModelPosition' ) to control this now, but it’d be good if it was somehow automated.

Step 2.

We need to fix this model selection:

<paragraph>Foo<widget name=bar>[</widget>x]</paragraph>

Into:

<paragraph>Foo[<widget name=bar></widget>x]</paragraph>

or:

<paragraph>Foo<widget name=bar></widget>[x]</paragraph>

This may happen already (selection post-fixer).

[xinglie]

The documentation for ContainerElement is a bit misleading at this moment. It says:

 * There might be a need to mark `<span>` element as a container node, for example in situation when it will be a
 * container of an inline widget:
 *
 *        <span color="red">foobar</span>     // attribute
 *        <span data-widget>foobar</span>     // container

But it doesn't mention any other additional steps, so it looks like all you need to do is create ContainerElement with span name. Which is not true -- that span will behave like any other ContainerElement. For starters, you might need to overwrite this.getFillerOffset property so an empty span won't get a bogus br. But I don't know if it will get a ZWS then? 🤔

Yes , i wrote a plugin use span by createContainerElement method .
when user delete all text in the span , the CKE will put a <br data-cke-filler="true"> in the span, and break lines .
so how to avoid this behave