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:

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:

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:

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.