This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Reported by Tim Down by private e-mail. E.g., if we bold <p>foo</p> <p>bar</p> currently we produce <p><b>foo</b></p><b> </b><p><b>bar</b></p> The extra <b> in the middle is pointless. The user can never focus the collapsed whitespace node, after all. We should abort early in "force the value" if the node is invisible, just like if the value already matches.
The extra <b> element is not only pointless but can also change the layout. In the <p><b>foo</b></p><b> </b><p><b>bar</b></p> example, if there is a style rule that adds a border to <b> elements, the middle <b> adds an extra unwanted line box in CSS 2.1 compliant browsers such as Firefox.
If tags like <b> have any style effects other than the default, all sorts of stuff will get messed up. All the spec algorithms assume that <b> does nothing except make stuff bold. So I explicitly don't care about things like authors adding a border to <b> -- they're shooting themselves in the foot and I can't stop it, so I won't try.
I've got a patch to do this now, but it has an undesired side effect I forgot about: after running a command like bold, the command might be indeterminate. I need to ignore invisible nodes when computing indeterm/state/value for this change to make sense.
https://dvcs.w3.org/hg/editing/rev/b2d328d179ac Bug 14231 filed as followup on an issue that arose while fixing this.
I checked in some extra tests afterward too: https://dvcs.w3.org/hg/editing/rev/4321a7e11603