13996 2011-09-01 14:58:06 +0000 Don't wrap invisible nodes when doing inline styling 2011-09-21 17:49:14 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - HTML Editing APIs unspecified All All RESOLVED FIXED P2 normal --- 14231 1 ayg ayg mike public-webapps timdown sideshowbarker+html-editing-api oldest_to_newest 56185 0 ayg 2011-09-01 14:58:06 +0000 Reported by Tim Down by private e-mail. E.g., if we bold foo bar currently we produce foo bar The extra 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. 56191 1 timdown 2011-09-01 16:05:51 +0000 The extra element is not only pointless but can also change the layout. In the foo bar example, if there is a style rule that adds a border to elements, the middle adds an extra unwanted line box in CSS 2.1 compliant browsers such as Firefox. 56194 2 ayg 2011-09-01 17:07:32 +0000 If tags like have any style effects other than the default, all sorts of stuff will get messed up. All the spec algorithms assume that does nothing except make stuff bold. So I explicitly don't care about things like authors adding a border to -- they're shooting themselves in the foot and I can't stop it, so I won't try. 57004 3 ayg 2011-09-19 22:20:54 +0000 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. 57080 4 ayg 2011-09-21 17:42:12 +0000 https://dvcs.w3.org/hg/editing/rev/b2d328d179ac Bug 14231 filed as followup on an issue that arose while fixing this. 57082 5 ayg 2011-09-21 17:49:14 +0000 I checked in some extra tests afterward too: https://dvcs.w3.org/hg/editing/rev/4321a7e11603