4461 - Problem with px -> em conversion

[Li, Cindy]

Story continues with IE9 em to px conversion:

I was playing reversely with the em numbers to find out with which em IE9 would return me a 10px. The result is none.

With parent element's font size 16px, which is the em to px conversion factor,

ems in the range of 0.62 - 0.629 are all converted into 9.93px ( === 0.62 * 16 + 0.01 );
ems in the range of 0.63 - 0.639 are all converted into 10.07px ( === 0.63 * 16 - 0.01 );
...

Obiviously, IE9 takes 2 decimal digits into account and ignore the third and onwards. IE9 also seems having its internal algorithm to determine the returned px which is not a simple equation of em * factor.

I then experimented with IE8 and found out even worse that IE8 always returns px in integer form without any decimal, in the 2 cases above that IE9 returns 9.93px and 10.07px, IE8 returns 10px instead.

An IE blog article I came across (http://blogs.msdn.com/b/ie/archive/2010/11/03/sub-pixel-fonts-in-ie9.aspx) says that IE9 uses sub-pixels font calculation while the older versions use whole-pixel which is an improvement at IE9 but I wish it could increase the precision further more.

After talking with Justin, we think we probably should confess the browser variation. I'm going to fix the IE9 unit test by providing a two decimal digits em.

Let me know if any other ideas. Thanks.

Cindy

On 2011-09-23, at 2:43 PM, Li, Cindy wrote:

> More updates:
> 
> In summary, 4461 leads to the discovery of 2 issues:
> 
> 1. Auto-detect px to em conversion factor rather than counting on the integrator, who has no idea of the page viewers' browser setting, to provide it.
> 
> After more search and experiment, this factor can be detected as easy as the font-size of the parent element, which is what the children "em"s  are relative to. So, This issue is fixed. Now UIEnhancer unit tests run through no matter how the browser default font size is adjusted.
> 
> 2. IE9's odd em -> px calculation:
> 
> The odd is that "0.625em" is calculated into "9.93px" by IE9 rather than "10px", with detected px2emFactor "16px".
> 
> The first guess is IE9 uses a different factor like "15.888". To prove, I set the initial font size to "16px", an equivalent of "body" font size, which is also the detected px2emFactor. IE9 happily returns "16px" for "1em", which indicates "15.888" factor may not be the case.
> 
> So more guessing and math, probably IE9 only keeps 2 decimal digits?! 0.625 is truncated into 0.62 since 0.62 * 16 = 9.92, close but still not exact 9.93.
> 
> So, still not surely sure about where 9.93 comes from. The only outcome is that IE9 behaves same as other browsers on integer em -> px conversion, but not guaranteed on decimal ems.
> 
> I can temporarily fixed IE9 by faking out the integer em numbers, but it certainly doesn't solve the root problem. However, unless we could figure out a universal way of em to px conversion that works across all browsers including IE9, fixing IE9 will likely break the UIEnhancer unit tests on IE8 and other browsers. 
> 
> Let me know if any opinion? I will continue looking for a universal conversion. :)
> 
> On 2011-09-22, at 1:32 PM, Li, Cindy wrote:
> 
>> After sending out the first email, I was looking into the issue that UIEnhancer unit tests fail in my Mac firefox6.
>> 
>> It turns out that it's because I explicitly set the default font size in my ff6 to 24px, which overwrites the original default "16px" and turns 1em === 24px.
>> 
>> Further more, another factor that would affect the default font size is,
>> 
>> For example, if the user has scale-down (or scale-up) css as:
>> 
>> body: {font-size: 62.5%}
>> 
>> Assuming the current default font size is 16px, this css takes it down to "10px".
>> 
>> I'm now thinking it might be less risky to have UIO directly apply the browser-computed font size in px, rather than discovering all the possible factors and re-computing px back into em, especially considering the computed font size is dynamically calculated and applied based on the current browser setting and css at every page refresh.
>> 
>> Of course, I may miss some good reasons that we should stick with em. Your comments are welcome. 
>> 
>> Thanks.
>> 
>> Cindy
>> 
>> On 2011-09-22, at 11:29 AM, Li, Cindy wrote:
>> 
>>> Hi,
>>> 
>>> I'm looking into FLUID-4461, which is UIEnhancer unit tests fail in IE9 because the line spacing size returns 1.51 rather than expected 1.5.
>>> 
>>> The problem is resulted from our recently-introduced px to em conversion on "font-size". Since retrieving "font-size" value via jQuery returns in px but we all agreed that it's better to set font size in "em", a new UIEnhancer option "px2emFactor" with default value "16" is introduced to convert jQuery returned px value into em before it's applied by UIO. However, the next time this UIO-set em value being retrieve by jQuery from browser, it is converted back to px. Seems the browser uses a different factor value which creates the issue.
>>> 
>>> For instance, the value returned by first query on "font-size" via jQuery is "10px", UIO converts and sets "0.625em" onto main page. The next retrieval via jQuery on "font-size" returns "9.93px" instead.
>>> 
>>> I had a peek into jQuery code on how it gets font size value, seems it uses browser supported function getComputedStyle() or property currentStyle. With IE, getComputedStyle() is supported since IE9. The older IE version uses currentStyle. In other words, the em to px conversion and the factor being used is determined by the browser rather than a jQuery behaviour.
>>> 
>>> https://github.com/fluid-project/infusion/blob/master/src/webapp/lib/jquery/core/js/jquery.js#L6541
>>> https://github.com/fluid-project/infusion/blob/master/src/webapp/lib/jquery/core/js/jquery.js#L6487-6504
>>> 
>>> Another interesting thing I noticed with IE9 is, if I turned on "compatible view", which is an IE9 feature saying "to make the websites designed for older browsers look better and problems such as out-of-place menus, images or text will be corrected", getComputedStyle() would return the expected "10px" and UIEnhancer unit test would pass. This gives me an impression that the regular IE9 deals with css a bit differently from its older siblings.
>>> 
>>> Any idea of the solution to this issue?
>>> 
>>> Thanks.
>>> 
>>> Cindy
>>> _______________________________________________________
>>> fluid-work mailing list - fluid-work at fluidproject.org
>>> To unsubscribe, change settings or access archives,
>>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>> 
>> _______________________________________________________
>> fluid-work mailing list - fluid-work at fluidproject.org
>> To unsubscribe, change settings or access archives,
>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work