W3C home > Mailing lists > Public > public-editing-tf@w3.org > September 2016

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

From: Ojan Vafai <ojan@google.com>
Date: Fri, 30 Sep 2016 11:55:27 +0000
Message-ID: <CANMdWTvn1qD=npQZLriZ=6FUC2wbJiB_bDkScr6gPWRe0vfk6g@mail.gmail.com>
To: Grisha Lyukshin <glyuk@microsoft.com>, public-editing-tf <public-editing-tf@w3.org>
Cc: Anupam Snigdha <snianu@microsoft.com>
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> 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 Friday, 30 September 2016 11:56:08 UTC

This archive was generated by hypermail 2.3.1 : Friday, 30 September 2016 11:56:09 UTC