[w3c/editing] insertParagraph definition is different from current browsers' behavior when selection is collapsed at end of inline element(s) (#172)

Although I'm not sure here is a good place to file an issue of execCommand spec:
https://w3c.github.io/editing/execCommand.html#the-insertparagraph-command

insertParagraph command declares that when selection is started from end of inline element(s), start of range to copy nodes to new container should be next to its next node (16). However, actually, at least Gecko and Blink copies inline elements for keeping same style in new paragraph. For example, |<p><b>foo[]</b></p>| will be |<p><p>foo</b></p><p><b>[]<br></b></p>|. I think that this behavior makes sense.

Oddly, if |<b>| is |<a href="">|, Blink doesn't copy it and Gecko didn't do it too (but currently, we changed the behavior accidentally, we will take the old behavior back *1). I feel that this must be better for users since users must not want to keep creating same link in new paragraph in most cases. So, perhaps, this should also be speced.

1: https://bugzilla.mozilla.org/show_bug.cgi?id=1422234

Here are some testcases:

at end of text node:
https://jsfiddle.net/d_toybox/x0kohuo0/8/ (|<b>|)
https://jsfiddle.net/d_toybox/x0kohuo0/9/ (|<a name="foo">|)
https://jsfiddle.net/d_toybox/x0kohuo0/10/ (|<a href="foo">|)

at after text node:
https://jsfiddle.net/d_toybox/x0kohuo0/11/ (|<b>|)
https://jsfiddle.net/d_toybox/x0kohuo0/12/ (|<a href="foo">|)

nested case:
https://jsfiddle.net/d_toybox/x0kohuo0/13/ (|<b><a href="foo">|)
https://jsfiddle.net/d_toybox/x0kohuo0/14/ (|<b><i>|)
https://jsfiddle.net/d_toybox/x0kohuo0/15/ (|<a href="foo"><i>|)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/172

Received on Friday, 19 January 2018 08:51:40 UTC