This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
See: https://bugs.webkit.org/show_bug.cgi?id=21679 I'm adding the following fontSize tests: ["6", '<span style=background-color:aqua>[foo]</span>'], ["6", '<span style=background-color:aqua>foo[bar]baz</span>'], ["6", '[foo<span style=background-color:aqua>bar</span>baz]'], And the following hiliteColor tests: '<font size=6>[foo]</font>', '<span style=font-size:xx-large>[foo]</span>', '<font size=6>foo[bar]baz</font>', '<span style=font-size:xx-large>foo[bar]baz</span>', '[foo<font size=6>bar</font>baz]', '[foo<span style=font-size:xx-large>bar</span>baz]', In many cases, the highlight is visually not high enough in the markup that the spec produces. We get things like <span style="background-color: teal">foo<font size=6>bar</font>baz</span>, 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.
Tests added: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=d7d54085
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.
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.
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.