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 - [email protected]
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
