Re: style preserving when forward deleting characters in content editable div

Thanks, Ojan.



Agree with rationale behind links.



I filed a bug on Chrome on 2nd case here<https://bugs.chromium.org/p/chromium/issues/detail?id=652912> since it looks like there is a bug in Windows.







Sent from Outlook<http://aka.ms/weboutlook>

________________________________
From: Ojan Vafai <ojan@google.com>
Sent: Friday, September 30, 2016 4:55:27 AM
To: Grisha Lyukshin; public-editing-tf
Cc: Anupam Snigdha
Subject: Re: style preserving when forward deleting characters in content editable div

I'm seeing Chrome and Edge do the same thing in your second test case (i.e. the z is red). Maybe I'm mistesting?

It could be we do something different on Windows, but that would be a bug.

My mental model of the Chrome (and Safari) behavior is that we always grab the style of the content to the left of the caret, except for links. Links are special because they're not just styling. Users are most annoyed by being unable to escape them and often rich text widgets don't give an easy way of truncating anchors they way they do styling. Although, I'll admit that our current behavior of inserting unstyled black text is a bit unexpected, it's not a thing I've ever heard complaints about. https://jsfiddle.net/whbk8npa/2/

To be clear, we only treat links specially, not all anchor tags (i.e. if it has no href, it's the same as a span).

The Firefox behavior has nothing to do with delete. It has to do with which direction your selection approached that point in the DOM from. You can repeat the same behavior with <span>a</span><span>b</span> and approaching the point between a and b from different directions.

On Fri, Sep 30, 2016 at 1:48 AM Grisha Lyukshin <glyuk@microsoft.com<mailto:glyuk@microsoft.com>> wrote:

Hello Editing Task Force,



I wanted to run the following scenario by you and hear your stance on it?



Here is the use case code snippet:



<body contenteditable="true">

<div><span style="color:red;">a</span></div>

<div><span style="color:blue;">bc</span></div>

</body>



Jsfiddle: https://jsfiddle.net/whbk8npa/



this markup will be displayed to the user like

a

bc



1. Place a caret to the right of character 'a'

2. Hit delete (new line will be removed and user will see 'abc'

3. Hit delete again  and user will see 'ac'

4. Type some character, 'z' for example. User will see different results, depending on the browser:



Chrome


Edge


Firefox


Safari


azc


azc


azc


Didn't test - someone who has Safari, please test




*It seems that Chrome and Edge grab styles from the span that is to the left of 'a' and Firefox grabs the stylse from the span to the right of 'a'.





Now, repeat the experiment but this time, delete everything to the right of 'a' so the end result would look like so 'a'. Results are again, quite different.

Chrome


Edge


Firefox


Safari


az


az


az


Didn't test - someone who has Safari, please test




In this case, Chrome seems to  grabs the style from the span to the right of 'a' if the last character in the span has been removed.

Edge still grabs styles from the span that is to the left of 'a'.

Firefox seems to do its own thing.



What do you think the most sensible behavior here is?



I believe, we should keep things simple - in accordance with how desktop and online editors do. Always grab styles from the left of 'a'.



Thoughts?


- Grisha




Sent from Outlook<http://aka.ms/weboutlook>

Received on Wednesday, 5 October 2016 00:29:19 UTC