This site is designed for accessibility. Content is obtainable and functional to any browser or Internet device. This site's full visual experience is available in a graphical browser that supports web standards. Please consider upgrading your web browser.

Inline Layout Foundations

How are text elements constructed?

All of the element's content, added up, determines the height of the element, the width is determined through other means. Content is effectively inline; containers like paragraphs are block-level, but some elements (e.g., SPAN) are also inline.

How does all this add up?

Every text element is a series of lines of text. Every line of text is a series of letters and (potentially) images. In the simplest case, the basic unit of a line is the character or embox. A line of text (any line, but assume one in the middle of a paragraph) is constructed of a series of boxes. There is the content area of each element or anonymous box, and then there is the inline box. The two are not guaranteed to be the same. Let's take a 'span', for instance.

Consider:

blah blah
<span style="line-height: 120%">woo hoo</span>
blah blah

Let's assume the parent element of the 'span' has a font-size of 10px. That means that all the text in this line is 10px tall. The anonymous boxes to either side of the span (one on each side) and the 'span' text thus all have content areas 10px tall. The anonymous boxes also have inline boxes 10px tall, assuming a line-height of 100%, but the span's inline box is 12px tall. So it will push lines of text before and after the line away from this one. That's because the line box-- which is what gets stacked with other line boxes, is determined by the height of inline boxes. NOT content areas.

Here's another example:

blah blah
<span style="font-size: 200%; line-height: 10px;">woo hoo</span>
blah blah

The 'span' text will be twice as big as everything else in the line, so its content area is 20px tall. However, the inline box is still 10px tall, although it no longer lines up with the other inline boxes in the line. (Explaining why this is so requires diagrams, and ideally physical models one can move around. It's way beyond the scope of this page.) Given these factors, the actual "woo hoo" text is very likely to overlap text in adjacent lines. This is all going somewhere.

Now let's replace the 'span' with an 'img':

blah blah
<img src="woohoo.gif" style="height: 20px;">
blah blah

With replaced elements (like images) the inline box is coincident with the content area. The only way to change it is with margins, padding, and borders-- and with negative margins, you can make the inline box of a replace element shorter than the content area. So far so good? Great. Because here's where it gets fun. According to CSS2, the borders of an inline element are drawn around the content area... not the inline box. Thus, if we draw a border on the image, it will go around the outside of the content area. If we draw it on a 'span', it will bound the content area. Of course, if the border goes around the content area, then the background goes within it. And while you can add padding to increase the size of the content area, this does not actually change the size of the inline box.

Therefore:

blah blah
<span style="font-size: 200%; line-height: 10px; padding: 5px; background: red;">woo hoo</span>
blah blah

Here you have an inline element whose content-area is 30px tall (20px + 10px of padding), but whose inline box is still just 10px tall. If we took out the 'line-height' then the inline box would be 20px tall, not 30px. So consider:

<span style="font-size: 10px; border: 1px solid black;">
blah blah
<img src="woohoo.gif" style="height: 20px;"> blah blah</span>

A border drawn around the 'span' will bound its content area, which is 10px tall. So the image will stick out of the border drawn around the 'span'. If you set a background on said 'span', the image will stick out of the colored/imaged area. If you replace the 'span' with an 'a' element, the same principles apply. Regardless, the line box is still as tall as it needs to be to contain all of the inline boxes within it-- even if the content areas are wildly different than the inline boxes.

For those who'd like to explore all this in terse detail, see Eric Meyer's Inline Formatting Model Summary paper (but heed that warning!). For those with access to Eric Meyer's O'Reilly book, see pages 290-302 for a more verbose discussion of this subject. It can be a brain-bender, no doubt. He spent two weeks trying to get the fundamental points down so that he could write pages 290-302, and he says he spent most of that time either cursing at the monitor or nursing a headache. This stuff is difficult.