4461 - Problem with px -> em conversion

[Li, Cindy]

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