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 >> [email protected] Inclusive Design Institute >> OCAD University >> >> _______________________________________________________ >> 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 --- Colin Clark Technical Lead, Fluid Project http://fluidproject.org _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
