4461 - Problem with px -> em conversion

Li, Cindy cli at ocad.ca
Fri Sep 23 18:43:53 UTC 2011


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



More information about the fluid-work mailing list