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