My CSS3 Wish List

Whether you frame the argument as “divs vs tables”, “tables vs pure CSS” or whatever there are some strong opinions out there. I’m all for the idea of semantic markup. The problem? There are some things you can do (sometimes trivially) with tables that with CSS are:

  • not compatible with IE6 (or even IE7 potentially);
  • done with a fixed or partially fixed width layout but can’t be done a liquid layout;
  • approximate facsimiles but have cases where they break down (eg if two side-by-side floated divs are too wide for their container one will drop below the other); or
  • just downright impossible.

But rather than rehash that debate I simply want to put up my list of what I think CSS3 needs to be able to do. More importantly, it needs to be done trivially.

1. Vertical Centering in Fixed Height

Vertical Centering in CSS, with it’s relative+absolute+relative positioning with three nested divs is a prime example of a non-trivial equivalent to “vertical-align: middle” on a table cell.

2. Vertical Centering in Variable Height

The previous technique can be applied to this problem too but things start getting messy and some trivial cases start to get hard.

3. Fixed Column Layout

Any number of fixed-width columns can be done trivially with “pure” CSS. The standard technique is to use floats. There are two problems with this technique (compared to tables):

  1. If the content in one of the columns stretches it, your “columns” can drop off below; and
  2. There is no automatic equalization of height. You can give each column a fixed height but one of the beauties of tables is that all cells in a row automatically have the same height.

CSS3 needs to do better.

4. Liquid Column Layout

A frequent question on the Web is people wanting a “pure” CSS solution that will have a fixed column (on the left or right) with the other div taking up the remaining space, making this a liquid layout.

The standard technique alternative to a table with one fixed column is to use floats and negative margins, which is rather unintuitive.

5. Full Window Height

Again this can be done but to get cross-browser support you have to use the right combination of CSS attributes on the right elements. It just needs to be easier.

6. Fixed Height Header with Full Window Height

The standard technique for this seems to be absolute positioning of the header and adding padding to the top of the content or columns so they’re properly 100% height. We need a more intuitive solution.

7. Variable Height Header with Full Window Height

For example, How can I convert this table based layout to CSS? demonstrates a trivial table-based solution to the problem of full height where the header height is unknown. I’ve seen no adequate CSS solution to this problem to date.

8. Sensible Numbered List Styling

It still astounds me that HTML then CSS only provided one way of styling numbered list items (ie “1.”). Particularly because other variants are arguably more common (eg “1)”, “(1)”). I’ve seen so many pseudo-lists rendered with tables to get around this problem (floats and negative margins should also work). This one I consider to be a particularly bad use of tables but there it is.

Oddly, the solution to this seems to be Generated content, automatic numbering, and lists. Having counters I guess is useful for chapter headings and the like but it’s completely overkill when all I want to do is style a list item. We need better.

9. Sensible Column Spacing

This is another one that just astounds me that it’s still a problem. Going back to HTML 3.2 up to the present day, there are various methods of putting space around, say, table cells. The problem is that all these solutions ignore the most common (in my experience) use case for tables.

Let’s say I need a table with 7 columns. I want that table to be the full width of the container. I just want a gap between each cell in each row. Using margins or padding I’ll end up with extra space on the left and/or right where the cell doesn’t go quite to the edge. The current solution for this is to treat the first or last cell different by adding a class to it or using inline styles.

Now with CSS3 this will get easier thanks to the :last-child and :first-child pseudo-elements but honestly, why can’t we just have a CSS attribute on tables that controls the space between cells putting space to the far left and far right?

10. Related Variable Height

Tables give you for free the ability for cells in the same row to have the same height. We need to be able to tell the browser that two (or more) cells will have exactly the same height without specifying a fixed height.

Suggestions of using display: table-cell (when supported widely enough) raise the inevitable question: well if you’re using table layout anyway, how is a div with table-cell display any better than a td?

11. Related Variable Width

Imagine you’re producing a report of some kind that has a number of tables on it. Those tables show essentially the same type of data but you might have one table per state, for example. Generally speaking you want those tables to have the same cell widths. The only way to do that currently is to give each cell a fixed width. This isn’t particularly flexible and if content in one table stretches the cell width the whole system breaks down anyway.

One (nasty) workaround to this is to generate the entire report as one table with, say, 7 columns (assuming the table per state has 7 columns). The table has no borders. The content in between the “tables” is merely a single row of that table with a colspan of (in this case) 7. That way the tables will layout exactly the same and can be variable width too.

CSS3 needs to provide a better solution for “related” layout like this.

12. Anchoring Blocks to the Bottom of Containers

Place content (particularly floats) at, say, the bottom right of a container is a real problem.

The Elephant in the Room

There is a lot of talk lately about CSS3 and HTML5. What we seem to be ignoring is that we’re still supporting IE6 and probably will be for at least a year or two more. To get HTML5/CSS3 support we’re looking at Chrome 4+ (3 partial), FF 4+ (3.5/3.6 partial) and IE9+.

How long will it be before those browsers (which mostly don’t exist yet) account for over 90% of users? It’s no wonder the HTML5 roadmaps goes out to 2022. So does any of this matter? Won’t we simply be developing against HTML4 and CSS2(ish) for years to come?

Conclusion

I see a lot of talk about “cool” features like animations in CSS3. Personally I wish the W3C CSS working group would spend a bit more time dealing with real problems that cover common usage patterns.

But then again, even if they do, will it even matter?

6 comments:

Anonymous said...

Yes, absolutely!



P.S. Looks like you're missing a closing tag somewhere because your bold goes on for too long.

alexwy said...

Great post. I agree with most of the things here. I like the challenge of trying to make CSS do what are trivial with tables. However, as a paid employee, telling my boss "It should be done like this but there is no different visually though it will take me a while longer" is often a reason why people go with tables.

Out of curiousity, how would you propose the equal height's CSS property might look like?

smerickson said...

Amen! I have had exactly the same feelings about the recent talks around HTML5 and CSS3. The features in your list would be so much more useful to me than all of the bickering about silly issues.

Mark Rushworth said...

*sigh* if you think support for ie6 will be limited to a couple of years then your sadly mistaken... i fear its going to be around for a looooong time as long as corporates refuse to update their IT infrastructure to the new free browsers

fantasai said...

3 & 4. Use display: table-cell; on two adjacent elements to get them to behave as you want. The only substantial criticism to this method (other than lack of support in IE<8) is that you can't reorder the columns. But it is as good as tables, without the markup pollution.

5. A new unit called 'vh' will make it possible to say 'height: 100vh' and have that mean 100% of the viewport height. This is part of the CSS3 Values and Units draft.

6 & 7. Combine solutions for 3, 4, and 5?

Anonymous said...

I'd like to have a pseudo-classes for

img:alt
(when the image is either not loaded yet, or there is another reason for the image not to show up)

element:loading
(children of this element are not yet completely loaded)

td:hover::td_in_column
or
td:column_hover
(hover effects for table columns)

or alternatively
table ::tcolumn:hover td
(treating table tcolumn as virtual containers containing all tds of that column)

advanced:
table ::tcolumn:hover tr.odd td
table ::tcolumn:hover tbody.section-i td
table ::tcolumn:hover tbody.section-i:hover td
(affecting only the tds in the specified tr or tbody. the tbody is not a child of the virtual ::tcolumn container, ::tcolumn just works as a filter on the tds.

But for the "elephant" I think it will be a long time until it dies. I wonder if M$ can't make some kind of auto-update that would kill ie6 on older windows versions?

Post a Comment