Empty Inline Elements
See CSS2, section 10.8.1.
If you have any comments to make regarding this test, e-mail ian@hixie.ch.
- Prerequisites
- Browsers that are subjected to this test should support CSS1,
and especially multiple keyword classes.
1. Simplest Case
Empty inline elements still affect line-height calculations. One
of the lines below should have a larger line-height for no visibly
apparent reason.
This is a lot of text with a line-height ratio of
1.0 and a font-size of 13 pixels. This means lines should be 13 pixels
high, exactly. Please make sure that this sentence ends on at least
line two. Thanks. It is important that the next bit is not on the
first line. There will now follow an empty inline element. It is...
here: Ok. Now, the line-height of the line in
which that element appeared should be 30 pixels, which is
considerably more than anything around it, so it should be very
noticeable. I hope this text is long enough to spill onto another
line. Lets add a bit more for luck. I hope your window is not too
wide.
Now the same test, but with borders. The result should be the same,
but with some added vertical lines at one point.
This is a lot of text with a line-height ratio of
1.0 and a font-size of 13 pixels. This means lines should be 13 pixels
high, exactly. There will now follow an empty inline element. This
time, however, it has borders and background. It is... here:
Ok. Now, the line-height of the
line in which that element appeared should be 30 pixels, which is
considerably more than anything around it, so it should be very
noticeable. I hope this text is long enough to spill onto another
line. I presume that a weird border should be visible too, as a
vertical triple bar, with the middle bar double the thickness of the
other two. The bar should be around 30px high.
2. Special Case
As described in the collapsing element
test, empty P elements should be totally ignored. There should be no gaps
or anything weird below.
This is a lot of text with a line-height ratio of
1.0 and a font-size of 30 pixels. This means lines should be 30 pixels
high, exactly. There will now follow an empty P element, with display
set to inline. It is... here:
Ok.
Now, the line-height of the line in which that element appeared should
be in no way affected. Nor, in fact, should any break of any sort
appear, or anything weird. There should be strictly no symptoms of its
existence. Not even the border.
That was with an inline P, but what about a block level P? The spec
says to ignore empty Ps... Again, this test should
just be a solid block of text. No gaps/borders/color/anything.
This is a lot of text with a line-height ratio of
1.0 and a font-size of 13 pixels. This means lines should be 13 pixels
high, exactly. There will now follow an empty P element. It is...
here:
Ok. Now, there should not have been
any breaks of any sort appear, or anything weird. This is all one long
piece of text. No big lines, no gaps, no borders, no breaks,
nothing.
Mozilla developers refuse to
correct this particular bug. I don't suppose it matters too much,
as empty Ps in between inline text, which are already frowned open by
the spec, are unlikely to appear in documents written by authors who
actually mean them to dissappear altogether in the fashion described
above. Never mind.
3. Trailing Whitespace
There is the weird problem of trailing whitespace. If an element
has a space at the end, and the space wraps to a new line, then
clearly that line should not start with a space. But also clearly, if
the newline is "inside" the element, before the space, that means that
the inline element spans onto the next line, and thus things like
line-height should affect the next line. That is probably not a good
idea.
(extra text) (extra text) (extra text) (extra text)
(extra text) (extra text) (extra text) (extra text)
(extra text) (extra text) (extra text) (extra text)
(extra text) (extra text) (extra text) (extra text)
There now follows a strong element, with some
spaces at the end. Resize your browser window so that the strong
appears at the end of a line. STRONG
The line below (probably this one) should not be affected by
borders or weird line height, in my opinion.
(extra text) (extra text) (extra text) (extra text)
(extra text) (extra text) (extra text) (extra text)
(extra text) (extra text) (extra text) (extra text)
(extra text) (extra text) (extra text) (extra text)
Resize your window horizontally until the STRONG text is at the end of
the line, but the space would flow onto the next line.
In my opinion, the trailing space should be lost, and the STRONG
should be bordered on all four sides. Technically, if the space is
converted to a line end, and the STRONG ends on the next line, even
with no content, then the border should end on the next line. This
would look stupid, though. Opera 3.51 seems to do this
in a sensible manner (this is not, however, any sort of endorsement
regarding their inline code. I am aware that it is in fact otherwise
quite buggy).
4. Anonymous inlines separated by display:none
Below are several anonymous inline boxes, in a DIV, with a few
other boxes with display:none, which should have no
effect. This does not really belong on this page, but for lack of a
better place to put it...
This text should all
(Should be hidden)
be in
(Should be hidden)
one long
(Should be hidden)
undivided sentence.
The above should have no line breaks in it (except if it wraps at
the viewport edge, obviously!).
Submit Results
Up to the Evil Tests Page.
Bugzilla: Bug 4247 (test 1), Bug 4248 (test 3).
Last updated in May 1999.