![]() | |
![]() |
| | Thread Tools | Display Modes |
#41
| |||
| |||
|
|
dorayme wrote: In article <1218087276.460646 (AT) angel (DOT) amnet.net.au>, David Morris <dlmorrisDONTSPAM (AT) netwizDONTSPAM (DOT) com.au> wrote: dorayme wrote: I am not sure if you know there is an issue with line height being specified in units. There could be some circumstances where you might consciously want units but for the most part it is safest to use line height as a mere proportion without units. I see that I have something on this that explains the idea a bit: http://netweaver.com.au/alt/line-height_demo.html I thought 1.5em was proportional to the font-size of the parent element. I was doing this because I had read somewhere that your eyes follow text better if the line height is consistent, though I can't remember where, and may have got in wrong in any event. Clearly, line height should be more or less consistent within a paragraph of same sized text. But if you are relying on the actual (em or px) line height of the parent element to dictate the line height of a child or grandchild, then it will result in what no one would want as I tried to example. I remember now, that part of this approach was to set padding or margin to add up to the same value as line height. Just to make sure I have understood this, ...by specifying 'ems' you are using the parent containers font-size to specify the line height, where as just the number is the font size of the text in the element. |
|
The effect I wanted was to have everything based on a ratio of 1.5 of the typical body text font (as displayed not the element). What ever I actually got, I liked it enough, and so stuck with that. This means that the spacing around heading and larger fonts 'should' add up to some number that is an integer multiplier of the line-height of this basic body text style -- I think. If you want consistent readability, you have two choices. (1) Use units with line-height but watch your back all the time, and be ready to hand code more line heights for the children and grandchildren so readability and commonsense prevails. And this looks like what I have done. (2) Don't use units and relax and let one (or very few) line height declarations do the job for the trunk and branches. Which would be nice if I fully grokked what is going on. I need to revisit by quick and dirty approach and sort this out so I actually do understand what is going on. A few changes to just 1.5 made things look very odd. |
#42
| |||
| |||
|
|
Which would be nice if I fully grokked what is going on. |
#43
| |||
| |||
|
|
"(One would expect most Opera users to be using the very latest version)" - but Opera 9.5 has dropped (AFAICS) a useful feature present in 9.2 - CtrlAltV. |
|
The comments textarea is foolishly narrow. BTW, one can add a button to do rows++. |
#44
| |||
| |||
|
|
Dr J R Stockton wrote: "(One would expect most Opera users to be using the very latest version)" - but Opera 9.5 has dropped (AFAICS) a useful feature present in 9.2 - CtrlAltV. The site was tested with the latest version of Opera at the time, which was 9.2. |
|
The comments textarea is foolishly narrow. BTW, one can add a button to do rows++. I am sure you meant 'unnecessarily' rather the than 'foolishly'. To be foolish would be to include Javascript on a page that highlighted why you shouldn't use Javascript. |
![]() |
| Thread Tools | |
| Display Modes | |
| |