13829 2011-08-18 18:08:28 +0000 Ensure that hiliteColor is the innermost style applied 2011-09-28 21:19:42 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - HTML Editing APIs unspecified All All NEW P5 normal --- 1 ayg ayg mike public-webapps sideshowbarker+html-editing-api oldest_to_newest 55439 0 ayg 2011-08-18 18:08:28 +0000 See: https://bugs.webkit.org/show_bug.cgi?id=21679 I'm adding the following fontSize tests: ["6", '[foo]'], ["6", 'foo[bar]baz'], ["6", '[foobarbaz]'], And the following hiliteColor tests: '[foo]', '[foo]', 'foo[bar]baz', 'foo[bar]baz', '[foobarbaz]', '[foobarbaz]', In many cases, the highlight is visually not high enough in the markup that the spec produces. We get things like foobarbaz, and the background doesn't get higher to match the increased height of "bar". I think the correct fix is to change the effective value algorithm so that it returns a special value like "mixed" if this case is detected. That way, any descendants that have this problem will have the algorithm applied to them again. 55440 1 ayg 2011-08-18 18:09:58 +0000 Tests added: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=d7d54085 55948 2 ayg 2011-08-28 16:59:12 +0000 Ryosuke pointed out at the face-to-face that changing the effective value algorithm isn't enough. We also need to add extra save/restore checks whenever fontSize changes. This should still be doable, though. 55998 3 ayg 2011-08-29 18:27:19 +0000 He also pointed out that you have to do it on delete too, and perhaps other places. Should still be doable. We just need to make sure we're saving and restoring values as often as necessary. 57487 4 ayg 2011-09-28 21:19:42 +0000 This is trickier than I thought. Just changing the effective command value is bad, because it will affect the value of queryCommandValue(). Something subtler is needed, and perhaps more special.