Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#11175 closed defect (fixed)

InlineEditBox: IE8 font is tiny

Reported by: haysmark Owned by: bill
Priority: high Milestone: 1.5
Component: Dijit Version: 1.5.0b2
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)


In the InlineEditBox tab, look at one of the bottom TextBox editors:

before clicking

Click to open the editor:

The font size for the editable text is very small.

Attachments (3)

display.png (7.8 KB) - added by bill 12 years ago.
before clicking
11175.patch (894 bytes) - added by Douglas Hays 12 years ago.
possible fix w/o usng font metrics
edit.png (9.3 KB) - added by bill 12 years ago.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 12 years ago by bill

Milestone: tbd1.5
Summary: IE8 InlineEditBox edit font is tinyClaro InlineEditBox: IE8 edit font is tiny

Hmm, that's a bad one.

On my machine (running themeTester.html on IE8), both the ComboBox root node and the ComboBox .dijitInputField get an inline style of font-size: 0.68em. They are multiplying in effect.

I think this is something that's specific to IE. Note that dojo.css defines font-size differently for IE vs. other browsers:

body { 
	font: 12px Myriad,Helvetica,Tahoma,Arial,clean,sans-serif; 
	*font-size: 75%;

However, themes/claro/Common.css overrides that setting:

.claro {
	font-size: .688em;
	background-color: #fff;

As a side note, themeTester.html?theme=tundra is getting class="claro tundra", rather than class="tundra", on the <body> tag. But that's just a test file issue.

Changed 12 years ago by bill

Attachment: display.png added

before clicking

Changed 12 years ago by Douglas Hays

Attachment: 11175.patch added

possible fix w/o usng font metrics

comment:2 Changed 12 years ago by bill

Summary: Claro InlineEditBox: IE8 edit font is tinyInlineEditBox: IE8 font is tiny

Here's some background on the issue (written here for posterity):

InlineEditBox tries to match it's font (specifically font-size, but also italic/bold/etc.) to the display text. The idea is that if the user clicks an <h1> to edit it, the editor will have a large font just like the <h1>. This matching is done by calling getComputedStyle() on the display node, which theoretically will return a font size in px that can be applied to the editor.

Note that the font of a given node can be affected in many ways, both by a font setting on the node itself, and a font setting on it's ancestor. And note that both em and % are relative font settings, so they multiply.

For example, font set directly on node:

<style> h1 { font-size: 2em; } </style>
<h1> I'm big </h1>

Font size inherited from parent:

<style> p { font-size: 2em; } </style>
    <span> I'm big too </span>

Font size inherited and then set explicitly, resulting in 400% size increase:

    p { font-size: 2em; }
    span { font-size: 2em; }
    <span> I'm doubly big </span>

The underlying problem is that IE's getComputedStyle() returns "2em" for both the <h1> and the <span> in all three examples above. The correct behavior is to return an absolute value like "24px", or for the final example, "48px"

As for Doug's patch, it looks like it might lessen the number of cases where the problem occurs. Specifically it will avoid the problem where the display text is 200% but the edit text becomes 400% (because InlineEditBox set font-size: 200% on the editor widget):

<p style="font-size: 200%;">
   <span dojoType=dijit.InlineEditBox>hello world</span>

I think the patch will cause a new failure in a case like this though:

<p style="font-size: 200%;">
   <span dojoType=dijit.InlineEditBox style="font-size: 200%">hello world</span>

... as the display text will be 400% but the edit text will only be 200%.

In the current code, the font size bug only occurs when:

  1. the node itself doesn't have a font-size setting
  2. the closest ancestor has a relative font-size setting not equal to 100% or 1em

For that reason it doesn't usually occur in tundra/soria/nihilo, since dojo.css sets an absolute 12px font size on <body> and 1em font size on <p>. Note that IE's and FF's View/Text? Size menu still affects the page's font size in this case. Similarly, in claro, there's no problem when the InlineEditBox is inside of a <p>, since <p> has font-size: 1em. Thus, test_InlineEditBox.html?theme=claro looks OK.

However, a problem does occur in themeTester.html on IE6/IE7/IE quirks, for all themes, since in that case the nearest ancestor is <body>, and body has a font-size of 75%:

body { 
	font: 12px Myriad,Helvetica,Tahoma,Arial,clean,sans-serif; 
	*font-size: 75%;   <--- override for IE6/7/quirks

It would be nice to just remove the 75% rule, but unfortunately that causes View/Text? Size to have no effect on IE6/IE7/IE quirks.

Claro theme has the same problem on IE6/IE7/IE quirks, only more pronounced, since it sets <body>'s font-size smaller than dojo.css. And since claro doesn't set an absolute font-size for the non-IE6/7/quirks case, the problem occurs on IE8 too.

Note finally though that regardless of the settings in claro or dojo.css, this problem could occur based on the app CSS.

comment:3 Changed 12 years ago by bill

Resolution: fixed
Status: newclosed

(In [22218]) Fix from Doug for IE/InlineEditBox font-size problem, thanks!, fixes #11175 !strict. Not sure if there are any corner cases where it still fails but anyway it works in general.

Changed 12 years ago by bill

Attachment: edit.png added

comment:4 Changed 12 years ago by bill

Description: modified (diff)
Note: See TracTickets for help on using tickets.