Templates for Rapid Interactive Prototyping

January 27, 2009 8:49 PM

This used to be really hard with CSS. Fluid 960 Grid System: Up to 16-column grid design that is flexible and fluid. Created by Stephen Bau, based on the 960 Grid System by Nathan Smith. [previously]
posted by netbros (56 comments total)

For those of us somewhat less informed about web design and CSS, please explain why this is so cool.
posted by leotrotsky at 9:14 PM on January 27

@leotrotsky, significantly more pictures of Scarlett Johansson/Jessica Alba can be added to any given website this way.
posted by Burton at 9:24 PM on January 27 [3 favorites has favorites]

For those of us somewhat less informed about web design and CSS, please explain why this is so cool.

Well, making multiple columns of content (of the same height, no less) is one of those ongoing dilemmas a beginner-to-intermediate designer tooling around with pure-CSS layouts has to battle with.

I've only recently discovered the 960 grid system, preferring instead to just code sites from scratch as the needs change. But, of all the CSS frameworks (of which there are many - even ones from Yahoo and Google), I've found 960gs to be the simplest.

As the site explains..

60 is divisible by 2, 3, 4, 5, 6, 8, 10, 12, 15, 16, 20, 24, 30, 32, 40, 48, 60, 64, 80, 96, 120, 160, 192, 240, 320 and 480. This makes it a highly flexible base number to work with.

Why that's significant (and why I've recently begun using it in some projects) is that I can make a 2, 3, 4 (even 16!) column website with minimal trouble. In fact, all I really need to do is add a class which matches how many columns a given item should take up (div class = "grid_4" for instance, will take up 4 grid points) and I can move on to making a site's overall layout and graphics, without having to spend hours wondering "so.... which CSS hack should I use here to make this sucker take up X amount of screen real estate?"

Taken a bit further, this FPP points out a further advancement that allows one to use 0 to 16 grids, but ALSO have them automatically resize proportionally to fit the browser window's width. Months ago, there was also an elastic version of the layout, but I don't think I've seen a fluid version of 960gs yet.

To some degree, it's a bit of a "holy grail" of plug-and-play CSS layouts. And, yes, it's significant to most CSS-based designers -- though, not exactly "news" (since this has always been possible, and definitely so with other CSS frameworks), it is worth mentioning.

Now, as for "why 960gs and not (fill in other CSS framework here)?" -- that answer is entirely in the hands of the designer. For me, I like that 960gs is slim (in filesize) and leaves all the design details up to me. The CSS reset doesn't attempt to force anything on me, and there's no default colors or lines or borders --- the whole system is setup to just give me a grid and get all the weird browser quirks out of my way. YMMV, of course, and this comment isn't meant to evangelize, only to answer your question and give some perspective.
posted by revmitcz at 9:40 PM on January 27 [17 favorites has favorites]

Ron Richardson: Yeah? Are you gonna make it all 220?

Jack Butler: Yeah. 220, 221, whatever it takes.
posted by turgid dahlia at 9:42 PM on January 27 [1 favorite has favorites]

d'oh. That one line was supposed to read "960 is divisible by.....". I guess I need to be more careful in my copy-pasta.
posted by revmitcz at 9:43 PM on January 27

leotrotsky - A few years ago Jason Santa Maria wrote an article about his 'grey box methodology' which basically was a tool for working on structure and spacing issues before working on other design problems in web design. This adds to that by giving you the structure necessary to quickly build out content within a structure without worrying too much about the presentation. That way, when the client is like 'why don't we move this paragraph over there' it doesn't ruin your day. And building fluid layouts with css usually does take longer (more math, plus it's just hard), so this seems like it would take some of the pain out of it. And it's GPL'd which I think everyone can appreciate.
posted by mike_bling at 9:47 PM on January 27

leo, as Nathan Smith said on his site, "Like it or not, web pages essentially revolve around boxy shapes. Inevitably, these rectangles have to come together in some way or another to form a design... Basically, 1024×768 is the new 800×600, and 960 makes for a good magic number to utilize the wider canvas."

A decade ago, that boxiness was handled with tables. Eventually, designers learned to create the grid-like layouts with CSS, but it was always somewhat kludgy, and difficult to support cross-browser. It also tended to be in a fixed format. Where Bau has gone a step further is to make the CSS fluid, stretchy. It will fit on any screen that is greater that 960 pixels.

And on preview, what revmitcz said.
posted by netbros at 9:48 PM on January 27

Here's a thought. If designers are such control freaks, why don't they stop wasting such a staggering amount of time and energy trying to bend a simple text markup language to their will, and just create a new format that does exactly what they want?
posted by phooky at 9:55 PM on January 27 [4 favorites has favorites]

While we're all geeking out on CSS here, I do have some MAJOR gripes with CSS. Don't get me wrong - I've been doing pure-CSS layouts (using semantic HTML, keeping my XHTML valid) for years now and it's felt much more flexible and elegant than slicing up tables and images.

But, why god (err.. W3C) why... WHY did no one think to give CSS some actual layout methods? Yeah, yeah, there's "float: left" and "float: right", but where the hell is "float : center". And what the hell is a "float" anyway? If you came to me 10 years ago and said "hey MItcz, how should we make the layout engine of the future? where should we start?", I'd have said "well, the first thing to do is give me a way to put something on the left, in the center, and on the right ON THE SAME LINE!".

Somehow, in the 13+ years I've been designing, and the ~11 years we've had CSS, NO ONE has bothered to sit down and say "ya know.... we still don't have a way to properly left-align, center-align, and right-align things"? That's just ri-goddamn-diculous.

W3C is trying to draft CSS 3 and they're finally talking about proper layouts, so I guess there's hope.

Anyone else know why that's never been at the top of the importance heap?
posted by revmitcz at 10:06 PM on January 27 [9 favorites has favorites]

Here's a thought. If designers are such control freaks, why don't they stop wasting such a staggering amount of time and energy trying to bend a simple text markup language to their will, and just create a new format that does exactly what they want?

Because it's more useful this way. The ones who care more about control than usability put everything in Flash or PDF.
posted by grouse at 10:10 PM on January 27 [3 favorites has favorites]

phooky: Because the likelihood of any new format being readily adopted by the masses any time soon is approximately the same as that of monkeys flying out of my butt.

The majority of web designers and devlopers are still having to write code to support a version of a browser that was first released in 2001.

It's taken us this long to get to this point with CSS, a standard which has been around for OVER TWELVE YEARS.
posted by cheaily at 10:14 PM on January 27 [2 favorites has favorites]

But, why god (err.. W3C) why... WHY did no one think to give CSS some actual layout methods? Yeah, yeah, there's "float: left" and "float: right", but where the hell is "float : center". And what the hell is a "float" anyway? If you came to me 10 years ago and said "hey MItcz, how should we make the layout engine of the future? where should we start?", I'd have said "well, the first thing to do is give me a way to put something on the left, in the center, and on the right ON THE SAME LINE!".

Yeah, or maybe even put a LOT of things on one line. They could call it a "table." Fetishization of "pure CSS" and Zen gardens aside, up until now CSS just hasn't worked very well for making a cross-browser, pixel-prefect, dynamic-content-holding website.

I hope this framework changes that. And I hope someone tested on IE6.
posted by drjimmy11 at 10:18 PM on January 27 [3 favorites has favorites]

Here's a thought. If designers are such control freaks, why don't they stop wasting such a staggering amount of time and energy trying to bend a simple text markup language to their will, and just create a new format that does exactly what they want?

1. They kinda have. See here and here.

2. Coming up with a new markup language is only a small part of the battle. Then you have to write all the documentation on how to implement it. THEN you have to convince browser-makers to implement all that fancy new markup.

3. Even with the best of intentions, there's still 3-4 major browsers, about 10 different browser versions, and god-knows-how-many variants of those browsers for various devices. If you came up with the "perfect" markup language tomorrow, it would be 10-15 years before anyone could actually use it, since the average person doesn't even know what a browser IS ("I just double-click 'The Internet' to get internetz goin' on mah system"), much less how to upgrade it. They use what comes with the OS, and if you can guess how often people and especially companies upgrade their OS......
posted by revmitcz at 10:18 PM on January 27

Also, I've been coding in Flex for the last ~2 years. It has its bugs, but it's completely object oriented and it looks the same in every browser as long as they have the Flash plugin. it's not perfect, but it or something like it is the future.
posted by drjimmy11 at 10:20 PM on January 27

I hope this framework changes that. And I hope someone tested on IE6.

Yup. From the docs :

IE6 has a wicked bug which doubles the margin on any floated elements. This could be a huge problem, but is easily fixed by adding display: inline to that which is floated. This causes no side-effects in any other browsers, so it simply lives in the main 960.css file.

And to address :
Also, I've been coding in Flex for the last ~2 years. It has its bugs, but it's completely object oriented and it looks the same in every browser as long as they have the Flash plugin. it's not perfect, but it or something like it is the future.

I think Flash has found its niche : rich-media. For too many years, webmasters have had to struggle with "which codec should we use? how many people have X plugin? what's the filesize-to-quality ratio?" and now, I feel, we're getting close to a definitive solution. You can provide most of your browsing audience with video targeted for Flash 8, and the uber-geeks with version Flash 9-10 video (using, if you'd like, h.264).

Beyond that, I don't really care for all-flash websites. I think AJAX solutions have rendered much of Flash's initial functionality useless -- the "all on one page" and "ooh.. look, animations!" functionality can be matched pretty easily with jQuery, for free -- but it's hard to beat Flash for ubiquity when it comes to audio and video presentation.

When I can middle-click inside of a Flash movie and open a link in a new tab, maybe I'll feel differently about using it as a consumer.

As a designer, however, who often has to hand off pieces of a site to other people, I simply can't do it all in Flash. Right now, I can match Flash/Flex functionality almost identically with XHTML/CSS/JS/PHP and hand it off to any web developer or designer and I KNOW they have the tools necessary (ya know... like, a text editor) to open any of the pieces and work on them without trouble. I have no such guarantee if I were to develop using Flash/Flex technology. And, in fact, that exact issue came up recently when I tried to convince a team I was working with to use a Flash-based multiple file uploader I built in their CMS system. They said "well, it's great, but none of us can open your FLA file without buying Flash 9 pro", so we're using an AJAX-based solution instead.

So, yeah, Flash is the future of rich media delivery. And I'm glad it's found its niche. I welcome it in that arena with open arms. But, as an engine to power web apps? Ew. No thanks.
posted by revmitcz at 10:36 PM on January 27 [1 favorite has favorites]

I hadn't seen this yet. Very nice. I'll be fiddling with it next time I build a site, I reckon. Thanks.
posted by stavrosthewonderchicken at 10:39 PM on January 27

I saw this today, and I kept wondering what was so new about it. Khoi Vinh has been talking about the grids he used on the NYT site since early 2007. Eric Meyer was showing some of this stuff off as well at the 2006 Event Apart seminars. Maybe this is the first time someone finally fully demonstrated a working model for a fluid version of a 960 grid, but I know I've seen this out there over the last two years as well. I guess this is just the first time some did it in a grokable form, because honestly, you have to do a lot of math with grids, and it's very easy to get lost in a hurry.
posted by dw at 11:08 PM on January 27

Flash is a wonderfully interesting technology. Pity they can't do text acceptably.

There's something achingly tragic about the company behind Postscript being unable to figure out text.
posted by effugas at 11:27 PM on January 27 [2 favorites has favorites]

That being said, HaXe has done more to make Flash interesting to me than anything else. But then I suppose my interests deviate from most :)
posted by effugas at 11:28 PM on January 27

My current site is a simple, one-column affair. It's valid XHTML and valid CSS and all that, but not much work put into it. I had a period where I was obsessive with CSS and layouts and 8-bit, web-friendly colors and all that. Then it stopped being fun and just felt like work. This is a cool post, though!
posted by wastelands at 11:34 PM on January 27

Grid systems are the enemy of semantic markup.
posted by Jairus at 11:39 PM on January 27 [1 favorite has favorites]

Yeah, or maybe even put a LOT of things on one line. They could call it a "table." Fetishization of "pure CSS" and Zen gardens aside, up until now CSS just hasn't worked very well for making a cross-browser, pixel-prefect, dynamic-content-holding website.

Can we not do this? Honestly? Because there are a lot of pure CSS site layouts in public use by major and minor companies, and it's been that way for five years now. At this point, we're dealing with the consequences of XHTML and CSS and trying to solve them, albeit too slowly.

Using tables for layout is like hammering a nail with your shoe. It will work, but it's still the wrong tool for the job, and it makes you look like an amateur if you try framing a house wielding a shoe.
posted by dw at 11:50 PM on January 27 [2 favorites has favorites]

Vertically aligning stuff without tables is still a shit though, and will ocntinue to be until display:table-cell is sufficiently adopted, and the fucking thing tells your DIVS to pretend to be table cells anyway.

But, why god (err.. W3C) why... WHY did no one think to give CSS some actual layout methods?

Because they hate you.
posted by Artw at 12:54 AM on January 28

Grid systems are the enemy of semantic markup.

Failtastic support for many common and obvious design requirements in CSS Is the enemy of semantic mark up.
posted by Artw at 12:56 AM on January 28

W3C is trying to draft CSS 3 and they're finally talking about proper layouts, so I guess there's hope.

The year 2020 is going to be awesome!
posted by Artw at 12:58 AM on January 28 [1 favorite has favorites]

Using tables for layout is like hammering a nail with your shoe hammer. It will work, it's easier than using a shoe, but at a meaningless high-level conceptual level it's somehow the wrong tool for the job, and it makes you look like an amateur if you try framing a house wielding a shoe hammer because everyone has taken to using shoes.
posted by alasdair at 1:26 AM on January 28 [5 favorites has favorites]

CSS "frameworks" are a hopeless crock. They are Tables 2.0. This is not progress.

Look at the markup of that page, endless lines of:

<div class="grid_1"><div class="box"><p>01</p></div></div>

Sorry, but this is better than <table> how, exactly?

The idea of CSS was to abstract out the presentation into a .css file separate from the markup. Now whilst you can certainly argue that CSS doesn't provide quite enough tools to completely separate out the layout stuff*, this is total capitulation. All the layout is firmly kicked back into the markup; you want to change a single aspect of the layout, say move your corner logo left a bit, you have to edit every pageful of markup you've got.

<div class="grid_1"> is in no way semantic; it's no better than <td width="10%">. If you're too scared of CSS to write your own layout rules (and most framework layout stuff really is little more than a few floats when it comes down to it), then do us all a favour and just use tables. At least then we don't have the extra burden of a long stylesheet that brings no benefit.

* - and yes, it is a great shame the browser vendors who gave us CSS 2.0 came up with the 'position:' scheme they did. 'float:' is understandable as it had to be like that for compatibility with old-school '<img float="left">', but for positioning, a system based on a flexible grid, where each block could be positioned independently of its order in the markup, would have been a lot better. The multicolumn specification, unfortunately, does not give us this, instead concentrating on replicating one specific case copied from newspaper layouts, which by its very nature is unsuitable for the web. We continue to lose.
posted by BobInce at 2:30 AM on January 28 [11 favorites has favorites]

Look at the markup of that page, endless lines of <DIV>

It's called divitis. Also known as spanitis in more inline parts of the world.
posted by Civil_Disobedient at 3:53 AM on January 28 [3 favorites has favorites]

But, why god (err.. W3C) why... WHY did no one think to give CSS some actual layout methods?

The W3C did put in proper layout methods, it's just that browser developers didn't implement them. CSS2, from 1998, includes the ridiculously simple "display: table" - the problem is even today IE7 doesn't support it. Floats are a dirty hack that is used because it works, not because the W3C wanted you to use it.

CSS for layout is pretty badly designed in general though. The box model is unintuitive (i.e. it's basically backwards), and it's pretty ugly and confusing in places. It's a shame because CSS for styling - especially in terms of the cascade and inheritance - and HTML are both pretty well-designed otherwise.

It's worth adding CSS is misunderstood by far too many people, especially those who haven't read the spec. CSS is not about "separation of presentation from content" and the CSS spec doesn't say that. The idea of using CSS for layout is separation of /design/ from /structured content/ - a subtle but important distinction. This has the huge advantage of accessibility, but also explains many of the perceived problems with CSS in that it doesn't provide tools that are easily misused such as allowing arbitrary rearrangement of pages.

I also don't really see nested DIVs as a big problem either, nor see semantic issues as being an issue nor particularly CSS's job...
posted by HaloMan at 4:58 AM on January 28

*Opens Indesign, does a layout without having to code it by hand, prints it out, smiles smugly*

Yeah, yeah print has issues, but I've always been surprised how the tools of web design seemed to thumb their nose at the centuries of tools and workflows that print developed. I mean, really, no formal way of making rounded corners yet? Really? Columns are coming?

Or maybe it's just that Microsoft never got its paws on print design (THANK YOU GOD).
posted by Brandon Blatcher at 5:32 AM on January 28

The problem is that the web is much harder than print, and print is a difficult problem in itself.

With print, you only care about what people can see on the page. If someone is blind, you decide it isn't your problem. You don't have to deal with interactivity. You don't have to deal with different resolutions, different measurement units, different browsers on different OSes or different languages on the same page with different text directions. You don't have to deal with the idea that someone may scan your page in and it needs to be machine readable. And even then there's problems with paper - the same tool that does layout is poor at mathematical equations and needs something different, and the difference between colour on the screen and colour when printed.

CSS for layout has its problems, but it's a /very/ difficult problem and web design has been quite remarkably resilient even when working within the boundaries of poorly-designed standards.
posted by HaloMan at 5:56 AM on January 28

I too like the basic concept behind CSS, and it's perfect for styling, but as pointed out, the layout stuff is ... a kludge, and harder than it needs to be. And I agree that one of the biggest reasons for this is the stupid browsers, not least the ones from Redmond WA. Hard to move forward with standards when the biggest player chooses to mess with them.


Using tables for layout is like hammering a nail with your shoe hammer. It will work, it's easier than using a shoe, but at a meaningless high-level conceptual level it's somehow the wrong tool for the job, and it makes you look like an amateur if you try framing a house wielding a shoe hammer because everyone has taken to using shoes.

Exactly right. For layout, the table metaphor is easy to comprehend and manipulate, and works right just about everywhere. To the purists, a well-executed table layout only 'sucks' when they view source. (Accessibility issues notwithstanding).

The web battle of design vs markup/accessibility/semantic goodness has almost been won by design, but it's not over yet. Both sides could be reconciled (hopefully in CSS3...?) if the browser makers would cooperate.
posted by Artful Codger at 6:13 AM on January 28

Flash is a wonderfully interesting technology. Pity they can't do text acceptably.

There's something achingly tragic about the company behind Postscript being unable to figure out text.

The company behind Postcript had nothing to do with Flash text. Flash was developed at Macromedia and was only recently acquired by Adobe. And one of the first things Adobe has done is improve its text capabilities. Flash Player 10 includes a new text engine.
posted by grumblebee at 6:24 AM on January 28

The problem is that the web is much harder than print

Oh, no argument and to be fair it took print design quite a while to hammer out printing issues. Artw may have been joking about 2020 being a great year for webdesign, but the general point is a good one: the journey to reach standards is long and the process of doing so is a bumpy ride.
posted by Brandon Blatcher at 6:38 AM on January 28

Flash Player 10 includes a new text engine.

*designgasm*
posted by Brandon Blatcher at 6:44 AM on January 28

Does Flash Player 10 include a "stop hijacking my browser's normal functions and/or crashing my aging and underpowered system" feature? If so, I might consider unblocking it.
posted by Dr.Enormous at 6:46 AM on January 28 [3 favorites has favorites]

I understand that "" is the MORTAL SIN of a semantic society, but what's wrong with ""

Or are we not allowed to compromise? Let's be honest- 99.99999999% of your hits, especially if it's e-commerce/corporate, are coming from folks who have no idea what "View Source" is and will call their children into the room to fix the computer if they select it.

I understand the importance of semantic markup, but I'm not going to allow it to impinge on design. I learned CSS/HTML/JS in an era where "semantics" was still a branch of literary theory and had nothing at all to do with code. Good, driven people will make heads or tails of whether or not you make it easy.
posted by GilloD at 7:30 AM on January 28

CSS "frameworks" are a hopeless crock. They are Tables 2.0. This is not progress.
Sorry, but this is better than how, exactly?


I kinda agree with you, but the problem is more in browser behavior than markup. If floats behaved correctly in every browser, a lot of this wouldn't be necessary. Designers still yearn for pixel-perfect control, and until browsers are standards-compliant ( I'm looking at you, Microsoft ) this kludginess will continue.

Grid 960 is sort of the grandfather of this kind of technique, but I like Typogridphy better. It complies with accessibility standards better in my experience.

Personally, I can deal with this OK because I've gotten used to the workarounds. I can't wait for proper support for the @font-face rules in CSS3, though.
posted by Benny Andajetz at 7:30 AM on January 28 [1 favorite has favorites]

It ate my code because I am a total goof: It said "
I understand that "div class=grid_1" is the MORTAL SIN of a semantic society, but what's wrong with "div class=grid_1 topmenu""?
posted by GilloD at 7:35 AM on January 28

Can someone explain to me the value of semantic markup?

No, seriously. I've been hearing about it for years and I have no fucking clue who would benefit from it.

Separation of presentation from content, I totally get. And I do that in my CMS, not my CSS. If I need to change the layout throughout my side, I do that by editing the templates that all my content gets churned through. The templates are a mixture of css and html and javascript and yes the occasional table. But that's fine because if I need to I can throw it all out and start over; my content is still sitting in the pristine (and yes, semantic) XML or SQL representation I designed for it originally.

I look at the HTML5 spec, with its "semantic" <article> and <sidebar> nodes, and my reaction is one of total disinterest. Fine if you assume that every site on the web is going to be a blog or newspaper, I guess. But how is that an improvement over <div class="article">? If those new nodes are going to be such an improvement over what we have now, why isn't there already widespread use of divs with those classes, whcih would be functionally identical and without having to wait fifteen years for the spec to be complete?

Compact code would be a virtue. Semantic markup doesn't necessarily give you that. Clean code would be a virtue, but semantic markup isn't necessarily going to be any cleaner than divs. It doesn't make layout easier, it makes it harder (because you arbitrarily abandon layout techniques that already work.) I see a lot of handwaving about accessibility, but that's mostly about code order, not about the markup. It doesn't even give you semantics, it just moves that from where it already is (the server) to the clientside.

So what's the point? To make life easier for webscrapers? Is there any more to it than that?


Oh, by the way, this is a nice grid system. I'll probably use it someday.
posted by ook at 8:22 AM on January 28

Can someone explain to me the value of semantic markup?

The reasons for semantic markup are basically two:

1. Accessibilty for everyone. Blind, deaf, doesn't matter.

2. Much improved "webscraping", as you call it. XML parsers can make much better decisions when classifying what information is on what web site. That may not sound like much, but everyone would benefit by being able to do highly targeted searches with returns that have a high degree of relevance.

Compact code would be a virtue. Semantic markup doesn't necessarily give you that. Clean code would be a virtue, but semantic markup isn't necessarily going to be any cleaner than divs.

Done correctly, practically the only markup on a page would be DIVs. All other styling and scripts would be elsewhere. Theoretically at least, that should make pages that load faster and are easier to maintain.
posted by Benny Andajetz at 8:47 AM on January 28 [1 favorite has favorites]

Here's a counterproposal for HTML 5 - we simplify things to only one tag, DIV, and it does EVERYTHING.
posted by Artw at 8:49 AM on January 28

Tables for layout? A fucking crime. So the only way to view your brilliant tabled layout on my mobile device is YOUR WAY OR NO WAY? The presentation is more important than the content?

Nice. Or not so much, actually.
posted by grubi at 8:52 AM on January 28 [2 favorites has favorites]

Heh. I think the public has collectively said "fuck you" to mobile layouts and decided on tiny versions of the real thing as the ideal way of surfing from a phone.
posted by Artw at 9:14 AM on January 28 [1 favorite has favorites]

1. Accessibilty for everyone. Blind, deaf, doesn't matter.

How does semantic markup help with this (beyond the basic header, paragraph, etc that we already have?) I'm not being snarky, I honestly don't see it. It's already possible to put the important content first in the code, and the navigation etc last so JAWS can read things in the order a blind user would presumably want. Or to include hidden-for-sighted-people links to skip the navigation. I guess I can sort of see, if everyone implemented <article> as the "this is the important part of the page" so a screenreader could always read that node first -- but that only works if all sites have the same basic structure, which won't be the case.

2. Much improved "webscraping", as you call it.

I hear what you're saying here as an ideal, but I don't see how the semantic tags they're talking about for HTML5 achieves this in practice (nor can I imagine any other broadly useful set of semantic tags that would).

We already have plenty of mature XML schemas for specific types of content (RSS, Atom, QTI for example). Including content-specific tag types in the underlying HTML spec would just lead to every website including those same content-specific tag types, and you're back to square one. (How does the fact that "this site has a sidebar! And contains articles!" help target my searches?)

The problem with including semantics in the underlying code of the web is that for those semantics to be broadly useful and to avoid steering the web into an evolutionary cul-de-sac, the they have to be so generic as to be pretty much useless. As far as I can tell we're already using these semantic interchange formats when they're useful, and we don't have to reinvent the web to do that.

So the only way to view your brilliant tabled layout on my mobile device is YOUR WAY OR NO WAY?

This isn't an argument against tables, it's an argument against poorly-tested code. It's just as easy to fuck up a layout for mobile devices without using tables.

If the producers of a given website feel that mobile users are significant, they can churn their content through a separate set of templates to produce a mobile-specific website. Or they can wait a couple years for mobile handsets to mature enough that they're able to read the same web pages everyone else can.
posted by ook at 9:15 AM on January 28

The excessive markup bothers me alittle but mostly these CSS frameworks never seem to fit what any of the designers I work with, come up with. And they'll never be game for sticking to such a thing.

Might be a different story if I designed the sites I build. But then I'm a bit rubbish at designing things and they're not; I'd just do something that was simple and didn't annoy me to build. They're not bothered how annoying it is and I think at times take pleasure in coming up with awkward layouts.
posted by 13twelve at 9:20 AM on January 28

ook Screen readers can describe the type of content as well as what the content is to the user, for example: if you format you forms with ordered lists, it will tell the user that the list has 6 items and then run through those items. This way they know how many things they need to fill out. More appropriate tags will enable the screenreaders to better tell the user what they are dealing with.

And I guess you could argue that with ultra semantic HTML if you wanted to translate it into another XML format, such as DOCBOOK, the process would be much simpler. This will probably be more relevant to HTML5 though. Although if your pulling from a database, it probably doesn't matter.

The main problem with semantic code for rich HTML sites these days is the lack of appropriate tags, causing us to stick content in rel and other inappropriate places (because custom attributes won't validate).

Semantics do annoy me because its become like a gloating buzz word in the F/E community - as though its a difficult thing to do. Which it isn't.
posted by 13twelve at 9:31 AM on January 28

Weirdly cheesy SEO types seem to be having more success pushing semantics than any web designer or accessibility expert ever has. It's now at least seen as vaguely desibable, even if clients will demand that and the whole site done in flash at the same time.
posted by Artw at 9:36 AM on January 28

CSS as a way to seperate content from presentation has been flawed from the beginning. From the authoring side, the way to do that is with a CMS. On the public side, RSS is much more effective.

That said, CSS does make coding presentation much easier - so I'm all for it - but everyone should just admit that the (X)HTML is presentation too.
posted by dickasso at 9:49 AM on January 28

For those complaining that frameworks are a step backwards semantically, blueprint now comes with some slick ruby scripts that will let you define semantic classes. I can see how using a framework might prevent someone from having a deep understanding of what they're doing, but this stuff is about getting things done and up quickly so you can talk about the real issue - the content.
posted by mike_bling at 1:00 PM on January 28

Tables for layout? A fucking crime. So the only way to view your brilliant tabled layout on my mobile device is YOUR WAY OR NO WAY? The presentation is more important than the content?

Well... ;-)

Given that a website's target audience may have 1 mobile viewer for every 999 PCs/laptops, developers should spend twice as long to format something to work for you...why?

(FYI, I do server-side; I don't do web pages anymore, so you're safe from me)

Another poster's already supplied what I think is the best answer - content is in the CMS, presentation is controlled by templates, with different templates used depending on the caller's client - web browser, talking browser, mobile, wifi pinky ring, whatever.
posted by Artful Codger at 1:16 PM on January 28

This is so cool - thank you! I spend a lot of my working days around web applications but only recently have I personally discovered the amazing possibilities of CSS. I'm cro-magnum in my web design skills -- I got off the bus around 1997 so I still think TD is a valid html command to do my formatting with. CSS started poking around and I was like "oh, cool, a way to specify a font..." and that was it.

Between this and what has probably been posted before, but what has blown my mind, the CSS Zen Garden, my mouth is left simply agape at the possibilities here.

Yeah, it would be great if I could take an InDesign or Illustrator file and just *poof* make happy web code out of it, but for all the reasons listed above the web really is its own medium when it comes to making all the different browsers happy. It'd be great if I could just post a PDF of what I want on a site -- the reality is we need it to render in IE7, FF3, and god damn it, IE6 I hate you I hate you so much IE6.

Thanks!

[dang! Left this browser open without clicking submit. And for the record, when I say "I still think TD is a valid html"... relax, I haven't been responsible for a (professional) website built by my code in, oh, 12 years. :)]
posted by cavalier at 2:06 PM on January 28

*Cough*
posted by joelf at 9:54 PM on January 28 [1 favorite has favorites]

Here's a counterproposal for HTML 5 - we simplify things to only one tag, DIV, and it does EVERYTHING.
posted by Artw at 10:49 AM on January 28 [+] [!]

So you know some of the programmers I work with!
posted by [insert clever name here] at 10:21 PM on January 28

Well, to be honest, after years of autodidactic messing about with CSS-based design, I'm still a bit fuzzy on when to use a span rather than a div. But then, I tend to hammer in nails with my forehead, so there you go.
posted by stavrosthewonderchicken at 12:04 AM on January 29

SPANs are for inline content. DIVs are for blocks.

Don't know if that helps or not.
posted by Civil_Disobedient at 2:18 AM on January 29