13839 2011-08-19 18:39:19 +0000 Merge adjacent inline markup when deleting 2015-07-30 23:47:08 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - HTML Editing APIs unspecified PC Linux NEW P2 enhancement --- 1 ayg ayg ehsan mike public-webapps 2015-07-30 sideshowbarker+html-editing-api oldest_to_newest 55494 0 ayg 2011-08-19 18:39:19 +0000 WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=12322 So for instance, if you delete the space in <b>foo</b> <b>bar</b>, it should be <b>foobar</b>, not <b>foo</b><b>bar</b>. This is not a common issue, but it might be nice to have eventually. 55560 1 ehsan 2011-08-22 03:30:14 +0000 Wouldn't this lead to surprises if the user is interacting with the text? Imagine this markup: <b>foo</b> b|<b>ar</b>. I would expect the following sequence of keys to produce the original markup (i.e., the entered b not being bold). backspace, backspace, space, b 55589 2 ayg 2011-08-22 19:22:57 +0000 Interesting point. Word 2007, Firefox 8.0a2, and Chrome 15 dev all behave as you describe. IE10PP2 and Opera 11.50 make the newly-typed " b" bold, although they don't merge the <b>'s. But this proposal doesn't have to conflict with that behavior. We have the concept of "state override"/"value override" already in the spec to handle things like this. For instance, if you have f<b>o</b>o and the user backspaces over "o", then the <b> is gone, but if they type without moving the cursor, a new <b> is created to wrap their newly-added text. So I just have to make sure that if two tags get merged this way, we set state/value overrides so that newly-typed text will un-split the tag. 55602 3 ehsan 2011-08-22 20:18:04 +0000 Yes, that would make sense to me.