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

[CRCulver]

Is this sort of what you are looking for?

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

[Anonymous Coward]

http://www.alistapart.com/articles/holygrail

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

[RzUpAnmsCwrds]

. 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

[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

[Vo0k]

One more problem. I often encounter websites that use CSS where tables would produce about the same results, and with CSS the site runs like a snail. It downloads faster, less markup overhead etc, but if I open 5 pages at once (my habit, see a list of links, middle-click them all to load in tabs, continue reading), Firefox freezes for, like, 30 seconds to render them. MSIE does even worse.

CSS is awfully computationally heavy. Full CSS support would be a hell for handhelds and such. It defines how things should look like, but not what the browser is to do to make them look like that. Computers hate this kind of approach - you demand results but you don't tell how to achieve them. SQL thanks to limited reach, works. Prolog failed a big time. AI is to appear "in 5 years" for last 50 years. And now you tell the computer a set of sometimes contradictory rules and "place this stuff any way you want, not violating these rules".

Writing a full HTML-only, CSS-Free browser for a handheld, one that can render tables and all HTML elements properly but ignores CSS is easier than writing one that reasonably follows the specs of CSS beyond the simple "@mobile" style. CSS pretty much closed doors to fully-featured webbrowsers on handhelds. They will be stuck with crude "@mobile" stylesheets for a long, long time yet, because "@screen" became too complex.

Lock the handicapped in a ghetto, because this way you'll have it easier to provide them with all they need. Don't let them out, because there's a dangerous, handicapped-unfriendly world out there.

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

[iariar]

I haven't used tables for something that wasn't a table of information at all for about 5 years now and haven't had any problems translating anything the designers throw at me perfectly into css'd xhtml. "Only a bad workman blames his tools."

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

[onlyjoking]

There's also no way you can approximate what the CSS float attribute does with only tables

You're right. It's impossible to reproduce all the float bugs with tables.

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

[Mouse42]

Doing your first site in 100% css is HARD. There is just no other way around it. You are going to spend days trying to figure even the most simple things out, and there are going to be temptations to revert back to the easy (not better) table layout. Some will succumb, and some will soldier on and succeed.

Ohhh yeah. It took me two months to figure out my first 100% CSS website (it's kinda wonky in anything other than IE... bare with me, it's one of my first). I had so many restrictions: must fit vertically and horizontally on the page, must look the same in the AOL browser on 640x480 and in IE on 1600x900, and most importantly no scrolling.

But after I did that, I knew CSS pretty well, and today I know it backwards and forwards. In fact, I can design the vast majority of my sites without any browser hacks (although... I do get lazy sometimes and throw in a hack), so I don't know what those nay sayers are talking about with needing hacks all the time.

Anyone who is serious about anything will invest the time that is nessisary to learn the new techniques that inevitably come along. If you don't have time to do it on the job, then take some time to do it on your own time. Take an hour a day to challenge yourself to reproduce a CSS layout - after struggling through that, you'll learn more and be able to apply it to your job.

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

[Blnky]

From actual experience of a web site I am currently designing, I must disagree. The old site used tables for layout and no font tags. The current site was redone with the same visible content, the same visual placements, and css for layout. The size drop for each html file was at least fifty percent. This is a huge reduction for the entire site. This is not an unusual situation either. ESPN.com made the shift from table layouts to css and the result was calculated to be near a savings of 730 terabytes per year. I think you will agree that a savings of approximately three quarters of a petabyte is a significant amount. As an early table layout designer I have found that the shift to css has drastically made things easier and many more things possible. Sure, it was hard at first until I had a good grasp of how to use css, but once I could look at a page and begin to know the css properties needed it became very efficient in both time and space.

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.

Whatever is next ...

[xmas2003]

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

rounded corners

[russellh]

and the long wait for CSS 3.0.

Re:rounded corners

[codered82]

Check out Nifty Corners. Best I've seen.

Simple answer

[kennygraham]

What's next?

XHTML2 and CSS3

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)

Re:Simple answer

[Lance Cooper]

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

ok....

[B00yah]

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

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

[Dracos]

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

[bertilow]

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

What semantic changes happend between HTML 4.01 and XHTML 1.0?

I don't think there was one single such change.

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:2 to 3 more years of the same, then a shift

[suv4x4]

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.

Why CSS xor Tables?

[G27 Radio]

Both parent and grandparent posts make good points. I used to do tables only, but finally got handed the Zen of CSS Design book by a designer and decided it was time to learn. I'm a programmer, not a design guy. I was really impressed with how much could be done with CSS, but like the parent says, CSS sucks at layout. I like the fact that it seperates the content from the style. However, after spending a couple days trying to get a couple pages laid out purely using div tags and CSS, I ended up using a couple tables to get things the way I wanted them. It kinda felt like I was cheating after looking at all the cool stuff people were able to do with Zen Garden, but is it really cheating to mix tables and CSS? No. Use the best tool(s) for the job and your life becomes much easier.

Re:Why CSS xor Tables?

[CastrTroy]

The problem with using tables is that when you make dynamic web pages, using PHP/JSP/ASP/?, that your code has to figure out how to display the content. If you use CSS, you can write the code once, and just have it output the content in a bunch of div tags. Then when you want to change how your site looks, you don't have to go through all your code changing things around. Just change the CSS that says how the content is to be displayed. Tables save time if you are never going to change your design. However, CSS saves time even if you have to change your design once.

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).

"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:"A good carpenter doesn't blame his tools"

[HawkingMattress]

I think people see absolute positioning as the evil, when it's really not.
It's mainly evil if you use it to place the main layout blocks, but once you enter into those blocks it's often very useful to place sub elements by using absolute inside the parent element positionning (i mean by using #layoutblock { position: relative } #layoutblock #logo {position: absolute; top: 0.5em (or maybe even px); left: 0} )
What i mean is that maybe it should not only be seen as the last resort, but also as something which can help your designs to scale the right way. Sometimes you can do without, and it scales, but it would scale more nicely if absolute positioning was used in some key parts of the design. Some designers refuse to see that, because they burned themselves with absolute positioning at first when learning CSS, and kinda fear it because of the consequences it can have when used at the page layout level.

Re:I love css

[Nested]

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...

[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.

It's a feature!!!

[mabhatter654]

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.

Re:CSS help

[Tteddo]

IE treats width as min-width, so your width entries are treated as a "suggestion" by IE.
Here's a great article that explains all the width quirks and ways to fix it:
http://www.communitymx.com/content/article.cfm?pag e=1&cid=CC96C

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

[Da Stylin' Rastan]

Do it yourself then. I'm not huge about the new redesign, but I was about one of the contestants, so I simply use the Stylish plugin to apply that stylesheet to the page. That's what User CSS is for. Stop bitching and fix it yourself :)

Something which bugs me about the W3C

[HawkingMattress]

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.