This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Based on WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=7360 Normally if we delete the full contents of a formatting tag like <b>, we delete the tag itself for tidiness, since there's no way to focus the tag anyway. E.g., if you delete foo<b>[bar]</b>baz, it becomes foo[]baz, not foo<b></b>[]baz or anything. State/value overrides (typing style in WebKit terms) ensure that if the user types again before moving the cursor, the text has the right style. However, this is bad when the tag is the only thing in a block. Consider <p>foo</p> <p>bar</p> <p>baz</p> The user selects all the text and bolds it: <p><b>foo</b></p> <p><b>bar</b></p> <p><b>baz</b></p> Then deletes "bar". Currently it becomes <p><b>foo</b></p> <p><br></p> <p><b>baz</b></p> so if the user moves away and back and types, the text in the middle is no longer bold. This isn't what the user wants: they made all three paragraphs bold and want them to stay bold. The solution is to insert a <br> if necessary *before* we strip wrappers. Then when we get to stripping wrappers, there will be a child, so we won't. This will produce <p><b>foo</b></p> <p><b><br></b></p> <p><b>baz</b></p> which should have the desired effect.
Neither webkit or Gecko persist the "typing style" (or "type-in state" in Gecko jargon) in the DOM under normal circumstances. Why should this be different?
The problem is that in this case, the user selected multiple paragraphs and made them all bold. Conceptually, they view the whole thing as one continuous run of bold text. If some text is deleted from the middle of a continuous run of bold text, and some more text is added later still in the middle of the run, the new text should be bold. E.g., if you have <b>foobarbaz</b> and delete "bar" and then do something else and later type "quz" where "bar" used to be, the newly-typed text is bold, because it's in the middle of a bold run of text. Likewise, if you have <p><b>foo</b></p> <p><b>bar</b></p> <p><b>baz</b></p> and do the same, you'd expect the same result. But you don't, because it so happens it's not one big <b>, it's secretly split into three <b>'s even though you only hit Ctrl-B once. Really the markup that would make sense here is <b><p>foo</p><p>bar</p><p>baz</p></b> which would behave as expected. We can't do that, but we can fake it. Word 2007 seems to behave something like this proposal. If you go to an empty paragraph, hit Ctrl-B, then navigate away and back, it's still bold. Basically, the idea would be empty *blocks* can still have styles, but a collapsed position inside *text* cannot once you move the cursor away. That seems reasonable to me.
I think the behavior that you're describing is definitely the behavior that we want. However, my question is, why do we need to put a br node _in the DOM_ in order to make this work correctly? Why can't we treat this as the regular "typing style"?
What's the advantage? It means that if the document is saved and restored, the style will vanish. This is fine for regular (typing style|type-in state|state/value overrides), because they disappear anyway if the cursor leaves the current location. But if the style stays put when the user goes and types someplace else, why should it vanish if the document is saved and restored?
(In reply to comment #4) > What's the advantage? It means that if the document is saved and restored, the > style will vanish. This is fine for regular (typing style|type-in > state|state/value overrides), because they disappear anyway if the cursor > leaves the current location. But if the style stays put when the user goes and > types someplace else, why should it vanish if the document is saved and > restored? I was going to say that the advantage would be being consistent with how the type-in state works, but you have a good point here... I guess I could live with the node living in the DOM then.
Related: when applying inline style, block nodes that contain no visible editable text nodes should still get their contents wrapped in a (possibly empty) tag. E.g., bolding <p><br></p> should give you <p><b><br></b></p>, not do nothing.
https://dvcs.w3.org/hg/editing/rev/d461532af710 Filed bug 14729 for comment 6.