10 Best Resources for CSS

victorialever writes "Since one could have noticed an increasing number of websites that are employing CSS and an increasing number of resources talking about how great CSS is, it seems to become impossible not to jump on the CSS bandwagon as well. The 10 Best Resources for CSS provides an impressive list of the CSS resources which have recently become essential for web-developers. Among them - CSSZenGarden, The Web Developer's Handbook, Stylegala, PositionIsEverything etc."

Comments

Good Article

[BishonenAngstMagnet]

That article is quite good and points out a few resources that I (even though I'm a CSS/XHTML/standards geek) hadn't heard of. Keeping it bookmarked for future reference. Hopefully some of these can be used to extend the area of sanity around proper markup...a bit.

Re:Good Article

[tobiasly]

One of the best CSS articles I've found is at Westciv... they take the uncommon yet intuitive approach of fully describing selectors first -- what they are, how to use them, etc. -- before they go into properties at all.

For me, the most frustrating aspect of designing CSS-based sites isn't applying the properties I want, it's figuring out how to select the elements I want. This site explains it all very clearly.

http://www.westciv.com/style_master/academy/css_tu torial/

No CSS on that site.

[McDutchie]

Anyone taking even a cursory look at the sitepronews.com article source code can see that the layout is done with the usual mess of tables.

Re:No CSS on that site.

[BishonenAngstMagnet]

True, but I was more interested in the article rather than the implementation.

Re:No CSS on that site.

[BishonenAngstMagnet]

But we all know that it can be fixed...

Re:No CSS on that site.

[iBod]

It's still easier to do certain things with table-based layouts than it is with CSS alone. Control of vertical positioning/height being the obvious one. That and fluid layouts.

If you're a busy designer, sometimes you just have to take the pragmatic route rather that waste hours or days trying to make a pure CSS layout work across all the common browsers (none of which implement CSS 100% correctly anyway).

Either that or (worse) you compromise the design to make it fit the limitations of a pure CSS layout.

I think the latter approach accounts for the huge number of 'identikit', bloggish-looking sites out there (all proudly displaying their little W3c validation logos of course).

It's still perfectly possible to create valid, semantic XHTML/CSS markup that uses the odd table for layout (no, I don't mean a heap of nested ones with spacer gifs!).

While I'm all for standards and separating content from presentation, at this stage of the game, we just need to choose the solution that works best.

I know it's probably heresy to say this, but IMO tables work in an intuitive way that you can easily visualize whereas a mass of floated DIVs often do not!

Re:No CSS on that site.

[mill]

Umm, it isn't valid semantic markup if you are using tables for layout.

Re:No CSS on that site.

[Anonymous Coward]

I agree that CSS got limitation, but not with vertical height/positioning and fluid layouts. The only thing bothering me is vertical centering.

Re:No CSS on that site.

[iBod]

Yes, you're correct. Tables only have semantic meaning for actual tabular data.

Re:No CSS on that site.

[Anonymous Coward]

in a way, not too dissimilar from slashdot then...doesn't mean the content is any less valuable.

Re:No CSS on that site.

[Anonymous Coward]

Good god, if it takes you *days* to do a CSS-positional layout, then you really should learn CSS.

Once you learn it, CSS is easier to layout than using table-hacks, so you actually save the client money.

Re:No CSS on that site.

[Bogtha]

It's still easier to do certain things with table-based layouts than it is with CSS alone. Control of vertical positioning/height being the obvious one. That and fluid layouts.

Okay, vertical positioning, I'll give you. But fluid layouts? That's not hard at all. Websites are fluid by default, they only stop being fluid when you set explicit widths using fixed units. You can do that with CSS or tables.

If you're a busy designer, sometimes you just have to take the pragmatic route rather that waste hours or days trying to make a pure CSS layout work across all the common browsers

If you are an experienced designer, then you've already done similar layouts a hundred times before, so you have the code and bug workarounds memorised and making it "work across all the common browsers" is at the very least least as easy as dumping a load of table code into each page.

Either that or (worse) you compromise the design to make it fit the limitations of a pure CSS layout.

I think the latter approach accounts for the huge number of 'identikit', bloggish-looking sites out there

Er, CSS is far less limited than tables (check out the CSS Zen Garden), and I've seen way, way, way more websites out there using tables that all look alike.

The reason most weblogs look alike is because they come with a set of default templates that people don't tweak very much.

It's still perfectly possible to create valid, semantic XHTML/CSS markup that uses the odd table for layout

Er, no. Not semantic. Not at all. If you are using tables for anything other than tabular data, it's not semantic.

While I'm all for standards and separating content from presentation, at this stage of the game, we just need to choose the solution that works best.

At any stage of the game you need to choose the solution that works best. In my experience, switching to CSS saved me a whole lot of time that was spent dealing with cruddy code. Sure, in the beginning, that extra time was wasted on stuff I didn't know about CSS, but once I got a bit of experience, it was a real time-saver.

I know it's probably heresy to say this, but IMO tables work in an intuitive way that you can easily visualize whereas a mass of floated DIVs often do not!

I've heard that before. Exclusively from developers that have years of experience with tables and who haven't spent any significant amount of time with CSS. Once they spend a week or two coding CSS every day, they wonder how they did without it. And if they never had much experience with tables in the first place, they don't want to bother with all the crap associated with tables (counting rowspans is never intuitive).

Really, just think about the difference involved in "just move that over to the right a bit" for the two approaches. With tables you have to insert an extra column, count rowspans, if there's any rows spanning across the whole layout you have to break for that, alter its colspan and put another cell below it with rowspans... and with CSS, you open up the stylesheet and change one number.

Re:No CSS on that site.

[Anonymous Coward]

"Anyone taking even a cursory look at the sitepronews.com article source code can see that the layout is done with the usual mess of tables."

There's no integrity in journalism. Just the other day I was watching a TV news report about a murder and it turned out Robin Meade has never murdered anyone!

Re:No CSS on that site.

[arkanes]

It isn't valid semantic markup if you have to nest everything in 18 layers of divs and spans to convince a browser to apply your CSS rules correctly, either. There's nothing "less" semantic about using tables instead, and there's some serious advantages - like the fact that all major and most minor browsers will render them identically, that they're far more intuitive, and that they allow re-flowing in a way that you can only do with CSS attributes that are explicitly designed to mimic the layout algorithms of "traditional" tables. Which, of course, IE doesn't implement. And much as it'd be nice to simply use the tags anyway, as a practical matter you can't simply ignore IE unless you're creating a special purposed or otherwise private web site.

HTML is not a semantic markup language, hijackers in the W3C not withstanding. It's a rich text markup format. It always has been. XML is (well, can be) semantic markup, and if you really want to store your pages semantically, use XML (with no styling at all), and transform them with XSLT. Dispense with the ridiculous concept of "semantic HTML", which is useless in practice and almost useless in theory, and try using the correct tools for the right job - XML for storing your content, and HTML for presenting it.

Re:No CSS on that site.

[R.Mo_Robert]

Either that or (worse) you compromise the design to make it fit the limitations of a pure CSS layout.

Because everybody knows presentation is more important than content?

Re:No CSS on that site.

[arkanes]

Okay, vertical positioning, I'll give you. But fluid layouts? That's not hard at all. Websites are fluid by default, they only stop being fluid when you set explicit widths using fixed units. You can do that with CSS or tables.

There is no way in CSS to say something like "size this element relative to the size of that other element" without a parent-child relationship between them. That's the biggest flaw in CSS and it's supposed "semantic markup", because the parent-child stuff is determined by your *content*, the markup, and not just by the CSS.

Your point about the difficulty of moving stuff around in tables is well taken, but on the other hand compare the difficulty of moving from a 3-column fixed format to a 2-column flowed one in CSS vs tables - the hacks to do that kind of flowed layout (at least cross-browser) will require a total reworking of the CSS, as well as content changes. The table version requires changing a couple tag attributes and some reformatting. And even with the huge amount of CSS hackery required to get a basic "newspaper" style column layout (and it takes a very detailed knowledge of CSS to implement this, although [of course] most people will simply lift it from elsewhere), it *still* doesn't demonstrate the same, intuitive behavior that table rendering does when you size it very small or very large. To the best of my knowledge, you cannot make a column based layout in CSS without defining explicit widths at some point without relying on the table-layout attributes, which are not widely implemented.

And it still grates on my nerves how people will proudly display their hacks with comments and exploiting bugs in parsers and 100s of lines of CSS to create "cross browser" CSS, while at the same time decrying table based markup as "hackish". Here's a hint - your bug reliant stylesheets are actually an *obstacle* to the implementation of proper CSS support in IE.

Re:No CSS on that site.

[xENoLocO]

Oh, ye with little experience.

Those of us who have been dealing with CSS for several years have no problem at all visualizing the layout. The big question here is, how do you visualize YOUR layout when you can't have images loading? How do you visualize your table layout on a cellphone? How do you visualize your layout when you cant visualize anything at all... for example if you have low vision or no vision?

Maybe instead of thinking about getting the job done fast you should consider getting the job done right when you're doing your estimates.

Have a good one!

This post brought to you in semantic XHTML.

Re:No CSS on that site.

[schon]

there's some serious advantages - like the fact that all major and most minor browsers will render them identically, that they're far more intuitive, and that they allow re-flowing in a way that you can only do with CSS attributes that are explicitly designed to mimic the layout algorithms of "traditional" tables

If you really believe all of this, then I don't think theres hope for you... unless you define "major and minor" browsers as "IE". Tables get rendered differently by different browsers, just like CSS gets rendered differently.. the only thing is that it's easier to work around CSS bugs

CSS is *WAY* more intuitive than tables ever were (and there's a reason - because it's designed that way.) You use DIVs to define blocks of code, then use CSS to say how you want them positioned. With tables, you have to screw around with row and column spans *in the HTML itself*.

It's pretty obvious that you prefer tables because you've spent a lot of time learning their quirks - don't slam CSS just because you don't know how to use it properly.

try using the correct tools for the right job

If you really believed this, you'd be using CSS.

Re:No CSS on that site.

[Anonymous Coward]

>> Oh, ye with little experience

Yeah! Looking at your site, you are ovbviously a total fucking design god with decades of experience.

While no doubt semantically correct, your site looks like a piece of dogshit and you clearly have more time on your hands than things to say!

Re:No CSS on that site.

[Mant]

Okay, vertical positioning, I'll give you. But fluid layouts? That's not hard at all. Websites are fluid by default, they only stop being fluid when you set explicit widths using fixed units. You can do that with CSS or tables.

I once tried to do some of our corporate intranet pages to use pure CSS, but couldn't. The mixture of headers, footers, fixed and flowing columns I just couldn't get to work.

CSS seems nice for simple layouts, or complex ones using fixed positioning. Complex ones with some fixed some flow though it seems to struggle with.

If you are an experienced designer, then you've already done similar layouts a hundred times before, so you have the code and bug workarounds memorised and making it "work across all the common browsers" is at the very least least as easy as dumping a load of table code into each page.

I'm an experienced designer but if I can't get CSS to do what I want (or find an example on the web) where does this code come from?

Er, no. Not semantic. Not at all. If you are using tables for anything other than tabular data, it's not semantic.

True, but HTML isn't semantic, never was, and doesn't look like it ever will be.

I've heard that before. Exclusively from developers that have years of experience with tables and who haven't spent any significant amount of time with CSS.

Multi columns in tables still seems much easier to me than CSS. Plus if its tricky lots of HTML editors will do a GUI interface for layout with tables behind the scenes. The code is nasty but it wins hands down for speed and being intuitive.

CSS is certainly great for fonts, sizes, colours and the like and I use it all the time. Complex flowing page layout though? Not there, not yet at least for me.

Re:No CSS on that site.

[arkanes]

Table layout algorithms have been essentially identical in all major browsers for at least 4 years. CSS layout, on the other hand, has at least 4 years to go before it's anywhere close.

I've been using CSS for many years. I've been using tables for many years, too, but don't mistake the fact that I'm aware of deficencies both in the CSS stndard and in it's imlpementations for a lack of knowledge. And the fact that you're telling me I need to use blocks of DIVs to layout my stuff is telling me that you're just another blind herd following CSS monkey, rather than anyone who can actually evaluate the usefullness and appropriateness of claims like "semantic markup". There's no excuse for telling someone to replace thier tables with divs "just because".

And just because you managed to find some stylesheet on a CSS site that you use blindly to work around certain CSS bugs (no doubt without realizing that the stylesheet itself relies on other bugs to work correctly, and the widespread reliance on these bugs is a major obstacle to the uptake of correct CSS implemetations in IE), doesn't mean that CSS incompatibilities are easier to work around than the practically non-existant table ones.

Re:No CSS on that site.

[Bogtha]

There is no way in CSS to say something like "size this element relative to the size of that other element" without a parent-child relationship between them.

Yes, there is. You can do it with CSS tables. Internet Explorer doesn't understand them, but we're talking about the capabilities of CSS, not the capabilities of Internet Explorer, right?

In any case, there's very few instances where a parent-child relationship isn't available to be used in this way. That's just the nature of web pages - things that are visually related tend to be structurally related too.

compare the difficulty of moving from a 3-column fixed format to a 2-column flowed one in CSS vs tables

That's not a very good example; in both cases it usually requires drastic alterations to the page structure.

The table version requires changing a couple tag attributes and some reformatting.

Come off it. Typical table layouts would need way more changes than that. I've made this change quite a few times to various websites of both kinds. The CSS websites, I've had to rearrange a couple of <div> elements and change a single stylesheet. The table websites, I've had to completely rework dozens or hundreds of pages, depending on whether they were dynamically generated or static.

And even with the huge amount of CSS hackery required to get a basic "newspaper" style column layout (and it takes a very detailed knowledge of CSS to implement this, although [of course] most people will simply lift it from elsewhere)

Rubbish. Float the first column over to the side, set percentage widths on each column, and clear the footer. That's not "a huge amount of CSS hackery", and it's even easier if you don't have to support Internet Explorer.

it *still* doesn't demonstrate the same, intuitive behavior that table rendering does when you size it very small or very large.

That's what min-width is for. I don't think table behaviour at extreme sizes is very intuitive at all, and I think it's just a convenient distraction - how many people actually need to resize their window to extremely small sizes and keep the layout intact?

To the best of my knowledge, you cannot make a column based layout in CSS without defining explicit widths at some point

You are being ambiguous. Did you mean fixed width?

Here's a hint - your bug reliant stylesheets are actually an *obstacle* to the implementation of proper CSS support in IE.

Unless you are an Internet Explorer developer, you'd better back off on that point, because they have posted on their weblog that they are going ahead and fixing CSS 2 selectors anyway. So it's not an obstacle and it looks very much like you've just made that up.

Re:No CSS on that site.

[AaronLawrence]

Why does the search box on your site sit partway off the page in Mozilla 1.7.8?

Never mind, it works ok in IE :D

Re:No CSS on that site.

[Bogtha]

I'm an experienced designer but if I can't get CSS to do what I want (or find an example on the web) where does this code come from?

Well you don't start out with a complicated example when you learn other stuff, do you? Back off on the corporate intranet pages and do a few simple layouts to begin with. Once you're familiar with the basic concepts, it'll be easier to move on and do more complicated things.

Experience with tables doesn't translate to experience with CSS. You aren't experienced, you are a newbie as far as CSS layouts are concerned.

HTML isn't semantic, never was, and doesn't look like it ever will be.

What are you talking about? "Semantics" means "meaning". If you are using element types that mean something (as opposed to element types that just give a particular visual effect), then you are using semantic HTML. HTML has had semantic element types since the very first version.

The code is nasty but it wins hands down for speed and being intuitive.

People keep saying tables are intuitive. They aren't. You've just been using them a long time. Lots of rowspans and colspans aren't intuitive. Spacer gifs aren't intuitive. Superfluous closing tags aren't intuitive. It's all just stuff you've memorised. Of course something new is going to be at a disadvantage if you are assuming that you are going to be just as good with the new stuff even though you haven't built up this experience first.

Re:No CSS on that site.

[arkanes]

Yes, there is. You can do it with CSS tables. Internet Explorer doesn't understand them, but we're talking about the capabilities of CSS, not the capabilities of Internet Explorer, right?

Maybe you are. I'm talking about not only the CSS standard, but also the usefullness of CSS layout vs. tables in the real world, where implementations matter. Talking about what CSS3 could do if there was 100% browser support might be interesting over a beer, but it's not very usefull when it actually comes to developing web pages. In any case, there's very few instances where a parent-child relationship isn't available to be used in this way. That's just the nature of web pages - things that are visually related tend to be structurally related too.

Thats why there's no need for lots of semantically meaningless divs and spans in CSS markup, right? So if I go to a CSS advocacy site I shouldn't see any of those, or any suggestions to use those to implement the layouts I want? The direct parent-child relationships needed to "hook" in your CSS are fairly rare. Thats why you end up creating them, either with div/span (meaningless markup, existing for no other reason than to manage layout and in my personal view, a bigger sin than using tables), or by going with tables and dispensing with the notion of semantic markup alltogether.

Re:No CSS on that site.

[Bogtha]

we're talking about the capabilities of CSS, not the capabilities of Internet Explorer, right?

Maybe you are.

You are too, when you say things like "There is no way in CSS to say...". If you mean "You can't do [x] in Internet Explorer with CSS", then say that instead of the misleading statements about CSS.

Talking about what CSS3 could do if there was 100% browser support might be interesting over a beer, but it's not very usefull

Except we're talking about what is in CSS 2, not CSS 3, which has been a finished specification for over seven years, and which works in all major browsers bar one. That's very useful, and not even remotely like the unimplemented future support that you are trying to characterise it as.

Thats why there's no need for lots of semantically meaningless divs and spans in CSS markup, right?

Straw man, I didn't say that. I said that structure and visual layout tend to be related, so the shortcoming of Internet Explorer's CSS layout you point out (and label as a shortcoming of CSS itself) isn't a big problem, because there is a preexisting structure there that you can use. That isn't at all like saying that superfluous <div> and <span> elements aren't sometimes necessary.

The direct parent-child relationships needed to "hook" in your CSS are fairly rare.

We'll have to agree to disagree there then, because I see the exact opposite. And let's not forget the context - we're talking about making the sizes of elements match up. The most common scenario I see that requires that is vertical navigation bars - where a ul > li, parent > child relationship is perfectly suitable, and a <div id="navigation> is quite reasonable too - no unnecessary divs and spans there.

meaningless markup, existing for no other reason than to manage layout and in my personal view, a bigger sin than using tables

Sin? Lighten up.

You seriously think that misusing an element type with a rigid definition - tabular data - for something else is better than using a generic element type intended to divide the page up into sections - to divide the page up into sections?

Re:No CSS on that site.

[Anonymous Coward]

Presentation is not *more* important than content, but it certainly *is* important.

I expect you'd prefer all websites to present raw information in an unbroken screeds of text, without paragraphs or columns, in 14pt black Times New Roman.

Whether you care or not, for the vast majority of people good, attractive design matters (if only subconciously) and is as much a part of communicating an idea as text is.

Re:No CSS on that site.

[nsasch]

You just made the last couple of days of my life seem pointless. I've been trying to make a 3-column table-less, CSS-based, XHTML page with a fluid center column. Next site I work on, I'm going to use XML, XSLT, and XHTML. What I've been doing for a while, is making a template file and then my content is in .tmpl files with a sort of XML style to them. I run ./rebuild and it rebuilds all my pages based on the template and content.tmpl file.

Re:No CSS on that site.

[arkanes]

I'll be clear - I'm talking *both* about limitations of the CSS spec, *and* of it's current implementations. One thing you cannot do, in any version of CSS, is size or position an element relative to any *other* element except it's immediate parent or the canvas. Period. That's a limitation and it's the root cause of a lot of the spurious divs and spans you see floating around. It is *not* an IE only problem - it's a limitation of the cascade model of CSS, and the fact that it's tied to a parent-child relationship defined by the content rather than being manipulatable by the markup. Its made worse by the poor selector and attribute support in IE, but even if IE supported CSS3 100% it wouldn't go away entirely. Even table-layout doesn't fix this - it simply allows you to apply the classic table layout algorithms to arbitrary elements - but those elements still need to be present. If IE7 would implement table-layout, though, that'd probably be enough for me and I'd move away from tables for my gross page layout (I use CSS for the stuff it supports well, like floating images within text, fiddling bits around, and static content areas. I use tables for content boxes).

There are many other limitations which are caused by current implementations - for example, until IE supports table-layout, you can't get the relative flowing sizing and positioning tables offer without using (of course) tables.

Presenting what *claims* to be semantically usefull markup, while in reality it's laden with non-semantic elements (like div and span) is useless. At least when you declare it as HTML, with tables for layout and everything, you're being up front about what you're presenting. Thats aside from the fact that tables as layout *are* a defacto standard for years now, and while it'd be cool to see a browser with the "rich table" functionality that the w3c suggests (like rendering a table in a data grid style control, rather than the site providing DHTML to do it), we need a lot wider uptake of both CSS support and desire on the part of web designers before thats practical. So, in the meantime, I'm going to be part of the problem. If I actually want to present a useful, semantically marked up version of information, I'll do it with XML. And the HTML I present will be created via XSLT. And thats a lot more powerful and usefull of a model than "semantic HTML" is, or ever will be. Something that too few people ever ask themselves is what the usefullness of this "semantic markup" thing is anyway.

As a final point, the (vast) majority of the HTML I create is done indirectly, via a CMS or a web framework, or whatever. It's the same in a large portion of the sites on the web today. In that environment, the managability of the generated HTML is a minor concern, and the maintenance features of the CSS are overshadowed by the features in the CMS/framework - templates and customized server-side tag libraries provide the same "site wide" updating features, rendering that benefit of CSS moot.

I'm a fan of what CSS allows you to do. I'd really, really like IE to cowboy up and get a full CSS2 implementation going. I'd like even more for a full CSS3 implementation. I think seperating content from presentation is a good idea, although it's not a neccesary as people like to claim it is, and I think that (X)HTML is a crappy way to do it. There's not one application of "pure semantic markup" that wouldn't be better addressed by sending XML instead of HTML. I'd like even more if we broke off from CSS totally, and implemented something a little more flexible and powerful (pseudo-classes, for example, are a total hack). And, of course, I'd like it if this new language was implemented identically and at the same time across all browsers. I'd also like a pony.

Re:No CSS on that site.

[iBod]

Well said!

I have yet to see any browser grossly mangle a table layout in they way the commonly do with CSS floats and DIVs.

A question for those who endlessly bang on about 'semantic markup' would be "what semantic value do DIVs and SPANs add"?

Tables do at least have some semantic value when used for actual tabular data - DIVs and SPANs have none at all - they only serve as containers to which styles are applied.

If you want your markup to be purely semantic, it should have no presentational aspect at all (no DIVs, no SPANs).

As you say, the logical conclusion would be to use XML and XSLT. The trouble is, it's not always a practical or desirable solution.

Re:No CSS on that site.

[Bogtha]

One thing you cannot do, in any version of CSS, is size or position an element relative to any *other* element except it's immediate parent or the canvas. Period. That's a limitation and it's the root cause of a lot of the spurious divs and spans you see floating around. It is *not* an IE only problem - it's a limitation of the cascade model of CSS

You are wrong. Set two sibling elements to display: table-cell and set their width to 50%. They are both the same width and height in Firefox, Opera and Konqueror. This is quite useful when you are coding for an intranet or any other situation where you don't have to bother with Internet Explorer.

There are many other limitations which are caused by current implementations - for example, until IE supports table-layout, you can't get the relative flowing sizing and positioning tables offer without using (of course) tables.

What do you mean by "relative flowing sizing"? I can't point out ways of doing it with CSS when you are being so vague.

Presenting what *claims* to be semantically usefull markup, while in reality it's laden with non-semantic elements (like div and span) is useless.

When I have a set of pages using semantic markup, I can run a script to, say, generate an index of tables for a few thousand pages. When I have a set of pages using presentational markup, I'm stuck trying to figure out a hack to distinguish between "real" tables and layout tables.

If table layouts weren't so widespread, browsers could turn tables on their side when they are too wide for the canvas - which works for "real" tables but breaks table layouts. That's an example of table layouts making things worse for everyone, not just the particular users of one website.

And the HTML I present will be created via XSLT. And thats a lot more powerful and usefull of a model than "semantic HTML" is, or ever will be.

You're still generating HTML - and that HTML still has to be laid out by some means. XSLT doesn't save you from that.

There's not one application of "pure semantic markup" that wouldn't be better addressed by sending XML instead of HTML.

That's great. Instead of a data format that everyone understands the meaning of (HTML), you want a format that everybody can parse, but nobody understands the meaning of but you. XML doesn't have embedded semantics that makes software magically understand it. XML solves the parsing problem, that is all. XML is a meta language - something in "plain" XML means absolutely nothing until it's associated with a specification people know and care about.

Re:No CSS on that site.

[R.Mo_Robert]

I expect you'd prefer all websites to present raw information in an unbroken screeds of text, without paragraphs...

Umm, no, paragraphs are part of content--hence, the existence of the <p> element in HTML. They have semantic meaning.

...in 14pt black Times New Roman.

No, but that's what CSS is for, and if I don't like it, at least I can turn it off (if my browser conforms to the W3C's recommendation) and use the font I specified in my browser.

I have nothing against Web pages looking pretty--but when it's 2005 and they're still using HTML rather than CSS to do it, it's time to wake up. It will generally make the pages lighter, faster to load, reduce bandwith costs, and improve accessibility (provided you use semantic HTML)--and I don't mean just for blind users; this goes also for people on cell phones, etc.

Re:No CSS on that site.

[arkanes]

You are wrong. Set two sibling elements to display: table-cell and set their width to 50%. They are both the same width and height in Firefox, Opera and Konqueror. This is quite useful when you are coding for an intranet or any other situation where you don't have to bother with Internet Explorer.

That doesn't address what I said - both those elements will still be sized and positioned relative to the parent, not to the sibling - the fact that they're the same size in that instance is a coincidence, and it doesn't address the positioning.

You're still generating HTML - and that HTML still has to be laid out by some means. XSLT doesn't save you from that.

Thats exactly the point. The generated HTML is designed to be displayed in a browser, and there's no need to worry about whether or not I can parse it to generate table indexes, because I don't care - the core XML is what I'd use for that. It's better suited anyway.

That's great. Instead of a data format that everyone understands the meaning of (HTML), you want a format that everybody can parse, but nobody understands the meaning of but you. XML doesn't have embedded semantics that makes software magically understand it. XML solves the parsing problem, that is all. XML is a meta language - something in "plain" XML means absolutely nothing until it's associated with a specification people know and care about.

I doubt you can give a usefull example of parsing semantically usefull data out of HTML that doesn't rely on either explicit or implicit assumptions about the data format either. A list of all the UL elements on your site is pretty useless. A list of all of the tables of contents is more usefull, but you won't get that from HTML. Now, I know that HTML actually has a pretty good set of semantic tags and that you can get a lot of information out of your pages, assuming everything is marked up with those tages. But, and this is important, anything thats *not* in HTML leaves you stranded. Thats where the X in XML comes from. Your XML files will be smaller and more concise than your HTML (because it'll contain *just* the data, and little need for the ids/classes/markup used for your styling), so it'll be simpler and easier to extract the data you want. And all the rest of the boilerplate on your site won't be present - just the data, ma'am. You still have to know what the data you want looks like and where it is - but thats an aspect of any sort of data mining and using HTML instead won't save you from that. Moreover, using XML allows you to store rich metadata or other information that you can't (or might not want) to embedd in the HTML. Unless every table in your 1000s of pages is the same thing, then storing metadata about what information is in the table might be worth doing. How about indexing all the images on your site? img tags only allow 2 bits of metadata, both of which are supposed to be human-readable and not best suited for programmatic classification. If your XML files include annotations with, say, chapter and figure references, you could easily extract all the figures associated with a specific chapter. Not so easy with your HTML documents.

Re:No CSS on that site.

[Bogtha]

Table layout algorithms have been essentially identical in all major browsers for at least 4 years.

Then how come people complained when Netscape 6 was released and it "broke" their table layouts? And how come people complained when Internet Explorer 6 was released and it "broke" their table layouts?

I've been using CSS for many years.

Then how come you feel the need to argue against straw-men? Who is telling you to use "18 layers of divs and spans"?

There's no excuse for telling someone to replace thier tables with divs "just because".

Again with the straw-men. Who is telling people to replace their tables with divs "just because"?

the widespread reliance on these bugs is a major obstacle to the uptake of correct CSS implemetations in IE

I've already pointed out this is untrue. The Internet Explorer developers are implementing correct CSS without stopping on account of people relying on these bugs.

Re:No CSS on that site.

[Domo-Sun]

Umm, it isn't valid semantic markup if you are using tables for layout.

Maybe table layout is not 'valid' but it works. there are box model bugs in a few browsers that make it difficult to use DIVs for structuring a page.

What I currently do is enable the Light version of /. and use opera and activate my user stylesheet. I talk about this in my two journal entries. This would be easy for /. to implement if they're looking for a quick fix to reduce bandwidth. Just add a css option to the light version, and tell the geeks why it's better. Most people are smart here and would switch.

Re:No CSS on that site.

[iBod]

Table hacks?

What about the plethora of CSS hacks you have to memorize?

Hideous hacks implemented by relying on borked parsers! How is that better?

What table hacks anyway? cellspacing="0" cellpadding="0"? I think I can live with that one.

All remotely current browsers can render a table pretty much identically.

Re:No CSS on that site.

[zkn]

You can't compare tables to CSS. One is a tag the other is a stylesheet language.
The point is that XHTLM/CSS using tabletags are easier and in many cases better then XHTML/CSS using nested divs styled to apear like the table tags.
CSS is *WAY* more intuitive than tables ever were
If you mean that semantic HTML is more intuitive then nonsemantic HTML then you are correct. If you mean that 18layers of nested divs all styled differently to get render correctly in all mayor browsers(From IE to khtml) is more intuitive then a tablelayout, then you are wrong.
Both are nonsemantic, tables however can be directly interprited to outline the ideer(A two collom design being the easiest example) whereas two divs nested in another div will tell you nothing of the design.
Using CSS to get around using tables for design isn't in itself "a better way(tm)", but if you want semantic HTML then CSS is pretty much the only way to do it, and still have the content fit a design. However if you just want something to look "the way it should(tm)" then Tabels are still a valid option.

Re:No CSS on that site.

[Anonymous Coward]

Either that or (worse) you compromise the design to make it fit the limitations of a pure CSS layout.

Yes... God forbid you should compromise your design in order to increase functionality! Woe!

Re:No CSS on that site.

[Bogtha]

both those elements will still be sized and positioned relative to the parent, not to the sibling - the fact that they're the same size in that instance is a coincidence

You are wrong, again. Why didn't you try it? Seriously, I explained exactly how to do it and you didn't bother trying it out. The elements will be sized according to the larger of the two elements' contents. Try it.

The generated HTML is designed to be displayed in a browser, and there's no need to worry about whether or not I can parse it to generate table indexes, because I don't care - the core XML is what I'd use for that. It's better suited anyway.

Maybe it's better suited for you but it's not better suited to everybody consuming your pages. Like the table-on-its-side example I gave.

I doubt you can give a usefull example of parsing semantically usefull data out of HTML that doesn't rely on either explicit or implicit assumptions about the data format either.

Huh? The data format is HTML. The semantics are defined by the HTML specification you adhere to. You don't have to assume that HTML means anything, the semantics are supplied for you. That was my whole point - with generic XML, nothing is supplying the semantics.

A list of all the UL elements on your site is pretty useless.

No, but a list of all the "real" tables can be useful. And hey, I already gave that as an example.

A list of all of the tables of contents is more usefull, but you won't get that from HTML.

Why not? You can pull out the heading elements on each page to build a sitemap. If, of course, you are using semantic HTML (e.g. <h1>) and not presentational HTML (e.g. <font size=4><b>).

You still have to know what the data you want looks like and where it is - but thats an aspect of any sort of data mining and using HTML instead won't save you from that.

If I have an HTML document, I know exactly what the elements mean. If I have a generic XML document, I'm not going to know what the elements mean unless I can find a specification that describes the semantics, and even then it will be a non-standard data format. Just because the syntax is standard, doesn't mean anything else is.

You are still stuck in the mindset that the only people who need to extract meaning from web pages are the original developers. This has never been the case, and never will be. Your custom XML dialect is useless to me if I'm, say, writing a Greasemonkey script to remember things about the pages I visit.

Unless every table in your 1000s of pages is the same thing, then storing metadata about what information is in the table might be worth doing.

You mean like HTML provides with the summary attribute? No need for XML there.

If your XML files include annotations with, say, chapter and figure references, you could easily extract all the figures associated with a specific chapter. Not so easy with your HTML documents.

With HTML, each chapter would likely be on a separate page. Even if it wasn't, you can extract what you suggest by looking at where the figures are placed in relation to heading elements. Again, no need for XML.

Re:No CSS on that site.

[CRCulver]

Presenting what *claims* to be semantically usefull markup, while in reality it's laden with non-semantic elements (like div and span) is useless

span isn't semantic? Of course it is. How else can you apply the lang and xml:lang attributes to a foreign-language word in a text in another language? This is necessary if you want text-to-speech software to work ideally, and if you want to insert, say, Chinese ideographs when the vanilla font of your stylesheet is Latin-only.

Re:No CSS on that site.

[boomgopher]

CSS and the box rendering model is biased towards displaying web documents. But when you're working on web applications, the box model is a pain in the ass to deal with.

It's very hard to get a fluid layout in CSS that allows for dynamic content, resizable pages, and scalable fonts. Increase the font size on some of these slick CSS pages sometime and you'll see what I mean. Tables are way easier to do, without weird/buggy/unexpected behavior. CSS needs a more flexible grid-based layout, IMHO

Re:No CSS on that site.

[iBod]

Okay, vertical positioning, I'll give you. But fluid layouts? That's not hard at all. Websites are fluid by default, they only stop being fluid when you set explicit widths using fixed units. You can do that with CSS or tables.

Accurate, repeatable vertical positioning is essential for serious design. CSS just doesn't provide it out of the box - end of story.

If you are an experienced designer, then you've already done similar layouts a hundred times before, so you have the code and bug workarounds memorised...

Sure. Templates consisting of inviting 'boxes' and 'columns' are a breeze. I have a shedload of them for ever occasion!

The trouble is they often break apart or elements flow incorrectly when you insert any real world content into them.

Er, CSS is far less limited than tables (check out the CSS Zen Garden), and I've seen way, way, way more websites out there using tables that all look alike.

Thanks. I'm very familiar with Zen Garden. I do use CSS all the time, I just sometimes use tables for certain layout situations (which I then style using CSS). You're preaching to the choir.

Er, no. Not semantic. Not at all. If you are using tables for anything other than tabular data, it's not semantic.

True, but how are DIVs and SPANs more 'semantic' exactly?

I've heard that before. Exclusively from developers that have years of experience with tables and who haven't spent any significant amount of time with CSS.

You assume I know nothing of CSS but I've used it intensively, almost everyday for years and it often drives me nuts.

I'm always hearing about how great CSS is from 'experts' who think they know it but don't have to work with it everyday.

Re:No CSS on that site.

[Anonymous Coward]

That's great. Instead of a data format that everyone understands the meaning of (HTML), you want a format that everybody can parse, but nobody understands the meaning of but you.

How is that any different from using DIV and SPAN and adding a class. Two generic elements that can mean anything, unlike P or H1 which are already known by everyone, then you add the style.

Adding a class to a DIV does not make it more accessible, except to yourself.

Re:No CSS on that site.

[arkanes]

You are wrong, again. Why didn't you try it? Seriously, I explained exactly how to do it and you didn't bother trying it out. The elements will be sized according to the larger of the two elements' contents. Try it.

Maybe its because you don't know what the hell you're talking about. They're sized to 50% of the containing table, just as with a standard HTML table. They are *not* sized relative to each other, which is why you can't position one relative to the other. It's true that without an explicit width on the parent table, the width will be determined from the content of the cells (a vast improvement over CSS positioning without table-layout), but it still relies on the strict parent-child relationship thats fundamental in CSS.

Maybe it's better suited for you but it's not better suited to everybody consuming your pages. Like the table-on-its-side example I gave.

People who want to consume that data will consume the raw XML.

Why not? You can pull out the heading elements on each page to build a sitemap. If, of course, you are using semantic HTML (e.g. ) and not presentational HTML (e.g. ).

No you can't. Not unless you know what element the heading is contained in (title? h1? h1 class="pageheader"?).

If I have an HTML document, I know exactly what the elements mean. If I have a generic XML document, I'm not going to know what the elements mean unless I can find a specification that describes the semantics, and even then it will be a non-standard data format. Just because the syntax is standard, doesn't mean anything else is.

Bull. You'll know what the tags mean if and only if there is an HTML tag that specifies what a section is, and then only if there's no fuzziness about definitions. The only way you can meaningfully extract information from an HTML document is either through explicit knowledge of what the markup is intended to convey, or by inferring that knowledge by inspecting the document. That is exactly the case with XML as well.

You mean like HTML provides with the summary attribute? No need for XML there.

Sure, if you want to ignore standards and replace whats supposed to be a human-readable summary with a programmatic identifier. Get the best of both worlds and generate your human-readable text from a programmatic identifier, without losing either feature.

With HTML, each chapter would likely be on a separate page. Even if it wasn't, you can extract what you suggest by looking at where the figures are placed in relation to heading elements. Again, no need for XML.

So you need to have implicit knowledge of the structure - either you have to know that a page is one chapter, or you have to know how to extract a meaning from the placement of the image and surrounding tags. Thats stupid as hell - explicitly mark up your data and present that instead.

Re:No CSS on that site.

[Bogtha]

Accurate, repeatable vertical positioning is essential for serious design.

Be more specific, please. When you say "accurate, repeatable vertical positioning", exactly what do you mean? Because as far as I can see, a vast number of websites get by just fine with what CSS offers, so it's obviously not as "essential for serious design" as you make out.

I'm very familiar with Zen Garden.

You said "you compromise the design to make it fit the limitations of a pure CSS layout." in the context of CSS versus tables. You were strongly suggesting that table layouts are more flexible than CSS layouts. And yet, if you are familiar with the CSS Zen Garden, then surely you are aware that there are loads of things you simply cannot do with table layouts but you can with CSS layouts. That's why I pointed it out.

If you are using tables for anything other than tabular data, it's not semantic.

True, but how are DIVs and SPANs more 'semantic' exactly?

Semantics is the meaning of things. The <div> and <span> element types aren't "more semantic" than the <table> element type. There's no such thing as a "more semantic" element type. Element types mean what they mean.

When you use <table> elements for anything other than tabular data, then it ceases to mean what it is supposed to mean - so the markup on your website is not semantic. When you use <div> or <span> elements, you are not compromising their semantics because they are generic elements that basically mean "this is a bit of the document and I can't be more accurate than that".

It's like pointing to a book and saying "this is a newspaper". That is incorrect. Pointing to a book and saying "this is an object" is correct, if vague.

Re:No CSS on that site.

[Domo-Sun]

span isn't semantic? Of course it is. How else can you apply the lang and xml:lang attributes to a foreign-language word in a text in another language? This is necessary if you want text-to-speech software to work ideally, and if you want to insert, say, Chinese ideographs when the vanilla font of your stylesheet is Latin-only.

SPAN is a generic tag, unlike H1, it has no meaning. Maybe you can add meaning to it, but it would still have no standard meaning to the blind, or anyone but yourself. There is also nothing stopping bad designers from adding the wrong meaning to SPAN, making it impossible for the blind to be sure exactly what to expect from the SPAN tag.

CSS is not a panacea to the disabled.

Re:No CSS on that site.

[RedSteve]

If you want your markup to be purely semantic, it should have no presentational aspect at all (no DIVs, no SPANs).

Au contraire. How does a div or span tag impart ANY presentational information? In fact, those tags are inherently semantic -- they don't tell the browser how to present any information; they merely inform the user agent that the content contained within those tags are related in some way.

Of course, div and span tags without classes or IDs are pretty useless, so you have to add those attributes. However, by doing such a thing, you're only making those tags that much more semantic...by telling the user what the relationship of the content within those tags are.

The fact that you can attach styles to classes or IDs doesn't make divs and spans presentational; any visual presentation information is a function of the style sheet, not the divs and spans. I can still go into the source code of a page that has been marked up semantically, and read the source text in the order in which it was written, and still get a strong idea of what the author meant to convey. On the other hand, if I go into a slice table and try to read the segments of text contained between the calls to .gif files, there's no guarantee that I will be able to find all the blocks of text, let alone read them in the order in which the author intended.

Of course, the more practical application of coding using semantic markup is not having a human read the source code, but instead having the same page be able to be used by screen reader, palmtop browser, cell phone, or even a printer. By dividing related page pieces through div and span tags, it makes it that much easier to present the same page on all those different devices.

Re:No CSS on that site.

[Domo-Sun]

It's like pointing to a book and saying "this is a newspaper". That is incorrect. Pointing to a book and saying "this is an object" is correct, if vague.

No, it's more like saying this could be just about anything in the known universe, especially since that's what everyone uses DIV and SPAN for. The only person who really knows, is the author.

You can invent your own 'semantic' meanings for DIV and SPAN, but unless the user becomes a CSS expert and studies the source, it might as well be gibberish.

Re:No CSS on that site.

[Bogtha]

Maybe its because you don't know what the hell you're talking about. They're sized to 50% of the containing table

The containing table is not the parent element though. The parent element can be anything, and any size, and it doesn't matter. The "containing table" is merely an anonymous box that is assumed to exist, it's not part of the DOM, not part of the document and you don't have to create it.

They are *not* sized relative to each other

Make one bigger. The other one gets bigger too. Make one smaller. The other one gets smaller too. Nooo... of course they aren't sized relative to each other. It's... what did you call it? A "coincidence"?

Your original statement:

One thing you cannot do, in any version of CSS, is size or position an element relative to any *other* element except it's immediate parent or the canvas. Period.

Do you still stand by that?

People who want to consume that data will consume the raw XML.

How? They don't know what it means. It's not a standard data format, only the syntax is standard. They can get a document tree from it, but what that document tree means is a mystery. Like I said a few posts ago, XML solves the parsing problem, not the semantic problem. A standard data format like HTML solves the semantic problem.

Why not? You can pull out the heading elements on each page to build a sitemap. If, of course, you are using semantic HTML (e.g. ) and not presentational HTML (e.g. ).

No you can't. Not unless you know what element the heading is contained in (title? h1? h1 class="pageheader"?).

And wait... what tells you which element types headings occur in... that's right, the HTML specification. What tells you which element types headings occur in for generic XML... oh yeah, nothing. Once more, XML solves the parsing problem, XML alone doesn't buy you anything as far as semantics go.

You'll know what the tags mean

You mean the element types. I can tell you with 100% certainty what the tags mean for every XML language ever invented. They mean "I'm starting an element of this type".

if and only if there is an HTML tag that specifies what a section is

What on earth are you talking about? If I see an <h1> element, then I know that what is contained within is a top-level heading. I know this because the HTML specification says so.

That is exactly the case with XML as well.

No, that is the case with some standard XML formats. Not XML in general and not any particular ad-hoc format you might come up with. The semantics are defined in the particular XML application specifications, not in the XML specification itself for all XML dialects. XML is a meta-language, not a markup language itself. It has no semantics. HTML does because they are defined in the HTML specification.

You mean like HTML provides with the summary attribute? No need for XML there.

Sure, if you want to ignore standards and replace whats supposed to be a human-readable summary with a programmatic identifier.

It wasn't clear you wanted to store a programmatic identifier. Now, what on earth could I use in HTML for that? Maybe... oh I don't know... the id attribute? Again, no need for XML there.

So you need to have implicit knowledge of the structure

No, you don't. Did you actually read what I wrote? You can get the informati

Re:No CSS on that site.

[Bogtha]

No, it's more like saying this could be just about anything in the known universe

I believe I said that by using the word "object".

You can invent your own 'semantic' meanings for DIV and SPAN

You weren't listening, were you? It's not that <div> and <span> elements are "more semantic" than <table> elements, it's that <table> elements are for tabular data, not for generic sections of the document, unlike <div> and <span> elements.

It might not seem useful to say to somebody "fetch me every object in that room", but it's useful to say to somebody "fetch me every newspaper in that room" and not have them come back with newspapers, books, letters...

Re:No CSS on that site.

[Bogtha]

How is that any different from using DIV and SPAN and adding a class.

It isn't, which is why <div> and <span> elements should only be used as a last resort when there aren't any more accurate element types to use.

Re:No CSS on that site.

[inditek]

"Valid" and "semantic" are not the same thing. And using a table for non-tabular data/content is not semantic.

Re:No CSS on that site.

[arkanes]

The containing table is not the parent element though. The parent element can be anything, and any size, and it doesn't matter. The "containing table" is merely an anonymous box that is assumed to exist, it's not part of the DOM, not part of the document and you don't have to create it.

An implicit element is still an element. And it's cute how you totally ignored the second part of my statement, of course, which is "position". You can do cell layout with the CSS2 attributes specifically designed for that - I already knew that. It doesn't change the fact that you still can't position or size elements relative to other arbitrary elements! You can only simulate it via nesting divs and/or spans. And nesting your content in divs and spans means you're altering your content to match your presentation - against the whole point of this semantic markup malarky.

In fact, the fact that CSS is tied to tightly to your content is a wart - it's a direct contradiction to the seperation thats trying to be created.

Make one bigger. The other one gets bigger too. Make one smaller. The other one gets smaller too. Nooo... of course they aren't sized relative to each other. It's... what did you call it? A "coincidence"?

Do you know *why* that happens? Because maybe if you did you'd understand that they aren't being sized relative to each other at all. And if you understood why it was happening, you'd see that the replacement for nested HTML table layout would be... nested DIV table layout.

It wasn't clear you wanted to store a programmatic identifier. Now, what on earth could I use in HTML for that? Maybe... oh I don't know... the id attribute? Again, no need for XML there.

If you *had* to pick an HTML attribute suitable for classifying tables, you'd use the class attribute. Too bad that class has specific semantics relateed to CSS.

XHTML is adequate for documents - it's pretty comprehensive and contains a lot of elements good for documents. It's useless for anything you'd want to put into tables, or for correlating, or anything else interesting. And the lack of precision whicch you casually wave off is very important - H1 is a top level heading, but knowing exactly what that means in context matters if you want to do anything with the data you extract. XML obviously has the same consideration, but because you're using an application specific markup you've got the ability to specify tags as specifically as you want. Additionally, the problem of references (an issue with XML and it's variants in general) can be addressed by storing them seperatly and including them as part of your XSLT, something which can't be done if you store everything in XHTML.

Now, if XHTML as an XML dialect is suitable for your documents, thats great. Store them as that. But store them as that *without* any of the markup or attributes you use for browser display, without any of the boilerplate or the headers or the navigation menus or anything - store it as *data*, not as a "web page". *Then* it's usefull, powerful, semantic content. And it'll still look nice and work right in browsers.

This algorithm only works if you know that there are document titles, where the document titles can appear, that there are headings, where the document headings can appear, which ones are more important, and so on. This information is available for HTML documents because HTML is a standard document format with defined semantics. An arbitrary XML document does not have that unless it conforms to a standard document format like XHTML, in which case the supposed benefits of an arbitrary XML document format vanish.

This algorithm won't work in the generic case simply because while HTML defines a page as having a title, there's no way of knowing what a "page" is in context. Assuming you have a book, a single HTML document could be the whole book, it could be a single chapter, or it could be a single conceptual page. Before you can usefully extract meaning from the markup, you must know more about the structure. This means that generic "parse the HTML and return all the H1 tags" scripts are of limited utility, even if all the HTML in the world was semantic markup.

Re:No CSS on that site.

[H310iSe]

I completely disagree that it's hard(er) to get fluid layout allowing dynamic content (resizable pages, etc.) using CSS - I've gone both ways to acheive that goal and using CSS was way easier to handle unknown-at-design-time changing content.

This is from the perspecive of writing server side scripting + html. Possibly if you're doing all your work client side then tables are easier (I don't know) but CSS + Server Side Scripting for the win every time if you want dynamic content.

I think the reason is CSS is more relational - you put things on the page relative to other things, or relative to other settings (i.e. all fonts are in em not in px, etc.).

For example, if you don't know if you'll be displaying 5 columns or 10 columns of graphics/text the scripting to write the tables out is a pain, accounting for spans, figuring out programaticaly where the end of the row is and getting all the correct table markup in, completely rewritting the table every time some data in the middle gets cut out and it goes to 9 columns... With CSS it's a breeze, you don't need to do much of anything on the server side, just drop the data into the document and, if it's well written, the document will bend itself around as needed to accomodate it.

I've got pages that display @ multiple resolutions (as in resize and realign everything to take advantage of the additional screen realestate) & at +- 2 font sizes that are written in under a hundred lines of code + markup. it would take hundreds of lines to do that w/ tables if it could even be done.

Re:No CSS on that site.

[Bogtha]

An implicit element is still an element.

It's not an implicit element. An implicit element is an element that exists, but hasn't got a starting tag.

The thing that is generated by the CSS engine is an anonymous object that would correspond to such an element if it existed. If it were an implicit element, then it would appear in the DOM. It does not appear in the DOM. Read the specification, it's quite clear that the element is missing, i.e. not present, absent, lacking, nonexistent, out to lunch, etc, and that the thing being generated is an "anonymous object".

And it's cute how you totally ignored the second part of my statement, of course, which is "position".

I didn't mention it because I didn't disagree with it.

It doesn't change the fact that you still can't position or size elements relative to other arbitrary elements!

But you can't do that with table layouts either.

And nesting your content in divs and spans means you're altering your content to match your presentation - against the whole point of this semantic markup malarky.

No, using <div> and <span> elements when you don't have to is semantically neutral. They mean, roughly, "this is a bit of the document and I can't be more specific than that". This is entirely different to saying "this is a table" about something that isn't a table.

Do you know *why* that happens? Because maybe if you did you'd understand that they aren't being sized relative to each other at all.

I know exactly why it happens. They are sized relative to an anonymous box. That anonymous box takes its size from the contents of those elements. By setting a percentage width, you are sizing them relative to each other. They are not being sized relative to their parent element.

If you *had* to pick an HTML attribute suitable for classifying tables

Bzzt, troll alarm going off because you are moving the goalposts. You said nothing about classifying tables. You were talking about assigning them "programmatic identifiers" - your words, not mine. It seems you're trying to twist the argument into a different one solely to disagree with me and prolong the argument. That's pointless and boring. Stop it.

And the lack of precision whicch you casually wave off is very important - H1 is a top level heading, but knowing exactly what that means in context matters if you want to do anything with the data you extract.

That's not true and I already gave an example - automatically generating a sitemap - where you don't need to know anything other than what bits of a document are top-level headings. Must I repeat myself?

XML obviously has the same consideration, but because you're using an application specific markup you've got the ability to specify tags as specifically as you want.

Element types, not "tags". And like I said, you are still stuck in the mindset that you are going to be the only person consuming this markup. Your ad-hoc data format means nothing to me. HTML is a standard format. XML is a standard syntax, but that's irrelevant, you are building something proprietary on top of the standard syntax instead of using a standard document format.

Maybe there isn't a standard document format that is suitable for what you are doing. Maybe a proprietary format is the best approach. But so far, you just keep giving examples where you can store the information in HTML just fine and have been suggesting that it's actually beneficial to throw away the semantics of HTML even in cases where HTML would do just fine!

Re:No CSS on that site.

[Domo-Sun]

Yes, there is. You can do it with CSS tables. Internet Explorer doesn't understand them, but we're talking about the capabilities of CSS, not the capabilities of Internet Explorer, right?

So instead of using tables, that actually work in all browsers, we should use DIV tags, then display them as tables using CSS... and that's better how?

I'm not saying that CSS is bad.. I love CSS, I use it every day. I eventually came to realize that it is very tricky getting a page to work in all browsers the same way, and that tables are not that evil.

You say that non tabular info shouldn't be displayed in a table, then you go ahead and turn it into a table with CSS. So what's the difference? (Other than your theoretical "Oh, what if everyone used tables like I want them to, then browsers could rotate large tables!" And when will browsers do that?)

You also say that it's semantic to add a class to a DIV or SPAN..

Then why not add the class to the TD and TABLE tags. That would make them more semantic.

My opinion is that you're a bit overzealous about this table thing.

Re:No CSS on that site.

[arkanes]

But you can't do that with table layouts either.

You can, sort of, but it requires altering your document structure with lots of nested tables. Table layouts in CSS require the same sort of munging, which is why this is a weakness (and a failure) of CSS. As long as CSS can't do layout any better than this (and it can't), and more importantly, until IE gets its head out of its ass, I see very few compelling reasons to use CSS for layout and several to not to. I don't find "semantic markup" a compelling reason, because you can present *better* data by creating an XML format and using that than you can HTML.

Bzzt, troll alarm going off because you are moving the goalposts. You said nothing about classifying tables. You were talking about assigning them "programmatic identifiers" - your words, not mine. It seems you're trying to twist the argument into a different one solely to disagree with me and prolong the argument. That's pointless and boring. Stop it.

Perhaps I was unclear about what exactly I was saying. A list of tables on a site (or in a document) is uninteresting and useless. A list of tables grouped by category or type or some other useful bit of metadata is not. There's no place in HTML to stick these bits of metadata, because the the HTML attributes are all either intended to be human-readable, or are overloaded with specific meanings. An XML dialect allows for the explicit specification of this information, and can be used to generate the human-facing HTML attributes. The same argument holds with, say, images - a list of images in a document isn't usefull. A list of images grouped by subject matter, or by chapter, or by the figure they reference, or any number of other bits of data that you can't embedd in the HTML is more usefull. You could, of course, do something like embedd comments or custom attributes or whatever in your HTML but if you do that you may as well use the XML.

Why would I want to throw away the semantics of HTML for an ad-hoc XML format which is meaningless to everybody outside my organisation? Or are you conceding that this is incorrect?

I'm drawing a difference between XML (any dialect, including XHTML) which includes *only* your marked up data, and HTML "for presentation", which includes things like the divs/spans/ids/classes you need to style it properly and the generic site boilerplate you typically find. Note that the benefits of XHTML over HTML 4.1 for the "presentation" are minimal at best. If you're the rare case where you don't have or want any of that, then go ahead and style your XHTML directly with CSS. However, you will find it difficult to create a nice looking and functional site this way. My standard qualification that this only matters if your site is presenting information that is at all usefull as raw data and not simply in its presented form applies. It doesn't matter. If all you want is a site map, then all you have to do is generate a bunch of links to a bunch of documents with sensible link text.

Perhaps this is where the confusion lies. I don't see a raw sitemap produced this way of being of any value whatsoever. Especially since your ability to extend this sitemap with more usefull information is limited. In my opinion, using a XML dialect as a storage medium, and not worrying about the semantic correctnes of your HTML is a far more powerful and flexible solution - given the current state of both the CSS spec and it's current implementations.

Re:No CSS on that site.

[Domo-Sun]

It might not seem useful to say to somebody "fetch me every object in that room", but it's useful to say to somebody "fetch me every newspaper in that room" and not have them come back with newspapers, books, letters...

But that's what they'll do, even if you use DIV and SPAN. So there is no difference, other than a philosophical one. And, browsers don't support your philosophy uniformly. And, there is nothing to stop people from using the DIV and SPAN tag too much. There are all sorts of pages on the net that consist of nothing but DIV and SPAN tags, which I find more annoying because when I activate my user stylesheet, I get a large page of unformatted text.

And I really don't see the tragic effect this has on people. I really don't see the problem with people using a simple table layout, nothing overboard. As long as they use Headings and other tags appropriately.

The default /. is too much, but if you login and enable the light version, I'd say that it's reasonable the way the tables are used. Then I just activate my style sheet.

Re:No CSS on that site.

[Domo-Sun]

I have nothing against Web pages looking pretty--but when it's 2005 and they're still using HTML rather than CSS to do it, it's time to wake up. It will generally make the pages lighter, faster to load, reduce bandwith costs, and improve accessibility (provided you use semantic HTML)--and I don't mean just for blind users; this goes also for people on cell phones, etc.

I agree with most of what you say, but correct me if I'm wrong, most of this argument centers around TABLE vs DIV, and how tables are just more solid and widely supported by all browsers. So what difference does it make how old they are, as long as they work?

Re:No CSS on that site.

[xENoLocO]

Because I'm playing with textpattern on my personal site at the moment. If you'd like to nitpick, see my most recent css creation: http://www.memorylanemusicgroup.com/

Re:No CSS on that site.

[Anonymous Coward]

You say that non tabular info shouldn't be displayed in a table, then you go ahead and turn it into a table with CSS. So what's the difference?

The difference is that the table tag itself implies tabular data, which isn't true if it's being used for layout. In contrast, using CSS tables is purely a layout function, thereby separating layout from semantic meaning.

Re:No CSS on that site.

[Anonymous Coward]

Your most recent creation doesn't display correctly in Firefox 1.0.6. The main menu's drop-down boxes appear behind the search box with javascript disabled.

Re:No CSS on that site.

[slycer]

        Table layout algorithms have been essentially identical in all major browsers for at least 4 years.

Then how come people complained when Netscape 6 was released and it "broke" their table layouts? And how come people complained when Internet Explorer 6 was released and it "broke" their table layouts?

Anybody else find it funny that the links pointed out are both more than 4 years old?

Re:No CSS on that site.

[larry bagina]

we also know that it will be fixed. (About fucking time, too)

Re:No CSS on that site.

[greggman]

Since you seem to be an expert at CSS please tell me how to solve these problems in CSS

http://greggman.com/pages/cssissues/css_wip.html is one with content that fits. It's basically a copy of the 3 column layout from glish.com

http://greggman.com/pages/cssissues/css_wip_over.h tml is the same page with common content that is slightly too large for each column.

If you know how to make the the css_wip_over.html work that would be great. You can see how the columns overlap and the sections are not the same size anymore, breaking the layout. Tables solve this problem, all the section of the same column will adjust their size to match the largest section. I have not been able to find a CSS solution for this.

Also there are some more compliacated conditions I would like to see happen too but just getting the 4 columns to work would be a start.

Re:No CSS on that site.

[mill]

DIV and SPAN don't have any semantics beyond what you believe them to have. TABLE on the other hand has the semantics of tabular data.

I am not terribly interested in your rationale for misusing tables for layout (MSIE incompatibilities, delusions of what HTML is, or what not). I am just stating that you are.

Re:No CSS on that site.

[Bogtha]

But that's what they'll do, even if you use DIV and SPAN.

Obviously you aren't grasping my analogy, so I'll try and make it simpler and clearer.

When you describe everything as a table, you lose the ability to refer to things by their type. Even tables. While referring to generic elements by their type might not be useful, referring to other stuff, including tables, by their type, is useful.

And, browsers don't support your philosophy uniformly.

On the contrary, pretty much every user-agent that has ever existed can tell the difference between element types if you actually mark up your content properly. And it's not my philosophy, it's the philosophy that's made markup languages work since the seventies.

And, there is nothing to stop people from using the DIV and SPAN tag too much.

Look, I'm saying "misusing element types is harmful" and you are responding "that's not right because people can misuse element types". That response doesn't make sense.

There are all sorts of pages on the net that consist of nothing but DIV and SPAN tags

That's the same sort of mistake as misusing <table> elements.

And I really don't see the tragic effect this has on people.

Of course you don't. You don't miss what you never had. I'm saying that this is holding back the web, not that the web was in a better place and this dragged it back.

I really don't see the problem with people using a simple table layout, nothing overboard. As long as they use Headings and other tags appropriately.

You mean element type, not "tag". And page layout is not an appropriate use for the <table> element type. "As long as they use Headings and other tags [sic] appropriately" is the very basis for my disagreement with table layouts.

Re:No CSS on that site.

[oriole1]

Tables do at least have some semantic value when used for actual tabular data - DIVs and SPANs have none at all - they only serve as containers to which styles are applied.

While the DIV tag itself may not lend any meaning to a document, I find them useful to DIVide my documents into logical sections, appropriately named. Since I don't actually have to style a DIV, the names can be reminders. Basically a fancy comment, but I can choose to style the DIV later if I feel like it.

Re:No CSS on that site.

[Bogtha]

So instead of using tables, that actually work in all browsers, we should use DIV tags

No! You should use the most appropriate element type. If it's a paragraph, use a <p> element. If it's a list of instructions, use an <ol> element. If it's tabular data, use a <table> element. Use whatever element type most accurately describes the information you are marking up.

then display them as tables using CSS... and that's better how?

A computer can understand something is a paragraph if you describe it as a paragraph. A computer can understand something is a list if you describe it as a list. A computer can understand something is a table if you describe it as a table.

If you describe everything as being a table, then a computer can't understand what anything means, not even tables. This limits what it can do with the information.

Sure, it can follow simple rules to lay it out, but then all the information is locked up where only a human can get at it. That's not as useful as information that both computers and humans can understand, because we've just resigned ourselves to handling that information ourselves instead of having the computer do it for us. I thought computers were meant to work for us, not the other way around?

You say that non tabular info shouldn't be displayed in a table, then you go ahead and turn it into a table with CSS.

I do no such thing. It doesn't matter how it's presented, I haven't changed the nature of the information just by applying display: table-cell to it. CSS tables and HTML tables are two completely different things. One is information, one is a layout strategy. Don't confuse them just because they look the same in your browser.

(Other than your theoretical "Oh, what if everyone used tables like I want them to, then browsers could rotate large tables!" And when will browsers do that?)

Just think that logic through for a second.

1. Rotating tables is silly
2. It's silly because it's impossible
3. It's impossible because loads of people misuse the <table> element type

Surely it's not so hard for you to accept a conclusion of "misusing the <table> element type is bad because it stops browsers from doing useful things for us"?

When you lock information away in a presentation where browsers can't get at it, you stop browsers from being able to do work for us. You don't think that's a good thing, do you?

And I'm not advocating people use tables "like I want them to". I'm advocating that people use tables the way they are described in the open specification that the W3C arrived at through peer review and free collaboration. If you don't want HTML to work that way, by all means convince the W3C that you are right and they are wrong, or convince browsers to support your own markup language that isn't HTML.

Re:No CSS on that site.

[jrockway]

> I run ./rebuild and it rebuilds all my pages based on the template and content.tmpl file.

Speaking of which, I think this site could use a /.rebuild as well :)

Re:No CSS on that site.

[Domo-Sun]

Obviously you aren't grasping my analogy,

I know what you're saying. What I'm saying is that it's better to use one standardized element for two things than it is to use one undefined element for a billion things because it's more accessible to the user. A blind user, or any user, can't differentiate between individual DIV and SPAN elements because they are generic. Knowing that something is a DIV or a SPAN is about as useful as knowing that something has a FONT tag around it.

And, browsers don't support your philosophy uniformly.

On the contrary, pretty much every user-agent that has ever existed can tell the difference between element types if you actually mark up your content properly.

Browsers have box model, and other bugs, making it difficult to use DIV in the place of TABLE. I know because I've made CSS versions of /. and plastic and tested them against browsers and it requires lots of work. I'm not in favor of using a million tables to have one comment, but it might be better to use one table per comment and add class to differentiate, and that would be more compatible with every browser than to simply use DIV for the entire page.

And I don't agree that the misuse of tables is holding back the web.

Re:No CSS on that site.

[Domo-Sun]

You should use the most appropriate element type...

I agree. But the w3c isn't making any new elements, therefore, we have to work with what we've got and what actually works.

Let's look at your logic:

1. Rotating tables is wonderful.
2. It's impossible because loads of people misuse the element type.

I actually think that rotating tables is impossible because no one made it possible. If they did, they could also make something like Table:max-width[100%] rotate-table or something.

I also think it's not practical to let computers auto rotate because, contrary to your theory of autonomous AI-computers formatting pages, people are required to format pages correctly.

If a page author messes up a page, the user should be able to override his style. The user can't do that if everything on the page is inside a DIV or a SPAN. Nor can the computer do that. Maybe the author told how a class of DIV is to be displayed, but a computer can't come up with a more acceptable alternative. This requires the user to debug a page. There goes accessibility.

If you don't want HTML to work that way, by all means convince the W3C that you are right and they are wrong, or convince browsers to support your own markup language that isn't HTML.

Like it or not, tables can be used for layout because browsers already support HTML TABLEs, and the spec was written to let them. Maybe there is a new spec that insists we use DIV class=whatever, but browsers have box model bugs.

Re:No CSS on that site.

[Bogtha]

What I'm saying is that it's better to use one standardized element for two things than it is to use one undefined element for a billion things

That's a false dichotomy. You say "use one standardized element [type]", but you aren't using it for what it's standardised for. You say "undefined element [type]", but the <div> and <span> element types are not undefined, they are defined by the HTML specifications. And there is no need to choose between the two extremes, you can use the standard element types for the purpose for which they are defined.

The thing you are arguing against, "to use one undefined element [type] for a billion things", is a straw-man argument of your own construction. Nobody is making that argument, you've just made it up. I'm certainly not making that argument, I pointed it out as wrong in the comment you are replying to, but you don't seem to have understood that. My argument, that you should use the appropriate element types for the task at hand, directly contradicts the argument you seem to think I am making. I have already explained this. Go back and read the thread again.

Knowing that something is a DIV or a SPAN is about as useful as knowing that something has a FONT tag around it.

Look, you still haven't understood what I am saying. If you don't get it this time, just give up.

My argument is not that referring to generic element types is useful. My argument is that referring to specific element types is useful, and that misusing specific element types for presentational purposes prevents you from doing so. Generic element types like <div> are incidental to the argument. Stop bringing them up, you are confusing yourself.

Have you heard the phrase "garbage in, garbage out"? By mislabelling the contents of your documents, the semantic information provided by your markup is garbage, so any computer program that could work with such information will produce garbage itself.

Browsers have box model, and other bugs, making it difficult to use DIV in the place of TABLE.

Once more, I'm not saying "use <div> elements instead of <table> elements". I'm saying "use the correct element type". Sometimes that's the <div> element type. Sometimes it's the <p> element type. Sometimes it's the <table> element type.

CSS layouts aren't some insurmountable task. Unless you already have experience in table layouts, they aren't any harder than table layouts. Yeah, browsers sometimes render them oddly, but that's true of table layouts too.

And I don't agree that the misuse of tables is holding back the web.

I gave you one very specific example of a feature that would only work if misuse of tables wasn't widespread, but you haven't refuted it.

Re:No CSS on that site.

[Bogtha]

But the w3c isn't making any new elements

You are wrong. And you mean element type. An element is a specific instance of an element type. Everybody who writes an HTML document makes new elements.

therefore, we have to work with what we've got and what actually works.

What we have is, among other things, an element type that means "this is a section of the document" and an element type that means "this is tabular data". When marking up a section of a document that is not tabular data, the former element type is clearly correct and the latter element type is clearly incorrect. If there's a more specific element type available, that's even better.

1. Rotating tables is wonderful.

Once more, you are misrepresenting what I say. I haven't said that. I said that it was a useful feature.

I actually think that rotating tables is impossible because no one made it possible.

What do you mean by "made it possible"? Wrote the feature into a web browser? Like I already explained, the reason why nobody has done that is because it would destroy table layouts - i.e. it's abuse of the <table> element type that is preventing such a feature from being put into browsers.

I also think it's not practical to let computers auto rotate because, contrary to your theory of autonomous AI-computers formatting pages, people are required to format pages correctly.

There you go with your straw-men arguments again. I'm talking about turning something ninety degrees. You think that requires AI?

If a page author messes up a page, the user should be able to override his style. The user can't do that if everything on the page is inside a DIV or a SPAN.

I'm not quite sure what you are saying. Taken literally, that's completely untrue. If reworded as "everything on the page is a <div> or <span>", then it's true, but has nothing to do with what I am saying.

In actual fact, the "if a page author messes up a page" argument works against you. If a page author messes up a CSS layout, you can simply disable styles and get the default layout. If a page author messes up a table layout, there's no easy way to disable that.

This requires the user to debug a page. There goes accessibility.

What are you talking about? If a page author messes up, there goes accessibility? Well yes, of course, but obviously that applies to table layouts too!

Like it or not, tables can be used for layout

Where have you been? I'm arguing that doing so is harmful. That would be a pretty pointless argument if I thought that it was impossible, wouldn't it?

Maybe there is a new spec that insists we use DIV class=whatever,

Yet another straw man.

but browsers have box model bugs.

Yeah, we should avoid CSS layouts because of a bug Microsoft fixed four years ago and that is trivial to work around anyway.

Re:No CSS on that site.

[smagruder]

Thanks to you and iBod for bringing much-needed sanity to the "div vs. table" design debate! It's nice to see your pragmatic lucidity up against the "divs must be used everywhere" dogma.

I use tables more often than div's for one straightforward reason: It's easier for me to come back to my HTML code later and figure out what I've done! The "table" extends a longstanding idiom that's all but engraved into many of our minds, whereas nested div's is kind of like the object-oriented programming of the software development world: very useful in some instances, but a mess if applied everywhere.

Re:No CSS on that site.

[Domo-Sun]

If there's a more specific element type available, that's even better.

Bingo! There isn't. And that's what I said.

We're left to choose between the (traditionally used for layout) TABLE that's supported in all browsers consistently, and DIV with CSS that the end results will be bizarre. It is not trivial and I'm not talking exclusively of one bug in one browser.

Now, you can call the use of TABLE for layout as wrong, incorrect, or unsemantic. The fact is that it works.

Re:No CSS on that site.

[Domo-Sun]

We're arguing but that doesn't mean that you have to nit pick over every single word of every sentence. Otherwise you're being difficult.

A DIV has very little meaning and a SPAN has even less meaning. You should know that yet your arguing about it now because you have every intention of being as difficult as possible and avoiding the fact that DIV/CSS layout is not as widely supported in browsers as the TABLE is. Period.

How many class or ids can be added to a DIV or a SPAN? Billions. Therefore the DIV/SPAN can be used for billions of things. That makes for less accessibility because the definition is not standardized in the way that a heading is a heading and can be expected by the blind to be read as a heading.

Traditionally people use tables for layout, today people are preaching about using DIV. So there is a dichotomy between what to use because if you use DIV you will have pages that won't display in many browsers.

Have you heard the phrase "garbage in, garbage out"? By mislabelling the contents of your documents, the semantic information provided by your markup is garbage, so any computer program that could work with such information will produce garbage itself.

No. I disagree. I think you're being overly dramatic. If someone uses a table for layout, the end result does not come out as 100% garbage. On the contrary, use of DIV and CSS for layout can be 65% garbage in some browsers.

Browsers have box model, and other bugs, making it difficult to use DIV in the place of TABLE.

Once more, I'm not saying "use <div> elements instead of <table> elements". I'm saying "use the correct element type". Sometimes that's the <div> element type. Sometimes it's the <p> element type. Sometimes it's the <table> element type.

Yes but were talking about TABLE being used for layout. Look at your other comments. And obviously P is not intended for layouts.

CSS layouts aren't some insurmountable task. Unless you already have experience in table layouts, they aren't any harder than table layouts. Yeah, browsers sometimes render them oddly, but that's true of table layouts too.

No, it's more of a problem with CSS/DIV layouts. I have experience with both. That's how I know. Your attitude is careless towards other browsers. The end result with CSS can be quite unpredictable, whereas with tables the end result is generally about the same.

Funny how you avoid the issue up to a point, then you say: "So what.. tables don't display the same in browsers either." or "We're not arguing about IE." and then you have the nerve to tell people that they are arguing deceptively.

And I don't agree that the misuse of tables is holding back the web.

I gave you one very specific example of a feature that would only work if misuse of tables wasn't widespread, but you haven't refuted it.

The ability to rotate elements is something that should be available to whoever wants it. That people use tables for layout is hardly an excuse to not provide it, nor is it the reason. You can't let the browsers rotate tables or format a page by itself because it's bound to do it by mistake because the task is too complex. That is the fundamental reason browsers don't rotate TABLES. Consider that people use IMG correctly... Yet the browsers don't yet rotate IMGs.

A table rotating formula shouldn't rotate any table that is as wide as it is tall, nor tables that are taller than they are wide. Nor should it rotate tables that are 100% of the screen. So I think that the majority of table layouts would be unaffected by this bug you speak of.

The issue is that the ability to rotate anything is not here yet. Then the ability to specify what should rotate would be something for a newer version of CSS perhaps.

Re:No CSS on that site.

[Bogtha]

If there's a more specific element type available, that's even better.

Bingo! There isn't. And that's what I said.

I think you are confused again. You can only decide such things on a case-by-case basis. You have some information that you want to mark up, and you think to yourself "what is the element type that describes this information the most accurately?". Sometimes it's the <p> element type. Sometimes it's the <ul> element type. Sometimes it's the <table> element type. And sometimes there isn't anything more accurate than the <div> element type that correctly describes the information you are attempting to mark up.

Saying "There isn't [a more specific element type]" is nonsensical. You can only say that when you try and mark up particular content.

We're left to choose between the (traditionally used for layout) TABLE that's supported in all browsers consistently

You didn't mean to say that, right? 'Cause we both know it's not true.

Try and say what you mean rather than exaggerating your claims until they are obviously wrong. I don't know how far back to scale that statement before I reach what you are trying to say. You might be trying to say something reasonable, or you might be trying to say something unreasonable. I don't know because I don't know how much you exaggerated your real opinion to reach that nonsense.

I know I'm going to get accused of dodging the point, but I'm not willing to fish about, attempting to divine your true opinion, because I'm undoubtedly going to get it wrong and that leads to misunderstandings. You've misunderstood me enough times to make it obvious that "reading between the lines" is a non-starter. State your opinion without any ludicrous exaggerations, and I'll address it. But I'm not going to address what you just wrote, because I don't think you really meant it, and I'm not going to guess at what I think you meant, because I don't think I can do so reliably.

and DIV with CSS that the end results will be bizarre.

The comments you post indicate that you think that it doesn't matter what stylesheets you write, only random presentation can occur. You leave no room for the possibility that layouts can successfully be constructed using CSS without major difficulty. I'm sorry, but that point of view is unsupportable. CSS layouts are widespread, from amateur personal sites right up to professional sites for multinationals. Anybody can do it. The last real hurdle was Netscape 4, and now that's niche, the only thing keeping table layouts popular is inertia - developer skill sets haven't all caught up yet.

Re:No CSS on that site.

[Bogtha]

A DIV has very little meaning and a SPAN has even less meaning. You should know that yet your arguing about it

I'm not arguing about that. I agree. You said that they were undefined and implied that they were non-standard. They are neither.

you have every intention of being as difficult as possible and avoiding the fact that DIV/CSS layout is not as widely supported in browsers as the TABLE is. Period.

I'm not avoiding that fact (it's true), and I'm not trying to be difficult. I've already suggested this once, but can you read back through the thread and pay attention to what I am actually saying please? You are either reading too much into what I am saying, or you are assuming that I hold particular points of view that have been expressed to you in the past by other people.

How many class or ids can be added to a DIV or a SPAN? Billions. Therefore the DIV/SPAN can be used for billions of things.

But we aren't talking about what can be done. We're talking about what's sensible to do. The choice of the <div> or <span> element type over more accurate element types is stupid and wrong. You seem to think that is what I am advocating, despite my repeated effort to shake that notion from your head. However, just because it's stupid to use a generic element type in place of a more accurate element type, that doesn't mean it's clever to use a specific element type in the wrong way, or that it's stupid to use a generic element type where no more accurate element types exist.

Going back to the previous analogy: Pointing at a book and saying "this is an object" is of limited value. Pointing at a book and saying "this is a car" is being more specific, but stupid. Pointing at a book and saying "this is a book" is best. However, if for some reason we have no word "book", it's better to say "this is an object" rather than "this is a car".

Can you translate that into the equivalent decision making process for markup? Do you see what I am saying now?

That makes for less accessibility because the definition is not standardized in the way that a heading is a heading

Yes, it is. You are confusing "defined as generic" with "not defined". Think back to the analogy. The word "object" has a meaning, does it not? You can have lots of different types of object, but the actual word itself, "object", has a meaning, right?

and can be expected by the blind to be read as a heading.

Stop and think for a second. The correct use of a <div> element is where no more appropriate element type is available. This isn't a "my blind friend can't understand headings" argument, because appropriate element types exist for headings. In situations where there is no more appropriate element type, an aural user-agent is assisted best by an accurate description - a description that says "this is simply a part of the document and I cannot be more specific".

If someone uses a table for layout, the end result does not come out as 100% garbage.

You missed out half the words I wrote. I'll say it again, with emphasis:

By mislabelling the contents of your documents, the semantic information provided by your markup is garbage, so any computer program that could work with such information will produce garbage itself.

I'm not talking about a pretty picture painted by your browser, I'm talking about the information that is available to it. The same information you hold so dear when you tell me how <div> and <span> elements shouldn't be used for everything because blind people can't understand them.

On the contrary, use of DIV and CSS for layout can

Re:No CSS on that site.

[Bogtha]

But you can't do that with table layouts either.

You can, sort of, but it requires altering your document structure with lots of nested tables. Table layouts in CSS require the same sort of munging, which is why this is a weakness (and a failure) of CSS.

But surely it's a weakness and a failure of table layouts too?

I don't find "semantic markup" a compelling reason, because you can present *better* data by creating an XML format and using that than you can HTML.

Once more, ad-hoc XML is a step backwards so long as you value the ability to access those semantics outside your own organisation. You keep ignoring that point.

A list of tables on a site (or in a document) is uninteresting and useless.

Er, it's a very well established practice. Maybe you might find it uninteresting and useless, but clearly it's of value to others.

A list of tables grouped by category or type or some other useful bit of metadata is not. There's no place in HTML to stick these bits of metadata, because the the HTML attributes are all either intended to be human-readable, or are overloaded with specific meanings.

Yes, but for all the examples you give, the "specific meanings" are in line with what you want to use them for. The id has a specific meaning for assigning programmatic identifiers to elements. You want to assign programmatic identifiers to elements. Rather than invent an ad-hoc XML format that nobody understands but you, you don't see the value in using the id attribute for what it is intended for?

A list of images grouped by subject matter, or by chapter, or by the figure they reference, or any number of other bits of data that you can't embedd in the HTML is more usefull.

But the information to group images based upon what section they are in is information that is present in the HTML. You know what page they are on. You know where in the document structure they are (because of headings).

Yeah, you can't group them by subject without further information. But that doesn't negate the fact that you can do useful things with HTML semantics, and where HTML semantics are not enough, you can still usually use HTML element types and attributes in the manner for which they are intended, to store such information.

You could, of course, do something like embedd comments or custom attributes or whatever in your HTML but if you do that you may as well use the XML.

No. If I get an HTML document with extra information that I can't understand, I can still work with the semantics that the HTML format provides, even if I can't access the extra information. If I get a generic XML document, I don't get any semantics whatsoever and I have nothing to work with.

I don't see a raw sitemap produced this way of being of any value whatsoever.

Well we'll have to disagree there. However, it's not just me you are disagreeing with, WCAG 1.0 lists a site map as a way of passing checkpoint 13.3, which is a priority 2 checkpoint.

Re:No CSS on that site.

[Domo-Sun]

A DIV has very little meaning and a SPAN has even less meaning. You should know that yet your arguing about it

I'm not arguing about that. I agree. You said that they were undefined and implied that they were non-standard. They are neither.

The point is that it offers little value to focus on that, except to avoid the real issue and be difficult.

just because it's stupid to use a generic element type in place of a more accurate element type, that doesn't mean it's clever to use a specific element type in the wrong way, or that it's stupid to use a generic element type where no more accurate element types exist.

If people don't have a more accurate tag, yes I said tag asshole, than according to you, they should use DIV or SPAN, obviously with a class to differentiate. The most commonly use would be class=note or footer, but outside of that you have billions of possibilities... There is no way for a computer to data mine or for a user to glean more than that without debugging and hacking through a page to determine what's going on behind the scenes.

Never said it was clever. I suggested that it was the lesser of two evils.

The correct use of a <div> element is where no more appropriate element type is available. This isn't a "my blind friend can't understand headings" argument, because appropriate element types exist for headings.In situations where there is no more appropriate element type, an aural user-agent is assisted best by an accurate description - a description that says "this is simply a part of the document and I cannot be more specific".

Here we go with you being difficult. I never said that the blind can't read headings. I was saying that headings are defined as something useful while DIV and SPAN are not useful to the blind, or anyone for that matter, except for authors self-gratification, because their definition is inadequate. I think you knew what I was saying, so pleas stick to the pertinent points.

If you can't be more specific about what a DIV is, then you are producing unsemantic inaccessible pages. Sure, sometimes you will come across DIV.NOTE and DIV.FOOTER, but that's about as close you can get to accessibility to the user or user style sheet.

If a blind person, or any person goes to a page layout that's using tables, they can at least jump to table cell 2 and get to the heart of the content. With DIV you can't do that.

By mislabelling the contents of your documents, the semantic information provided by your markup is garbage, so any computer program that could work with such information will produce garbage itself.

Nonsense. Not true. If someone uses table for layout then you either are looking at a table or a table layout. It's not that hard. The Internet doesn't come to a complete halt.

If you're talking about a computer that you're using to run data mining on sites, obviously you have a little problem. You may be able to come up with a formula to get around it, but if using a DIV with a class of layout or something is acceptable, I think it might be equally acceptable to use TABLE.LAYOUT and have a page that degrades well on all browsers.

Again, that's unsemantic, but then so is DIV.LAYOUT, at least to everyone but the author. The W3C should have provided a layout mechanism in earlier versions of HTML, but because they didn't, people have to make a choice between layouts that are currently 'unsemantic' that work, and ones that are recommended but fail in many browsers.

And why? Because of the ridiculous belief that our tables and elements will spin and dance about to our every wish, and the ad hoc theory that they don't because people use tables for layout.

On the contrary, use of DIV and CSS for layout can be 65% garbage in some browsers.

You're still focusing on <div

Re:No CSS on that site.

[Bogtha]

Look, every single thing you said either mischaracterises my argument, calls me names, or misses the point. It's really not worth me responding to that. If, like I have suggested twice already, you read through the thread again, you might be able to grasp what I am saying. If you do that, feel free to post again. But if you just want to persist in calling me names and attacking straw men arguments that aren't representative of what I am saying at all, then it's pointless for me to respond.

Best Resource for CSS?

[gowen]

The remains of the hull of the USS Merrimack.

Re:Best Resource for CSS?

[Colde]

Surely, you must be new here

Re:Best Resource for CSS?

[Anonymous Coward]

Moderators hate puns. And quit calling me Shirley!

But they forgot..

[IversenX]

How on earth can they not list THE resource?

http://www.w3.org/TR/REC-CSS2/

I'm talking about the official specification, of course.

That's what I'm always using to look up attributes, values, etc. It's easy to use, light-weight, and I never have to doubt wether the author made a mistake or not. :-)

Re:But they forgot..

[RangerRick98]

Interesting; the article I read has that site listed third as "Official Cascading Style Sheets Level 2 Specification."

Re:But they forgot..

[BishonenAngstMagnet]

Someone didn't read the article well...

Re:But they forgot..

[dagny_dev_]

I also wish they would have listed the web developer's handbook , at least as an aside. It's a good starting point. I keep it bookmarked and use it to get to other sites.

Re:But they forgot..

[iBod]

Not only that but he gets +4 Informative too!

Just another day on Slashdot ;)

Re:But they forgot..

[zkn]

How on earth can you not read THE fucking article?

Re:But they forgot..

[Jugalator]

It's easy to use, light-weight, and I never have to doubt wether the author made a mistake or not. :-)

Well, actually... ;-)

Re:But they forgot..

[stienman]

You are not alone.

And yet you are alone.

So very alone...

-Adam

Re:But they forgot..

[Anonymous Coward]

Did you not even read the summary, let alone TFA ?

It's right there, in the *"£)!ing summary "web developers handbook", with a link to the same place you posted.

Genius.

A list of the site links?

[puff the barbarian]

Anyone? The sitepronews site is already /.ed

Re:A list of the site links?

[RangerRick98]

Google Cache of article

Re:A list of the site links?

[BishonenAngstMagnet]

http://www.csszengarden.com/ http://www.alvit.de/handbook/ http://www.wpdfd.com/editorial/basics/index.html http://www.w3.org/TR/REC-CSS2/ http://css.maxdesign.com.au/listamatic/ http://www.cssvault.com/ http://glish.com/css/home.asp http://webhost.bridgew.edu/etribou/layouts/index.h tml http://www.positioniseverything.net/ http://www.stylegala.com/

Counterstike

[flamearrows]

Please don't let me be the only one who saw the title and immediately though Counterstrike: Source...

Re:Counterstike

[RangerRick98]

Sorry man. It's been 50 minutes and no one's spoken up to support your position. Looks like 821733 is the loneliest number on /. today. :)

Re:Counterstike

[pilkul]

Sigh, it's spread to CSS now. It used to be only when someone mentioned Computer Science that one of you Counterstrike people piped up.

Re:Counterstike

[ne0n]

ahh, thoughts of dvddecrypter & DVDshrink came here..

Re:Counterstike

[Anonymous Coward]

I'm with you brother.

Re:Counterstike

[aggiefalcon01]

Thanks mods. This gets "4, Funny", whereas this gets "-1, Troll". Way to have a consistent sense of humor.

(PS- the counterstrike joke is funny, too)

CSS Cheat Sheet

[Sheriff Fatman]

May I also recommend Dave Child's CSS Cheat Sheet ?

Print it out & stick it on the wall/partition - it covers almost all the CSS you'll use day-to-day, and (IMHO) it's much quicker than digging through the online documentation or the O'Reilly book.

Similar things for Javascript, PHP, etc. are linked from here if you're interested.

Re:CSS Cheat Sheet

[dse]

Visibone's HTML/CSS reference card is worth the $10. Nice four-page card that goes into a lot more detail on browser compatibility, CSS property values, how CSS relates with HTML, and so forth, yet manages to fit all the CSS stuff in one page.

(They also make a good JavaScript card from which I learned most of my JavaScript, as well as those nifty color charts.)

Re:CSS Cheat Sheet

[TedRiot]

Yes you may, but I looked at them hoping to find something useful such as the vi mug that my former colleague had, but all the cheat sheets seemed to be so basic that there really is no use for them if you do these things on a daily basis and you cannot really find useful information. Most of these attribute names I know in my sleep, but my memory fails on me when I have to come up with legal values for them. Same with PHP, I know the function names, but fail to recall whether the needle or the haystack comes first. I recommend php.net and w3.org. (For JavaScript, I don't know any GOOD references)

Re:CSS Cheat Sheet

[dascandy]

Do they have one for C++? I'm still looking for some good wallpaper for my entire house.

Re:CSS Cheat Sheet

[smallguy78]

also www.sloppycode.net/reference/css has a clean css 1 and 2 guide.

Re:CSS Cheat Sheet

[smallguy78]

oops no autolink for the lazy of us: http://www.sloppycode.net/reference/css

Another top 10, hurray!

[suspected]

I love reading articles that indicate the top 10 of anything because you never have to worry about the list being subjective. You always know that the author went out of his way and used a numerous amount of resources, reviews, and statistics to compile such a list. Either that or he just inappropriately used the "top 10" catch phrase to garner more readers, but I'll give him the benefit of the doubt since this article is on, as Bush would phrase it, "the internets."

Re:Another top 10, hurray!

[dascandy]

You wouldn't believe how right he is becoming.

There's this internet on one hand, which is commonly viewed with Firefox but can be well visited with others, using IPv6, usable all around the world and unfortunately using MSN for communication.

The other internet which is viewed only with MSIE, since the rest can't bake decent pages out of it, using IPv4 and pretty much only usable in the USA using AIM for communication.

There's not much intercommunication, and they're going further apart (USA still not going ahead, rest of the world embracing IPv6 on a slow pace).

can I add one?

[Anonymous Coward]

The edit css plugin for firefox lets you edit the css data for any page and instantly see the changes.

Re:can I add one?

[Spydr]

The web developer toolbar does this too, and a whole lot more. If you are building websites and don't have this, you have problems.

Re:can I add one?

[Karamojong]

The web developer toolbar is certainly indispensable for anyone building a website (I've found it very useful for this anyway), but I'd also really recommend it to anyone who is just a reader. People who say it's pointless swapping tables for divs that do the same job fail to recognise that I as a reader might want to change the way the page I'm looking at appears, and this is the way it should always be. I often use a key combination implemented by the web developer toolbar to kill CSS completely so that I'm left (provided the site has been designed with semantic markup) with a simple browser-default style of the kind you might see on a page with no styling at all. If a navigation menu at the side is too wide or the designer has used a stupid font or colours I can kill CSS and get a nice linear layout. If tables are used I can't do this. Most web developers fail to understand that HTML is not a painting language, and that it's not their place to tell me how their site must be displayed when I read it. As far as style is concerned they are entitled only to offer a recommendation in the form of a stylesheet I should be able to turn off to give me a clean unstyled page. After content, I would say graceful degradation, standards compliance, and relative instead of absolute sizing are the most important things to focus on, before worrying about precisely how your elaborate stylesheets look if you're going for an advanced style. Get the basics right first, then start worrying about columns and floats once you've already got a clean viewable website.

CSS Sidebar for Mozilla/Firefox

[superflippy]

I find the CSS Sidebar immensely useful. It lets me quickly look up a style and see what values it takes. It's also a good reminder of some of the little-used styles.

Re:CSS Sidebar for Mozilla/Firefox

[Anonymous Coward]

Instructions for getting it to work in Firefox?

Re:CSS Sidebar for Mozilla/Firefox

[superflippy]

You've got me there. I'd never tried to add additional tabs to the Firefox sidebar before (Mozilla is my primary browser at work, Safari at home). I assumed it would be the same as Mozilla, but now that I try I can't figure out how to add new tabs to the Firefox sidebar and there's nothing in the help file about it.

Sorry. It will still let you bookmark the sidebar as a web page.

Wishful thinking.

[reality-bytes]

Now if we could just get all browser software providers to go and read that spec and adhere to it, we would have a happy-shiny web for all ;)

Unfortunately, some browser writers feel the need to 'extend' standards to their own specification. Of course, it never seems to trouble them that this precludes their browser being standards compliant.

Re:Wishful thinking.

[D-Cypell]

Do you have any particular browser vendor in mind?

Re:Wishful thinking.

[reality-bytes]

I'm not one to name names and tell tales.

Besides, it would be nice if all browser writers aimed to support W3C standards so the writing of webpages themselves would become so much simpler.

The REAL news ...

[ggvaidya]

from the slashdot-is-moving-to-css-in-just-a-few-weeks dept. ...

Is that for real? Not been having much problems which Slashdot recently, but if they're chucking away their mess of tables ... the apocalypse might be at hand after all! Yippee!

Re:The REAL news ...

[The Mgt]

I notice slashcode seems to have done away with table layout, on the main page anyway.

Re:The REAL news ...

[Mr_Silver]

Is that for real? Not been having much problems which Slashdot recently, but if they're chucking away their mess of tables ... the apocalypse might be at hand after all! Yippee!

I hope this is for real since it will mean that I can stop supporting AvantSlash which tries to make Slashdot as PDA and WAP friendly as possible.

Of course, all the parsing of HTML that my code did meant that any little change that occurred on the main Slashdot site completely broke AvantSlash . If you have a look at the change log you can see that they did tinker with the HTML on a fairly frequent basis (v2.18 and onwards are mainly parsing changes to keep up with them).

Re:The REAL news ...

[H0p313ss]

With multiple stylesheets no less! Time to pre-order Duke Nukum Forever!

<link rel="stylesheet" type="text/css" media="screen, projection" href="//www.slashcode.com/base.css" >
<link rel="stylesheet" type="text/css" media="screen, projection" href="//www.slashcode.com/ostgnavbar.css" >
<link rel="stylesheet" type="text/css" media="screen, projection" href="//www.slashcode.com/slashcode.css" title="Slashcode" >
<link rel="Alternate stylesheet" type="text/css" media="screen, projection" href="//www.slashcode.com/slashdot.css" title="Slashdot" >
<link rel="stylesheet" type="text/css" media="print" href="//www.slashcode.com/print.css" >

Re:The REAL news ...

[dancallaghan]

Yeah about time too ... I mean, CSS has only been around for almost nine years ...

Re:The REAL news ...

[schon]

Yeah, too bad it doesn't validate. :o)

Re:The REAL news ...

[SnowWolf2003]

Looks like it is for real

See CmdrTaco's journal

pwnd.

[mindwar]

slashcache
also here's a few interesting links bookmarks layouts more layouts

Re:pwnd.

[foobar_fred]

im not pwnd ur a totl n00b i luv css i can dance all day, i can dance all day - FPS Doug

Re:pwnd.

[AaronLawrence]

Didn't I see you playing UT2004 the other day? Or am I going mad...

Am I alone?

[openfrog]

...having the impression that the list is not very impressive? Not very comprehensive and no mention of W3schools, for example. Is SitePro News a good site itself? -- I prefer to remain silent.

Re:Am I alone?

[BishonenAngstMagnet]

That's because the W3Schools site isn't very helpful. What good is a site that teaches you a collection of markup with no implementation?

Re:Am I alone?

[pimpimpim]

I use it as a reference, and for that it serves me just fine. w3schools might not be loaden with examples of how to implement the code, but when starting from scratch I'd often just want to know the options available and what they do, rather than having to crawl my way through loads of examples and have to overthink what exactly other people wanted to do there. The way you reason Zengarden might not be useful as well, as it is a collection of implementations without going into the markup details. I would say that w3schools is helpful, it just depends on what you want.

My 2 pence

[T-Kir]

A List Apart and StopDesign are sites that have great resources and tutorials, well worth a look.

CSS now also usable in IE!

[Anonymous Coward]

http://dean.edwards.name/IE7/

(not affilliated, just a happy user)

Re:CSS now also usable in IE!

[Bogtha]

CSS has been usable since Internet Explorer 3. It was the first mainstream browser with support for CSS.

Dean Edwards' work is good, but it doesn't add CSS support, it adds missing parts of CSS 2 support. And it does it with Javascript, so it's only useful if you don't mind your website falling apart when Javascript is not available.

Re:CSS now also usable in IE!

[MBHkewl]

If you're suggesting that IE is "good" at CSS rendering, by any means, you should be shot in the head.

All IE had (and still maintains) is a CSS render engine that doesn't comply to W3.org specs! Microsoft, as usual, defined its own standrads and forced many poor web developers to learn it and use it.

I don't think that IE was the first browser to implement CSS, but rather Netscape. IE was widely used because it was shuved into the windows' .. uhh .. you get the point.

Related MS joke :: how many microsoft engineers does it take to change a light bulb?

-> None. Microsoft has defined darkness as the new standard!

Re:CSS now also usable in IE!

[Bogtha]

If you're suggesting that IE is "good" at CSS rendering, by any means, you should be shot in the head.

Try reading my comment before responding next time. I said nothing even remotely like that.

I don't think that IE was the first browser to implement CSS, but rather Netscape.

You are wrong. Netscape busied themselves with implementing their own stylesheet language, JSSS. Internet Explorer 3 supported some CSS. Netscape 3 supported no CSS whatsoever. Netscape 4 supported some CSS. Internet Explorer 5 for the Mac was the first web browser with reasonably complete support for CSS 1.0.

Re:CSS now also usable in IE!

[MBHkewl]

Ah, I've read the text wrongly, my apologies.

Internet Explorer 5 for the Mac was the first web browser with reasonably complete support for CSS 1.0.

I don't know about Mac, but I kow for sure that IE 5+ (windows version) had poorly implemented CSS. Some of the attributes weren't implemented while others were poorly done.

P.S. :: I also doubt that IE 7 will fix those issues and follow the W3 path, rumors are already circuling the web.

Re:CSS now also usable in IE!

[Bogtha]

Ah, I've read the text wrongly, my apologies.

No problem.

I don't know about Mac, but I kow for sure that IE 5+ (windows version) had poorly implemented CSS.

Yep. Fortunately for Mac users, Internet Explorer for the Mac is entirely different to Internet Explorer for Windows - it's a completely different codebase.

I also doubt that IE 7 will fix those issues and follow the W3 path, rumors are already circuling the web.

Pay no attention to rumours. Internet Explorer 7 will have much better support for CSS. It won't fix everything, but it's a big step forward (or, rather, it will be a big step forward in about five years time when most people have upgraded).

Re:CSS now also usable in IE!

[MBHkewl]

or, rather, it will be a big step forward in about five years time when most people have upgraded

Upgraded to FireFox that is ;)

Best - NCDesign.org

[N8F8]

Awesome reference for HTML and CSS that shows examples and browser compatability:

• CSS
• CSS Property List
• HTML
• HTML Tag List

Re:Best - NCDesign.org

[MemeRot]

I just checked out that site. Specifically, this page: http://ncdesign.org/html/s040box.htm#box/.

At the bottom of the page, a lot of their examples didn't look right. I checked it in IE and they looked fine. Does anyone know if there's a Firefox bug with overflow:visible or overflow-x:scroll; overflow-y:hidden;? They look like I'd expect in IE but the overflowing isn't working in Firefox.

The IE only style text-overflow:ellipsis; which I'd never heard of before would really be handy. I wonder why it was never part of the standard?

Re:Best - NCDesign.org

[Bogtha]

Does anyone know if there's a Firefox bug with overflow:visible or overflow-x:scroll; overflow-y:hidden;?

If I remember correctly, overflow-x and overflow-y are originally proprietary CSS properties that Microsoft put into Internet Explorer, and which have subsequently been added to CSS 3 drafts that will eventually become W3C Recommendations. It's possible that Firefox nightlies support it as they support other CSS 3 properties.

Bookmark this page

[jurt1235]

A lot of other CSS sources are already being quoted now, better start bookmarking this /. article then.

Re:Bookmark this page

[alnapp]

Indeed, and a good reference site always helps

Re:Bookmark this page

[jurt1235]

Don't say that I already made mistakes in my little post which w3schools could have prevented (-:

CSS tables

[Richard W.M. Jones]

Yes, a few sites are now using CSS. But often, they still don't "get it" - they've just replaced with to arrive at a mess of divs, instead of a mess of tables. We call this "CSS tables".

Structural markup is the essential differentiating factor, not just that you have found out how to replace tables with divs ...

</rant> over.

Rich.

Re:CSS tables

[mindwar]

which is still better as tables are actualy ment for displaying tabular data

Re:CSS tables

[zkn]

And divs are ment to mark divisions, not be a universal styling element.
The point of CSS is to seperate the design from the underlying HTML, not just replace tables with a mess of nested divs.
Divs are ofcause usefull to seperate different parts of the site like menues and content, but to many use several nested divs to make borders, backgrounds and position elements "just right" ending up with code like this for menues:

<div>
<div><a /><div>
<div><a /><div>
<div><a /><div>
</div>

So instead of using CSS to improve the HTML, they use it to fuck it even more up. Now having effectively removed even the slightly understandeble table layout, and replaced it with HTML that only looks right when you have the magic Stylesheet that it was designed for.

Now that CSS has caught on, people need to push semantic HTML using divs for everything just isn't right.

Re:CSS tables

[Eustace Tilley]

I understand that you were ranting, but what is the substance of your objection to using divs for page layout?
Is csszengarden not doing exactly that to superb effect?

Re:CSS tables

[Darkman, Walkin Dude]

CSS Zen Garden is a wonderful resource and has a lot of pretty pictures in it, but really it is taking two steps back to the start of the web, where every site was a poster with little interaction. All of those fixed layout designs and shiny objects are good to display artistic talent, but try putting dynamic content in there, and you are in for a world of hurt.

Re:CSS tables

[Richard W.M. Jones]

is only occasionally necessary, and should be avoided most of the time.

Admittedly not a great example of web design, but structurally it does the right thing. If you have firefox, view that web page and go to View -> Page Style -> No Style to see the structural markup (or just use View Source if you're comfortable with that). Of course we do use <div>, but only where it's essential. I would prefer to use it less, or even not at all.

Compare to this or this or this to see the overuse of <div>.

Rich.

Re:CSS tables

[Eustace Tilley]

Is the complaint that the author presents the menu using divs rather than ul/li pairs? Do you advocate authors deploy site specific DTDs so they can write instead of ?

Re:CSS tables

[Anonymous Coward]

Why? I really don't understand this, what's wrong with divs? I think using divs as much as possible gives a better and more flexible page, easier to adjust with css.

Re:CSS tables

[colanut]

The problem is that most people are thinking of how the "page" should look and code to that. Instead, try your design by thinking of what content am i presenting and then "how do I div-y up the content into display groups". If you really think that a table to hold two columns of information are better than two divs nested in a container div, you may want to rethink the purpose of the site and what you are trying to present.

Hell, at that point you might as well use Flash.

Re:CSS tables

[Richard W.M. Jones]

Why? I really don't understand this, what's wrong with divs?

So that your site works in older browsers. - If it's just a bunch of nested divs, it'll collapse into short lines of text on an older browser.

So that your site works in text-only browsers. Not just some Unix reprobates using Lynx, but people using mobile or otherwise "reduced" devices.

So that a speech reader (an accessibility device used by the millions of partially sighted and blind people in the world) can stress the structure of the page when reading it, which helps the visitor to understand how it is laid out even when they can't see it.

So that you can easily retarget content just by changing the stylesheet or (better) providing device-specific alternate stylesheets.

So that search engine spiders can understand the structure of your page - eg. they can identify the important headings.

So that you don't forget what elements in your site mean.

That's just off the top of my head.

Rich.

Re:CSS tables

[colanut]

The purpose of CSS Zen Garden is to demonstrate flexible and reusable CSS design with the same style sheet. It not for copying code with out adapting in to your environment. They made their choices for their purpose, you have to make yours for your site.

I write dynamic web apps all day long. Our style sheet was developed to set it and forget it. When the designer comes along and updates the look, all my apps work exactly the same with out me updating a single thing.

Maybe you should write better templates for your dynamic content.

Re:CSS tables

[Anonymous Coward]

the way to do it is to break your layout into it's basic components (often header, couple of columns and a footer) and make them divs. for everything else inside those divs, use descendant selectors.

nesting endless divs will mess your head up. using fewer divs but more descendant selectors is the path to enlightenment.

FWIW, ZenGarden is an interesting place to look at and is made by some very talented designers, but some of the designs are rather restricting. "The Zen Garden aims to excite, inspire, and encourage participation" but it isn't the final word in design.

Re:CSS tables

[Anonymous Coward]

I see what you're saying, but I don't fully agree. Actually I don't agree at all.

>older browser
How much older? I'm not worried about IE5.5 and earlier. If the browser doesn't understand doctype, that's too bad. How far back should I go in your opinion?

>text-only browsers
They should display divs just like a graphical browser, or whatever it's called. Just because it's showing text doesn't mean it should ignore the stylesheet!

>speech reader
The divs give structure to the page, the stylesheet gives design, display. If I want my page to be read well by a speech reader, I should make a speech-stylesheet which tells the reader how to parse the page with all its divs, just as the css tells the browser how to show it.

>retarget content
I don't understand this. How are you going to retarget a page if it's made with ul and li all over?

>search engine spiders
Again, this does not belong in the document structure, it belongs in a spider-sheet.

>So that you don't forget what elements in your site mean.
I use very descriptive class names all over my divs, just as you can do with hr and ul and p.

Re:CSS tables

[pilkul]

Not just some Unix reprobates using Lynx

"reprobates", ha. You just taught me a new word :).

I think the web design on your site is excellent, actually. No genius there but a very clean, pleasant look. I would get rid of the Firefox banner or make it much smaller, though; it distracts too much attention from your main message.

Re:CSS tables

[arkanes]

This is how the "CSS is only good for crappy looking websites" thing got started. Especially when you're limited by practical concerns (IE, essentially), doing this means you *cannot* implement non-trivial layouts. And if you start messing with your markup to support your need for more complex CSS, what exactly is your benefit over tables again?

The biggest problem is that you can't reference other elements in CSS - so, for example, when your designer comes to you and tells you that he wants the picture of the widget aligned with the left edge of the nav menu, there is *no way* to implement this cleanly. You have to either start using fixed positioning and size, so you can calculate beforehand were the edge of menu is, or you need to start wrapping your content up in divs to represet "content boxes" or whatever. Whenever your presentation needs differ from the semantic parent-child relationship you've created, you're screwed.

This is why I advocate leaving your semantic markup in XML, which is suited for it, and treating HTML+CSS as a rich-text markup output from an XSLT transform - XSLT giving you the power to add things like semantically meaningless markup (like div layout boxes) without compromising your "pure" semantic markup. And that supposing that semantic markup is actually valuable, which is actually a pretty iffy proposition in many cases.

Re:CSS tables

[AaronLawrence]

I'm not worried about IE5.5 and earlier

Uh... if you're in business with a website, then I personally would say you should make the site at least vaguely usable in IE 4 and Netscape 4. Preferably, anyone back to the version 2 browsers should be able to get something out of it (although obviously severely restricted).

I presume you don't have a commercial site if you're not even concerned about IE5.5.

Re:CSS tables

[Millennium]

Why? I really don't understand this, what's wrong with divs?

Nothing is inherently wrong with divs, as long as you keep in mind that divs don't mean anything, and that a meaningful tag is always preferable when one is available.

To illustrate this, let's look at some common page-design tasks. Suppose that you want your page's title (which you'll type in text) and an image to appear at the top of your page. Many people would tell you to use a div with an id of 'head' to wrap everything, but there's a better way: simply use an h1 tag and give it a background and background-image. By using a meaningful tag for your page header, you've cut out excess HTML code, and the result is more elegant.

Let's say, however, that you want more than just text and an image in your header. Suppose, for example,that you want to do something like Slashdot, using text, an image, and more images representing the last several categories that have been updated. There is no one tag that can encompass all of this, and so here we have a case where a div is appropriate. Give it a meaningful ID -'header' is a common choice- and put your header elements inside it.

The rule for elegant code is to use the most meaningful tags which will do what you want. DIV tags are suitable when nothing else is available, and there are times when that happens. However, they should not be used when better tags exist.

Re:CSS tables

[Anonymous Coward]

The main problem when using 5.5 is with the box-model, which means that divs don't align as they should. A couple of pixels here and there, nothing major.

However, what is your justification for "2 versions"? Isn't that kind of arbitrary? Why not 3 versions? And what is a version anyway? IE6 came in 2001, that's a long, long time in IT.

I stand by what I said: I'm not speding _any_ time making things look nice in 5.5. I have a couple of small commercial websites. I'm not worried about Links or Navigator 2.0 or Explorer 5.5. I draw the line at Explorer 6.

Re:CSS tables

[Anonymous Coward]

I disagree. I don't think it's elegant to sometimes use h1 and sometimes div for things that are quite similar.

In this specific example I'd ask: when do I use which? I don't see a clear answer to that, and so I choose to start with the div. It's more flexible, so I'll never have to change it to something else. And I don't have to think about any pre-set values for h1, it's just a generic block-level element I can do whatever I want with.

>you've cut out excess HTML code
You mean because 'h1' is shorter than 'div'? OK, I admit it, I'm wasting bandwidth like a madman.

>The rule for elegant code is to use the most >meaningful tags which will do what you want.
My tags should have the meaning I give them, more or less. If I use h1 as you suggest, the default h1-values will be mixed with my own values, and I have to think a bit harder. If I use a div, all values will be there in the stylesheet. If I specify font-size (and others) for h1, h2 and h3 why not just use with divs instead?

Re:CSS tables

[Millennium]

My tags should have the meaning I give them, more or less. If I use h1 as you suggest, the default h1-values will be mixed with my own values, and I have to think a bit harder.

You're a developer. Thinking is your job, so that the end user (be it the actual person or their user-agent) doesn't have to. You can reset the default h1-values to whatever you want. In most browsers, that means simply resetting font-family, font-size, and the margins, which odds are you would be doing anyway.

Re:CSS tables

[Anonymous Coward]

Exactly, and I'm thinking that I'll use a generic block-level element and directly specify whatever parameters and values I want. I don't see how that should give the browser much more to think about. A later developer, however, can easily see all values for any element. He doesn't have to add up default h1-values with stylesheet values in his head.

And I still can't see why it's easier to use h1 and reset those things you mention plus those things you've forgotten plus those things the browser might add to h1 for fun, than to just use a clean div.

Re:CSS tables

[RoadWarriorX]

I would respectfully disagree. The garden (and it's book I might add) gave me some wonderful insights on how to arrange my blog. I am not a designer, but it certainly help in my layout rather than trying to figure out Blogger's insane templates.

Re:CSS tables

[Bogtha]

Preferably, anyone back to the version 2 browsers should be able to get something out of it

That's taking things too far. Anybody using browsers that old are dead in the water - they don't support the HTTP Host header, which makes it impossible to visit websites that use virtual hosting - which is extremely common. Also, if I remember correctly, you couldn't even use Internet Explorer 2.0 to download Internet Explorer 4.0 from microsoft.com when it was released - about five years ago.

As far as version 3.0-era browsers go, their SSL root authority certificates expired years ago, so you can't use them for e-commerce without customers getting big warnings about your website being insecure.

Version 4.0-era browsers are so rare, with capabilities so diminished compared with version 5.0-era browsers, that I would say that it's not worth supporting them, although a case can be made both ways. But supporting 3.0 and 2.0-era browsers isn't justifiable in my opinion.

Re:CSS tables

[Eustace Tilley]

Would you please give some examples of dynamic content that could not be styled with shiny cssgardenesque images? Are you referring to things like variable length texts that are not known to the designer in advance, like a slashdot comment?

WebCore vs. Gecko, CSS Rendering

[mnemonic_]

I've not been paying as much attention to the browser wars as I once did. Does anyone know how WebCore (Safari) and Gecko (Firefox) compare in rendering CSS? I know that Safari supports the (completely awesome) text-shadow property whereas Firefox does not, but what are some other differences?

Re:WebCore vs. Gecko, CSS Rendering

[MBHkewl]

Googlized :: compare browsers firefox safari

Best result :: http://www.howtocreate.co.uk/browserSpeed.html

Does a nice job on comparing run time, CSS render speeds, scripts, loading history ...etc., it even counts Lynx !

Re:WebCore vs. Gecko, CSS Rendering

[porneL]

Table of CSS support in various browsers: http://www.quirksmode.org/css

Re:WebCore vs. Gecko, CSS Rendering

[Bogtha]

Safari supports CSS 3 backgrounds which is great for getting rid of superfluous <div> elements. Great example.

Oh, and of course, Safari passes the Acid2 test, where Gecko does not.

Re:WebCore vs. Gecko, CSS Rendering

[Anonymous Coward]

Stock Safari RSS does not pass the Acid2 test. From Wikipedia : "Dave Hyatt announced that a specially patched version of Safari (with WebCore as its layout engine, a spin-off from KDE's KHTML) had passed the test." There are currently no browsers whose latest "final" releases actually pass the Acid2 test, including Safari. Try it for yourself if you don't believe me.

Re:WebCore vs. Gecko, CSS Rendering

[Bogtha]

Wikipedia's out of date. You don't need a "specially patched" version; the latest stock CVS checkout works fine - although it's not a final release, it's a long way from a hacked up version that only one developer has.

CSS Zen Garden styles

[AaronLawrence]

I find it interesting that none of the CSS ZenGarden style sheets I tried resized at all with the browser window, and most of them coped poorly or not at all with large text (many became unusable).

Re:CSS Zen Garden styles

[Bogtha]

You're right, and it's a bit disappointing. You have to remember where the CSS Zen Garden is coming from though. At one point in time, many people simply refused to believe that CSS could create good-looking websites. Perhaps because the leading-edge developers using CSS were also mostly pretty crappy graphic designers, and also chose usability and accessibility over prettiness.

Anyway, the CSS Zen Garden was an experiment to show that you can in fact create beautiful websites with CSS. And it did its job magnificently - how often do you hear "CSS can only make ugly, boring, plain websites" these days? Unfortunately, the emphasis was placed all on looks, so few of the designs took usability or accessibility into account, which is why there are so many fixed-width, tiny text designs in it.

Re:CSS Zen Garden styles

[arkanes]

I believe the claim still stands, at least to a degree, because you (still) can't create beautiful layouts in CSS, while maintaining anything like cross browser support or (mind blowingly), user defined styles or overriden text size or even page size - features which are fundamental to the concept of the "semantic" markup which is so beloved of CSS advocates.

Of course, having all these features in some avante-garde fancy art designers wet dream is hard using *any* technology - and thats another fundamental that people skip over, too. Posterware is trivial - CSS garden could be implemented with a big image map much more simply, and a Flash site not only simply but also with more functionality.

Re:CSS Zen Garden styles

[nazh]

There are exception like Patrick Griffith's "Elastic Lawn" http://www.csszengarden.com/?cssfile=/063/063.css& page=0. Scales rather nicely when you adjust the font-size.

Re:CSS Zen Garden styles

[Bogtha]

you (still) can't create beautiful layouts in CSS, while maintaining anything like cross browser support

The majority of the CSS Zen Garden designs have cross-browser support.

user defined styles or overriden text size or even page size

Table layouts have no support for user-defined styles.

Whether a layout works with overridden text size or has a fluid layout is not something that is different between table layouts and CSS layouts. Both can break, both can work. It's whether you assume a certain text size or canvas size when laying things out that makes the difference, not whether you use CSS or tables.

Of course, having all these features in some avante-garde fancy art designers wet dream is hard using *any* technology - and thats another fundamental that people skip over, too.

I missed your point there. Can you restate it?

CSS garden could be implemented with a big image map much more simply, and a Flash site not only simply but also with more functionality.

Huh? Maybe you could get it to look similar under default settings, but it wouldn't work the same - and I thought you just said user-defined styles, overridden text size, different window size and cross-browser support were success criteria? Image maps and Flash presentations can't acheive all that.

Re:CSS Zen Garden styles

[WaxParadigm]

That is not an exception, but a perfect example, of what the parent to your post was complaining about - namely, a site that does not rezise with the browser. (resizing text != resizing browser window)

Re:CSS Zen Garden styles

[nazh]

He was also complaining about designs that did not handle resizing of text very vell. And very common "webdesigners" tries to lock the users to one font-size and the layout breaks horrible if one tries to resize the text. So yes, the layout I linked to is an exception to that rule. Even a layout that uses the whole width can break when the text is resized.

So for me a design that doesn't break in diffrent font-sizes is more important than one that uses the whole width.

since when...

[thelost]

is this news? not to belittle the importance of CSS but I'm sure everyone here is already quite aware of what it is, how to use it and where the web resources are; I first visited Zen-garden a long time ago for instance. If you're not then you probably are not a web developer. This is not news.

Re:since when...

[DanthemaninVA1]

And if you're not ALREADY a web developer, that certainly eliminates ever becoming one, right?

How great CSS is

[ChrisF79]

I'm not the best one to comment on this by any means, but when I saw in the summary the part about "how great CSS is," I really do have to agree. I threw together a site just as a way to help some of my students back when I was teaching and really didn't know anything about creating a website. I hacked together a site with tables for layout and some very limited PHP and enjoyed doing it. From there, I went to a site that showed a table layout and the exact page done in CSS and used that as a starting point to learn CSS. I have to say, I was impressed with how much easier it was to use and modify later. Like I said, I'm still a horrible web designer by all accounts, but I can attest to how much easier it is for a person new to the concepts to use CSS instead of tables.

Moderators, you didn't get the joke

[lasindi]

During the US Civil War, the sunken USS Merrimack was raised and converted to an ironclad by the Confederates, who renamed it the CSS Virginia (which later fought in the famous battle of the ironclads). So the parent was just trying to make a, albeit lame, joke about the acronym "CSS." It wasn't truly offtopic, and it definitely wasn't a troll.

Re:Moderators, you didn't get the joke

[Anonymous Coward]

But deserved to be modded down nonetheless, for extreme stupidity. That joke was about as funny as a Far Side cartoon.

Take a step back and re-evaluate CSS

[Loundry]

I'm a programmer who has been thrust into the world of CSS and been on many occasions quite frustrated with it. It seems arbitrary, arcane, and particularly difficult to debug. On top of that, it seems to have a set of zealots who defend it (and demand it) with bitter viciousness.

I had concluded that CSS was "programmer-friendly" in the same way that a rusty jigsaw was "penis-friendly".

I recently picked up a book entitled _Designing with Web Standards_ by Jeffrey Zeldman. It's a good an honest resource, and he even claims to avoid zealotry. But, in the book, he examines a particular website, one with a plain-jane two-column appearance, which he said took "three CSS experts" to re-code from tables to CSS layout. Not three CSS advocates, three CSS *experts*. On top of that, their "solution" turned out to be a hack.

Honestly, what success am I supposed to expect in using CSS when recoding common layouts in CSS is a struggle for even CSS experts? I am forced to conclude that it is folly trying to adhere to any kind of CSS standards with any kind of rigor until CSS itself becomes more mature.

Now this is where I get flamed. I'm sorry, but I have to call it like I see it.

Re:Take a step back and re-evaluate CSS

[Anonymous Coward]

On top of that, it seems to have a set of zealots who defend it (and demand it) with bitter viciousness.

And rightfully so - programming already requires you to separate presentation from content, why would programming for the web drop that?

I had concluded that CSS was "programmer-friendly" in the same way that a rusty jigsaw was "penis-friendly".
Again, try to apply this paradigm to programming and see how deep the mess can get. You usually don't notice because a lot of HTML is light-weight.

I recently picked up a book entitled _Designing with Web Standards_ by Jeffrey Zeldman. It's a good an honest resource, and he even claims to avoid zealotry. But, in the book, he examines a particular website, one with a plain-jane two-column appearance, which he said took "three CSS experts" to re-code from tables to CSS layout. Not three CSS advocates, three CSS *experts*. On top of that, their "solution" turned out to be a hack.
It took experts because to them, the solution would be clear in a shorter timespan, and they are able to motivate the choices for the design, and they wouldn't go "okay.. whoops. let's scrap idea nr. 1". You could've picked CSS newbies too - but for programming, there's something called a 'design pattern' and it works if you know about them and when to use them.

I am forced to conclude that it is folly trying to adhere to any kind of CSS standards with any kind of rigor until CSS itself becomes more mature.
You mean, until a certain browser adheres instead of making all kinds of stuff up ;).

Now this is where I get flamed. I'm sorry, but I have to call it like I see it.
If you are a programmer, try to spot the equivalent of CSS files in your discipline. Why aren't they arcane there? Because the compiler or the virtual machine will give you the same results, and even for smaller programs, you accept these things as 'required'; when you're learning they're the parts you don't have to understand intimately, but just put 'm in because otherwise it won't work.

Re:Take a step back and re-evaluate CSS

[Xarius]

I haven't read that book in a while, but it took the three experts to code a cross-browser re-implementation that looked the same across the platforms.

The problem is not CSS itself, but the various implementations of it.

A two column layout is piss-easy in theory, but getting it to look the same in mozilla/MSIE/Opera and friends is another matter altogether.

Re:Take a step back and re-evaluate CSS

[dtfinch]

Just don't use CSS for the things it's not very good for, like replacing a variable width, variable height table layout.

Re:Take a step back and re-evaluate CSS

[Uther Pendragon]

I think CSS is good, most of the times I have had problems with CSS is when trying to adapt a correct layout to a layout that works with IE. Yes its frustrating.

The good thing is that if there is something that is particularly difficult to do in css you can be pragmatic and just use tables for that part.

It is still worth controlling as much as you can through css but don't be too obstinate about falling back to tried and true layouts.

Re:Take a step back and re-evaluate CSS

[Bogtha]

But, in the book, he examines a particular website, one with a plain-jane two-column appearance, which he said took "three CSS experts" to re-code from tables to CSS layout. Not three CSS advocates, three CSS *experts*.

I haven't read the book, but since you haven't provided any quotes, I can only assume you are misrepresenting what the book says, because two column websites are ten a penny and dead simple to create with CSS. You certainly don't need a team of experts.

Re:Take a step back and re-evaluate CSS

[Anonymous Coward]

CSS is good, it is just lacking some things that would be quite neat such as multi-column layouts, things to replace using tables for laying out pages, and so on. I think that a facility for tabbing would be cool too.

p {
      tabs: 100px left, 400px right, 600px right;
}

or whatever, I haven't got time to think about it right now.

CSS3 is what CSS should have been.

Re:Take a step back and re-evaluate CSS

[foniksonik]

Despite the limitations CSS is still the future of the web. It's not about beating table layouts though. It's about programmable attributes in a scalable system.

Think about using XML + XSLT + CSS to generate scalable presentation layers that meet the needs of multiple PLATFORMS using the same business logic and content layers.

Think about Accessibilty and the ability to define stylesheets for web browsers, text readers for the blind, PDF, printed versions, etc. without having to use multiple html layouts.

I find CSS to be quite robust as it is now and couldn't possibly design some of the web sites I've created recently without it. In fact I find myself wishing for a more robust CSS like stylesheet support model in my print programs, ie: InDesign, Illustrator, etc. so that I could transform content designs into multiple print layouts as easily as I do my web sites.

Sorry I couldn't flame you more but I felt it was more important to point out the positive side of CSS than tell you how ignorant you may or may not be on the subject.

Re:Take a step back and re-evaluate CSS

[Anonymous Coward]

Oh, don't be so silly. A two column layout? Please.

body{background:url(tilingstripe.png) center repeat-y;}
#leftcol{width:49%;float:left} #rightcol{width:49%;float:left}

Pshaw. And I'm a *girl*.

-Dody

Re:Take a step back and re-evaluate CSS

[Loundry]

The problem is not CSS itself, but the various implementations of it. A two column layout is piss-easy in theory, but getting it to look the same in mozilla/MSIE/Opera and friends is another matter altogether.

How about this:

<table border="0">
  <tr>
    <td>Column 1</td>
    <td>Column 2</td>
  </tr>
</table>

And then I get flamed because I'm using tables for layout instead of CSS. But it takes 3 CSS experts to code such a thing using CSS.

And don't get me wrong: it very well likely is the browsers that are to blame for much of this problem. This doesn't mean that using CSS to do what appears to be rather simple things is, at times, really difficult. Hence, we should re-evaluate whether or not we should be putting so much effort into coding "purely" as is desired by CSS advocates. It's just too early to be such strong devotees to a good idea.

Re:Take a step back and re-evaluate CSS

[iBod]

A two column layout is piss-easy in theory...

What if I want both columns to grow vertically depedning on the longest content of either column (like a 2 column table would).

Now that should be piss easy, but is it?

Re:Take a step back and re-evaluate CSS

[Finuvir]

That same design would have been trivial to convert to CSS (dropping most of the extraneous markup along the way) if those experts were able to use the full power of CSS2. Unfortunately a significant number of people use a browser that has yet to make any headway into supporting CSS2. You may be able to guess who produces said browser.

Re:Take a step back and re-evaluate CSS

[Bogtha]

What if I want both columns to grow vertically depedning on the longest content of either column

Easy:

.foo { display: table-cell; }

Re:Take a step back and re-evaluate CSS

[cr0sh]

Yeah - but try adding a footer at the bottom of those two columns - or expand it to three columns with a footer - and keep the lengths of *all three* columns the same regardless of what content is being displayed in any one of the three columns.

I am a recent CSS convert, and this problem popped up on me almost immediately because I am redoing my site. I ended up going with a different layout (though it breaks in different, but not unuasable, way under IE) - because all the hacks I found where you encapsulate all three columns in a background container div with a background image that repeats vertically just wasn't cutting it for me.

I still don't understand why you can't have divs "linked" to each other (oh, wait - you can in some manner, that I haven't explored - in CSS2 or something there is a way to get divs to emulate tables to do just what I wanted it to do - but IE it doesn't work at all!)...

Gah - why can't all the browsers properly use standards the way they were defined and meant to be used!!!

Re:Take a step back and re-evaluate CSS

[squoozer]

Here you go I put together a page about it CSS layout. I'm no CSS expert but I investigated this in quite some depth. All the ways that I could find to do it stank of a hack so I just used a table (which also stinks of a hack but it felt like the least worst option).

Re:Take a step back and re-evaluate CSS

[Anonymous Coward]

To be fair, Zeldman's book was written an age ago by CSS standards, and I think you'll find most standards-savvy web designers would most likely consider the book as more a "call-to-arms" than an actual instructional manual.

The hacks described in the book WERE cutting-edge at the time, when browser support was (far) less than perfect (even less so than today). Hence the need for experts.

These experts pioneered a great deal of the CSS knowledge we have today, and it's by their early efforts that we have such a wealth of cross-browser techniques available. These techniques are quite mature in themselves, and allow designers the freedom create complex CSS-based designs.

So - no flame, just a little perspective.

Re:Take a step back and re-evaluate CSS

[cranos]

It seems arbitrary, arcane, and particularly difficult to debug. On top of that, it seems to have a set of zealots who defend it (and demand it) with bitter viciousness.

And this is different from any other development language how?

Re:Take a step back and re-evaluate CSS

[Anonymous Coward]

Errr. I guess, some combination of:

#footer {width:100%;height:10%;clear:both; background:#fff;}

I dunno.

Three columns works well with a containing div. You can do funky things with background colours too. I'm not sure why that wasn't cutting it for you.

Personally I think that emulating tables is restrictive. Divs, representing units of information (or complete clauses if you like), in a logical hierarchy, should just be let free to boogie all over the page. Float everything left and play Tetris with the damn thing. Tables for tabular data; divs for units of information! *waves banner vaguely* :)

-Dody, who really should get round to getting an account one of these days

Re:Take a step back and re-evaluate CSS

[tedgyz]

I recently picked up a book entitled _Designing with Web Standards_ by Jeffrey Zeldman. It's a good an honest resource, and he even claims to avoid zealotry. But, in the book, he examines a particular website, one with a plain-jane two-column appearance, which he said took "three CSS experts" to re-code from tables to CSS layout. Not three CSS advocates, three CSS *experts*. On top of that, their "solution" turned out to be a hack.

Ugh! No zealotry? The whole book is one big "Ra, ra! Cis boom ba! Goooooo CSSS!" I had to put it down halfway through because there was no meat to the book, just chapter after chapter telling me why I should use CSS.

The fact is, I'm already using CSS. I like CSS. I know it's strengths and weaknesses. I was trying to learn more about CSS. Zeldman's book did not do it for me.

Eric Meyer does a fair job in O'Reilly's "Cascading Style Sheets: The Definitive Guide", but that book is not perfect either. His problem stems from crude examples that demonstrate CSS subtleties, but bear very little resemblance to real-world websites.

Re:Take a step back and re-evaluate CSS

[iBod]

Clearly the irony of that 'solution' is lost on you.

Hey! Lets make DIVs act like table cells - COOL!!

Re:Take a step back and re-evaluate CSS

[smagruder]

Hey, I won't flame you, but perhaps surprise you by shaking your hand (rhetorically).

I think the biggest question to ask when considering CSS for layout versus tables is: "Does the paying customer care?"

That said, I am definitely an advocate of using CSS for cross-site tag formatting to achieve a common look that's easily maintainable.

But using CSS for layout in place of tables, while worth exploring, and even implementing in cases where you end up with simpler resulting code (that actually works the same across all browsers), is really not worth doing for its own sake. I mean, if you can't get something to work with CSS, don't pull your hair out... just stick with tables and breathe easier.

The "CSS for layout" zealots seem to be as vehement in their dogma as the "OOP for all programming" zealots. Last time I checked, writing code in C, Perl and non-OO PHP is still quite popular. Objects are great for particular implementations, but for everything? Nope.

I would say ignore the zealots and do what your customers want. Also note that the visitors of sites who actually need the "semantic layout" are extremely rare--another tidbit the zealots won't admit.

Re:Take a step back and re-evaluate CSS

[Bogtha]

No irony. You want something that isn't a table cell to be presented like a table cell, so I pointed out the CSS that does just that. Hacking up content by describing things that aren't table cells as table cells to get a particular presentation further down the line is a circuitous hack and hardly something that I would gladly use.

Java Swing or AWT to HTML and CSS

[syousef]

Here's a shameless plug for you. Here's my code for converting Java Swing or AWT to HTML and CSS. It's primitive, but it may be useful to someone. It should be easy to modify this to convert any running Swing/AWT application from Java to HTML/CSS. Oh and of course its GPL.

http://www.progsoc.uts.edu.au/~sammy/javaGUIConver ter.html

Re:Java Swing or AWT to HTML and CSS

[OmniVector]

Spiffy. It would be nice if you included screenshots :) / example exported webpages. My other request is, make the swing converter convert to JSP, so you could create a usable interface for apps / webpages and the same java backend :)

Re:Java Swing or AWT to HTML and CSS

[syousef]

That's cool. It currently works for my own purposes. I haven't actually had any interest in the tool yet, and it is a programmer's tool rather than a user tool. If I had interest I'd consider improving it.

Re:CSS linx

[MBHkewl]

CSS = Cascading Style Sheets, not Counter Strike, you egg-head!

Oooh, oh, unless you're trying to be funny.. yea that's kinda funny.

Real answer - - Money

[rednip]

If you're a busy designer, sometimes you just have to take the pragmatic route rather that waste hours or days trying to make a pure CSS layout work across all the common browsers (none of which implement CSS 100% correctly anyway).

As long as you use the 'strict' delcaration on you pages, it's fairly easy to create a good looking page accross browser implementations. The real issue is that news sites don't build pages indivudally and a change to 'real' CSS would take a major change in the system code. Changing it would be a major implementation, which could cost millions.

Keep it simple stupid...

[bradbury]

I fail to understand *why* people are fixing things which are not broken. I use the web as an information resource. That means I want "Just the facts Mam". Those could have been presented to me in HTML 3.2 (which many readers may be too young to remember)...

Some sites have intelligent managers (Amazon and Google come to mind). They don't go overboard on overengineering their pages. They work with legacy browsers, etc.

How about an open-source app which plugs into standard proxy filters (e.g. squid) which removes all of the over-engineered crap web sites distribute? (I.e. No more Flash that I didn't request, no more Microsoft HTML'isms I didn't request, no more CSS, no more marketing crap I didn't request, etc.)

I.e. I get back to a world where I view what is important to *me* and not someone trying to sell me something I have no interest in. If that means a few information providers have to revise their business models -- hey thats life.

But I tend to come from the old school -- show me what I want to see -- when I want to see it. All of this overengineering of web pages defeats that.

Re:Keep it simple stupid...

[Anonymous Coward]

What the hell are you ranting about?

Look, the world has moved on since HTML 3.2.

There are many more devices other than computers than need to render web pages now, and you need to be able to SEPARATE CONTENT FROM PRESENTATION and provide a SEMANTIC CONTEXT for the information.

If this blows your mind, go and lie down in a darkened room until the 21st century arrives.

Re:Keep it simple stupid...

[zkn]

The internet seems to me in itself to be a fixing of something that wasn't broken. If you feel like using the web for nothing but text use Lynx.
Why do you feel you need to filter contents to render stuff in browsers that support all the stuff you don't want? Why not just find a browser that fits your needs?
The problem isn't the content providers, it's your inability to request content to your own specifications.

Re:Keep it simple stupid...

[danielk1982]

CSS is mostly for web builders.

YOU might not care whether or not a website is made with HTML3.2 or CSS or whether it uses php scripting with a Database backend but the guy behind the scenes probably does; especially if the time to edit ,add or format content will decrease from 5 hours to 10 seconds.

It seems like the internet peaked for you back in 1996.


If that means a few information providers have to revise their business models -- hey thats life.

Yes.. they will revise just for you.. you special person you.... ..

Keep waiting.

Re:Keep it simple stupid...

[porneL]

Yes, CSS is made to keep HTML simple. It takes layout/presentation complexity out of it. So-called semantic code looks just like HTML2/3, and works great even in Lynx.

CSS allows users to override authors stylesheets. Take a look at user CSS in Opera 8 - you can increase contrast, add debug elements or even make every page look like displayed in Commodore 64 text mode.

CSS stores presentation information in quite efficient format - selectors and cascade allow elimination of most repetition while keeping it relatively simple (obviously you have to know and understand CSS for it to be simple).

There should be no dispute about Tables VS CSS - CSS has display:table-cell. Internet Explorer (including IE7) is the only major browser that doesn't support it, so it's CSS vs IE-stuck-with-tables.

Re:Keep it simple stupid...

[ultrafunkula]

The idea of using CSS is that the content is kept separate from the presentation. This actually makes it easier to show you what you want when you want to see it.
You can use your own stylesheet, for example, to cut out sections you don't want to see (assuming the content has been marked up properly).
This also means that users with specific requirements (partially sighted, for example) can access content in the way that is most convenient for them (using a screen reader, or just applying a high contrast stylesheet) without having to have a specially designed site.
Personally, I think widespread CSS adoption will make the web a lot more accessible and customisable.
We, the audience, will have control of how information is displayed.

Re:Keep it simple stupid...

[Bogtha]

I use the web as an information resource. That means I want "Just the facts Mam". Those could have been presented to me in HTML 3.2

Disable CSS in your web browser. You'll get "just the facts" from the websites that use HTML + CSS, and you'll get "the facts dressed up with lots of style" from the websites that use HTML + tables. It sounds to me like HTML + CSS does what you want, not HTML + tables.

I.e. I get back to a world where I view what is important to *me* [...] But I tend to come from the old school -- show me what I want to see -- when I want to see it.

That's exactly what CSS was designed to do. Want a plainer website? Use a user-stylesheet that disables all the backgrounds, hides all the graphics, and uses your colour scheme. That's the "Cascade" in "Cascading Style Sheets".

Re:Keep it simple stupid...

[Mant]

One of the ideas of CSS is it does strip out all the presentation stuff, and puts it into the CSS file. Since most browsers allow you to overide the sites CSS file with a local one, you could make a "plain" CSS file and you get what you want.

Unfortantely CSS as implimented is up to doing serous layout stuff, so sites still use nested tables and things that replacing the CSS won't remove.

Of course web sites did that in HTML3.2 as well.

Re:Keep it simple stupid...

[hswerdfe]

HTML 3.2 (which many readers may be too young to remember)...

all they need to do is go view source.

Re:Keep it simple stupid...

[colinrichardday]

No more CSS?

What if I have a table of numerical values, and I want the numerals aligned on the right? Am I supposed to type align="right" in every instance of <td>? Gee, I wish there were a way of typing class="numerical" into the table tag and then having table.numerical td {text-align: right;} in some other file. Oh wait, there is.

What next? No .h files in C?

Re:Keep it simple stupid...

[Eustace Tilley]

When the n-th child pseudo class (http://www.w3.org/TR/2001/CR-css3-selectors-20011 113/#nth-child-pseudo) becomes available, you will be able to text-align a particular column of tds without having to type class="numerical".

It's even better...

[Hurricane78]

... to know the whole css spec by heart and *understand* it. (like i do ;)

Re:It's even better...

[deesine]

You are hereby crowned Lord Geek of CSS. Protect thy kingdom and do no evil!

Counter Strike Source

[Anonymous Coward]

css rocks... boom headshot

Trying to understand CSS...

[islandrain]

Ironically, I am taking the week to sit down and really figure out CSS because I'm sick of seeing the term everywhere and having ZERO clue of how to use it effectively. Let me get this straight to begin with - I'm a designer, not a web expert. I use *gasp* Dreamweaver, although I know HTML just fine. It's a visual thing and I work better seeing the flow of the graphics, etc. directly on the page. So my biggest beef is wanting to design non-framed pages where menu links will change without having to manually change them in each page. I want you CSS people to respond to this: Tell me three reasons why CSS is the way to go (cleaner codes isn't a good reason for me, either).

Re:Trying to understand CSS...

[megrims]

(cleaner codes isn't a good reason for me, either).

You wouldn't love pasta, by any chance, would you?

Re:Trying to understand CSS...

[goldspider]

1. You don't have to modify every .html file when it comes time to re-design.

2. Accessibility - your site will be readable by screen-readers and PDAs.

3. You can use standalone CSS to control the overall dosplay, and in-line CSS to control page-specific elements.

I wouldn't call myself a CSS "expert", but I am a recent convert.

Re:Trying to understand CSS...

[mpitcavage]

"where menu links will change without having to manually change them in each page"

I think your looking for SSI, not CSS. SSI will allow you to "include" a menu page on all your other pages. If you make a change to that menu page, it appears sitewide instantly. It's like Dreamweaver "Templates", but usable.

Re:Trying to understand CSS...

[oglueck]

It makes Webapp development easier. You don't need web designers to make the HTML. As a developer just produce HTML and let the web designer create the CSS.

This is important, since in webapps there rarely are HTML pages that you could open in Dreamweaver and edit nicely. HTML is normally distributet in several include files and messed up with non-HTML code like JSP, JSTL, template engine code. In lolcalized applications there is not even text in a dynamic page.

Now, just generate a sample page with dummy content and give it to your designer to make a CSS for it. Of course your designer will require you to include some meta information in the HTML code: element ids, style classes, grouping certain elements in div elements etc. But this is far easier than maintaining a design in HTML!

Re:Trying to understand CSS...

[Anonymous Coward]

Accessibility
Ease of layout change across site
Bandwidth (useful for high-volume sites)

There's three. I'll give you a fourth:
Once you've learnt it inside out, CSS is _vastly_ more flexible than anything else. Ok, you'll need to memorise a couple of hacks to make it work across all browsers, but I work with designers who give me obscene layouts and I wouldn't even dream of trying them with tables.

Try writing a cross-browser overlapping tab-menu with tables and no Javascript.

Re:Trying to understand CSS...

[islandrain]

*Sigh* This stuff is totally past me. I wish I knew someone who I could work with on some of this stuff.

Re:Trying to understand CSS...

[Anonymous Coward]

I want you CSS people to respond to this

It would be far more polite to say something like "can somebody tell me...?" and not "I want you CSS people to..." One asks for help. The other is a demand for help.

Re:Trying to understand CSS...

[Man in Spandex]

Reason #1: Your ePenis will grow HUGE!

Re:Trying to understand CSS...

[Anonymous Coward]

Tell me three reasons why CSS is the way to go

1. Site-wide changes in a single place. Want to change the font? Change it in the stylesheet.
2. Bandwidth. If all the design is in a stylesheet, both visitors AND proxy servers can cache the file. Then all they need to download in subsequent pages is a fairly lean and clean HTML file. (Sorry - I mentioned clean code.)
3. It's the right way to do it. Tables are the mother of all web-design hacks. They've been used and abused far beyond their original intention.
   
   And I'll give you a bonus 4th reason:
4. Search Engines and blind users will love you for making clean, CSS-based sites. They Work Better. (TM)

Bandwagon?

[danbeck]

Jump on the bandwagon? There is no bandwagon, web pages are built with HTML and CSS for many reasons - the least of which is because the Jones' are doing it.

Welcome to the intarnetz, we use CSS here.

Poor CSS2 browser support

[goldspider]

For not I'm sticking with CSS1 until there is better browser support for CSS2. It's great to be standards-compliant, but it's kind of pointless if the majority of browsers can't read it properly. Just my $0.02.

Re:Poor CSS2 browser support

[Anonymous Coward]

Majority? Only one browser can't.

The problem is browsers, not CSS

[goldspider]

I'm reading that book too, but I have a different take on why it took three CSS "experts" to re-code that page.

It's not CSS' fault; it's the noncompliant browsers. Zeldman's book is basically about using CSS to build a standards-compliant web site that renders properly on a variety of non-compliant browsers.

Given the differing level of support among the browsers out there, it's no wonder that one has to jump through some hoops to get a consistent display.

Re:The problem is browsers, not CSS

[dcam]

It's not CSS' fault; it's the noncompliant browsers

When it comes to boots on the ground stuff it doesn't matter who is in the wrong. The only significant difference is that in the future browsers may be fixed to work with CSS better. But that doesn't change the fact that right now your CSS won't work.

What is more the effective lifetime of a browser is probably around 4 years. So we still need to support IE5 *now*. We probably still be supporting IE6 in 3-4 years from now. So the problems we have now will still be problems in 4 years.

not sure if this is a css question

[Adult film producer]

but one of the biggest problems that I have with webpages are the font sizes. I've tried to configure the browsers that my mother & father use, their old eyes can't read many of the fonts people use in their webpages (supersmall & thin).. even with a 19 or 20" monitors, either I'm forced to lower the resolution to something ridiculous like 800x600 or run the regular res (1280x1024 or better) but have "minimum font size" set at 18 or 20 in firefox... That's a problem because fonts that large with a fixed minimum size cause the text in many webpages to overlap one another :( (espn.com, prisonplanet.com, etc even some of those zengarden pages suffer from this..)

Re:not sure if this is a css question

[Anonymous Coward]

CSS em sizing is the solution, or, a solution. If all elements are sized in ems and percentages they should be scalable without going screwy. Em sizing is becoming more popular but, for now, just turn off styles, I guess?

Or try user style sheets. Then you can configure the pages to your own liking. <a href="http://www.oreillynet.com/pub/a/network/2000 /06/30/magazine/mozilla_stylesheets.html">learn more</a>

-Dody

-moz-stylings

[zkn]

Gecko has som specific CSS stylings that are fairly usefull but only render in gecko like:

• -moz-border-radius:
• -moz-border-left-colors:
• -moz-opacity:

Can't say I know if they are on the official spec for CSS2 or CSS3 but I would like to see gecko implementing stuff in a more nonbrowserspecific way. I don't think these stylings will ever become standart with that syntax.

Re:-moz-stylings

[Rocketship Underpant]

Actually, Safari already has opacity as well, so you can't count that as Gecko-only.

What's more, Safari has implemented multiple background images for single elements. That means divs with custom corners and drop shadows no longer require messy code with extra divs.

It's funny how IE never comes up in a discussion of advanced web technologies. :)

Re:-moz-stylings

[arkanes]

These are the mozilla-specific names for features that are in CSS 3. The dash prefix, by the way, is the correct and standards-compliant way to create extensions.

I believe that -moz-border-radius is already mapped to it's CSS3 name, but if not they will be as CSS3 support is implemented.

Re:-moz-stylings

[Finuvir]

The CSS spec allows extensions as long as the vendor-specific properties and values are prepended by "-[vendor]-", like "-moz-", "-khtml-" or "-opera-". Mozilla uses these prefixes when the developers are working on implementing new features, like CSS3's opacity property. That was named "-moz-opacity" until it matched the relevant CSS3 candidate recommendation closely enough to rename it to "opacity" (the current and final name).

Re:-moz-stylings

[zkn]

My refering to it being "gecko only" wasn't the actual "effect", more the wording of the styling. I don't know this, but I assume that Safari won't reconize "-moz-opacity:0.4;"
Personally I hate the whole "-moz-" wording, I consider it destroctive to the building of a common standard, if others are going to impliment it they are going to do so with different names simply to get rid of the '-moz-'.

IE will hopefully catch up sometime in the future, or die out.

Re:-moz-stylings

[smagruder]

Don't mistake me for an MS shill, but IE supports opacity as well: Use "filter: alpha(opacity=nn)" where nn is the percentage.

Also, "opacity: 0.nn" can be used for both Safari and Gecko. "-moz-opacity" can still of course be used for Gecko, but the "-moz-" prefix isn't necessary.

CSS 2/3 Examples

[jdub_dub]

The other day I found http://nemesis1.f2o.org/aarchive?id=6 - it's a fantastic read, showcasing the power of CSS2/3. Well recommended (I learnt heaps - e.g. extracting data from to put into the document, using only CSS!)

CSS showcase

[Dr.Opveter]

Some more CSS showcase sites I like to check out every now and then:

CSS Beauty
The Weekly Standards

Also this site has some nice templates

Some more for you web-design junkies

[Anonymous Coward]

Google's Directory on Web Design -> FAQs, Help, and Tutorials
Eric Meyer's CSS Reference page (warning: requires frames, but it's tasteful use :P)

More on Eric Meyer, who is web-design guru in general, but well-known for his css/edge presentation, and, well, check out his site, definitely worth a read.

Well, that's it, other's that I know of have already been posted.

heehee

[mattyrobinson69]

1: the us copyright office
2: slashcode

One more

[amrittuladhar]

One more, a good resource not only for CSS but many different web technologies, mostly for beginners:

W3 schools (Warning: Has a popup, but it's worth it)

Re:One more

[Yremogtnom]

Actually, this site is a GREAT CSS (and more) reference for a web developer to have. It's all I use to find CSS info. Use google's site search to find things quickly. Go to google.com and type:

"<search terms$gt; site:w3schools.com"

It's funny that you mentioned this site has a popup... I've never noticed (thanks to Camino & Firefox)

Separate structure from design

[goldspider]

Developers need to keep in mind that (X)HTML should be used to establish structure, and CSS for display.

When you've used HTML for display your whole career (at the expense of structure), it's hard to think of a good page as two necessarily separate parts.

It doesn't help that browsers support bad code either.

Essential Bookmarks For Web Developers

[vitaly.friedman]

Ironically, the main version of The Web Developer's Handbook wasn't mentioned in the list. However, I actually feel great being slashdotted again. ;)

quirksmode

[eelcoh]

Has anyone mentioned http://www.quirksmode.org/?

Re:CSS!!! XHTML!!! OH GOD I LOVE THE STANDARDS

[bemenaker]

Right, and you had to read /. first..... whose the nerd now buddy.... :D

css attributes reference

[rnd()]

this is a great reference, and it shows which features are IE only vs which are standard.

Re:css attributes reference

[Anonymous Coward]

The fact that there's no such thing as a CSS attribute (they are called properties) does not inspire me with confidence. If they can't even get basic terminology right, how do I know there aren't more serious mistakes lurking?

Re:css attributes reference

[rnd()]

in inline stylesheets the css information is contained as attributes of tags.

Re:css attributes reference

[Anonymous Coward]

Sigh. No it isn't (it's the content of style elements), and even if it was, the attributes would be a property of the HTML, not of the CSS.

The article is talking about CSS properties, except they call them "attributes", which is a very good indicator that the person who wrote it doesn't communicate with people who know basic things about CSS very often, which is a very good indicator that the person only has basic familiarity with CSS, which is a very good indicator that there will be serious mistakes in the documentation.

Really, a good way of weeding out wannabes from people who know WTF they are talking about is that the people who know WTF they are talking about use the right words for things.

Would you trust a brain surgeon if he couldn't remember the right words for the parts of your head? Or would you start thinking "Hmm... I know he's a qualified surgeon, but that's a pretty big warning sign that he doesn't know what he's doing"?

Re:css attributes reference

[rnd()]

Why don't you look at the reference before you judge it only based on the title. It took me a while to find it due to the slightly misleading title, but once I found it I was glad I had.

W3!?

[the web]

Probably because there is nothing resourceful about trying to understand what the hell is spelled out there.
 
That's a developers site and not for people who draw for a living.

Frustrating

[boatboy]

One of the sites is described as another site dedicated to learning layouts and the little quirks that each browser brings into your CSS design. As a software developer, this is one of the most frustrating parts of CSS. Not one browser is compliant, forcing the developer to use wierd hacks to get a uniform look. This really detracts from purpose of CSS, and leads to hard-to-understand CSS and HTML.

Really?! Like wow!!!

[mysticgoat]

From the slashdot-is-moving-to-css-in-just-a-few-weeks dept.

oh I do hope commander taco isn't just putting me on...

The reason for the -moz syntax...

[Millennium]

Almost all of the -moz sttributes correspond directly to attributes proposed for CSS3, and they're mostly implemented as per the current proposal. However, CSS3 has not been finalized, and there is a small but nonzero chance that these attributes will somehow change. If that were to happen, then (for example) opacity: might work one way on earlier versions of Mozilla and differently on later ones. This is a Bad Thing, because it prevents pages from degrading gracefully.

Using the -moz prefix avoids this problem. If the standard is finalized without any changes, then opacity: and -moz-opacity: can use the same code, and that will be that. If the standard changes, however, then opacity: can be implemented according to the new standard, -moz-opacity: can continue according to the old implementation (since it was never standardized anyway), and neither old nor new pages will break.

Incidentally, the CSS specs suggest exactly this solution, and I believe they actually use the -moz prefix as an example. KHTML and WebCore have a similar scheme, though they use a -khtml prefix. It would be nice if IE started using an -ie prefix in the future for its own stuff, though it seems unlikely that this will happen.

actually it is

[Run4yourlives]

just use a single background image for your "columns" and carry on as per.

Re:actually it is

[Matt Perry]

Which works until you need to background image to stop at your header or footer. Better to use javascript to find the tallest column and make the other column the same height.

Re:actually it is

[iBod]

>>Better to use javascript to find the tallest column and make the other column the same height.

Or use a table ;)

Don't forget centricle's CSS filter chart!

[Anonymous Coward]

This resource gets used by our team at least every day:

http://centricle.com/ref/css/filters/

The w3c XHTML validator says:

[Anonymous Coward]

"YOU FAIL IT BIG TIME"...

http://validator.w3.org/check?uri=http%3A%2F%2Fwww .mentallyretired.com%2F&charset=(detect+automatica lly)&doctype=Inline

Now what was that you were saying about semantic XHTML?

[p.s. whatch how he immediately goes in a panic to fix up his crappy markup and then reply with 'I don't know what you're talking about l00zer']

The Problem

[Run4yourlives]

multiply said structure by 1000.

Client: We'd like to have a three column layout now please.

Result: P.I.T.A.

Here's a better way:

HTML:


       
       



CSS:

#wrap {background url(2_col_background.png) top left no-repeat;}
#col_1 {width: 200px; float: left;}
#col_1 {float: right;}
#footer {clear: both;}

The trick is in the backgound image, which would have one colour for 200px, then switch to your other colour for the rest...

Personal Observations:

[LifesABeach]

I've noticed that for a lot of web designer folks; It is aways acceptable to be the second slowest Zebra in the heard. What is even more entertaining to watch, is that their client IS the slowest Zebra in the heard.

Of course it goes without saying that unless your the lead zebra, the landscape NEVER changes.

Your solution is illustrative of my gripe

[Loundry]

Client: We'd like to have a three column layout now please.

Result: P.I.T.A.

I suppose I should thank god such a thing has never happened to me. It seems to me that in the eyes of CSS adherents, 100% of web pages are wildly fluid things that change with the winds, and wildly. Maybe that can be said for some development projects, but, in my experience, it's just not that bad. My problem is not that my clients are as fickle as you make them out to be, but rather that CSS is near impossible to do correctly for some simple tasks. Solve the real problem, not the hypothetical one!

#wrap {background url(2_col_background.png) top left no-repeat;}
#col_1 {width: 200px; float: left;}
#col_1 {float: right;}
#footer {clear: both;}

The trick is in the backgound image,

I described CSS as "arbitrary" and "arcane", and your code example is illustrative of my point. I suppose the "clear: both;" should have been obvious to me? Furthermore, why should such a simple layout require a "trick" (as in your background image)? I conclude that it is too early to try to adhere to CSS standards with any rigor.

Re:Your solution is illustrative of my gripe

[Matt Perry]

I suppose the "clear: both;" should have been obvious to me?

Probably not. There's always going to be a point where you have to read the docs. I didn't understand C's pointer syntax until I read the docs. The 'clear' property has to do with allowing objects to float to the left or right of the current object. In the previous poster's example he has the smaller column on the left float to one side and the larger column on the right float to the other side. Using "clear: both;" on the footer indicates that he wants to footer to be clear of any floating elements on the left and right side. He could have used 'left' or 'right' in place of 'both' in the declaration. Had he not cleared both floating elements the footer would be between the two floating columns.

Furthermore, why should such a simple layout require a "trick" (as in your background image)?

It doesn't. It's not a trick as much as a design decision. Unfortunately CSS doesn't allow for setting the height of an element. If you wanted to have a two column layout with one column's background using one colour and another column using another colour then you'd usually use tables. That way the height of both columns would be the same and the background colour of the smaller (usually navigation) column would stretch down to the bottom of the content column. With CSS you can't guarantee the height of the enclosing block. In this case the user worked around that by using a background image with a colour stripe that would pass underneath the area that had the left column. An alternate way to hand this would be to use javascript to check the height of the two columns and make the shorter column the same height as the taller column.

Re:Your solution is illustrative of my gripe

[Bogtha]

I described CSS as "arbitrary" and "arcane", and your code example is illustrative of my point. I suppose the "clear: both;" should have been obvious to me?

That's a bad example, because the 'clear' CSS property gets its name from the 'clear' HTML attribute that was introduced along with all the other HTML 3.2 cruft.

Furthermore, why should such a simple layout require a "trick" (as in your background image)?

But the whole concept of using tables for page layout is a "trick" like that!

I conclude that it is too early to try to adhere to CSS standards with any rigor.

If that's your basis for avoiding CSS, then you must avoid table layouts and other presentational HTML too, for this criticism applies equally, if not more so, to that.

Re:Your solution is illustrative of my gripe

[smagruder]

If that's your basis for avoiding CSS, then you must avoid table layouts and other presentational HTML too, for this criticism applies equally, if not more so, to that.

Please don't take offense, but many many designers will "call bullshit" on a remark like this. Tables reflect a very old presentation idiom that many are very well-accustomed to. It may often be "as complex" to do a layout with tables, but if it follows existing long-term experience, it's also a lot easier.

Re:Your solution is illustrative of my gripe

[Bogtha]

No offense taken. I completely agree that if you're experienced with tables, they are going to be easier. But we shouldn't let experience blind us to new, better ways of doings things just because "that's what we are accustomed to". And ease isn't the only factor. It's easier to only code for Internet Explorer, that doesn't mean it's better.

And I must say..

[pkphilip]

I agree. From my experience with designing using CSS divs alone, it has been a very frustrating experience. Getting DIVs to hold their position has been very difficult and I have had some real problems with it. I would have saved myself loads of work by just using table markup instead.

As for semantic HTML, you could achieve quite the same level of semantic information using tables and spans. And so, yes, I agree with you completely.

Re:And I must say..

[Anonymous Coward]

Stop pixel perfect positioning.

Here is the quote from the book, CSS experts fail

[Loundry]

I haven't read the book, but since you haven't provided any quotes, I can only assume you are misrepresenting what the book says, because two column websites are ten a penny and dead simple to create with CSS. You certainly don't need a team of experts.

We all know what assuming does. I searched the book for about 20 minutes by hand until I finally found the section, and I quote it here:

"When A List Apart magazine converting from HTML tables to CSS layout in February 2001, it took three designers, including this author, to figure out how to do it. The two others were experts Fahrner (who contributed to the CSS specifications) and Celik (who contributed to the CSS specifications and built the Tasman rendering engine in IE5/Mac). The original, table-based design was essentially a two-column layout with a liquid content area and a right-hand sidebar whose width was cast in stone. Between the three of us, we managed to achieve roughly the same effect in CSS using the nonintuitive method sketched in the preceding paragraph. The overall width is kludged with values that never add up to exactly 100%. It should not be that hard to create a two-column layout combining liquid and fixed elements." Jeffrey Zeldman, _Designing with Web Standards_, p. 281

Read a few of the choice quotes:

- "The other two were experts..."
- "...using the nonintuitive method..."
- "The over width is kluged..."
- "It should not be that hard [to create what is otherwise a simple design using the inferior, table-based method]"

Honestly, Zeldman wrote a book that was intended to "convert" me to the CSS mindset, but, reading what he writes here, it seems that I'm destined to find at least some degree of failure or imperfection. It leads me to believe that "no, it's not just me" when CSS seems kludged and nonintuitive (if I may borrow a few of Zeldman's adjectives to describe CSS).

Web Designers Still Clueless

[RonBurk]

The zen garden is particularly emblematic of what you're likely to get if you pay a "web designer" to make your website. It totally ignores what typical website customer needs are:

1. They mostly use IE.
2. They mostly want pages to load quickly (look at those piggy graphics)
3. They mostly have older eyes that can't comfortably read small fonts (look at all the glitches on those websites when you set View|Text|Largest)

Website designers like this are also clueless about the needs of they people who pay for website design. There is really no point in jumping through tons of hoops with cluttered codes just to get three columns that still don't quite work right in all conditions when you can just use an HTML table to do the same thing in 1/10th the complexity.

They generally still end up doing a miserable job at separating presentation from content.

The only good way to make websites that have to be maintained is to generate the websites. That way, you can use tables, CSS, whatever-you-like, and know that you can change your mind site-wide just by changing the generating code.

Re:Here is the quote from the book, CSS experts fa

[Bogtha]

I'm amazed, really. That's a dead simple layout, and I have no explanation for why it's described as such a gargantuan effort. I was under the impression that this was a good book, but after reading that, I can only suggest that you throw it away and read something else instead. I'm sorry for doubting your description of the book. Really, try another book. CSS just isn't as hard as it is made out to be.

Experience?

[iBod]

Thank your for sharing your wisdom.

I too have 'several' years of experience of CSS - probably as much as anyone as I use it almost everyday. This doesn't make me blind to CSS's shortcomings however.

If you have been dealing with CSS for 'several' years and you 'have no problem at all visualizing the layout' then all I can say is:

a) you can't have desiged very many layouts, or

b) all your layouts must have been piss simple

Major commercial sites require complex, flexible, modular layouts that change on a day-by-day basis and need to accomodate whatever piece-of-crap, third-party content item that comes along.

I'm not talking blogs here.

Re:Experience?

[xENoLocO]

Nor am I. I'm part of the two man team that is teaching CSS development classes at Disney Internet Group.

Re:Experience?

[iBod]

Disney Internet Group?

Isn't that something to do with Mikey Mouse?

God help them if YOU are teaching them CSS Development!

Have a nice Celebration in Celebration!

Recoding a web site in CSS

[horza]

If you look at the following web site with property for sale in Nice, you will see it uses extensive CSS. The original web site was done using tables, which I then converted to CSS. There isn't a single image in the whole of the HTML of the web site apart from a few photos which are content and not design.

Advantages CSS over tables:
* the nested tables were fixed width, too complicated to convert to proportional, and if you resized the windows to anything larger than 1024x768 then you had to pan around using the scroll bars. The CSS degrades wonderfully. Even if the display breaks and doesn't look as pretty, it's still usable at any window size
* pages are a fraction of their original size, and the actual content is clearly visible and editable

Advantages tables over CSS:
* cross-browser compatibility. Everything always works in Firefox but IE is a nightmare. Grey bars appearing randomly for no apparent reason, margins having unpredictable behaviour, and things breaking for no reason when pixels are exactly aligned (as proved by basic arithmetic)

From painful experience I can recommend that you get the designer to mock up in photoshop, and then you design the site directly in CSS and ask for the images to be chopped into the way you need as you go along. Don't get the designer to provide you the HTML in table form which you then convert afterwards.

Hope this helps,

Phillip.

Re:Recoding a web site in CSS

[yasgo]

You don't code a site in CSS. The content still uses HTML.

The CSS styles that content.

Instead of div hell you should code the content using semantic blocks: headings (to introduce sections of the page), lists (for lists of items), forms, paragraphs (for most of the normal content), and tables (for your tabular data)

Armchair Quarterbacks Still Clueless

[Orrin Bloquy]

Ahem. I rebuilt our university's library website 3 years ago. The layout is roughly comparable to Slashdot's home page: 2 fixed-width, side-flush columns surrounding a central content section which expands to the browser window's width.

1. We work within IE's limitations, but we push the envelope where we can. CSS is about graceful degradation, not lowest-common-denominator features.
2. A site which depends on a central stylesheet loads faster because .css files are cached by browsers. Zen Garden's demonstrating technique, not an acid test for bandwidth.
3. I can't speak for other designers. We stress test our layouts for largest type size. Also understand that Verdana/Vera Sans are oversized compared to all other screen fonts, and its overuse on websites is contributing to the problem.

When I rebuilt our site, I did two things simultaneously. One, the layouts became CSS instead of tables (modularity of design). Two, the reused content became server-side includes (modularity of content).

Both serve the same goal: modularity = faster, better maintenance. Either by itself is inadequate. CMSes which burp out tables are actually more trouble to maintain in the long run.

Trust me on this.

No - DIVs are still not same height !!

[iBod]

Everyone knows about the old background image trick but that's just a CHEAT.

There is no easy way of doing this with DIVs whereas it is 'piss simple' using TDs.

Best you can hope for is messing about with the DIV heights in the DOM using js after the page is loaded/resized - yuck!

css-discuss wiki

[g8oz]

The wiki for the CSS-Discuss mailing list is extremely helpful as well.

http://css-discuss.incutio.com/

Don't sweat it

[Loundry]

Believe me, I still use CSS even despite all the harsh things I've said about it! I think my gripe comes in two forms:

1. For some layouts, CSS just can't cut it the same way that tables can. Not all layouts, just some layouts.

2. CSS syntax, behavior, and debugging are arcane and unintutive.

Well, let's add a third gripe:

3. CSS advocates are often times really snotty, mean, and religious about CSS. They treat me like I'm some kind of retarded hick because I dare name a class "OrangeBox" or use a table to lay out a site.

And this is why I think we need to re-evaluate our use of CSS. It is not *yet* the cure-all that we want it to be. Let's not put too much effort into rigorous adherence to standards as such efforts will ultimately be futile in one way or another. I mean, if three CSS experts can't lay out a two-column site without nonintuitive kludges, then what hope does a neophyte like myself have at achieving "CSS purity"?

Re:Don't sweat it

[Bogtha]

1. For some layouts, CSS just can't cut it the same way that tables can. Not all layouts, just some layouts.

Maybe I'm just an unusual exception, but it's been years since I've resorted to table layouts. Netscape 4 was the last reason to hang onto them as far as I'm concerned. Maybe it's different if you are making "arty" websites, but for websites that just want to present information in an attractive way (i.e. every website I can think of outside of graphic design), I really don't see any need.

2. CSS syntax, behavior, and debugging are arcane and unintutive.

I agree. But I think exactly the same thing about table layouts. I think the only reason people call them "intuitive" is because they've been doing them for years. I once watched somebody (with a lot of experience) build a website that had tables nested about a dozen deep. I then went in and deleted more than half of them - without adding any CSS or anything - and the layout remained exactly the same. I've seen similar people get completely tied in knots trying to keep track of how deep they are and how many rowspans they need. I've seen bugs relating to table layouts where one half of a submit button was clickable and the other half wasn't. Things like that wouldn't happen if table layouts were intuitive.

3. CSS advocates are often times really snotty, mean, and religious about CSS.

You can say that about any technology really (table layout bigot example), if you use that as a reason to avoid CSS, then you are just cutting off your nose to spite your face.

Re:Don't sweat it

[Loundry]

Maybe it's different if you are making "arty" websites, but for websites that just want to present information in an attractive way (i.e. every website I can think of outside of graphic design), I really don't see any need.

The pages I have to code are artsy as all hell. Everyone on my team is a graphic designer. Perhaps you see no need becuase your experience is limited.

I agree. But I think exactly the same thing about table layouts. I think the only reason people call them "intuitive" is because they've been doing them for years.

Perhaps if there were a clear document explaining how commonly-used table-based designs would be rendered in CSS, then I would sympathize with this point. Since I have never seen any such document, and, furthermore, since three CSS experts found a common example of translating a common table-based design into CSS "kludgey" and "nonintutive", then you really don't have much to stand on here. Sometimes CSS just doesn't make the grade.

You can say that about any technology really (table layout bigot example), if you use that as a reason to avoid CSS, then you are just cutting off your nose to spite your face.

I feel like you are proving my point by resorting to the argument that I must be stupid if I don't properly accept your favorite technology. It's not like children will be tortured to death if I don't immediately turn all of my tables into divs, so, please, try to relax. Will you please accept that my situation might be different from yours and CSS might be more trouble than it's worth in regards to solving my problems? Will you please concede that my choosing to not use "perfect" CSS in all instances (remember, I still use it, and frequently!) might have nothing to do with my stupidity or my lack of discipline?

Re:Don't sweat it

[Bogtha]

The pages I have to code are artsy as all hell. Everyone on my team is a graphic designer. Perhaps you see no need becuase your experience is limited.

I wouldn't say so, I've been building websites since the 90s.

When you say that the pages you code are "artsy as all hell", does that mean that they are art for art's sake? I code for businesses; there's a purpose to the pages I create above and beyond just looking pretty. And like I said, I just don't see a need for table layouts - all the information I have to present can quite naturally be laid out well with CSS. If your pages aren't all about presenting information, then I can see how your experience might differ from mine.

Perhaps if there were a clear document explaining how commonly-used table-based designs would be rendered in CSS, then I would sympathize with this point.

But CSS is a fundamentally different approach. It's about modifying the document flow to create a layout, not trying to fit stuff into a grid. There's no easy translation from one to the other because they have completely different foundations. It's like trying to translate from English to Cantonese one letter at a time instead of taking the context of a sentence into account. What is suitable for one website using a particular layout is not necessarily suitable for another, similar-looking website.

since three CSS experts found a common example of translating a common table-based design into CSS "kludgey" and "nonintutive", then you really don't have much to stand on here.

Hang on a sec. They called this CSS approach kludgey and unintuitive. They didn't call table layouts non-kludgey and intuitive, at least not in the quote you provided. The description you provided does sound like a kludge and does sound unituitive. As I said above, I think that CSS is kludgey and unintuitive. But no more so than table layouts.

I feel like you are proving my point by resorting to the argument that I must be stupid if I don't properly accept your favorite technology.

WTF are you talking about? I made no such claim! You included the attitude of a few bigots as a reason to avoid CSS, and I pointed out that there are bigots to every approach and that you are cutting your nose off to spite your face if you use that as a reason to avoid a technology instead of judging it on its merits. If you don't accept CSS, that's fair enough, but to not accept it because people you don't like use it, then that's bad. Read what you wrote again:

CSS advocates are often times really snotty, mean, and religious about CSS... [...] ...this is why I think we need to re-evaluate our use of CSS.

You think that's a reasonable attitude?

Will you please accept that my situation might be different from yours and CSS might be more trouble than it's worth in regards to solving my problems?

You are responding to a comment where I did just that. That's what I was trying to get at when I was talking about "arty" websites as opposite to websites that present information.

Will you please concede that my choosing to not use "perfect" CSS in all instances (remember, I still use it, and frequently!) might have nothing to do with my stupidity or my lack of discipline?

Now you are just putting words in my mouth. Will you please concede that you have stopped beating your wife?

Re:Don't sweat it

[Loundry]

But CSS is a fundamentally different approach. It's about modifying the document flow to create a layout, not trying to fit stuff into a grid. There's no easy translation from one to the other because they have completely different foundations.

I would agree with this in the sense that the scope of CSS certainly exceeds that which is described as "table-based layout". That said, what is wrong with using a grid approach to layout?

Hang on a sec. They called this CSS approach kludgey and unintuitive. They didn't call table layouts non-kludgey and intuitive, at least not in the quote you provided. The description you provided does sound like a kludge and does sound unituitive. As I said above, I think that CSS is kludgey and unintuitive. But no more so than table layouts.

I don't agree with your analysis. They were trying to translate a two-column table layout into CSS layout and found it kludgey and nonintuitive. The description I provided is the best that three CSS *experts*, not laypeople, could muster when it comes to making CSS layout function on par with what tables can provide. Once again your defense of CSS comes down to bashing tables. Certainly tables are not used for what they were intended, but I don't see anything wrong with grid layouts and tables seem to do a fair job and executing that. CSS is certainly no better at doing layout than tables; in fact, it's worse. I've had another CSS defender in this very thread indicating that you have to *program* the CSS layout in JavaScript in some cases!

WTF are you talking about? I made no such claim! You included the attitude of a few bigots as a reason to avoid CSS, and I pointed out that there are bigots to every approach and that you are cutting your nose off to spite your face if you use that as a reason to avoid a technology instead of judging it on its merits.

And why would I "cut my nose off to spite my face" if not for stupidity or lack of discipline? Please explain to me why your argument is not an ad hominem, because, right now, it just looks like another "You're a dumbass because you don't use CSS in the proper way" argument. Besides, I have indicated the failures of CSS on numerous occasions in this thread, and your responses to those failures largely suck. You have 1) gone back to bashing tables, 2) bashed me, 3) characterized my complaints as irrelevant. Again, I repeat: I use CSS and think it's great, but it's not the cure-all that we want it to be. And I also dislike your snotty attitude and wish you would shape up. It certainly would improve your chances of CSS advocacy!

Read what you wrote again: CSS advocates are often times really snotty, mean, and religious about CSS... [...] ...this is why I think we need to re-evaluate our use of CSS. You think that's a reasonable attitude?

That is very unfair of you. I claim responsibility for using the demonstrative pronoun "this" is a loose way, as such a thing can lead to misunderstanding. But I think your misunderstanding is deliberate. You *want* me to be unreasonable.

The "this" in that post actually refers to these two points:

1. For some layouts, CSS just can't cut it the same way that tables can. Not all layouts, just some layouts.

2. CSS syntax, behavior, and debugging are arcane and unintutive.

And "this" is why we need to re-evaluate our use of CSS. Attempting to adhere to CSS standards with rigor is folly, and I am explicitly referring to using CSS for layout instead of tables.

Now you are just putting words in my mouth.

Okay, excuse me. How about I phrase it like this: Is it acceptable for me to use tables for layout because CSS sucks in comparison in that regard?

Re:Don't sweat it

[Bogtha]

That said, what is wrong with using a grid approach to layout?

Nothing. I'm just saying the two approaches have different foundations, so there's no easy translation.

I don't agree with your analysis.

Look, I'm pointing out that the experts are calling CSS kludgy and unintuitive, not calling tables non-kludgy and intuitive. You are responding by pointing out that they are calling CSS kludgy and unintuitive and expecting that to somehow support your opinion that tables are non-kludgy and intuitive. You're just making the same logical error again. Logical errors don't go away just because you keep restating them.

Once again your defense of CSS comes down to bashing tables.

You aren't reading what I am saying. I am saying that in terms of kludginess and intuitiveness, they are equal. Is that not clear when I say "I think that CSS is kludgey and unintuitive. But no more so than table layouts."?

Certainly tables are not used for what they were intended, but I don't see anything wrong with grid layouts

Who said there was anything wrong with grid layouts?

CSS is certainly no better at doing layout than tables; in fact, it's worse. I've had another CSS defender in this very thread indicating that you have to *program* the CSS layout in JavaScript in some cases!

Hey, I bet I can find a five year-old kid that will tell you that tables for layout is impossible. Guess what? Not all opinions are equal. So what if somebody can't find a way of laying something out with CSS without resorting to Javascript? You are assuming that they are so experienced that if they can't do it, nobody can. I read the same comment. I assumed it was somebody relatively new to web development because it's not good practice to rely on Javascript for layout. In that context, why does their opinion that you need Javascript matter?

And why would I "cut my nose off to spite my face" if not for stupidity or lack of discipline?

I don't know; plenty of smart and disciplined people do it though. It's not up to me to explain human behaviour.

Please explain to me why your argument is not an ad hominem, because, right now, it just looks like another "You're a dumbass because you don't use CSS in the proper way" argument.

Except I've said nothing of the sort. Not even remotely. I refer you to my previous comment:

If you don't accept CSS, that's fair enough, but to not accept it because people you don't like use it, then that's bad.

It's quite clear I'm not referring to your non-acceptance of CSS, but your inclusion of your opinion of a few CSS users as a factor in that decision. How you can read "If you don't accept CSS, that's fair enough", and translate it into "You're a dumbass because you don't use CSS in the proper way" is beyond me.

You have 1) gone back to bashing tables

We are comparing CSS and tables for layout. Pointing out that tables aren't as good as you claim is quite reasonable.

2) bashed me

Daring to point out that one of your reasons for not accepting CSS layouts is unreasonable constitutes "bashing" you in your opinion?

3) characterized my complaints as irrelevant.

Exactly which complaints, and exactly where did I characterise them as irrelevant?

Again, I repeat: I use CSS and think it's great, but it's not the cure-all that we want it to be.

I didn't say that it was. I said CSS was kludg

Write plain HTML, then just add divs

[oddityfds]

Just write a plain HTML page, something that would look ok and be readable without CSS. Then add div:s and CSS.

The result is a page that separates content from layout and works well both with and without CSS. It will also be easy to replace the CSS when you need to. This is also useful when you have different style sheets for different media. Have a "print" style sheet that excludes the sidebar and uses different colours.

bungie.net

[triceam]

I don't know if any has posted this yet, but http://www.bungie.net/ usese some really impressive CSS. The page overlay is something that simply cannot be done with traditional table-based layout.

HTML tables are usually hacks

[WebCowboy]

It's still easier to do certain things with table-based layouts than it is with CSS alone.

Tables are "easier" because you are used to them. Their use as a layout tool came about because HTML was never intended for layout and was invented before graphical browsing existed. Unfortunately standards committees never move as fast enough to address a need so such hacks were allowed to catch on before the W3C got its act together.

Control of vertical positioning/height being the obvious one. That and fluid layouts.

I gree with you that tables are an important part of (X)HTML. Sometimes you MUST use tables--like, say....when you are presenting TABLULAR information. Are you showing a little calendar on you page? Perhaps a table depicting a summary of product reviews? Snapshot of a spreadsheet? Yes, PLEASE use a table. "Vertical positioning" and "fluid layouts" are NOT reasons to use tables. The latter reason you mention in particular is baffling to me because in my experience tables REDUCE the fluidity of a page--I mean, I've NEVER seen a browser break up a row if it is too wide for a window, whereas CSS objects will wrap around. I'm curious to know when tables are more "fluid" because it seems by definition they are meant to CONSTRAIN layout. As for vertical alignment with CSS I've not had too much difficulty yet, although it isn't completely elegant.

I know it's probably heresy to say this, but IMO tables work in an intuitive way that you can easily visualize whereas a mass of floated DIVs often do not!

I'd have to disagree with you there. If you are looking at your own work that maight be true, but I find that when I look at the source of someone else's work and it is all TR TD TD TR...I get lost more easily. Add in COLSPANs and ROWSPANs and it becomes an absolute nightmare to manage layout changes without messing up the table. To keep it all straight you'd have to add comments or id or class attributes to the td tags--and if you're gonna do that you might as well use CSS and span and div tags.

As for being easy to visualise--if you are a bad coder it is difficult regardless of the techniques you use. However, I find borderless tables quite difficult to visualise (I cringe when I see "JPEG Jigsaws" especially--large images broken up into pieces and reassenbled using tables. C'mon what is this, 1996? How is TABLE-TR-TD.... showing up as a single, solid image intuitive?). OTOH, div id="SideMenu" or span class="MenuItem" makes much more sense to outside observers: You look at the page and see a menu on the side--then you view source and see id="SideMenu". Gee, maybe it's a bit of a stretch but I'm willing to hazard a guess that that div's contents represent the uhhhh menu at the side of the screen?

The other advantage of CSS is that it removes layout from content--and HTML was invented to handle CONTENT and has always stunk at layout. You can create a "printer friendly" CSS for the exact same file and bam--there's a printer friendly document--no alternative HTML file or "printer friendly" link needed. Also, the layout doesn't dictate the order in which the content must appear in the HTML. That is extremely useful for doing layouts to suit portable devices or printed format (hiding sidelinks etc). Also, it is the easiest way to make accessible documents--you can put the menu at the end of your HTML and display it at the top of the screen and aural browser users don't have to bother with skipping over the links to hear the content.

I think that people who find CSS "too hard" probably haven't spent enough time with it. I use it all the time and much prever it over using tables for layout. Not to say that I don't still use tables in HTML--they are vital in some applications--when you need TABULAR REPRESENTATION. Even then, I use CSS to apply borders, alignment, font and colouring.

In any case, I suggest giving CSS a chance. It might take you a fair bit longer to to your first properly constructed page, but after that you'll be much more productive and maintaining those pages will be far easier.

Web developers have 29" screens?

[Anonymous Coward]

I just visited the Web developer handbook. Is it good design to use an unbelievably small font size? Are they designing this to be viewed at 2048x1536? Im running a 19 inch TFT at 1280x1024 and can barely make out the letters...

Id rather turn elsewhere for advice as they seem to be lacking common sense!

REDUNDANT?

[milktoastman]

REDUNDANT?...Is the second squirt of milk redundant for my starving mode springs? NO!

um...

[Run4yourlives]

#footer {clear: both;}

Re:um...

[Matt Perry]

Which does nothing to change a background image.

Good grief

[Pope]

Man, that site demonstrates some of the crap that made me anti-CSS for the longest time! Hover over a link (dotted, not solid underline, naturally) and the damn thing animates! Who the hell thinks that this is a good thing? It's bad enough when I see sites whose links are not underlined (therefore going against years of web tradition) or whose links do retarded shit link over and underline, or change to bold and italic (thereby actually moving text around in their paragraphs), etc.

Gah, it's bad enough when people don't use a different colour for VLINKS, one of my main pet peeves. Gosh, I might want to know where I've already been on your site? Imagine!

Re:Good grief

[Bogtha]

it's bad enough when people don't use a different colour for VLINKS, one of my main pet peeves.

You can override this with a user stylesheet. :visited { text-decoration: line-through !important } should do the trick. Oh, but you are anti-CSS aren't you, so you probably won't want to use this :).

You know, just because some people do stupid things with a tool, it doesn't make the tool all bad. Using CSS doesn't turn you into an idiot that wants to animate everything.

Re:Good grief

[Pope]

No, you mis-read me: I said I was anti-CSS for the longest time because of the stupid shit people did with it, in my professional life I can't live without it.

I know I can override anything with a user stylesheet, but why can't the people making things in the first place have some sense of usibility?

Eh, it's a moo point. :)

um

[Run4yourlives]

using tables for page layout is one big cheat, in case you've yet to notice.

Re:um

[smagruder]

But this kind of cheating is standard practice, and follows an old presentation idiom that continues to makes sense to many. So what if W3C doesn't like it? Perhaps they should just change their minds on tables... and say they're for layout too... decriminalize the crimes, so to speak. :) After all, it's easy to make tables "semantic" anyway (by using CSS classes and structuring the tables semantically).

Well-done!

[Loundry]

Sorry I couldn't flame you more but I felt it was more important to point out the positive side of CSS than tell you how ignorant you may or may not be on the subject.

Oh please don't apologize! I thought your post was rather positive and informative. In fact, I agree with your principal argument: CSS *is* the future of the web.

My gripe lies elsewhere. The CSS that we have today is NOT the future, nor it is even usable in some instances. The gyrations that a programmer has to go through in order to change an Evil table-based layout into a Holy CSS-based layout are sometimes downright masochistic, as some posts in this thread will reveal. All one has to do is find an experienced HTML coder to say, "Yeah well what about *this* example?" (shows off a particular table-based design) in order to reduce a CSS advocate to blubbering, "Well, I guess, it might be, easier to use, a, table, in that instance." Either that, or the CSS advocate ends up admitting that the CSS solution is just as big of a hack as using tables is.

And somehow the uglier, non-table-based hack is supposed to be better than the easier, table-based hack. Do we see what pointless, arrogant zealotry brings us? It certainly doesn't help me write a better web page.

All that said, what CSS *can* do is really nice, and I use it all the time! In time, it will get to the point where it will fix the horrible mess that "web development" has become. Either that, or Microsoft will continue to ignore standards and it will fix nothing.

Good post, though! We need more folks like you who can share facts rather than trying to snottily point out the ignorance of people they look down upon. If you can point me to a good primer on using XML + XSLT + CSS, then I'd love to see it. :)

Re:Well-done!

[foniksonik]

http://www.stylegala.com/store/0596003722/XSLT_Coo kbook.html

That's a link to a review of an O'Reilly book that will jump you in feet first.

Good response.. i agree, evangelism is one thing but zealotry has no place in solving problems. If it works it works but try to go standards anytime you can.

You gotta be kidding me!

[Loundry]

Which works until you need to background image to stop at your header or footer. Better to use javascript to find the tallest column and make the other column the same height.

As I was saying: CSS is, at times, arcane and unintuitive. Is using JavaScript to *program* the layout somehow supposed to be superior to a table-based layout? I mean, I had troubles with CSS layout before (after 30 minutes I resorted to using tables and said troubles vanished), but I am actually quite surprised by your solution. It sounds ridiculous!

Re:You gotta be kidding me!

[Matt Perry]

As I was saying: CSS is, at times, arcane and unintuitive. Is using JavaScript to *program* the layout somehow supposed to be superior to a table-based layout? I mean, I had troubles with CSS layout before (after 30 minutes I resorted to using tables and said troubles vanished), but I am actually quite surprised by your solution. It sounds ridiculous!

It is ridiculous. But it's a design decision. Tables might be the way to go to contain the major elements on your page. However, if you are serving content to users who might have small screens (cell phones, handheld units) then you might not want to use tables as it would force users with small screens to scroll right and left.

Personally I do as much with CSS as reasonably possible and then hammer something into a table if I have a major design hurdle that calls for it. I'm certainly not going to avoid tables just to say "look ma, no tables." That's for people without real work to get done.

Re:You gotta be kidding me!

[Loundry]

It is ridiculous. But it's a design decision. Tables might be the way to go to contain the major elements on your page. However, if you are serving content to users who might have small screens (cell phones, handheld units) then you might not want to use tables as it would force users with small screens to scroll right and left.

I can understand that, and I appreciate your admission that it is ridiculous rather than replying with, "Yeah, but tables are just as bad!" as others in this very thread have chosen to do.

In my situation, where I work, we are NOT designing anything for small screens. All of our designs are big and flashy and intended to be viewed at 800x600 at least. Hence, there is no benefit to using CSS in this regard in this circumstance. We *do* use CSS, but we also use tables. I.e., we have a hybrid approach, which seems to be the most popular approach to designing web pages these days.

This isn't good enough for some CSS zealots. They insist that I'm a retarded hick for using this heretical, backward approach. All I really want is for particular people to admit that CSS has failings and is not always the best approach because of those failings.

Personally I do as much with CSS as reasonably possible and then hammer something into a table if I have a major design hurdle that calls for it. I'm certainly not going to avoid tables just to say "look ma, no tables." That's for people without real work to get done.

You seem like a reasonable person. I think there are a lot of people who *do* code with the intent of showing how forward-thinking and cool they are by not using the Sinful Table approach to layout.

Re:You gotta be kidding me!

[smagruder]

I'm willing to bet the numbers of good designers using this hybrid approach *far* outnumber those doing pure CSS layout. You're both in good company.

Re:You gotta be kidding me!

[Loundry]

I would agree with you! In practice, the practical wins out over the pure. ;)

I vote Libertarian. Can we still be friends? :)

TopStyle CSS Editor

[PizzaFace]

The best tool for editing CSS (and the HTML/XHTML that goes with it) is TopStyle Pro, from Nick Bradbury, the original creator of the HomeSite editor. Unfortunately, TopStyle is for Windows only. (Nick codes in Delphi.)

tables

[falconwolf]

tables work in an intuitive way that you can easily visualize whereas a mass of floated DIVs often do not!

If you can visualize. The last I heard aural browsers for the visually impaired trip over tables, especially when someone uses one and access keys and so aren't included. Of course divs may present the same problems.

Falcon

rendering tables cross platform/browser

[falconwolf]

here's nothing "less" semantic about using tables instead, and there's some serious advantages - like the fact that all major and most minor browsers will render them identically

Last I saw this wasn't true cross platform, browsers for different OSes render tables differently. I've seen tables rendered ok on Windows that fall apart on *nices or Macs and visa versa.

Falcon

Where the savings come from

[SuperKendall]

You're still generating HTML - and that HTML still has to be laid out by some means. XSLT doesn't save you from that.

Actually it does, because it is generating HTML tailored to the exact content being displayed. CSS by it's very nature is designed to handle some abstract content, but a XSLT transformation can look at what is really going to be presented and take a lot of shortcuts in the final HTML generated. It doesn't matter so much if THAT output looks odd because no-one should ever need to edit it (though it should not be too odd because someone WILL be debugging it someday!).

It's the differnce in producing HTML that needs to be maintainable vs. readable.

Re:Where the savings come from

[Bogtha]

a XSLT transformation can look at what is really going to be presented and take a lot of shortcuts in the final HTML generated.

...and that final HTML generated will be laid out how exactly?

Like I said, XSLT isn't relevant when discussing CSS versus tables, because the argument will loop back around to CSS versus tables even if you are using XSLT to generate the HTML.

Firefox users; a handy extension to help learn CSS

[rjd97c]

This is a great extension which enables you to see and edit (in real time) CSS for sites, as well as overlay ID and class info on the actual page! BRILLIANT! (and a lot more stuff too) WEB DEVELOPER

Simplifies the argument

[SuperKendall]

and as *I* said, it makes the code that gets laid out much less important in the grand scheme of things - an ugly table structure is just as easy to generate than nice CSS, in fact probably eveen easier. And more likley to work on more browsers without testing.

If I am writing a page by hand I prefer to use CSS because it makes everything so much cleaner. If I am generating HTML the choice I make are different because the computer doesn't care how annoying it is to work with tables but I do care that I can just eliminate a lot of extra testing.

What about the CSS validator?

[Anonymous Coward]

I scanned the article quickly, and did not find a CSS validator on the list. This is a useful tool for CSS novices such as myself.

Separation of content and presentation

[Anonymous Coward]

Either that, or the CSS advocate ends up admitting that the CSS solution is just as big of a hack as using tables is.

It's not about how much of a hack it is to lay something out in tables vs. CSS. It's about separating content from presentation.

This has obvious advantages: you can present in a browser, on a PDA, to a screenreader or braille device, to a cell phone, etc. etc. without changing a line of markup.

For many of those devices, the holy grail is very real: often the device itself can provide its own stylesheet which will render semantic markup properly without any intervention by the site developer.

But, there are less obvious advantages also: a page marked up semantically can be parsed programmatically much more easily than a tag-soup page filled with nonsense presentation markup.

The uglier, non-table-based hack is better if it preserves this separation of content and presentation. CSS hacks that work around browser bugs, for instance, usually do not clutter the markup.

Early CSS techniques did sometimes hoop-jumping in the markup, but that's not really true anymore. Pages styled with CSS usually are on the whole much more semantically correct than their table-based counterparts. Modern XHTML pages with CSS are very simple. Modern CSS techniques are therefore superior, even if uglier, for this reason alone.

/. should go for xhtml

[kezze]

I'm just waiting for the day.

Difference in advocacy

[Loundry]

And this is different from any other development language how?

You could have written this, "How is this different from any other development language?" but you seem to be going for the "snide and snotty" approach.

Let's actually expand your statement to include not only development languages, but also operating systems, applications, and licencing schemes. That said, how is it different?

It's a difference in degree, not kind.

OpenBSD advocates are, by far, the worst. They are the most elitist, most rude, most abusive, most cruel, and most in-your-face about it. They deserve to be marginalized and ignored. Too bad OpenBSD can be replaced by many other operating systems.

I think the second worst would be LISP advocates. They think they are smart and everyone else is stupid and backward, and they feel like they have the need to educate everyone in the true, pure way. Too bad LISP can be replaced by many other programming languages.

I would have to label CSS advocates as "third worst". Too bad CSS has failings and the insisitence of its advocates mostly amount to, "If you don't accept our way, we'll just whine louder!"

Certainly there's room for disagreement about my rankings. They are, after all, my opinion, and I don't really have a "hard" way of ranking them objectively. I will, however, defend my rankings. I think you can agree with me that Delphi advocates are not as loud, ugly, or elitist as LISP advocates, particularly considering that Delphi users grossly outnumber the handful of people who actively code in LISP for a living.

In the grand scheme of things, none of it matters one iota. I think all technological advocacy, particularly the elitist sort, is an easily-ignored waste of energy.

true.

[Run4yourlives]

but it solves the problem once you give the cleared element it's own background.

What about visibone?

[DaFork]

I use the visibone style guides. All the CSS tags on one page including browser compatability notes, equivalent HTML tag attributes, and some examples.

Oh Shit!

[iBod]

What did I start here.

Sorry guy. Just give it a break huh?