line-height in UIEnhancer: 'em' vs unitless
colinbdclark at gmail.com
Sat Apr 21 01:22:24 UTC 2012
While I'm not keen to add extra scope to a release like this, I wonder if it wouldn't make sense to also consider the prospect of putting out an Infusion 1.4.1 release with the jQuery upgrades that Antranig has been looking into.
I assume, however, that this would require a full retest of Infusion?
On 2012-04-20, at 4:16 PM, Justin Obara wrote:
> I looked over the pull-request and things look good. I've merged and pushed the changes into the project repo ( https://github.com/fluid-project/infusion/commit/ddecffb33b1ddd45813abe23edc46bbfde9ed239 ).
> I wonder though if we should create a maintenance release for Infusion 1.4 with this fix in place. It should be fairly straight forward to tests.
> • run the unit tests
> • go through the UIO test plans
> On 2012-04-20, at 2:31 PM, Cheetham, Anastasia wrote:
>> In working on the IDI website, Cindy and I were having problems with different line heights, so I did a bit of research.
>> The UI Enhancer (used by UI Options to adjust the page) attaches a line-height CSS property to the body of the document. Currently, it uses a unit of 'em' for that line height. It seems that this is what was causing the problem.
>> When an absolute value is used for line-height (i.e. when a unit is specified, such as 'em' or 'px'), the computed line-height - based on the the font-size of the element where the line-height was specified - is inherited by all elements that don't have their own line-height set. In the case of UIO, this means that everything inherits the computed - and therefore fixed - line height based on the body font size. The result is that elements with larger fonts end up with too little line-spacing, requiring integrators to hard-code a line-height for those elements. Then, increasing the line-height with UIO doesn't affect those elements (this is what's happening in FLUID-4491).
>> In contrast, when the line-height is a unitless number, it is treated as a scaling factor, and that factor is inherited. The factor will be used by each element to calculate the line height based on the element's own font size. I have posted a branch in which the 'em' is removed from the line-height:
>> This fixes the problems we were having in the IDI site, and allows us to remove the extra line-height properties in our UIO demo that were causing FLUID-4491. I've tested the fix across the sites that are currently using UIO. The change does result in some slight changes to line-spacing in some contexts, but nothing major.
>> I did have to adjust some of the tests to accommodate the change. Cindy was very helpful in figuring out what was going on and suggesting how to compensate: When unitless line-heights are used, a jQuery call to elem.css('lineHeight') returns the unitless factor in IE, but a calculated pixel value in all other browsers. The adjustment to the tests was to use the same check that UIEnhancer already uses for this issue.
>> Anastasia Cheetham Inclusive Design Research Centre
>> acheetham at ocadu.ca Inclusive Design Institute
>> OCAD University
>> 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
Technical Lead, Fluid Project
More information about the fluid-work