A New Era in CSS Centric Design?

byrnereese wonders: "The media never fails to point out how the age of Web Two-Point-Oh has helped to drive the adoption of Ajax into the Internet industry, but rarely does anyone point out that it has also help popularize CSS-centric design practices -- the Slashdot redesign being only one example. But now that we, as programmers, feel comfortable ditching the use of font tags, finally grok div's, understand absolute vs relative positioning, and can work around all of IE's CSS bugs, what is the next step for HTML and CSS? Several standards or conventions seem to be coming to forefront: one is building standards around the HTML structure itself so that wildly different designs can be achieved via style-sheets alone (e.g. CSS Zen Garden and The Style Contest), the other being the standardization of CSS classes (e.g. micro-formats) so that semantic meaning can be derived from the class name we use to label our content. Both show an interesting potential for how this technology is evolving. So here is the question for all the visionaries out there: where is this taking us? What's next for HTML? What's next for CSS?"

Comments

I'm sure the naysayers will be here shortly

[CRCulver]

Every time there is a story on CSS here, we always get a bunch of people who say CSS is useless and that table tags are the only way to design a site. I'm always amused by people who have been living under a rock (or haven't updated their skill sets) for the last couple of years. CSS Zen Garden should stand as solid proof that CSS works, and can produce some gorgeous and highly usable results (and check out the Zen Garden's Zen of CSS Design ) for a description of general aesthetic.

CSS is broken in some obscure ways, I've encountered some limitations with styling elements with a certain xml:lang in documents whose body tag has a different xml:lang, but for 99% of sites, it's ready now.

Re:I'm sure the naysayers will be here shortly

[BalanceOfJudgement]

But there are so many things that were simple with tables that become unnecessarily complex with CSS.

This is why tables were popularized in the first place. The lay-person who just wanted to throw up a personal web page had neither the time, nor the inclination to learn CSS, so they resorted to the easiest possible manner of positioning things the way they wanted: tables.

Creating layouts with CSS was never easy, which has always been exactly the problem.

But there are problems with table-based designs, first and foremost being user presentation, in the form of increased load times for the increased amount of text, AND because browsers can't render the table until the entire thing is downloaded. I have seen some website that don't come up for quite sometime because their entire 226kb layout is contained within a single outer table, so it doesn't show up on the screen until the whole page is downloaded.

The second major problem with table-based designs is accessibility: screen readers for the blind don't like tables very much. I don't know about the newest versions of programs like JAWS, but the ones a few years ago would read every table element, including empty ones that only contained spacer images. Not a very user-friendly experience.

Most developers simply give up and use tables because it's faster. This is ALWAYS the motivating factor in businesses where time is money - and consequently why so few commercial websites are built using CSS. It takes longer to learn. But once you learn it, things that are at first "unnecessarily complex" become easy, just as tables are easy now because everyone does it that way.

"Easy" in the end has less to do with syntax and language, and more to do with how widely the technology is used, because the more people use CSS, the better the documentation for it will be, and the more websites will show you how to do simple things like a 3 column, full height layout (which I know how to do; I have a basic template I always use when starting a new page for this layout, so I don't have to redo it every time).

Re:I'm sure the naysayers will be here shortly

[Dracos]

Whether or not tables are a better (I think you mean easier) layout tool, they are not meant to be used for anything other than (gasp) tabular data. Using a table for anything else is bad semantics, page bloat, and, let's face it, primitive.

In the last three years, every site I've attempted to rebuild in CSS from tables I've been able to do with 90% accuracy. It's not only a different layout tool, it's a different layout model. You can't expect tables to CSS to be a 1:1 conversion, there will be compromises along the way.

I've been in the same situation with graphic designers. The problem is that they think the web works like paper, where the design is a monolithic entity that simply exists. They have little to no understanding of what HTML and CSS is, does, or how it works. The concept that their full screen 50 layer photoshop file will be chopped up, gutted of text, and reassembled later is entirely beyond them. Long time print designers make the absolute worst web designers, I've found.

Another part of the problem is browser support for CSS, especially the various values for the display property (especially table, table-row, table-cell, inline-block), and the position property. Position is mostly misunderstood, anyway: "relative" is not the default value, "static" is. See my sig for my thoughts on browser CSS support.

Too many people try to wrestle with CSS to make it do what they want. This is most often the fault of a poorly thought out document structure combined with a poor understanding of CSS. Let the document work for you, I always say.

CSS is vastly better than what was before: nested tables full of font tags. CSS is more flexible, concise, and clean. Is it perfect? Not in its current form, but maybe the next version.

Equal height columns are easy: height: 100%;. Too bad IE can't get this right unless you declare the height of the parent element. Hate the implementation, not the specification.

Re:I'm sure the naysayers will be here shortly

[Bogtha]

Three-column layouts are easy.

body {
display: table;
width: 100%;
}

#header, #footer {
display: table-row;
}

#foo, #bar, #baz {
display: table-cell;
width: 33.3%;
}

Tell me that CSS is broken and I know you'll be trolling. We all know it's not CSS that's broken, but browsers. Browsers have bugs. Web developers have to work around them. This is nothing new. Table layouts themselves are one big bug workaround hack. You say you don't want browser-specific hacks in the CSS, but the CSS only has to be written once. I want to avoid hacks in the HTML, which is one of the reasons why I choose CSS layouts.

Re:I'm sure the naysayers will be here shortly

[Bogtha]

Every browser implements tables properly.

Try align="char". Or how about the whitespace-significant bug Internet Explorer has? Or how about THEAD/TFOOT? How many browsers do something with the axis attribute? How about the vertical-alignment "bug" that is actually correct behaviour but breaks up table layouts so that there's lots of little gaps? What about the abbr attribute? Do some browsers still treat optional closing tags as required (not sure about this one)?

Table layouts are buggy too, it's just all the advocates tend to forget about the bugs because they are so used to avoiding them.

Re:I'm sure the naysayers will be here shortly

[Bloater]

If CSS let the user break the page into actual elements that humans deal with, like columns, headers and footers

The blind don't deal with "headers" and "footers". Tools for processing semantic markup don't either.

Neither the blind nor tools for processing semantic markup deal with CSS (not @screen anyway) - they deal with the markup.

CSS should have had operators to group marked up data and style things relative to their place in the group. And it should have had the ability to set constraints on sizes (eg "with (foo) {width + padding-left + padding-right + border-left + border-right} = with (bar) {width + padding-left + padding-right + border-left + border-right}"). So any auto styles in that constraint could be set by the agent to make the constraint true.

I also want to be able to CSS the body to put in a header who's content and style is selected according to the element that I put into the metadata of an article. That can't be done.

I also want to be able to just have 20 paragraphs in a sequence inside an element and give some CSS that splits it into columns at page height with my chosen width - as it is, I have to either add presentation markup, or I have to use pseudo selectors... lots of them... and not be able to split a paragraph automatically like a line gets split - I have to separate the columns at paragraph granularity.

I also want to be able to set rules to be applied to decorate ends of lines automatically when they are added by automatic wrapping, and decorate the start of the next line, etc, so I can give some shell code and have the browser put in the line continuations where appropriate for *their* chosen display width and not mine. And stuff like that.

Instead we have to group marked up data by adding extra presentation markup throughout the semantic markup. That's wrong - and its been years with no hint of improvement.

So they gave us XSLT instead... gee, thanks, that makes it all better...

Re:I'm sure the naysayers will be here shortly

[Metasquares]

The difference is that using the table "HTML hack" is syntactically correct and highly likely to show up properly on all modern (and even many archaic) user agents. Many of the CSS hacks rely on either improper syntax or improper parsing of correct syntax - which means you're disregarding standards on a much more fundamental level than if you had just used a table. You need to get syntax down before you can worry about semantics.

Hopefully CSS3 will make this discussion moot in the near future.

Re:Simple answer

[Lance Cooper]

And considering that Internet Explorer barely supports CSS2, it's going to be a while...

"A good carpenter doesn't blame his tools"

[Assaulted_Peanut]

Like any tool, CSS can be abused. Absolute positioning is a powerful tool that is easy to misuse in WWW environments because it tends to be used with pixel units to create print-centric, rigid designs that can't be scaled/zoomed (e.g. in pre-IE7 browsers, Firefox). Pixels may be great for kiosks and other fixed width/height environments but there're not good for use with current mainstream browsers - but use 'em' and 'percentage' units and you can automatically create designs that resize to the viewport and the user's preferred font size without the problems you describe.

Something I advise developers new to CSS is to avoid using absolute positioning until they clearly understand the side-effects of applying it and to generally treat it as a last resort in the CSS toolbox - kind of like 'if-all-else-fails try the sledgehammer'. With a well structured document as a foundation (headings, lists, et al) then a good understanding of floats, margins and clear can do most layout tricks for you, but if there's no other way but to use absolute positioning then use it with 'em' and 'percentage' units again to keep it scaling. Granted that this is difficult to do if developers use todays WYSIWYG authoring tools - almost by definition.

Not a giant step backwards by any means, developers of problematic sites just need to think a bit more about the best use of the tools in the CSS toolbox and a bit more about designs that scale. After-all, it's possible to create rigid layout problems with table-based design too.

Re:Just a question...

[Jetson]

I can set my page layout using css and html divs but this results in the styling being in the css sheet, the data in the html and the layout sort of strewn between the two with the result that there is no one document I can look at which would give me a good idea whatthe page will actually look like.

I use 4 different web browsers depending on where I am and what I am doing. Very few sites render on all 4 of them, mainly because people assume the client is running on a graphical desktop with a large display area. On my PDA, sites that use nested tables for layout end up wider than the embedded browser can handle and I have to side-scroll to read text or else get
sites
that
run
down
the
screen
in one column of words because the nested tables cause the content to get squished to the point of being unreadable.

CSS allows you to specify layout in such a way that the site can gracefully degrade if the client needs to alter the layout to suit the hardware. That was the point of one of the other posts in this thread - if you use tables then you are using content-description tags as if they were layout tags. The solution is not to have a third file for layout, but to realize that the problem you are having with layout being strewn among several files is an artificial one that would go away if people would simply stop using tables for non-tabular data.

Re:2 to 3 more years of the same, then a shift

[Bogtha]

HTML has been deprecated for six years.

HTML 4.01 has not been deprecated in any way.

XHTML finally got rid of HTML's quirky syntax and bad semantics.

HTML 4.01 and XHTML 1.0 are virtually identical in terms of semantics. You do realise that things like <font> are present in XHTML 1.0, don't you?

What's next won't even be achieveable for two to three years.

CSS 2 won't be achievable for two to three years, let alone CSS 3. Internet Explorer 7.0 will still be missing key parts of CSS 2 when it is released, and it will take at least a few years for enough people to upgrade to that. And a few years after that, perhaps enough people will have upgraded to Internet Explorer 8.0, which will possibly support CSS 2 properly. So we'll probably be waiting until 2012 or so for CSS 2 support, and then perhaps we can start thinking about CSS 3.

The same goes for XHTML 1/2. Internet Explorer 7.0 won't support XHTML 1. Internet Explorer 8.0 probably will. XHTML 2 is something that might not even be implemented for Internet Explorer 9.0, assuming there is such a thing.

Re:Why CSS xor Tables?

[jZnat]

But tables are way, way easier to learn than css layout is.

I think I can speak for most people who have used CSS for a while by saying that once you actually know how to use CSS, table layouts are far harder, tedious, and time-consuming than semantic markup and some CSS. I'd recommend trying to redesign a table-based site (with no tabular content to boot; that's like using a spreadsheet program as an actual database). Oh wait, that might take a while as you have to change every fucking page and deprecated element to match your new idea for a theme. Or, you could edit a single CSS file and have a completely new theme and layout (like Slashdot did).