After I replied, I got quite a bit of feedback. Hixie explained himself a bit more and pointed me in the direction of a few things in CSS 3. Nothing startling. He confessed that he agreed that CSS may require some extra bits. The problem is that the layouts desired are not simple to specify and nobody, least of all me, has gone far towards solving the problem of condensing the required knowledge into syntax.

Then a proposal from academia for a system called Constraint CSS emerged. In the proposal the authors discuss the additions of rules that describe relationships mathematically. For example, that the first column in a table should be twice as wide as the second, with syntax something like:

#col2[width] = #col1[width] * 2

It looks like a very powerful system, although I have only read the specification briefly. I asked the WG members to feed back on what consideration, if any, they've given this proposal, how tricky it would be to add to the current specification and how serious the effect would be on browser code. If a proposal for a change to CSS is to be serious, it has to be incredibly easy for the buffoons responsible for IE PC to code. Preferably it should be done for them.

In my last mail to the list I asked the spec people to comment. Ian Hickson (AKA Hixie) of Mozilla did. Hixie is one of the specifications group and standards QA for Netscape. He's also an implementor and is really one of the browser big guns right now. However, he said nothing more than that CSS has tables, a cop out!

Tables are good for some things, but in complicated layouts they get nasty. Now we have CSS, but we have the same situation. It's good, but decent layouts are too complicated to build. A rock! A hard place! Which way to turn? In the last year I've solved most problems by using both systems, which is silly and rapidly going out of date.

Coises says:

Designers want and need control, but /not/ at the pixel-engineer level CSS2 so readily provides. We need control at the /logical/ level

It's the relationships between blocks which are difficult to express in CSS, but the ability to define these relationships is what makes tables such a great tool for displaying changing content in a diverse range of environments, the core task of web design.

I just replied to www-style quickly explaining my plan, the same content as the previous post but-one really. I got one reply almost straight away:

Just FYI I completely agree with you. Other than inconsistency across browsers, tables are a great layout mechanism - easy to understand and very powerful. I think that the CSS designers saw the "misuse" of tables and threw the baby out with the bathwater. If you simply renamed the TABLE tag to LAYOUT, you'd have a simpler, more powerful, and more familiar tool than CSS layout and no semantic or accessibility issues.

This expresses something which I agree with but hadn't put down in writing. Sometimes, grids (AKA tables) are a very simple and powerful tool that CSS doesn't provide. The main problem with trying to do things the CSS way is that often the content needs to jostle with other areas to be laid out properly. It's those relationships that absolute positioning can't express, but tables do with ease.

Blocks with pretty graphical borders.

Often you see content managed sites that feature content split up into multiple blocks. The chief example is probably the weblog. Many people like to put nice graphical borders around each "portlet", but this requires tables or a whole bunch of CSS faff. The gist is simple, a particular graphic at each corner and then others that scale either vertically or horizontally to fit the sides, the sizes of which are dictated by the content.

An example would be the portlets down the left of Amazon's front page or the content areas on The Forum's site (one of mine).

This problem distills down to a more fundamental one: the problem of arranging one piece of content at the left side of a block and another at the right. Another example would be a toolbar that has navigational links on the left, and displays the time on the right. This is a doddle with tables, but in CSS, the float property isn't powerful enough and wasn't really designed for the task. As usual you can go a long with absolute positioning here, but it's usefulness begins to break down as you start including more complex content in your two regions.

← previous page, next page →

Choose another page: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113 or return to the most recent entries.

Last updated at 11:32, Wednesday June 18th, 2008. All times are shown in 24-hour clock format and are BST.

Rate my journal on bloghop.com: