Re: [css-d] Font-size affecting line-height?
On 2/10/2013 11:06 AM, Kyle Sessions wrote:
I've come across some really strange behavior when trying to mix multiple
font-sizes within a single block element. I've built an example page here:
http://kage23.com/line-height.html
Basically, it seems like I'm getting an extra pixel of height and I can't
track down how or why. In my example, the paragraph inside of the first
block is 24px tall, as one would expect from a line of text with
line-height of 24px and no margins or padding.
This is not true. The in the first box is 20px tall. This is since a
font size of 16px gives a space of roughly 19.5px (rounds to 20px) for
ascenders and descenders.
However, the paragraph
inside of the second block is 25px tall, even though it has a line-height
of 24px.
Correct but it not due to the line-height. The extra 1px is due to the
font-size difference. A font size of 20px gives a space of roughly
24.375 (rounds to 25px) for ascenders and descenders.
The span has a font-size of 20px, so it should still fit within
the line-height.
The line-height will only cause a new line to be positioned on top of
the first line if the line wraps.
(In fact, as I was playing with it, I was still seeing the
same issue, in some cases even more pronounced, when I made the span a
smaller font-size than the rest of the paragraph.)
This only seems to happen when I mess with varying font-sizes within the
same BLOCK-LEVEL element. If, for example, I assign { display: block; } to
.block p span, then the span becomes 24px tall, and the p becomes 48px
tall, as I would expect. So when my span is inline, why does changing the
font-size on the span affect the line-height of the p???
The line-height is on the outer and this value is
inherited by the and the . The line-height is not effected by
the font-size. The line-height is 24px for , and the
. Don't confused the CSS property line-height with the visual and
computed height.
I've been banging my head against this for a while now. I would greatly
appreciate any thoughts or suggestions!
~Kyle
Eric and Philippe have show some demos. The test case below may also
help. Change the first test to 0 line-height and the select "show span"
on the first test. In firefox, narrow the viewport so the Oo overlaps
the Xx. Have a play around with the various test.
http://css-class.com/test/css/text/linebox-line-height-011.html
[Please note that the values above is due to my default font for my browser]
Alan
--
Alan Gresley
http://css-3d.org/
http://css-class.com/
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Two classes, two conflicting rules, which wins ?
On 2 Oct 2013, at 10:43, Greg Gamble wrote:
OK, I'll bite :-)
What is origin, weight, and specificity? I hear the terms and I
think I get it ... but, to hear it from the Master would be great.
Well, the Master isn't available (something about a drum circle and
looking for a police box key), but I'll take a swing at it. The details
are here:
http://www.w3.org/TR/CSS2/cascade.html#cascade
Here's what I meant:
* Origin -- whether the rule comes from the author, the user, or the
user agent. There's a precedence order defined in the specification, so
that (for example) author rules always override user agent rules.
That's why you saying 'strong {font-weight: normal;}' removes the
boldface treatment even if there's a user agent rule that says something
like 'h1 strong {font-weight: bolder;}'.
* Weight -- called "importance" in CSS 2.1. If a rule has been given
'!important' then it wins over any non-important rule, period, end of
story. Two conflicting rules that have the same weight (or importance),
and thus have their conflict resolved through other means.
* Specificity -- how specific a selector is, which is figured out by
counting the pieces and coming up with a value. Higher specificity
trumps lower specificity, assuming the origin and weight are the same:
thus two normal-weight author rules that conflict are resolved using
selector specificity.
…and if, after all that, two rules are still in conflict, THEN the
order they're written in matters.
There's a little bit more to the story, once you take into account
inheritance and the lack of a notion of element proximity in the
document tree and so forth, but those are the core bits.
--
Eric A. Meyer - http://meyerweb.com/
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Two classes, two conflicting rules, which wins ?
OK, I'll bite :-) What is origin, weight, and specificity? I hear the terms and I think I get it ... but, to hear it from the Master would be great. Greg -Original Message- From: css-d-boun...@lists.css-discuss.org [mailto:css-d-boun...@lists.css-discuss.org] On Behalf Of Eric A. Meyer Sent: Wednesday, October 02, 2013 6:18 AM To: CSS-D Subject: Re: [css-d] Two classes, two conflicting rules, which wins ? On 1 Oct 2013, at 16:50, Robert A. Rosenberg wrote: > So you are saying that in a 'class="c2 c1"' case, it scans the CSS > defs, sees .c1 and applies it, keeps going and sees .c2 which > overrides the c1 width? > > IOW: The order that you list the class in the HTML is ignored and only > the order that the classes are defined in the CSS defs counts. That's correct. (Assuming the selectors have the same origin, weight, AND specificity, that is; in that case, then the order the rules are listed in the CSS matters. If two selectors don't have the same origin, weight, OR specificity, then the order they're listed in the CSS is irrelevant.) -- Eric A. Meyer - http://meyerweb.com/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Two classes, two conflicting rules, which wins ?
On 1 Oct 2013, at 16:50, Robert A. Rosenberg wrote: So you are saying that in a 'class="c2 c1"' case, it scans the CSS defs, sees .c1 and applies it, keeps going and sees .c2 which overrides the c1 width? IOW: The order that you list the class in the HTML is ignored and only the order that the classes are defined in the CSS defs counts. That's correct. (Assuming the selectors have the same origin, weight, AND specificity, that is; in that case, then the order the rules are listed in the CSS matters. If two selectors don't have the same origin, weight, OR specificity, then the order they're listed in the CSS is irrelevant.) -- Eric A. Meyer - http://meyerweb.com/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Font-size affecting line-height?
On 1 Oct 2013, at 21:06, Kyle Sessions wrote: I've come across some really strange behavior when trying to mix multiple font-sizes within a single block element. I've built an example page here: http://kage23.com/line-height.html Basically, it seems like I'm getting an extra pixel of height and I can't track down how or why. Believe it or not, this is expected behavior. It arises from the interaction of 'vertical-align' and 'line-height'. I created some images to illustrate what's happening: http://meyerweb.com/eric/css/discuss/examples/kyle-lineheight.html (Note the images are twice the size of the original test case, in order to make things a little more obvious.) In #1, you can see how line-height is applied to the boxes in the line of text. The orange-backed bits of text have pink line height space above and below. What's happening there is that the difference between the 'font-size' and the 'line-height' is split in half and added to the top and bottom. So 24px 'line-height' minus 16px 'font-size' is 8px, which is split into two 4px chunks. That adds 4px above and 4px below the font. The cyan span in #1 doesn't have any pink because the difference between its 'font-size' (24px) and the 'line-height' (still 24px) is zero, so there's nothing to apply above and below. The text boxes don't align, though, because the text is all vertically aligned on the baseline, but the baseline in English (and many, many other languages) is not vertically centered on the letterforms. It's much closer to the bottom of letterforms than the top. So the boxes, though each is 24px tall, don't have the same amount of letter-and-line-height space above and below the baseline, and thus when their baselines are aligned the boxes don't line up. In #2, the overall line box has been filled in with a cornflower-blue-like color, just to make clear that the line box encloses all of the boxes within it. In this one-line case, that overall line box defines the content box of the element. You can see how it fills in above the orange text but below the cyan text. If you want crawl really deep into the inline layout weeds, feel free to head over to http://meyerweb.com/eric/css/inline-format.html. Please note that I am not liable for any glazed eyes or migraine headaches that may result. Now for a couple of caveats. The first is that different fonts have different baseline placement with respect to their letterforms, so just because your testcase shows an extra 1px of height, with another font face there might be two or three or five extra pixels of height. The second caveat is that even if the same font face is in use, font rendering is dependent on both browsers and operating systems, and can vary by a pixel or two from one user agent to another. For example, I saw the boxes in Philippe's testcase as being 16px and 24px tall, even though he saw 17px and 25px. On the other hand, once I filled the line height and overall line box colors into my example images, I got an overall box that indicates a 26px-tall line box. In other words, it shows an extra 2px of height, not the 1px you saw, Kyle. This stuff happens with fonts. It isn't random or inexplicable, but like I say, I don't have anything like the knowledge required to explicate it. All I know is that, even with my limited grasp of how text lines get constructed, I'm faintly astonished that pages full of text get rendered at all. Anyway, hopefully all this has illuminated some of the corners of this topic (plus your testcase) without damaging too much of your sanity. -- Eric A. Meyer - http://meyerweb.com/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
