|

»

line-height in UIEnhancer: 'em' vs unitless

View: New views

4 Messages — Rating Filter: Alert me

	line-height in UIEnhancer: 'em' vs unitless by Cheetham, Anastasia-2 :: Rate this Message: \| View Threaded \| Show Only this Message 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@... Inclusive Design Institute OCAD University _______________________________________________________ fluid-work mailing list - fluid-work@... To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work signature.asc (506 bytes) Download Attachment
	Re: line-height in UIEnhancer: 'em' vs unitless by Justin Obara-3 :: Rate this Message: \| View Threaded \| Show Only this Message 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@... Inclusive Design Institute OCAD University _______________________________________________________ fluid-work mailing list - fluid-work@... To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work _______________________________________________________ fluid-work mailing list - fluid-work@... To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
	Re: line-height in UIEnhancer: 'em' vs unitless by Colin Clark-2 :: Rate this Message: \| View Threaded \| Show Only this Message 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@... Inclusive Design Institute >> OCAD University >> >> _______________________________________________________ >> fluid-work mailing list - fluid-work@... >> To unsubscribe, change settings or access archives, >> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work > > _______________________________________________________ > fluid-work mailing list - fluid-work@... > 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 - fluid-work@... To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
	Re: line-height in UIEnhancer: 'em' vs unitless by Justin Obara-3 :: Rate this Message: \| View Threaded \| Show Only this Message It would require a full test, but it does seem to be an important fix. I'd +1 if we have time. -Justin On 2012-04-20, at 9:22 PM, Colin Clark <colinbdclark@...> wrote: > 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@... Inclusive Design Institute >>> OCAD University >>> >>> _______________________________________________________ >>> fluid-work mailing list - fluid-work@... >>> To unsubscribe, change settings or access archives, >>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work >> >> _______________________________________________________ >> fluid-work mailing list - fluid-work@... >> 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 - fluid-work@... To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work