Note: Due to ambiguities (and differences of interpretation) in the CSS specs, it is not clear whether this test is valid.
This test tests the vertical formatting of inline boxes. It is not meant to be a comprehensive test. It only tests the hardest aspects of the inline box model -- the ones that none of the browsers available today gets right. This test is modeled in some ways after Todd Fahrner's boxacidtest, that is, it only tests the core set of features in a certain small area, but a browser that passes it is likely to handle a larger set of features very well (unless it was written to pass the test).
This test tests only CSS1 properties, although it uses the CSS2
definitions of those properties. Some of the CSS1 definitions were
not clear enough to define a required outcome as definite as this
test describes (mainly the exact meaning of
vertical-align). However, CSS2 does state the relevant
rules, so any CSS2-conformant browser should easily pass this test.
(There was one error in CSS2: the spec fails to mention that for
the purposes of padding, border, and margins, the height of the element
comes from the font-size, not the line-height, so the top of the element
is the top of the font and the bottom of the element is the bottom of
the font. This was stated in CSS1, and I have been told it will soon
appear on the errata list for CSS2.)
In the following div, there should be straight green
horizontal lines, 2px wide, above the first line of text, between all
lines, and below the last line, up to the beginning of the xs. These lines are created by top and
bottom borders, and these borders should always overlap and
should always be straight. (There may be a few gaps around
font size changes.) The text itself should show considerable
variations in font size and vertical alignment. See the reference
rendering at the bottom of the page for an example
of correct layout. Note that font size differences could make the
line breaks be at slightly different places. Also note that if
font-size substitutions are made because a font in a certain size is
not available, the test is no longer valid.
A sequence of ten xs indicates where I expect a line break to be. It's fine if all ten of the xs are on the end of the old line rather than the beginning of the new line, but if anything after the xs is on the old line, then that's a problem. If your browser is showing a line-break somewhere else, but seems to be showing the rest of the test with some accuracy, let me know, and send me a screenshot. If the line breaks aren't where the xs are, then the test results are not valid. Also, please let me know if you find any errors in the CSS, i.e., anything that would cause the green lines not to line up in a CSS2-conformant browser. My email address is dbaron@dbaron.org.
Here's the test repeated, but with the Ahem font, so that it's a valid CSS 2.1 test in addition to a CSS2 test:
The above test should agree with the reference rendering below, except for the exact location of line breaks. Note that the reference rendering has a slight error: all of the fonts are slightly too big, and there is not enough room at the top for accent marks.
The following may also be useful, since it shows edges and padding.
Well, if any browser ever passes the above test, let me know, and I
will write the advanced test. This will include tests of relative
and absolute positioning, background colors and images (and
background-position and
background-attachment, word-spacing, setting of
display to inline, and display: run-in.
Version 0.9: Preliminary draft.
Version 1 (1999-02-02): Original release. Announced on www-style. Changed test so that largest element on each line was anchored to the xs so that the reference rendering could specify where the xs go. (Note: This was done incorrectly, and fixed in version 1.10.)
Version 1.0.1 (1999-03-11): Added second reference rendering.
Version 1.1 (1999-03-13): There was an error in version 1.0.1 of this test. SPAN.fifteen had vertical-align of baseline when it should have been bottom. SPAN.seventeen had vertical-align of top when it should have been baseline. I fixed the test and the reference rendering.
Version 1.1.1 (1999-03-17): The reference rendering was updated. There was an error in the position of the xs on the third line. I had positioned them as if they were uppercase, but they are lowercase.
Version 1.1.2 (1999-03-26): The reference rendering was updated. I made the same mistake in the second line as I did in the third. The error wasn't as big, since the problem was the size of the descenders of the xs.
Version 1.2 (2004-05-11): Added version using Ahem font, since the original test is no longer valid according to CSS 2.1 because the definition of 'font-size' changed.
Thanks to Kipp Hickman (who is doing the work to get Netscape 5.0 to pass the test), Geir Ivarsøy (who is doing the same at Opera) and Ian Hickson for lots of comments.
(Back to CSS Testing Information, David Baron)
