SCAYT - when enabled, text formatting is working differently

[Wiktor Walc]

Probably somehow related to #4793, but this problem exists in many browsers (tested on FF 3.5.5, Safari 4.0.4, IE8):

• paste the following in source mode:

   <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>
  

• switch to wysiwyg mode
• enable SCAYT
• select "etur adipisicing elit, sed", press Ctrl + B
• result:

  ... consect<strong>etur</strong><strong> adipisicing elit, sed</strong> do ...
  

  (when SCAYT is disabled, only one <strong> element is created, when enabled, another <strong> element is created straight after the end of first word)

[Garry Yao]

Obviously that's because of the SCAYT marker and the applied style is conflicting with each other, though it's possible to introduce something to make them coordinate with each other, or even yield to one other and fixing up on output, I would suggest of another more generic way of such kinds of troubles: The idea is to make SCAYT working isolated from the editor commands, by meaning that, SCAYT would reset the DOM state (including the selection) back to normal on 'beforeCommandExec' event( I don't know if there's an existing SCAYT API already capable of that) and then restart again after the command has completed on 'afterCommandExec', in this way editor and SCAYT could work in different *process* thus will not be interrupted by each other.
I would ask SpellChecker.net to evaluate the pros and cons of this approach, especially from the performance perspective, then we'll know better which way to head for.

[WebSpellChecker.net]

The problem reproduces when the SCAYT markup overlaps editor markup. It is not reproduces when editor markup covers SCAYT markup and vise versa. The problem reason is that browser's DOM normalize the markup - when two markups are overlapped (<strong>a<em>b</strong>c</em>) then DOM closes the first tag and re-opens it after the second and etc. (<strong>a</strong><em><strong>b</strong></em><em>c</em>).

Removing SCAYT markup before running command and then applying it after the command ran will not solve the problem.

We are evaluating possibility to join split markups while removing SCAYT markup. It is easy enough for 2 overlapped markups but not so easy when there are 3 or more of them.

[Garry Yao]

Removing SCAYT markup before running command and then applying it after the command ran will not solve the problem.

It depends on how SCAYT behaves there, we know there's really no win-win situation, where one of our "marker" has to yield.

// Apply strong style
consect<strong>etur adipisicing</strong>
// Current SCAYT markup
<span scaytid="1">consect<strong>etur</strong></span><strong> <span scaytid="2">adipisicing</span></strong>
// Markup *we* prefer
<span scaytid="1">consect</span><strong><span scaytid="1">etur</span> <span scaytid="2">adipisicing</span></strong>

We are evaluating possibility to join split markups while removing SCAYT markup...

This could be our secondary preference as it adds one more unmanageable DOM modification to us.

[WebSpellChecker.net]

To resolve this issue need to publish 4836 patch provided to spellchecker.net earlier, ,take a patches from #5550 (scayt plugin updates) and #5551 (scayt core updates).

[Garry Yao]

Combine all the necessary patches for easy reviewing.

[Garry Yao]

The review is already conducted at #5567.

[Garry Yao]

Fixed with [5397].