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

[databoing]

You have heard of the tag, havent you? Read up on them. With it, that challenge is quite easy.

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

[databoing]

DIV!! I was saying DIV!!

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

[CRCulver]

Drat. Stiljstek.nl used have lots of great CSS templates, including a three-column one with headers and footers, but it appears to no longer exist. Back in 2003 I pared their three columns down to two to use on my own site. Their CSS worked fine without Javascript, and in Internet Explorer. So, it is possible.

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]

Show me an implementation of a three column layout, with header and footer, without using javascript. In a perfect world, you'd do it without browser dependent hacks too.

The websites I did this for are no longer up, but it's not something I found terribly difficult. In fact, I learned to do almost everything better without Javascript, especially dynamic multi-level menus that are easy, semantically correct (e.g. using ul and li instead of tables and javascript), and stylishly appealing, using about 100 lines of pure CSS.

Problem is, people have just been doing it this way for so long that it seems impossibly difficult to do it any other way. And, at first, it IS very difficult, because it requires a different way of thinking about the page. Once you get past the conceptual hurdles though, it starts to make very good sense.

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

[BalanceOfJudgement]

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

Yes!! That's the article I used quite some time ago to learn to do this! I had long since lost the link, thank you!

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

[larry bagina]

Resize your browser. It turns into a mess as the window narrows. Every 3-column css layout (that I've seen) has that problem. Tables for layouts are horribly overused, but for 3+ columns, css doesn't cut it.

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

[BalanceOfJudgement]

What sane developer relies on a parsing bug in a browser? How easy is that to maintain?

Well, I can't disagree with you there. That part is insane and I hope in the next couple of years we see a proliferation of fully CSS compliant browsers. I mean, that's the whole point of standard in the first place. Even Firefox doesn't fully implement CSS correctly, and I'm not sure why.

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

[kubrick]

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.

When tables were popularised in the first place, Netscape 4 ruled the web. Have you ever tried to use its CSS support?

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

[sco08y]

CSS is broken in some obscure ways

It's fundamentally broken in that it's incredibly arcane. A sane standard would have examined what people actually did in web pages and other layouts and designed constructs that would accomodate those.

CSS gives you a bunch of tags and a "box model" that no one had ever heard of, that is incredibly hard to implement and that bears only a mathematical relationship to what the user wants to do.

If CSS let the user break the page into actual elements that humans deal with, like columns, headers and footers, it would be a good standard. It doesn't, and that's why it's broken.

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

[CRCulver]

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.

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

[Isofarro]

That part is insane and I hope in the next couple of years we see a proliferation of fully CSS compliant browsers. I mean, that's the whole point of standard in the first place. Even Firefox doesn't fully implement CSS correctly, and I'm not sure why.

Full support of CSS isn't necessary for the production of CSS designed websites. It just needs to be good enough - which is where we already are. Its the same as not needing to know every word in the English language in order to have a conversation.

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

[jwkane]

I don't think he (or any sensible developer) would have any problem with using table tags for tabular data, especially data with good headings and captions.

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

[misleb]

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

Then that needs to be fixed.

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

What you need, then are web designers, not graphics designers. As a programmer, you should not be stuck with the task of implementing a design. That is not your job. It should be implemented, CSS and all, for you. And you just plug it into your application/site. Yes, that is ideal. But I can assure you it is attainable. I currently work in such an environment.

-matthew

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]

If you can't do something you could do with tables in CSS without hacks, is CSS really a step forward?

You're forgetting that abusing the <table> element type for non-tabular data is a hack in itself. The real choice is between hacks that appear in the HTML for every page (table layouts) and hacks that appear in a single stylesheet (CSS layouts). When you pollute your HTML, you make it harder to do things like screen-scraping, use user-stylesheets, use Greasemonkey scripts, cache effectively, and so on.

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

[Bogtha]

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'm a web developer too, and I think the exact opposite. Take a look in any bookshop lately. How many books are teaching table layouts these days? How many books are teaching CSS layouts these days? I think it's clear which layout method is preferred on an industry-wide basis these days, regardless of what individual developers like you or I think.

The main reason table layouts are still popular is due to inertia. Most of the people I've encountered who prefer table layouts have years of experience in table layouts but have much less experience with CSS because they keep choosing the layout method they know better. People like that simply can't make a fair comparison, of course they're going to find it easier using what they know best.

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.

Maybe if you started from scratch each time it would be a pain. But surely you figured out how to do it once and kept using that technique?

Why should padding be excluded from "width"?

Because it's not part of the content, it's padding. Don't the names give it away? It's not the width-of-content-plus-padding property, it's the width property.

Why is it so hard to make equal-height columns?

You already answered your own question. It's because one particular company refuses to implement that part of CSS.

There's all kinds of ways in which table layouts are deficient from purely the layout perspective too. For instance, why is it impossible to move something higher on the page? Why is it so hard to remove the gap after a form? Why do lots of little gaps appear in table layouts in strict mode?

The trouble is, most CSS advocates ignore the layout-specific deficiencies of table layouts in favour of other arguments, like the semantic argument or the download speed argument. Why don't you try recreating the CSS Zen Garden with table layouts? You'll find that a lot of the designs are impossible to achieve with table layouts. Not merely hard, not annoying due to browser bugs, but flat-out impossible.

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

[Bogtha]

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.

Actually, table layouts were popularised because most web browsers didn't implement a style language at the time and table layouts were a quick hack to get fancy layouts. CSS didn't exist at the time table layouts became popular. If it had, then I doubt table layouts would ever have taken off.

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

[greening]

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 have to disagree with you here. I've been a web programmer professionaly for 2 years and been doing it on my own since back when PHP3 was a new and cool language (looking back, I get to thinking, why the hell did I think php3 was a good language?). Back then, CSS was still fairly young and didn't have near as much standard support as it does now. Building a website without tables was laughable. When I started getting back into PHP and web programming in general, I picked back up using tables like before. A guy I worked with at my current place of employment showed me how far CSS support has gone since I dropped out of the scene. I was impressed, to say the least (even though the company's websites were all still done using tables). I quickly started learning of the benefits of CSS and using valid (X)HTML. Now, whenever I have to build a website, I have my HTML already written (for the most part) and just upload the necessary files. I then write the CSS and position everything where they need to be (unless the layout is drastically different from others). Using CSS has saved me at least an hours worth of time when starting a website. Then, when they want to redesign, it's just switching out graphics and minor changes to the HTML/CSS. If only my boss could see the time it would save by switching over from tables, instead, they saw the amount of time it took to overcome the learning curve. That's one of the key things that CSS Zen Garden showcases. You can have a completely different site using identical HTML (alot of that is in the graphics the site uses but, still). I find it fun to browse through the Special Effects category of CSS Zen and see just how completely different people make that site look just using CSS alone.

There are drawbacks to CSS. The equal length columns issue and IE are two of the problems. It would be downright awesome if all browsers supported CSS1 and 2 100% but, that would also mean my job would be even less secure. I don't know how many times I've clashed with my boss over the equal columns issue. It got so bad with one site (the site had a bunch of 'boxes' stacked one next to the other) that I had to write an ugly javascript function that would manually size each box based on the largest box on that row.

I've found equal-height columns to be a very negative design mechanism. It looks great in Photoshop, but horribly fails when the site is complete. Invariably, the client will be too absent-minded to realize that if one column has substantially more content then the other, then the other column will be incredibly long with very little content (the people of the aformentioned site did that and then called complaining about their own content).

There are some CSS tricks you can use to your advantage, though, that will work great in (what I call) the big 3 (Windows: IE, FF, Opera; Mac: Safari, FF, Opera). You can have an entire column wrapped in a single div, set the width of that div (with no padding, margin nor border), then use divs for the content inside that div. Leave the width alone and set the necessary margin, padding and borders. That way, there's no need for hacks around IE's box model bug or anything. It can potentially create some wasted div space in the HTML, which is undesirable but unavoidable until browsers all become more aligned.

It sounds like your only problem is that CSS just hasn't clicked for you yet. (Forgive me if I'm wrong, you probably have more experience than I do and I'm by no means a CSS genius or anything, that's just what it sounds like to me) If you just take your time and force yourself to only use tables were appropriate or absolutely necessary, you'll get to a point where you can do almost anything you could with tables without having to use ugly hacks and do it easier and quicker than before.

Really, it all comes down

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

[Bogtha]

Liquid layouts, for example, are totally impossible with tables.

This isn't the case. The width attribute of tables and table cells can take a percentage width, which is all you really need for fluid layouts.

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

[Mornelithe]

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.

Out of curiosity: what browser does that work on? I fooled with it, and I couldn't get it to work without declaring the height of the body explicitly on either konqueror or firefox. I may not be doing it correctly either, I suppose. Do you have an example, perchance?

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

[Haeleth]

Why is it so hard to make equal-height columns?

Because columns are bad. Columns were designed for print layout. The web is not print. When I am reading a web page, I want to read linearly. I do not want to scroll all the way down one column, only to have to scroll all the way back up to the top of the page again to start reading the next column. It is seriously inconvenient. And, no, you can't simply design your page so that the columns fit on a single screen, because you don't know what size my screen and font will be. Your design must lay itself out elegantly at any size, any resolution, any zoom level.

This is why websites designed by graphic designers tend to suck, and why websites designed by serious web designers tend not to have silly print-inspired things like multiple columns.

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

[Haeleth]

That is totally broken; I opened up their example, with my standard settings, and the "header" text was printed over the top of the left-hand column.

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

[Bogtha]

Dracos is (sort-of) wrong. From the specification:

If the height of the containing block is not specified explicitly (i.e., it depends on content height), and this element is not absolutely positioned, the value computes to 'auto'. A percentage height on the root element is relative to the initial containing block

The special case for the root element was undefined in previous specifications, which is why Internet Explorer doesn't get it right.

So basically, Dracos' technique should work, but only if you explicitly set the height for all parent elements or if you use absolute positioning, and only if you expect browsers to follow the more recent specification.

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

[Bogtha]

beyond the simple "@mobile" style.

Where did you get @mobile from? Are you thinking of @media "handheld"?

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

[mattyrobinson69]

iirc, its possible to have equal length columns using a parent div:

<div style='height:auto;'>
    <div style='margin-bottom:0px;'>
      $text1
    </div>
    <div style='margin-bottom:0px;'>
      $text2
    </div>
    <div style='margin-bottom:0px;'>
      $text3
    </div>
</div>

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

[neoform]

because browsers can't render the table until the entire thing is downloaded

What browsers have you been using? Every browser i've used renders tables before completing the page download.

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.

Sorry dude, but if you're viewing html websites that are that fat, it's not because of html (unless the web designer is horribly incompetent), it's because it's got too much content on one page. besides, rendering 235k of html doesn't take more than a few seconds, quit being so impatient.

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

[neoform]

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.

Explain to me how

<table><tr><td></td></tr></table>

is "bloat", trying to get CSS to do the same thing ends up with 4x the code.. THAT's bloat.

what's the actual advantage to the CSS layout? not enough gain to justify it's bloat/complexity, not only that, but the amount of hacks it requires to get proper rendering under all browsers is beyond rediculous (yes, that's not css' fault, but it's still a big problem with css when doing layout).

IMO, css is great for styling stuff, but it's terrible for layouts and isn't ready for production use (yet).

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

[suv4x4]

You are the face of CSS zealots in this thread, my man.

I use CSS for layouts on a daily basis, but just about anything you said here is wrong.

Tables are not bloat, a three cell table is not larger as HTML code than the outer set of 4-5 divs required to fake it qith faux columns, not to say the added weight of the extra images required for faux columns which is not the case with tables (especially if you want simply solid color columns).

About tables being "primitive", I guess you're too sophisticated to expand your way too narrow view on web design, so I'll not try.

You can't tell me it's not funny as hell that you rant how IE doesn't support the display:table/table-row/table-cell, what you're essentially saying is that you NEED the layout tools a table provides, but you want to hack other elements to behave as tables, or it won't be l33t enough.

CSS is vastly better than what was before: nested tables full of font tags

You've apprently not seen what some people do when they try to push CSS do the same what "nested tables" do: "nested divs and 3000px wide images".

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.

You don't even know CSS, do you. It's IE which doesn't require (in quirks mode) that parent height is set. But with proper DOCTYPE it does require it. Just like Firefox and Opera also do.

But your parent element has to have known height per spec, and that height can't stretch to its content as content amount changes, hence CSS can't do equal size columns, unless you hard-code the height in the element or parent elements.

Pretty simple. Like all CSS zealots.

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

[EnglishTim]

I'm a web developer too, and I think the exact opposite. Take a look in any bookshop lately. How many books are teaching table layouts these days? How many books are teaching CSS layouts these days?

But that's the great thing: you don't need a damn book to learn how to use tables.

You'll get no arguments from me about the merits of CSS, but one thing I don't like about it is that it's a lot harder to pick up, especially for layout. Now sure, if you do web stuff for a living - big deal. You learn what you gotta learn. But if you just need to knock a page together now and then sticking in some tables is a hell of a lot easier.

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

[sehryan]

Web Designing is my job, and every web site I create, I do in a pure CSS layout.

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.

Table-based layouts are wrong. Tables were designed to show tabular data. By using them for layout, you are perverting their function. You are also making your site much more difficult in terms of usability for the handicap.

And finally, I have found that CSS has changed the way I design a site, in terms of the new and different things I can do. It allows me to position things in a way that tables just cannot do, at least not without 20 different cells. It also allows me the ability to create a specific look for print. To see a great example, go to A List Apart and check out there (all CSS) design, and then look at how it prints. I can also create a specific style sheet that works with mobile devices, while still using the exact same HTML page.

CSS isn't easy to start, but once you start mastering it, you will realize how limiting a table-based design actually is.

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

[EnglishTim]

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.

No, it's because back then (when Netscape 3 came out), tables were the only way to do it. CSS wasn't implemented in any browsers for a while after that, and the early CSS implementations were pretty buggy.

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

[bueda]

I guess the Question is not, how to do this, but more, how to avoid it. If you want to design a page with 3 colums of content and seperate content above and below, you should probably reconsider the structure of your page, and if you want your users to find something or to get lost.

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

[Nicholas Evans]

What you need, then are web designers, not graphics designers. As a programmer, you should not be stuck with the task of implementing a design. That is not your job. It should be implemented, CSS and all, for you. And you just plug it into your application/site. Yes, that is ideal. But I can assure you it is attainable. I currently work in such an environment.

You are being completely unrealistic. If he can mog together a layout with a few tables, I'm sure management would prefer that to hiring additional people or contractors.

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

[duncangough]

Tables are for laying out tabular data. Use them where they're meant to be used and that's fine. It's just that tables got a bad name for being full of spacer.gif's and nested tables. Stay away from that, mark up your tables with relevant CSS and you'll end up with a semantically useful design.

http://ecolocal.co.uk/ - Green news and views in the UK

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

[onlyjoking]

So let me get this straight. Tables are BAD and so are columnar layouts. Wow, this CSS sure expands your range of options.

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

[Hynee]

Wow, I thought you were full of !#@$ until I checked out W3School's CSS display page. Does this actually work on IE? I'll probably test it, but it would be nice to know. The last time I checked there was only display: none/block/inline.

At first I thought this was just a CSS replacement for <table><tr><td>, but it does truly mean that you can completely change your layout by switching stylesheets, while keeping the "layout power" of tables. Using absolute positioning or floating blocks always seemed a little deficient to me.

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

[mysticgoat]

Long before there were web designers churning out pages of advertising, there were content providers whose needs are significantly different. My experience as a web developer consists of over a decade of devising ways of presenting procedure manuals, FAQs, help pages, reports, and similar information on the web. My goal is to do this in a way that makes revisions and additions simple. Ideally, so simple that the content developers can do the maintenance and extensions on their own, without needing to study web technology, or bother me ever again.

The techniques of HTML 3 and 3.2 sucked. Preserving the tabular format of a complex document is not something that you can expect of someone who doesn't know HTML, doesn't want to learn HTML, and who you don't want to try to teach HTML to. And believe me, you don't want to try to teach HTML to a surgeon or corporate vice president: he's got other things on his mind and he costs way too much per hour anyway.

The answer lies in splitting out the content from the layout. Surgeons and CEOs can and will understand the use of <H1-6>, <strong>, <div class="sidebar">, and so on. They can and do understand that the web developer can manipulate the CSS independently of what they write, and that while they can make suggestions about how they want the <span class="doItMyWay"> to look, getting it to look that way is something they can delegate to someone with technical expertise in web development.

I can understand web developers who work in advertising and similar graphics presentations having a desire to stay with the tabular layouts of yesteryear. Doing web pages that look like posters or TV images is a lot easier with tables than with CSS. But their job is very different from the web developer who is tasked with presenting reading material that will need to be revised and extended from time to time. CSS— and the split between content and presentation that is its reason for being— rocks!

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

[jZnat]

You write a single CSS file (which will get cached on the user agent's end). You have multiple pages on your site. You've just saved an asswad of bandwidth if you get a bunch of users.

Using CSS, you can cut down the size of the markup pages to negligible, and a one-time download of a CSS file isn't bad either. Downloading a crapload of useless tables that don't even show tabular content (y'know, more than one column and one row, each column and row is related to each other somehow, a "table" of "data" if you will) wastes a lot of space and bandwidth even in the short run.

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

[jZnat]

For the shell scripts thing, use "white-space: pre-wrap;". Most of your other problems have already been solved or probably will be in CSS 2.1 and CSS 3.

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

[NutscrapeSucks]

CSS-P only has a significant filesize savings over tables if you were using FONT tags, which most people stopped using 8 years ago with "version 4" browsers. Given comparable layouts, you will have nearly as many DIV tags as TABLE TR TD tags -- if not more. It's a wash, there won't be any big difference.

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

[misleb]

You are being completely unrealistic. If he can mog together a layout with a few tables, I'm sure management would prefer that to hiring additional people or contractors.

Or just fire the graphics designer and hire a web designer. Who you fire/hire certinainly depends on the situation, of course, but a good web designer will ultimately come up with a better design than either a graphics designer or a programmer. Not only that, a good CSS based layout is MUCH more flexible than the table design. When management comes down and says "we'd prefer the page look more like this..." it might take a couple hours to change it with CSS (as long as it isn't all absolute positioned crap) where it will often require days to overhaul a table layout. Certainly management can understand that.

Anyway, it is stupid to argue for table based layouts based on how poorly assembled some web development teams are. Fix the teams. Get the right people do do the job(s).

-matthew

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

[daviddennis]

About six months ago, when I decided I really needed to change my layouts to a more modern CSS design, I bought and read a book about CSS design.

It told me there were three choices:

* A table-only based layout;
* A CSS+Table-based layout; and
* Pure CSS

It also said that pure CSS was more complex and handling browser varations were more difficult. It looked to me that if I wanted a table with three columns, all of them with background colors filled to the bottom, I would have to create a fixed-size layout, knowing what the size of every element was at the start.

Since I wanted to create templates I could use for arbitrary-sized content, that obviously would not work.

So I selected a table-based layout where each cell was styled with CSS.

Since people are very slow to change browsers, I think the way i did it was probably best.

So tell me, what is wrong with this approach? It seems to work very well for me. What can massive numbers of DIVs and complex markup do that tables cannot?

Is a div really intrinsically better than a table? Seems to me they mean basically the same thing nowadays. They are used to show the relative positioning and style of formatting elements. In reality they have no semantic meaning whatsoever.

So how is it "better" to use div? It certainly doesn't bring any particular meaning to the table.

Personally, I wish CSS just let me define my own tags. I hate having to use

<div class = 'sidebar'>

I'd much rather use

<sidebar>sidebar content</sidebar>

where sidebar was defined exactly as you would define h1. That would be TRUE semantic markup! I think <div class = ...> is just a crude hack.

I do web development professionally, but content is more my focus - making it easy to create, find and so on. I want to create an attractive format as simply as possible so that it's easy to edit and understand. Many of the complex CSS formats I've seen are anything but that.

D

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

[Vo0k]

Something like that... I really don't write media-specific css styles often enough to remember the syntax without reference.

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

[HawkingMattress]

Yeah, and how exactly do you work around the fact that display:table is not implemented at all in IE ? You just don't care about the 80+% users who will see the site look like total shit ?

I mostly agree with you, table based design is stupid. But saying that you can resolve the issue by using display:table is just unrealistic. And even if you can find workarounds most of the time, they're just that, workarounds. And they often take way too much time...
And CSS 2 is broken, in some places. How do you place a container at the bottom of the page, for example ? #container{position:absolute; bottom:0 } ? No, that will position it at the bottom of the *viewport*, which is the same if you page has no vertical scrollbar, but the bottom of the viewing area you can see when the scrollbar is up if you have one. You have no way that i know of to specify that, unless you use fixed positionning, or have a container of top with content pushing the bottom one. Both of which totally defeat the purpose of CSS since you either have to use fixed positionning, or break the separation of content and styling...

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

[Bogtha]

Wow, I thought you were full of !#@$ until I checked out W3School's CSS display page.

Why are you referring to those guys? They are pretty sleazy. Why not refer to the authorative source for whether something is valid CSS or not?

Does this actually work on IE?

No, which was basically my point. CSS doesn't make it difficult, Internet Explorer makes it difficult.

The last time I checked there was only display: none/block/inline.

display: table-cell has been around since 1998, and most browsers implemented it ages ago. You haven't heard of it because nobody uses it. Nobody uses it because it isn't in any tutorials. It isn't in any tutorials because Internet Explorer doesn't support it.

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

[BalanceOfJudgement]

Every browser i've used renders tables before completing the page download.

How in the world does the browser know what to draw until the [/table] tag has been reached? The reason you see some of the page render as it is downloading is because it's drawing intermediate tables that are already completed. I'm talking about a very few poorly designed websites (and yes, I agree that's because of the developer, not the HTML), because over the years people have learned NOT to jam 200kb of content into one table (or one page, for that matter, although Amazon's web pages are still routinely over 200kb each).

quit being so impatient.

Totally uncalled for. I didn't say anything about being impatient, nor did I even imply I was sitting there tapping my finger waiting for it to complete. I said (and implied) only that the page doesn't appear until it's done downloading.

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

[Bogtha]

Yeah, and how exactly do you work around the fact that display:table is not implemented at all in IE ? You just don't care about the 80+% users who will see the site look like total shit ?

Wow, talk about missing the point. My point was not that you should use this for public websites. My point was that it's not CSS that is broken, but Internet Explorer.

And CSS 2 is broken, in some places. How do you place a container at the bottom of the page, for example ?

The last child of the <body> element is at the bottom of the page by default. I assume you mean something other than the bottom of the page?

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

[HawkingMattress]

Column splitting is present in CSS 3... possibly others, I just skimmed through a few pages of the proposal and decided to stop there because i'd feel spoiled for the next 5 years. Yeah i know, it's not very helpful to do real work but still.

And of course you realize that XSLT is not in any way a replacement to CSS... When using XSLT to do web stuff you generate HTML with xslt, and style it with CSS.
At least a cool thing about CSS is that it can remove a lot of complexity in XSLT sheets since most of the time you can just spit your data into divs with XSLT, and do all the layout with CSS.
Complex layout with pure XSLT can get really nasty, way too often you end up doing procedural programming with an XSLT engine which is... a little crazy in my opinion.

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

[Bogtha]

you don't need a damn book to learn how to use tables.

That's funny, because if I remember correctly, a watershed moment for the uptake of table layouts was when the technique was included in one particular book. So yes, when the industry wasn't swamped with loads of developers who knew table layouts, you did indeed "need a damn book to learn how to use tables". There's nothing that makes CSS layouts intrinsically more difficult than table layouts, it's the fact that table layouts came first that makes you perceive them as being easier.

If you've ever tried to teach somebody how to create a table layout, then you wouldn't be claiming that it's easy. I've even seen professionals with years of experience in table layouts construct monstrous amounts of tables nested a dozen deep, even though you could accomplish the same layout with at most half as many tables if you truly understood them.

Now sure, if you do web stuff for a living - big deal. You learn what you gotta learn. But if you just need to knock a page together now and then sticking in some tables is a hell of a lot easier.

So what you are saying is that CSS layouts are the professional method and table layouts are the amateur method?

If you "just need to knock a page together now and then", why are you designing the layout in the first place? Why not just use a template?

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

[hankwang]

Surgeons and CEOs can and will understand the use of <H1-6>, <strong> <div class="sidebar">, and so on.

Really? So you let them edit raw html? I once had to setup a website of a university department, where each researcher had to write a page about ongoing research. No way I could get them to do that, so I ended up letting them use frontpage (at least it's better than Word for this purpose), and then hand-editing it myself after filtering out the crap that Frontpage produces.

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

[Bogtha]

It looked to me that if I wanted a table with three columns, all of them with background colors filled to the bottom, I would have to create a fixed-size layout, knowing what the size of every element was at the start.

This is incorrect, there are a number of ways you can do this without using a fixed layout. Follow the links people have been posting in other comments.

So tell me, what is wrong with this approach? It seems to work very well for me. What can massive numbers of DIVs and complex markup do that tables cannot?

As I said in another comment, try looking through the CSS Zen Garden, there are plenty of designs that cannot be accomplished with table layouts.

If you are using "massive numbers of DIVs", then it sounds like you've fallen into the trap of thinking you need to use a <div> element for everything as a substitute for using a <td> element for everything. The idea behind CSS layouts is to use the most appropriate element type, not to simply change all the <td>s to <div>s. And why are you describing it as complex markup versus tables? Tables are complex markup.

Is a div really intrinsically better than a table?

For what? It all depends on the nature of your content. For tabular data, no that's what the <table> element type is for. For content that can be described more accurately with another element type? No, you use the other element type. You only use <div> elements when there's nothing more specific to use.

Seems to me they mean basically the same thing nowadays.

Some CSS newbies start thinking like this if they haven't learnt HTML properly. If you take a table layout and switch all the table cells to <div> elements, then you'd be screwing up. <div> isn't a replacement for tables, it's a generic division of content.

In reality they have no semantic meaning whatsoever.

If that were true, then it wouldn't be so bad. But tables do have semantic meaning. They mean that the cells are related across a number of axes. It's describing the relationship between multiple pieces of data, it's not instructions to put something on the screen in a particular way.

It so happens that there's a usual way of presenting a table that's useful in most situations, but the meaning of the information isn't defined by its presentation, and in some cases, it might be very useful to present that information in an alternative way. Table layouts have essentially made this impossible for browsers to do. How could a browser reformat a table in a better way now that a particular presentation is expected of it?

I'd much rather use <sidebar>sidebar content</sidebar> where sidebar was defined exactly as you would define h1. That would be TRUE semantic markup!

No, it's not semantic at all. Semantics describe the meaning of things. "sidebar" is a description of where something is on the page.

And even if you chose a true "semantic" element type, it would still be useless, because the semantics would be your own private definition that nobody else knew about. The benefit semantic markup brings is when everybody uses a standardised set of element types, so everybody understands the same element types to mean the same things.

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

[ptlis]

If you're using more div elements than the corrosponding elements used to create a syntaxically and semantically correct table then you're doing something seriously wrong. This whole CSS/semantic HTML 'revolution' isn't about getting rid of tables because of some vague ideal that tables are somehow intrinsically evil - it is about taking a step backwards and re-thinking the whole web development process. If you recall HTML was designed as a hyper text markup language (emphasis mine), it's purpose is to 'mark up' data in a semantic manner, tables used for presentational purposes are incorrect because designers are ignoring the semantic meaning of them. In the same way, using many div elements in place of table elements is equally as incorrect - div elements by definition do not denote any particular meaning to the structure of that part of the document.

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

[HawkingMattress]

Ok, I read too fast ;)
I was about to answer a long rant about how i thought the w3c should propose reference implementations of their standards, but finally decided it had little to do with your post so i answered the main post (here)

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

[NutscrapeSucks]

I'm not arguing against the semantic ideology, in fact I agree with it. I just don't agree with the statement that it makes any significant difference in filesizes.

In the same way, using many div elements in place of table elements is equally as incorrect - div elements by definition do not denote any particular meaning to the structure of that part of the document.

That's nice, but CSS-P requires non-semantic DIVs/SPANs to achive the desired layout. Back to the drawing board, if that's now how it's supposed to work.

If you're using more div elements than the corrosponding elements used to create a syntaxically and semantically correct table then you're doing something seriously wrong.

More? I said it was roughly the same because practically TDs and TRs get turned into DIVs.

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

[NutscrapeSucks]

A site like ESPN probably had the sort of obsessive table layout that used TDs for borders and nested tables for padding and the like. A long way away from the kinds of table sites I used to build,

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

[neoform]

Firefox renders any competed tag immediately.

once it recieves a it will render that cell.. the same way it doesn't wait to get the or tag to start rendering, it simply waits for a completed tag, in this case a and it renders it.

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

[masterzora]

I'll show you that as soon as you show me one done in CSS without hacks or abuses of CSS if you show me one done in HTML without hacks or abuses of HTML. And we'll start with the fact that using for layouts instead of tabular data is an abuse in itself, so no tabled layouts allowed.

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

[Bloater]

whitespace: pre-wrap does not solve the shell script problem. It stops wrapping so the user gets a scroll bar and half the script is invisible.

I don't know the geometry of my user's screen so I want to give the browser a specification for how to wrap that language. I should, essentially, be able to define new langs for the lang attribute so this is handled properly.

So far, my other problems are *not* solved by either CSS 2.1 or 3. They require tallying up all the sizes and entering them explicitly and prohibiting wrapping, and doing the tallying for every output device the user might want to render to. It also, mostly, requires adding presentation markup (ie, position: relative container elements). And the auto-columnifying is *not* solved, in any way, shape, or form. It still cannot be done, AFAICS.

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

[Bloater]

It appears that CSS 3 *does* support column splitting, so maybe after a couple more years that will be available for use in 15% of the users' browsers.

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:I'm sure the naysayers will be here shortly

[sco08y]

The blind don't deal with "headers" and "footers".

Wow, so when reading a page of braile there's no top and bottom? You're full of shit.

Tools for processing semantic markup don't either.

Right, and the current clusterfuck is so much better.

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

[Short Circuit]

Yes, but would you rather have a conversation with a l33tsp34k3r, or with Robert Frost?

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

[Hynee]

Does this actually work on IE?

No, which was basically my point. CSS doesn't make it difficult, Internet Explorer makes it difficult.

... which makes it totally useless to me.

Next.

Wow, I thought you were full of !#@$ until I checked out W3School's CSS display page.

Why are you referring to those guys? They are pretty sleazy. Why not refer to the authorative source for whether something is valid CSS or not?

Do they differ on this one? Only in level of detail.

The last time I checked there was only display: none/block/inline.

display: table-cell has been around since 1998, and most browsers implemented it ages ago. You haven't heard of it because nobody uses it. Nobody uses it because it isn't in any tutorials. It isn't in any tutorials because Internet Explorer doesn't support it.

Oh please, I forgot it because I don't use it because it's of no use to me because IE doesn't support it. Boo hoo.

Can you crawl out from under your rock and tell me whether IE7 supports this? That would be one useful thing from this conversation.

In summary to any readers, regardless of the worthiness of Microsoft and Internet Explorer, you must learn to use a smaller, crippled subset of CSS (and workarounds) if you're going to web design, mainly because of the deficiencies of IE. You can do some pretty fancy Flash-like stuff if you use CSS that's available in Mozilla/Opera/KHTML, but downloading software is not what the internet is about, it's going to an internet cafe and checking out a site with whatever's available.

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

[Hynee]

Touché, well said.

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

[HTH NE1]

It remains my opinion that multi-columnar rendering of web pages should never exceed the height of the browser window, no single column hsould exceed the width of the browser window, and can cause horizontal scrolling exclusively, so that no reverse scrolling would ever be necessary for a single read.

At least for languages that are read left-to-right, top-to-bottom. Other languages (right-to-left, top-to-bottom; top-to-bottom, right-to-left; etc.) will have different constraints. I don't like to think about mixing them.

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

[Lord Flipper]

Personally, I wish CSS just let me define my own tags.

Heheh, it will, but you have to ditch the crippled HTML and even XHTML, to really do it right.

Store all your content in your own, personally-defined XML tags, and use whatever stylesheet system you want when you have your content all written out. [XSL, CSS, etc]. Your 'much rather' is exactly what makes XML [or SGML] so powerful; it is flexible, user-defined, and can be formatted any way you want, with the content's tags only beholden to your own DTD.

I've been learning CSS, too, and, as an amateur, I appreciate the thoughts and opinions of the 'real' web developers in this discussion, a lot.

The troubles I have seem to center around the polarized nature of the tips and tutorials out there, for CSS: Either they are something along the lines of the "Photoshop: Every Tool Explained", or they dwell on the other end of the scale, i.e., cutting edge CSS2/CSS3 stuff that doesn't actually work in any user agents, yet.

So, for me, taking templates and altering them radically with CSS-a trial and error deal-helps a lot, as does reading the different web-based treatises, and, as a side benefit, learning how to alter php and js stuff, too. I'm also an advocate of down;oading old sites and redoing them in CSS. It's time-consuming, for me, but well worth the learning experience.

But, as an old XML guy, I have to weigh in on the side of the separation of content from form, and CSS looks like the way to go, as long as html or xhtml is the code being used. Do I think people tossing together blogs or basic, ISP-style 'freebie' home pages ought to learn xml and start delving into DTDs or schemas? Nope. But for the bigger projects and bigger databases, and web apps, it looks like the boss to me.

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

[mysticgoat]

Really? So you let them edit raw html?

Yeah, sometimes I offer them that. When there is a good template or they are revising the content of something that is already in good HTML. So its pretty well "cooked" in the sense that they can copy-paste structures from place to place, etc, but its "raw" in the sense that I want them to work in something like HTML-Kit or HomeSite.

Some refuse to do the HTML, and then I'm bargaining with them from a position of strength on matters of formating and deadlines. They know they would have more "artistic freedom" if they did it in HTML. My boss knows that if he won't support me in this bargaining, then I'll drag my feet until I've got the backing I need.

I haven't kept count, but probably around 70% of those who give the HTML editing a try change their minds after a while. They'd rather put up with my constraints and work in a word processor they know. Many of them end up with a better appreciation of what I do before they quit their HTML efforts, and that doesn't hurt me at all. It's usually easier to talk over format and design problems with them after they've had a taste of the raw.

The ones who actually do work in HTML get my high-priority attention when they ask for help. They tend to be fun to work with, and they tend to say very nice things about me.

I can't imagine turning a bunch of neophytes loose with FrontPage or any other WYSIWG HTML editor and then trying to patch together the results afterward. That sounds like the recipe for a lot of long, gruelling, unrewarding hours. Probably with content writers bitching about how you've mangled their glorious presentation, and the boss bitching about why it is taking so long when the content writers have already done all the work.

How did you ever get that to work out?

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

[MikeFM]

At least with IE7 things seem to be improving a lot. It's still far from perfect and not even in the same level of quality as Firefox, Safari, or Opera 9 but it's to the point where I don't have to do some really shitty looking rehash of the site just to make things look okay in IE. My IE7 stylesheets have many fewer changes from my standard stylesheets than my IE6 stylesheets.

I just wish Mac people would stop using IE5. What the hell is wrong with you people. Use Safari, Opera 9, or Firefox. IE5 just flat out sucks and isn't worth supporting. I force most my websites into non-styled mode for people who use IE5. Luckily I haven't seen a classic Netscape or IE4 user in a long time so it seems most users have upgraded past those. IE6 has about 50% with IE7 starting to pop up. Firefox and other gecko-based browsers have about 35%. The rest is mostly Safari and Opera with a few odd browsers thrown in.

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

[Skapare]

It has seemed to me that much of the design of the web standards, from the earliest HTML to the latest CSS2, has been more about academic documents where there is a clear dividing line between what is semantic content, and what is style of presentation. The real world mixes style and content together as a single unit. Print and television media have been doing it this way for decades before the web came along. While I can understand the principle of why the content and presentation need to be separate for the ideal web page (or whatever media is being used), the fact is much (most) of the real world isn't making stuff for which that ideal fits. If the CSS standards makers were to address some of the issues where "content" makers are actually creating a combination content and presentation, they might find a way to make the "more correct" method of separate content and presentation easier to work with.

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

[Skapare]

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.

There is nothing inherint in a table that prevents it from being incrementally displayed as it is arriving. You're speaking of a browser issue. I know this is the case because I've seen browsers vary in the way they handle this. I've seen many pages load their tables as they arrive. My own LinuxHomePage does, though that's hard to see because its layout table is just one row and three columns. A better example is here. Of course it helps to speed up layout if everything inside the table has a known layout size as soon as possible. That's one reason why my images in LinuxHomePage have the width and height specified explicitly in the HTML.

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

[Skapare]

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.

But many people don't want the kind of compromises they are sometimes forced into with CSS layout models.

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.

They are also thinking about content and presentation simultaneously. They don't think about issues with some content being presentable in different ways and in different media. The print and TV industries have never needed to do it any other way before.

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

[hankwang]

I can't imagine turning a bunch of neophytes loose with FrontPage (...) How did you ever get that to work out?

Well, I gave them a template and explained to them that they should only use the basic h1, h2, p, b, i tags and a couple of divs for figures. I made a stylesheet that would display every span or font element in ugly red letters to discourage them from sneaking in those forbidden tags. :-) I had to run the pages through a bunch of perl scripts anyway to generate a table of contents and other links.

It was more a problem to get the content in the first place. You know, many scientists don't give PR a high priority. As you can understand, nobody was bothered about the change in layout. Also not everybody wanted to touch Frontpage. I think I ended up hand-formatting quite a few texts from MS-Word documents, which was much faster than removing Word's HTML output.

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

[tigersha]

One thing that irks me about CSS is that all the hot CSS sites tend to look the same: They have a fixed width column in the middle and padding on the sides. This is not because it is aesthetically better, its because CSS makes it hell to do some kinds of layout differently. So now the very real limitations of CSS layout is forcing a very real change in they way many websites look. And the new way is quite limiting.

And lets not talk about all the flashy CSS hacks to get it to work in most modern browsers the same way. None of that crap with tables.

CSS is a good idea that needs a few extensions to make it really useful.

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

[mysticgoat]

Hmm, you've given me something to think about, wrt a separate development style sheet that would highlight problem tags...

Thanks!

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

[baadger]

All the hacks belong to IE. Maybe CSS is great for styling *and* layout and IE is just lousy for CSS?

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

[godefroi]

IE at least will render tables happily as they're downloaded, as long as you set the table-layout: fixed style. That way, it uses the first row (or <colgroup> or <col> tags) to determine how to draw the table, and off it goes.

See IEBlog for details.

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

[godefroi]

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.

I don't know where you work, but around here, the design comes in a .psd file from the graphic artist (who knows nothing about what can actually be accomplished inside a browser), and the output on the browser screen WILL be 100% pixel-perfect. No compromises, no 90%, just web sites that look like brochures.

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

[gstoddart]

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

Kind of. Except tables existed for a very long time before we had stylesheets (HTML borrowed it's table syntax from CALS and SGML authoring) And tables were a step up from the ways in which the DIV tag was abused for a period there creating some of the *ugliest* web sites in history.

Tables were popularized because they were the only game in town for a very long time. The fact that CSS didn't exist made tables even more popular.

The horse and buggy didn't become popular because the internal combustion engines of the day were fiddly to work with. :-P

Cheers

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

[elrous0]

You put in a bunch of tables, and your normal IE users may see it fine, everyone else gets f'ed in the a.

You mean just like how everyone using an older browser gets f'ed in the a when you use CSS instead of tables?

-Eric

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

[elrous0]

My point was that it's not CSS that is broken, but Internet Explorer.

For those of us who have to design in the real world, this distinction is pointless. With an 80% market share, like it or not, IE *makes* the standard.

-Eric

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

[colmore]

Tables might be a good way of solving the problem of poor designers who don't understand that the web isn't, won't be, and shouldn't be print media but they don't solve many others.

It sounds like your designers need to aquiant themselves with the reality of their medium.

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

[RedSteve]

Explain to me how

<table><tr><td></td></tr></table>

is "bloat", trying to get CSS to do the same thing ends up with 4x the code.. THAT's bloat.

Funny. In my xhtml/css world, your table code translates to

<div></div>

That's 26 characters reduced to 11. What math do you use to find that 11 is 4 times bigger than 26?

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

[mdavids]

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.

So you're the one that's been making all those sites. Don't you feel at least some obligation to explain to your colleagues in graphic design that equal length columns of text in a medium where there is no concept of pagination, where the viewport is a different size for every reader, where the font size (not to mention 'font-family', 'line-height' etc.) specified by the author (if they have specified it at all and aren't just relying on the default font size of the browser they happen to be using) can (and will) be overridden by the reader, where some classes of reader can't even see tables, and so on (I'll stop there, but could go on all night) is a bad idea?

It's the people who insist on treating the web as if it were made of sheets of paper of uniform size that are the pain in the neck, not CSS.

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

[neoform]

that was purely an example. add another and you've suddenly got something css can't do without tons of tags..

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

[petermgreen]

the idea of css done right is to produce a fancy layout for your pr department to see but have it degrade gracefully to a simple but perfectly usable layout with anything else.

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

[RedSteve]

Shennanigans.

I'm working on a redesign from a table soup layout to a CSS layout. My page weight of just the HTML document is now 1/5 of what it used to be. My total page load -- including images, style sheets, javascripts, etc. is easily HALF of what it used to be.

If you can't make a div layout lighter than a table layout, you're doing something wrong.

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

[neoform]

see, now that's just half of it there.. i'm sure you could reduce a page from tables to css by about 1/3, but if you reduce the page to 1/5 it's original size, then you are not making good use of the tables..

the other side of the problem is that css is riddled with incompatibilities. a table will look the same in EVERY browser on the planet dating back to the oldest existing version of netscape.. i'm sure css will be great once it's ready, but it's not ready yet.

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

[RedSteve]

No, the tables in this site were a complex mess of nested tables inside nested tables with very precise widths, font treatments, and backgrounds. They needed to be as large as they were in order to fine-tune every bit of presentation to make things look exactly the same -- which you seem to think is the full advantage of a table.

In fact, you are not making good use of tables if you're using them for anything besides presentation of tabular data.

The problem is that the web inherently is not a precise presentation medium. The moment you let go of the notion that you can make everything look exactly the same all the time, the sooner you can focus on marking up the content in a way that makes sense rather than wrapping content in table tag after table tag.

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

[after fallout]

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

you asked.

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

[neoform]

You do realize that tables and css are perfectly compatible, right?

you can easily do:

table#table5 tr td { width: 50px; background: #eee; color: #111; }

.. if you want to write inefficient code, that your thing, i never said css was crap, but css for layout is.

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

[RedSteve]

That doesn't change the fact that tables were never intended for page layout; they were intended for tabular data. Wrapping non-tabular content in tables -- no matter how pretty the styling -- still unnecessarily complicates the content tagging process.

Whatever is next ...

[xmas2003]

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

Re:Whatever is next ...

[Drathos]

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

There.. Fixed that for you..

rounded corners

[russellh]

and the long wait for CSS 3.0.

Re:rounded corners

[codered82]

Check out Nifty Corners. Best I've seen.

Re:rounded corners

[russellh]

yeah, that and others are decent interim solutions, but CSS 3.0 brings it for real, and designers will be able to rely on common and complete CSS 3.0 support as soon as maybe 2012 (shed a tear). Though we have -moz-border-radius in mozilla browsers.

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

Re:Simple answer

[Ant P.]

You can send it as XML and it'll work in IE, IIRC.

Re:Simple answer

[kennygraham]

you can send as text/xml, but not as application/xml or application/xml+xhtml. And text/xml is still just text, and invalid for XHTML 1.1 and higher. I'm pretty sure IE still parses text/xml as SGML, too.

ok....

[B00yah]

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

[rnd()]

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!

Re:how about browser standardinzation 1.0

[whereiseljefe]

Support them both identically?

You must be crazy...

Re:how about browser standardinzation 1.0

[rnd()]

Standardization, my friend. Vendor neutral. It will happen on the web soon. Microsoft will have no choice.

Re:how about browser standardinzation 1.0

[larry bagina]

firefox does have a plug in to use IE/mshtml to render pages....

CSS

[bahwi]

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.

Re:My web speaks with a Lisp

[byrnereese]

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

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.

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

[Bogtha]

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

Amaya's an experimental testbed intended to fit as many different technologies into one browser as possible. I think expecting it to be as polished as a commercial web browser is a little much, don't you think?

What makes you say that it's dead? The CVS shows activity as recent as two days ago and the last release was less than two months ago.

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

[suv4x4]

Amaya's an experimental testbed intended to fit as many different technologies into one browser as possible. I think expecting it to be as polished as a commercial web browser is a little much, don't you think?

I don't follow your logic. It's a testbed, therefore it's ok it's broken and can't render properly written and implemented HTML/CSS pages. Is this what you mean?

If this is what W3C tests its standards on, then thank god for WHATWG.

What makes you say that it's dead? The CVS shows activity as recent as two days ago and the last release was less than two months ago.

It's an open source project, I can myself go, change a comment, and update the CVS and register "activity". But W3C officially abandoned Amaya in 2003, and this was all over the Internet media.

It's still hosted at W3C, but they are no longer working on it. They said they are instead refocusing on their recommendations and standards.

Re:Just a question...

[larry bagina]

xsl. php. shtml.

Absolute positioning makes things much worse

[Animats]

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, and browser-specific dreck in the page markup. Giant step backwards. Tables were a good feature and they need to come back.

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?

[CRCulver]

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.

But life doesn't become easier for those using screenreaders, nor for those developing processing tools that expect semantic markup.

Re:Why CSS xor Tables?

[CRCulver]

they may not care if someone with a screenreader can properly read it.

Many Western countries have laws now that require certain groups to make their web content accessible to people with disibilities. Sometimes it is a serious issue that designers make their sites readable with a screenreader.

Re:Why CSS xor Tables?

[Bogtha]

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.

But how long have you been doing table layouts? And you expect to catch up to that level of experience with CSS in a couple of days? If you keep using that logic, you'll never learn anything new, because new stuff that you have no experience with is always going to be harder than stuff you already know.

You say that you are a programmer, not a design guy. I doubt you only know one programming language. Where would you be if you had stuck with the first programming language you ever learnt instead of facing the learning curve and accepting that in the beginning, some things are going to be more difficult until you get a bit of experience in the new language?

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?

[EnglishTim]

But how long have you been doing table layouts? And you expect to catch up to that level of experience with CSS in a couple of days?

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

Where would you be if you had stuck with the first programming language you ever learnt instead of facing the learning curve and accepting that in the beginning, some things are going to be more difficult until you get a bit of experience in the new language?

It's called priorities. There are a whole bunch of more interesting things I'd like to learn rather than CSS, and I still won't even get time to learn most of them. If a table does the job (albeit roughly), it does the job.

Re:Why CSS xor Tables?

[EnglishTim]

In which case they'll hire a professional rather than one of us schmucks who just wants to kick up a quick site.

Re:Why CSS xor Tables?

[billcopc]

Ok little interference here. I've been a web developer since early HTML and Netscape 2.0. I've been trying to come to grips with CSS for a few years now, but the bulk of the information available on CSS involves working around browser bugs. There is no consistent implementation of CSS anywhere, I don't care what you Opera zealots thing, it's still not right. CSS itself is lacking in many areas, most notably tables. Sure, the HTML table system is a pain in the butt, having to futz with ROWSPAN/COLSPAN and the link, but CSS can't even do that yet.

I still have to mix them both almost all the time, so I usually end up using CSS to describe fonts, colors and chrome, but decade-old HTML to describe the layout. My biggest peeve with CSS positioning is that of the few options available, half of them are unsupported, especially if they relate more to screen than print, such as when you're trying to present a web application.

Just try to put down a consistent status bar docked to the bottom of the browser, another across the top, and a task pane on the left; Outlook-style. The wealth of CSS trickery required to just make it work is horrible. Sure, getting the accessory panes up there is easy, it's getting the remainder of the window to flow naturally that's a disgusting hack. Your content pane ends up being the full size of the client area because those toolbars and status bars are "floating", so you have to set hard margins everywhere, but then you have to nest DIVs or else your scrolling will be fubarred. Really, how hard would it be for a browser that just rendered a bunch of rectangles, to figure out how much space is left for the remaining items ? Something like good old "frameset N,*" that flows automatically when resized.. trivial functionality yet it's not there thanks to some angry god-fearing designer.

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

Re:Why CSS xor Tables?

[CRCulver]

In which case they'll hire a professional rather than one of us schmucks who just wants to kick up a quick site.

From the discussion so far, it seems that individuals are more likely to adopt CSS. Professional web designers, stuck in a mentality that time is money so spending some time to update their skills would cause them to lose money, stick with table-based designs.

Re:Why CSS xor Tables?

[Eivind Eklund]

Professional table users use template systems to do the separation of layout and content, so the parent's point is gone. Professional table users also use CSS where they see CSS as useful, and use tables for the rest.

This may be because I'm still not good enough at CSS use, yet I still find the combination of templates, CSS, and tables much faster to both design and redesign than pure CSS designs. The pure CSS designs has a beautiful cleanness to them - it's just that they're a pain to actually mod.

Eivind.

Re:Why CSS xor Tables?

[Larry Lightbulb]

Are there any site testers which check if pages can be read by screenreaders?

2 things that would make CSS truly God

[SlappyBastard]

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.

Re:2 things that would make CSS truly God

[HaydnH]

While IE doesn't support PNG's correctly, you can get transparency working by using an IE filter in the css, however it does make the css fail the validation tests:

#someDiv {
filter:progid:DXImageTransform.Microsoft.AlphaImag eLoader (src='./someImage.png', sizing Method='scale');
}

Re:Just a question...

[CRCulver]

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

[wan-fu]

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

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

[protohiro1]

I get designs from print people that require using absolute. I think part of the process of turning a design in to a template is for better or worse doing what the designer intended. So I would say fully relative positioned "bullerproof" layouts are the ideal, but in practice aren't always possible.

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.

IE digs, Firefox, and Safari

[Archibald Buttle]

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

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.

Re:IE digs, Firefox, and Safari

[Anonymous Coward]

You're using Safari as your benchmark? Passing the ACID2 test is irrelevant unless you happen to be trying to use the features the ACID2 test actually tests for, which you shouldn't. You shouldn't because only three or four of the less popular browsers pass it, while the biggest two (IE and Firefox) don't even come close. The ACID2 test was designed as a test suite for a load of CSS features that would be useful, but no browser on the planet had implemented correctly. It is not a test suite for the whole of CSS, and misses all kinds of stuff that you'd actually use on a real website.

I think you'll find that Firefox tends to be far closer to the standards than either Internet Explorer or Safari. The two browsers I use as a benchmark are Firefox and Opera. If it doesn't work in either of those, it usually means that it's either an edge case that won't work on most browsers anyway, or my understanding of the standard is wrong.

And those bugs you linked to are six years old. Mozilla is not IE, you know - there has been massive progress over the past 6 years.

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

[ClassMyAss]

It's a bad idea because the "page layout" would only be useful for one audience, probably sighted iusers.

Kind of like how CSS information is only useful for the sighted users? I don't get the difference (okay, I know you can specify the tone of voice of the screen reader in CSS, but this is hardly vital...).

I'm clearly asking for trouble with this, but I'm going to say it anyway. One of the most common arguments I've heard in favor of accepting CSS as the cure-all of website design is that it if you use tables instead, blind people will be inconvenienced by your site. Not to be insensitive, as I'm all for making things available to all (don't use Flash, etc.), but how many of your visitors are actually blind? The parent's quote suggests that sighted people are a negligible group, certainly not worth developing web standards around, but personally, the only browsers that I see showing up in my server logs are FF, IE, and Safari. Why is it that we should not make layout as easy as possible?

The way I see it (disclaimer: I'm a relative newbie to this - I've only been back into this stuff for a year or so, having gotten out of the whole web-design thing during the dotcom bust), CSS's biggest weakness is that it takes a lot of hackwork to achieve designs that seem like they should be quite simple intuitively - I fully understand why people often just give up and resort to either tables or absolute positioning. CSS acts very much like a formatting tool rather than a layout tool, and the layout stuff feels shoehorned in. The grandparent's comment seems quite reasonable (that layout should be separated from formatting), and much more OO than the current state of affairs. One class, one task, right?

Lastly, I can't resist, I've got to say it, even if it's not related to the parent: if browsers for the blind are stupid enough to read the blank entries in tables, then we should be going after the people that make those browsers, not the people who use tables in their designs!

Recommended Text

[Samuar]

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.

Re:Just a question...

[CRCulver]

Not to be insensitive, as I'm all for making things available to all (don't use Flash, etc.), but how many of your visitors are actually blind?

The ADA and similar laws in other countries require many groups by law to make their content accessible to people with disabilities regardless of how many blind users visit in practise.

OT: Good CSS Reading?

[pembo13]

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.

Re:OT: Good CSS Reading?

[Tteddo]

These are 2 books I have learned from:
Cascading Style Sheets: The Designer's Edge
The CSS Anthology : 101 Essential Tips, Tricks & Hacks
I also joined Community MX which helped loads in leaning all the strange browser quirks. Those people have it nailed and are very helpful.

Re:OT: Good CSS Reading?

[Strixy]

As for practices, two things that I would recommend right away is to use plenty of backups during your design process. Also, sketch your designs on paper first and reference those sketches often. Keep a sketch book and a pen on you at all times. You never know when inspiration will hit.

As for learning CSS do a web search for "css tutorial", "css tags" and then work your way through each and every css tag. Give yourself an excuse to use each of them. Using them is the best way to learn how to use them.

Then start checking out the style sheets for web pages you come across that grab your attention. Figure out how they did something and that's a pretty good way to learn. (Just don't go ripping off someone elses stylesheets).

On an aside, why hasn't the topic of javascript popped up yet? (pardon the pun).

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:Just a question...

[Bogtha]

how many of your visitors are actually blind?

Some of your most important visitors are blind. Or do you think the Googlebot has eyes?

Re:Just a question...

[ClassMyAss]

Some of your most important visitors are blind. Or do you think the Googlebot has eyes?

Certainly this is true - I'm most definitely not arguing that sites shouldn't make every effort to get their information across even if all one sees is the text. Using images and Flash to convey textual information is just downright wrong. Tables don't seem that bad to me - Googlebot seems to handle them fine, as far as I can tell, and I don't really understand why screen readers would have such trouble. In any case, though, striving for accessibility should not mean that we punt on the issue of making layout easier. The hardcore CSS folks seem to think that everyone else is either stupid or lazy, but that's a bit unfair, and I think it places the blame in the wrong place.

Yes, you can do beautiful and complex layouts in CSS. You could also program the next version of Firefox in Assembly. [I'm aware that's a bad analogy - I'm too tired to come up with a better one] That doesn't mean that there's not a better tool for the job, or that lacking one, a better tool shouldn't be developed. A lot of people don't dig CSS for layout, period (personally, I don't know enough to stake a claim either way). That speaks to a failing of CSS, so we should be seeking a solution rather than arguing that we already have it.

Re:Just a question...

[Isofarro]

One of the most common arguments I've heard in favor of accepting CSS as the cure-all of website design is that it if you use tables instead, blind people will be inconvenienced by your site.

Its a nice sound bite - but, in practice, tables for layout aren't that much of an accessibility barrier. Screen readers today can ignore table markup - they've had to adapt to the bad markup practices and short comings of web designers and web developers. But there is a limit to what they can do, and its certainly not equitable for screen reader vendors to have to make up for web designer deficiencies and ignorance.

Part of the problem of tables for layout is when you also use tables for tabular data. Answering the question of is this table a data table or a layout table isn't straightforward with screen readers. Ignoring layout tables helps, but ignoring the structure of data tables can create an accessibility barrier, since there's typically a two-dimensional relationship (or more, if you have subheadings and complex tables) described by the table markup - that is necessary for screen reader users to access the information. The data without the semantic structure is difficult to digest.

The main benefit to accessibility of CSS is that it encourages a consistency of markup across a websites. This consistency offers benefits like:

• since the navigation always starts at the same place in every page of a website, it can be skipped to (or over) easier than if a screen reader user needs to plough through the entire document every time. Consistency is a key requirement for highly accessible websites.
• If the styles of the CSS are proving to be a barrier (colour contrast or text sizing), the CSS can either be removed, or overridden by a user stylesheet.

The helpful benefit to accessibility of CSS lie in the simple fact that the separation of structured content and presentation allows a visitor to remove the presentation if that creates an accessibility barrier that must be overcome before the information can be read. That simply cannot be easily done when there's font tags all over the document.

For CSS to be a benefit to accessibility, it needs a well structured and semantically descriptive document to work from. There's little accessibility benefit in marking up HTML with just div and span, and then styling that. The structure of an HTML document is important to accessibility, and thus, not damaging the real structure of an HTML document by using layout tables is certainly helpful in that regard.

Re:Just a question...

[Bogtha]

In any case, though, striving for accessibility should not mean that we punt on the issue of making layout easier.

I agree that CSS is harder than it should be, but it still gives a better end result than tables. In many cases, a design principle allowing for easy or efficient implementation by user-agents has caused CSS to have artificial limitations. And given the fact that browser vendors have produced some pretty dire implementations, you can hardly blame the CSS-WG for trying to make it easier for browser vendors at the designers' expense.

The hardcore CSS folks seem to think that everyone else is either stupid or lazy, but that's a bit unfair, and I think it places the blame in the wrong place.

No, the impression I get is that the "hardcore CSS folks" are fed up with everybody complaining about CSS making it difficult to do something, when they are talking about something that is actually easy to do if only one particular vendor would implement the CSS specification published way back in 1998, or anything newer. The "hardcore CSS folks" listened to the designers and fixed the major problems with CSS almost a decade ago, but people are still blaming them because Microsoft ignored them (despite having employees on the working group that published the specification).

CSS might have some rough edges, but most of the things that people complain about are directly caused by poor implementations.

Re:Why is this under programming?

[m1ndrape]

They are declarative languages.

CSS help

[mobby_6kl]

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.

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:CSS help

[jZnat]

That's because the margins of those two div's aren't included in the width, and I'd guess that they're about 2px each.

div#left { margin-right: 0em; }
div#right { margin-left: 0em; }

Re:CSS help

[mobby_6kl]

Thanks for the replies everyone (you, the AC, and jZnat). A quick test of the suggestions didn't seem to help, but I'm possibly missing something. I'll have a look at it again tomorrow when I'm not completely wasted ;)

Re:CSS help

[Tteddo]

Ahh...what's the fun in that?

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:Two words:

[martinultima]

Definitely agreed – while I tend to be almost insanely obsessive about using CSS, there are a few things that I've found are just so much easier with tables; as far as I'm concerned, image galleries are "tabular" enough that it's OK to bend the no-tables-for-non-tabular-data rule just a little bit. And complex pages like the Get Ultima! page (for my distribution – not an ad, just what I feel's a good example) would be hard to implement without tables, either. Personally, I honestly couldn't care how the Web site's implemented – the only thing that I consider important for a "proper" Web site design, other than the design itself of course, is whether or not it validates.

By the way, you can even do without <div>'s if you know what you're doing – that same link's also a good example of that. Other than the actual content, everything's implemented using <ul>'s and <h1>, as well as the <body> tab itself. It's a bit broken in IE, but since it is a Linux site most of the people are probably already somewhat into open-source stuff like Firefox anyway, and honestly, I don't even use Microsoft products so I couldn't care less.

Just thought I'd add my two cents.

Twisted logic

[onlyjoking]

Doesn't anyone question the twisted logic of the accessibility fascists? Isn't it the responsibility of the screen-reader manufacturers and text browsers to come up with something that can handle table-based layouts rather than insisit the vast majority of websites be re-engineered to cater for a tiny minority with inadequate browsesrs? Note, I'm not aiming here at genuine accessibility issues like colour contrasts etc., just the tired CSS layout crap. CSS layout is and always was ****ed. That's why tables are still commonly used. CSS layout was originally CSS-P - bascially an afterthought/hack.

Re:Twisted logic

[NutscrapeSucks]

What've heard is the most popular screenreaders hook into Internet Explorer, understand the page DOM, and don't have too much trouble with table-based layouts (which are all over the Internet). I think the whole lynx thing is largely a slashdot myth put forward by Unix caveman types that hate all technology invented after 1994.

Re:Twisted logic

[CRCulver]

Isn't it the responsibility of the screen-reader manufacturers and text browsers to come up with something that can handle table-based layouts rather than insisit the vast majority of websites be re-engineered to cater for a tiny minority with inadequate browsesrs?

That's like saying that, instead of placing wheelchair ramps at each new or renovated buildings, we should put the onus on handicapped people to come up with magical robot exoskeletons that can climb stairs. Disability laws are pretty clear that the burden of accessibility falls on the owner of the establishment, so it makes sense to apply the same to virtual establishments.

Re:Twisted logic

[onlyjoking]

The fault is in the wheelchair, not the ramp. If screenreaders and text browsers can't parse simple HTML (yes, tables are simple) then they're inadequate for their purpsose. Don't blame web designers for using HTML tables when CSS-P support is laughable.

Templates

[onlyjoking]

Ever heard of templates? They make a lot of the CSS redesign issues redundant.

Re:Templates

[jZnat]

Templates may be part of MVC, but if you ignore the fact that the model is the XHTML and the view is the CSS, you're already defeating the purpose of using MVC in a web application by not even using it.

Re:Templates

[onlyjoking]

Who said anything about MVC? Using templates, as with most large sites, makes the whole CSS redesign thing redundant. With Perl's Template Toolkit I can develop a much more fine-grained library of components than the crude CSS layout model has to offer. It won't break in IE6/5.5/5.0 etc. either. Productive use of time matters to me. I wasted far too much time with CSS bugs when I was into it. Template Toolkit put an end to all that.

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

[toby]

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.

Leave the CSS vs Tables Argument to the Designers

[Mouse42]

Why are you trying to argue with people who do web design as a living to tout that you don't care how it's done, as long as you can quickly knock out a website that obviously has no need for professional development?

These are people who do web development day in and day out of their lives, and you're trying to argue with them to support your simple and limited version of web design? Thats like saying "Why should I learn how to use Photoshop when I can just knock out an image in MS Paint in a fraction of the time it would take me to learn how to use Photoshop? You don't need a damn book to learn MS Paint, but there are plenty of books out there for Photoshop!"

There's no point in addressing your argument because it shows you don't care about web design - you only care about getting information onto the world wide web, not it's presentation. So, please, leave ths CSS vs. tables argument to the people who actually care about creating the best presentation for their website, those who obviously care more than to just "knock a page together."

MOD PARENT UP

[metamatic]

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.

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

fully intended to

[toby]

I knew I'd probably have to roll my own. I was curious as to the mechanisms available for overriding it. I'll have to look into browser support... (Pity you can't attach a custom css to your profile, then it would go wherever you go, with no browser support required, eh.) Speaking of bitching - where *is* the "I hate the new CSS" thread? I can't be the only one.

Re:Just a question...

[jfanning]

One important point that all you table users are missing is that NOT ALL PEOPLE ARE USING A PC!

Within the next few years most of the world's population will be getting their internet access through their mobile phone. Try reading your table layout on a device with QVGA resolution or less and see if you still like tables.

At least a well designed CSS site will degrade gracefully.

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

[The Wicked Priest]

I used to be set to "Light Mode", which seems to have been translated to the combination of "Simple Design" and "Low Bandwidth" in the new design. This also changed considerably with the resdesign... but I still have a serif font. (I think just because it's my default.) The settings are under "Preferences", "Homepage".

good suggestion

[toby]

That's probably the easiest way of getting Times again (cool, thanks). But there are some less appealing side effects...

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

[Bogtha]

I need to switch to a serif font, at least. What's the easiest way to do this?

If you are using Firefox, install the Stylish extension and use this user stylesheet. It changes the font size, the font family and the line-height back to normal (i.e. what is configured in your browser as the default, which is what Slashdot used to use).

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.

Re:ok...

[faolan_devyn_aodfin]

not an endless loop of pain:
"A whole new spectrum of pain, like a rainbow!" ~Random Barbarian from "Korgoth of Barbaria"

I know what the problem is.

[Ayanami Rei]

You (and many other people) are trying to design INTERFACES.

Web pages (and CSS) were originally designed for marking up DOCUMENTS.

There needs to be an HTML-like variant for designing interfaces. You know, where you aren't fooling yourself into thinking that the display device is anything but a monitor on a computer. No cell phones, no text web browsers, no printers, MAYBE pdas.
You could use AJAX, SVG... get rid of a lot of the beat-around-the-bush tag definitions.

In the interim I seriously advise anyone who wants status bars and toolbars and buttons and screen-edge relative positioned content to consider FLASH.
Yes Flash.
Flash and actionscript are perfect. And you don't even need anything special in the backend... actionscript can launch GET/POST requests to interface whatever you got, it's just ECMAScript. It's got HTML and XML parses and such, so it's well suited.

Re:I know what the problem is.

[jgrahn]

You (and many other people) are trying to design INTERFACES. Web pages (and CSS) were originally designed for marking up DOCUMENTS. There needs to be an HTML-like variant for designing interfaces.

There is. It's called X11.

Re:I know what the problem is.

[billcopc]

Well then why do most word processors offer precise positioning of any element, various text and object justification schemes, headers and footers, even left/right margin breakers and many other layout controls ? They exist only to create readable documents after all.. why couldn't HTML do the same ? If I can tell Wordperfect to render a text block 3 inches wide by 2 inches tall, rotated 30 degrees and place it dead center in the page while reflowing text around it etc etc etc.. why not HTML ?

I think the reason I'm so upset with HTML and CSS is that they're just hacks layered on top of more hacks and wrapped in the wedgeless hack that is SGML.

Now show me the CSS for an N-column layout

[Skapare]

How well does your CSS work in IE6 or even IE5 (still in wide use)?

Now show me the CSS for an N-column layout, where a separate static stylesheet is used in conjunction with dynamically generated content that may have varying numbers of columns based on selections provided by the user. And these columns cannot be allowed to flow down to the next row, as that would confuse their meanings.

Of course the biggest problems designing for the web are broken browsers, especially IE6 (it doesn't even support CSS tables). Nevertheless, CSS itself still has issue. Not everything can yet be done by CSS, and many of those things can still be hacked with at least some HTML that doesn't follow the semantic intentions.

Here's another example. Write the CSS code to show how to produce a drop shadow effect behind a box with a border. Now expand that so that with pointer hover, the drop shadow is made to appear higher. Now fix the glitch where the rising box oscillates when the pointer is at just at the right spot in the 2 split corners (hint: put the whole thing in a box and use :hover on that box). That's all easy enough. The real challenge is to make all this work on an existing HTML file that has only ONE layer of DIV elements wrapping the content to be styled this way.

Style ... any style you might think of ... should never need to depend on creating multiple levels of DIV elements in the HTML. It should be designed so the entire style, however complex, can be applied as a unit to a single element by class or id. Your markup semantics should have nothing more than the elements to mark up what is what. The markup should have to worry about how many layers need to be used to create the desired style. CSS isn't there, yet, and since they aren't even considering this for CSS3, and the long times it takes for Microsoft to catch up to complying with standards in a reasonably bug free way, I'm afraid that CSS will remain broken for years, maybe even a decade or two. Fortunately, most of these hacks are relatively benign additions to HTML.

Re:Two words:

[donatzsky]

as far as I'm concerned, image galleries are "tabular" enough that it's OK to bend the no-tables-for-non-tabular-data rule just a little bit.

May I point your attention to this then?
And a real-world example: http://www.anaerob.dk/gallery/studenterkoersel/ind ex.html
No reason at all, actually there are good reasons not to, use tables.

Given the sorry shape of the majority of the web..

[Richard Steiner]

...when it comes to standards compliance, I'm not sure you can hold out "professional web designers" as some sort of ultimate authority on anything.

Besides, the web is about CONTENT, not PRESENTATION. To me, as an end-user, it's far more important that a site is easy to use and navigate with the browser I happen to be using, and I couldn't care less about the kind of flashy customizable interfaces that most "pro" designers are spending much of their time with.

Concentrate on the cake, not the frosting. The latter is nice, and perhaps for commercial sites it sells, but a crappy underpinning is gonna drive away more customers than your pretty frosting brings in!

Re:Two words:

[martinultima]

Well, I don't know about you, but I'd say that for what I need from an image gallery, tables are acceptable enough, at least for now – rules or not, they work for me, so that's what really matters. (And yes, I know it would make life miserable for Lynx users, but I have yet to see anyone browsing an image gallery in Lynx – and yes, I use Lynx all the time.)

Welcome to 2001!

[Junks Jerzey]

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

[dannylurks]

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