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?"

I'm sure the naysayers will be here shortly

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 [csszengarden.com] 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 [amazon.com] ) 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

. CSS Zen Garden [csszengarden.com] should stand as solid proof that CSS works

No, it doesn't. Seeing as web programming is my job, I can tell yout that tables - horrible as they may be - make a better layout tool than CSS. I can't tell you how many times I have to tell graphic designers that one of the elements of their design (like equal length columns) is a major pain in the neck to implement in CSS. Of course, IE's horribly buggy CSS2 support doesn't help, but there are so many things in CSS that seem - well - stupid. CSS was designed around an idealistic view of the web - a web where pages were designed by web developers. In the real world, this is rarely the case - it is the graphic designers who lay out the page, and the web programmers get stuck trying to implement their design. CSS utterly fails in that regard.

Sure, you can make a design that works well using CSS - zen garden and countless other sites prove this. But there are so many things that were simple with tables that become unnecessarily complex with CSS.

Most developers simply give up and resort to absolute positioning or nesting

tags. Neither is substantially better than the tables that they replaced - and in many cases, they are substantially worse.

There are other elements of CSS that are utterly stupid. Why should padding be excluded from "width"? Or, for that matter, the border? Why is it so hard to make equal-height columns?

Is CSS better than what it replaced? In terms of element style - borders, fonts, colors, etc. - it's substantially better. But CSS sucks at layout.

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

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

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

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.

Whatever is next ...

Slashdot will adopt in 5 years ... ;-)

rounded corners

and the long wait for CSS 3.0.

Simple answer

What's next?

XHTML2 [w3.org] and CSS3 [w3.org]

But XHTML2 can't be a reality until IE can parse XHTML, or IE loses a lot more market share. (no, it can't, it can parse pretend XHTML that's served as text/html, and you can't serve XHTML 1.1 or XHTML2 as text)

ok....

if slashdot links itself in a story, then does it cause a /. effect on itself? seems like an endless loop of pain.

how about browser standardinzation 1.0

The main reason CSS has taken off is that one can feasibly write one sheet that mostly works in the mainstream browsers.

Back when one had to code for multiple versions of IE with poor CSS support it was just easier to hack together a mix of HTML layout and some inline CSS embellishments.

IE7 still has some significant CSS issues, but we're getting much closer.

Imagine when IE8 and Firefox 2 both support CSS3 nearly identically!

CSS

CSS is more than just web. It's XUL, it's XAML, and it's Boxeley(For all those AOL nerds out there). It's also in several smaller toolkits, and it's starting to pop up kinda everywhere. It's a good thing.

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

First, let's get a couple things straight:

• AJAX is the functional foundation of Web 2.0. Sprinkle in a design philosophy that actually embraces whitespace and non-miniscule fonts, and primitive machine to machine communication, and you get the rest of the "trend".
• HTML has been deprecated for six years. XHTML finally got rid of HTML's quirky syntax and bad semantics.

What's next won't even be achieveable for two to three years. The other browsers will continue to implement standards as they are drafted while IE continues to struggle with catching up to 1998, much less 2006. This involves several elements:

CSS3: This is the next generation style and layout methodology. Even though some properties will behave vastly differently from their 2.0/2.1 versions, the vast amount of new properties will entice designers with the possibility to do more (gradients, shadows, masks, text rotation, and more). Because, as Daniel Glazman blogged months ago, CSS has no verioning mechainsm, designers will be able to pick and choose what they want to use.

XHTML2: This is the next generation for web page markup itself (the canvas to the paint of CSS). Further steps towards semantic bliss include semantically-relavant tag attributes, more versatile workhorse attributes (add href and src onto any tag), and a more streamlined namespace.

XHTML2 has some competition, however, in the form of HTML5. While I can understand frustration at the glacial speed of the W3C at producing new documents, WHATWG seeks to damage most of the progress made since HTML 4.01. Apparently "tag soup" becomes an option again, which means few people will bother to write valid, correct pages (a key element for machine readable content to work).

The canvas element and SVG bring new ways of displaying graphical stuff to be interacted with. XForms will finally allow data input to happen in a non-archaic way.

And when this all happens, the table layout trolls and Dreamweaver monkeys will be two tech generations behind. More work for those of us who have real skill.

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

HTML has been deprecated for six years. XHTML finally got rid of HTML's quirky syntax and bad semantics.

That's funny. Because XHTML is a carbon copy of HTML 4.01 as a dialect of XML. All that got "cleaner" is that XHTML uses a subset of SGML (XML), where HTML is a SGML dialect.

The semantics of both are totally the same. You've been brainwashed.

XHTML2 has some competition, however, in the form of HTML5. While I can understand frustration at the glacial speed of the W3C at producing new documents, WHATWG seeks to damage most of the progress made since HTML 4.01.

W3C says "do as I say". They can't even implement what they recommend properly. They tried, with Amaya, and the project is now dead (not to mention it was always one buggy and slow piece of software).

WHATWG catters to the needs of the web developers and web users TODAY. They are formed by browser makers and web developers who have feet firmly planted on the ground as to what constitutes a semantic and functional web we can actually use.

W3C unwillingness to cooperate brought us the table hacks, and now the CSS hacks. We, web devs, always have to use "hacks" of some sort, not just because of bad browser implementation, but because if plain defunctional standards..

Then come zealots who claim W3C can't be wrong, refuse to join a discussion and declare WHATWG is a bunch of terrorists who want to blow up the internet.

Good thing is, while zealots are pretty vocal, the rest of the practical folks are quietly working on making a better Internet with WHAWG.

The canvas element and SVG bring new ways of displaying graphical stuff to be interacted with

The canvas element was invented by Safari and incorporated in WHATWG's HTML5. I though they work hard on wrecking the Internet?

the table layout trolls and Dreamweaver monkeys will be two tech generations behind

The current generation of Dreamweaver produces strict XHTML with CSS based layouts. I bet ranting at fukll power didn't leave you time to see how the world around you adapts to changes.

Absolute positioning makes things much worse

I'm totally fed up with absolute positioning. That was a terrible idea. It was a bad idea in TeX, it was a bad idea in PostScript, and it is a bad idea in CSS. Now font width assumptions are built into the layout. We have text that runs off the page boundaries, buttons that move when clicked [tribe.net], and browser-specific dreck in the page markup. Giant step backwards. Tables were a good feature and they need to come back.

"A good carpenter doesn't blame his tools"

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.

2 things that would make CSS truly God

1. Out of the box, decent browser support for non-square shapes without work-arounds. In the case of IE, any support at all would do. In the case of Firefox, cleaner support (particularly anti-aliasing), plus a wider range of shapes (nothing against rounded corners).

2. Proper support from IE for PNG transparency, or an equivalent format that everyone can accept. No workarounds. The ability to do 24-bit color layers with alpha would be a huge leap forward in design. In fact, it looks damned good when done in Firefox.

These are the two things that make me shake my head. PNG support, because it's just MS being stubborn and dumb. The non-suare thing because I'm not sure how long designers have to develop workarounds before the industry just makes the workdarounds out-of-the-box features.

Why is this under programming?

HTML is a markup language; CSS is a stylesheet language. Neither is a programming language.

IE digs, Firefox, and Safari

I've recently done a load of cross-browser Web 2.0 stuff. Working on a Mac my primary platform is Safari which, as many will know, is one of a very limited number of browsers to pass the ACID test. It took me quite a while to get to grips with the idiosyncrasies of CSS itself (the specificity rules about which style will be used can be confusing and slightly counter-intuitive sometimes) but generally working with Safari was fine.

I checked and validated my HTML and CSS code against the W3C validation tools, and they all passed, which was nice. The next step was obviously to make sure that they rendered well inside IE and Firefox... This is where the pain began.

There are bugs and omissions in both IE and Firefox's CSS support. Quite how bad these failings will affect your page depends a very great deal on what HTML and CSS you are trying to use.

Personally I found it consistently easier to work around the failings of IE; I could get my new bits of HTML and CSS to work perfectly in IE with only minimal changes.

Whilst the reputation of Firefox is better, I consistently found it much harder to get my pages working properly. Trying to get items to display on the same line inside Firefox without getting forced below the preceding item can be incredibly tough, often requiring a custom work-around. In one case I found myself forced to throw away my (div using) code and re-write it using tables, since even after several hours of trying I couldn't get Firefox to render my page acceptably.

This seems like a good page that outlines the bugs in Mozilla/Firefox:
http://www.richinstyle.com/bugs/mozilla.html [richinstyle.com]

Unfortunately there's not always clearly documented work-arounds for these bugs...

Oh for the bright future when all the browsers properly support CSS... The life of a cross-browser web site producer would be less painful.

Recommended Text

I'm interested in expanding my CSS skills, and to be fair, IE did drive me close to insanity.

I made the daft mistake of building a website on a linux box with Firefox, then testing it with IE afterwards. I definately recommend checking with the big three browsers at all times.

I also bought a really good book,

"CSS MASTERY
Advanced Web Standards Solutions"

by Budd, Moll and Collison. ISBN 1-59059-614-5 (www.friendsofed.com)

I've found it far more useful than w3 schools website - if only because it has dedicated chapters detailing the cross browser issues. My only criticism is that it seems to cover everything but fonts. I know it says Advanced in the title, but a very small chapter on fonts would really make this book feel complete. Still, I'd definately recommend it to people who are still using table based layouts.

OT: Good CSS Reading?

Slightly offtopic, but can anyone suggest some good reading on CSS Centric design? Also, what practices should a good web dev put into place in a modern website? Thank you.

CSS help

Since we're talking about CSS anyway, maybe somebody could explain to me what happens in IE with the following CSS:

  div#left {width: 4em; height: 1.5em; float: left;}
  div#right {width: auto; height: 1.5em;}

IE renders them next to each other and on the same line (as intended), but there's a ~4 pixel gap between these two boxes. I checked margins and borders, that's not the problem. To fix it, I placed these two into another div with the background, but that for some reason seems to screw up Opera/Firefox. This wasn't hard to deal with since I generate the pages with perl cgi, but I don't like the unnecessary complication. I did look through a lot of IE-specific CSS bugs, but couldn't find anything. Maybe it's a feature and not a bug, in which case I still need to get it to render the way I want it to. Thanks.

I'm trapped in /.'s CSS theme & I can't get ou

I'd post this on the "omg ponies /. redesign" thread, but it's closed.

What can you do if you don't much like /.'s new CSS? I mean, it's okay for the most part, like a new haircut. It doesn't turn Helen Hunt into Jessica Alba. But the part that I don't think I can live with long term is the switch to Verdana from Times. Say what you like about Times -- and the most wounding thing is perhaps "it was just the default. So that font is called 'Times', eh?" -- it's a remarkable print typeface and I got used to seeing /. in crisp serifs and authentic italics over the past decade or so.

Laugh if you will but I am finding it subconsciously hard to take /.'s bland sans-serif content seriously and it has even made me reluctant to post in my journal (and guys, there are some lingering bugs too. Try the <I> tag in a journal entry?) I need to switch to a serif font, at least. What's the easiest way to do this?

Actually there are other things I think could be improved in the new CSS (introducing a couple more colour accents would be very practical) but that's for another time.

Something which bugs me about the W3C

I don't understand why they don't procure reference implementations of their standards to go with them, like tomcat is for servlet containers. Oh I understand why they didn't chose to do that at the beginning, because the internet has been built on specifications like that. But it's not like implementing an FTP or SMTP server, it's way more complicated and it seems it's very hard to get right, and nearly impossible to get right for every browsers at a given time. History has proven that, so maybe it's time to try another method ?

I think it would make things so much simpler for everybody, especially if they used firefox or another free (freedom) browser as a base. Maybe it would force others to fill the gaps.
In fact in my perfect world they'd just code a friggin good xhtml/css engine, make binding for x languages, and provide it for free to every browser maker or whatever... Seriously, I know it won't happen, but it would be such a step forward for the web in general.
Choice is good, competition is good, but not in this particular area. You'd still be able to chose between a lot a browser, but their rendering would be consistent.

Welcome to 2001!

Slashdot not using CSS was the equivalent of someone still using an Amiga in 1999. It's not an indication of anything except Slashdot being waaaay behind the curve. CSS as been *the* way to go for a long time now.

XML

Well I sure hope the next step is replacing HTML with XML and having everyone use both CSS and XSL for formatting.

Re:My web speaks with a Lisp

Sex Press Ions? You just had to bring porn into this didn't you.

Re:Just a question...

xsl. php. shtml.

Re:Just a question...

Formatting could go in css, data in the html (or links to it anyway) and page layout in a third document (lss?). Are there good reasons why this is a bad idea?

It's a bad idea because the "page layout" would only be useful for one audience, probably sighted users. The blind using screenreaders and those using semantic markup processing tools would not be able to use the page. The current situation is good: one file with semantically meaningful data, and a choice of different CSS stylesheets that could be applied to it, depending on what sort of browser the end-user is browsing with.

Re:My web speaks with a Lisp

Well, we already it. After all, XML is just Lisp with the parentheses replaced by brackets (okay, not entirely true, but close).

Re:I love css

Troll??

Stick the CSS in a file and use it as your browser's custom CSS file. (hint: ad-free slashdot..) And actually, while we're here, let's refactor a bit:

div#advertisement-title, div#advertisement-content {
display: none;
}

div.ad1, div.ad2, div.ad3, div.ad4, div.ad5, div.ad6, div.ad7 {
display: none;
}

Re:Just a question...

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.

It's a feature!!!

If you're using Firefox look at this very page and you'll see why HTML/CSS is divided the way it is. Start by turning off the CSS and you'll see that all the links and text show up neatly and cleanyly formated. It's not PRETTY, but all of the information on the page is there and fairly readable too. What you're looking at is the RAW HTML. The Div tags keep groups of meaningful items together rather than just using P tags as fillers.

The other effect of proper Divs are AJAX related. That's what allows scripts like Greasemonkey and all the Google Maps mods to work... A page written by somebody else can cherry pick interesting data by Div tags rather than formating. Also, look at print preview for a different CSS applied to the same HTML to make a neatly printed page rather than the usual chopped up junk you get when trying to print Table/Frame based pages that waste paper for headers, or chop off the meaningful parts of the page because the decorations make a mess.

MOD PARENT UP

I was about to post exactly the same thing.

And apparently I'm on some kind of mod point blacklist, I haven't had mod points in months.