Bug 21679 – ExecCommand fontsize does not change size of background color

• Component: HTML Editing
• Status: NEW

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.

[Deepak Jindal]

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.

[Nick Santos]

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.

[Ryosuke Niwa]

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.

[Aryeh Gregor]

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

[Aryeh Gregor]

. . . 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.

[Naresh.vt]

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.

[Ahmad Saleem]

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!