copyright © CSSPG, last modified February 22 2001

for practical use of CSS
While working on the content of our site, my partner Sue came up with an idea for the suggested rendering of our main index page.
It was to be a two column table-like design with all links vertically left aligned in a left column and a right column, also left aligned, containing a brief description of each link.
Sue made the first attempt to create a page like this and I got interested in her work and started to play around a bit with her creation, trying to investigate the relationship between a CSS and markup based on the DIV element.
I then discovered the practical aspects of something in the CSS specs, namely that a floating element is allowed to "break out" of its containing parent element. This may of course be desirable at times but the thing is that there's no CSS property defined to help suggest an alternate behaviour, should that be required.
My view of this is that it would be good to have a CSS property available to suggest a rendering leading to a full containment of floating elements inside their parent elements. In absence of that, one now have to resort to the use of additional "empty block type" elements to create "dents" in the HTML parse tree that allows for additional CSS suggestions leading up to this type of rendering.
Both IEx and NS4x handled the situation of full containment by default design (although that turns out to be a plain violation of current CSS recommendations in these two). But then I had the opportunity to use one of the earlier beta versions of Opera 3.50, and now the result was very different.
I designed a test page to illustrate the differences in rendering between browsers and posted a question about it at the W3 style list. Håkon Vium Lie replies to this that Operas rendering is the correct one and that the other two are not following recommendations on this.
But he also suggests a mark-up "trick" that can be
used to suggest the same rendering in spec compliant browsers as in the
other two. The "trick" is to include a block level element without content, e.g a DIV element, that at a minimum
should be given a style rule containing...
{ clear: both; }
A plain block level element without content, does not
give raise to the creation of any inline box at all but still keeps its
block box properties available for styling. The fact that there is no
inline element content to be rendered results in a block box that
"collapses" to whatever height that is specified as the browser default
through the margin, padding and
possibly border
properties. A user «--» author style sheet can now cascade
new values on top of the browsers ua.css default to give a visual effect of a "not
existing" block box, leaving only the effect of 'clear: both;' as a visual
result.
This example page shows the "markup trick" in use and
illustrates how to specify nested DIV elements to create an impression of content
arranged as a table of data. You already have the source mark-up
downloaded, since you are reading this right now. The corresponding
stylesheet can be found here...
In all examples below I have specified borders for all
CSS layers to clearly indicate how the nesting of layers is done. I have
found out during testing that it's not fully reliable to take out the
border specification from the style rules, browsers may not be coded to
use acceptable initial values. But a border can be turned off simply by
changing the border-style from solid to none while
still leaving the rest of the border definition in there.
All my testing has been done with Opera 3.62, Opera 5.02, MSIE 5.5+Sp1 and Netscape 4.08, all of them running on my WinNT4 + SP6a platform. I have also noted that my examples gives a fully usable presentation in non-style aware browsers (e.g. Lynx), and not that much imagination is needed to get the info even there.
I have only used text to fill my example "tables" with some content, but naturally nothing prohibits the use of images, possibly mixed with text, either.
This first example is basically the same as what we use
on our main index page, except that the
index page does not have the blue bordered "left floating" DIV elements, but instead puts
the link text left aligned directly in the parent element.
Abra Cadabra Abra Cadabra.
Abra Cadabra Abra Cadabra Abra Cadabra Abra Cadabra Abra Cadabra Abra Cadabra Abra Cadabra.
Abra Cadabra Abra Cadabra Abra Cadabra Abra Cadabra Abra Cadabra Abra Cadabra Abra Cadabra.
Abra Cadabra Abra Cadabra.
Abra Cadabra Abra Cadabra.
Abra Cadabra Abra Cadabra Abra Cadabra Abra Cadabra Abra Cadabra Abra Cadabra Abra Cadabra.
This example should illustrate a more realistic version of a table that actually has some tabular data in it.
1901
Röntgen, W.C.
Germany
1902
Lorenz, H.A.
Zeeman, P.
Netherlands
Netherlands
1903
Becquerel, A.H.
Curie, P.
Curie, M.
France
France
France
1904
Lord Rayleigh
(Strutt, J.W.)
Great Britain
1905
von Lenard, P.E.A.
Germany
Please note that the final rendered width of a "table
cell" is made up from the sum the content, padding, border and margin
widths, as specified for the DIV's that forms the cell.
The stylesheet, that governs rendering of this page, goes to great lengths to assure that all width measures adds up to 100% where ever they should, and it can be clearly seen that only few CSS aware browsers, available at the time of revising this page, do their percentage calculation correct.
In an attempt to push the rendering engines up to some
limit, I decided to try this little example containing some 55+ nested
and floating DIV
elements total, arranged into a matrix.
It turns out that Opera, Mozilla and IE handles this
quite good, while NS4x runs into some quite serious problems due to its
default introduction of uncontrollable vertical white space after <Hx> elements,
and its inherent buggy way of handling width calculations.
Opera also shows off a bit of its usual internal math round off problems in that it misses out on the total sum of percentage specified widths.
But over and all, none of the tested browsers "breaks" while presenting the content. I guess one have to be satisfied with that for the time being.
1
2
3
4
5
6
7
8
9
10
2
4
6
8
10
12
14
16
18
20
3
6
9
12
15
18
21
24
27
30
4
8
12
16
20
24
28
32
36
40
Disclaimer: Not that I particularly "like" the idea of using markup to suggest presentation, but given the current state of the CSS1/2 specs, there is no other way to suggest the effect of a parent element fully enclosing a floating child element.
See HTML source and stylesheet for details.