I’ve been putting off forever on writing an extended treatise on the weaknesses of CSS, ie why people do find working with CSS to be so painful. While that drags longer treatise drags on, one of the tangents it sent me exploring was on the nature of why there were no mechanisms for even simple gridbags type layouts in CSS2 (whereas it was almost intuitive with table layouts). There are no less than 25 Three Column Layouts currently listed in the css-d wiki. Almost all of them have weaknesses/bugs.
Considering that the majority of web sites were constructed with gridbags in mind, it seems almost inconceivable that this issue hadn’t been addressed over the course of creating CSS (a second revision no less). Well, maybe not, considering some of the other fundamental flaws built in… A digression for another day.
This thinking about tables, of course, led me to the obvious. The CSS2 table box model of course, specifies table layouts. Via the display property, one can use table mechanics for semantically neutral container elements. While for some, it may not seem much of an aesthetic improvement, but there are several properties that directly address CSS weaknesses, including:
- Widths – not specified to the Viewport, calculated against minimum content width
- Vertical Alignment – not great, but at least everything you had w/ tables
- Collapsing Border Model
Of course, in the course of preparing this, it occurred that I should probably check how it works in some browsers. A quick check shows that it doesn’t work for IE/PC. [check on laptop – IE/Mac, Safari, Opera] According to the spec, the display property is optional and may be ignored by HTML UA’s.
Using the table box model doesn’t solve the fundamental weaknesses in property specification, block relation, or flow control, but if you’re using a user agent that supports display assignment, it may be a worthwhile avenue to persue as a stopgap.