line-height in UIEnhancer: 'em' vs unitless

Colin Clark 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?

Colin

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
> 
> Thanks
> Justin
> 
> 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:
>> 
>> 	https://github.com/acheetham/infusion/tree/FLUID-4703-uie-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

---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org



More information about the fluid-work mailing list