In rich text editing, when calling execCommand("FontSize") on some selected text, the text size will correctly be changed, but if the selected text had some background color, the background color block will not change size. This causes the text to look very funny. If you change the text to be twice the size it was before, the previous background color will only cover the bottom half of the new text. This does not repro in Firefox (Mac & Windows) and IE7.
For an html like this: <span style="background-color: rgb(255,0,0);"><font size="7">This line is bad</font></span> The background color doesn't stretch to the font size. Other browsers put the <font> tag outside of the <span> tag, so that would be one way of fixing this bug. IE will always stretch the background color's width to match the largest text in the line. Not sure if that is correct or not, but it seems to be a better behavior in this case.
Created attachment 64145 [details] Repro case for execCommand('fontsize') bug This is still reproducible as of WebKit 534.3. This repro case demonstrates that the bug occurs on webkit but not on firefox. Honestly, i think the real bug is that webkit is creating unnecessary <span> tags. It should just modify the existing <span> tag.
http://www.w3.org/TR/CSS2/visudet.html#inline-non-replaced and http://meyerweb.com/eric/css/inline-format.html (linked from http://www.w3.org/TR/css3-roadmap/) seem to imply that the line-height of the outer SPAN (inline non-replaced element) is determined by the font size of the outer span. So our rendering is correct (at least does not violate CSS2 spec). <span class="Apple-style-span" style="background-color: rgb(255, 0, 0);"><span class="Apple-style-span" style="font-size: xx-large;">This is a font-size tag nested in a background-color tag.</span></span> (In reply to comment #2) > Honestly, i think the real bug is that webkit is creating unnecessary <span> tags. It should just modify the existing <span> tag. You're right. We should avoid specifying font-size inside non-replaced inline element.
The editing spec also has this problem. I filed a bug there, for those who are interested: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13829
. . . FWIW, the problem is not limited to creating extra span tags. If you have markup like foo<font size=6>bar</font>baz then the markup you need to generate is actually <span style=background-color:aqua>foo<font size=6 style=background-color:aqua>bar</font>baz</span> or something. You need to actually check each descendant for this condition and fix it -- in some cases you'll really need to add more markup. Of course, it's less of an issue if you don't create extra spans, but that brings its own problems.
Today I tired applying current hilite color before applying font size, and it is working fine. Changed in ExecuteFontSize() of EditorComand.cpp Any thoughts.?? (In reply to comment #5) > . . . FWIW, the problem is not limited to creating extra span tags. If you have markup like > > foo<font size=6>bar</font>baz > > then the markup you need to generate is actually > > <span style=background-color:aqua>foo<font size=6 style=background-color:aqua>bar</font>baz</span> > > or something. You need to actually check each descendant for this condition and fix it -- in some cases you'll really need to add more markup. Of course, it's less of an issue if you don't create extra spans, but that brings its own problems.
Created attachment 463842 [details] Safari 16.1 matches Chrome Canary 110 but differs from FX109 As can be seen from attached, there is a gap in background painting of Firefox but font-size wise all of the browsers are matching. I am not sure, whether it is something need to be fixed or not but just sharing updated testing results. Thanks!