So, I’m going to give up and use tables. It’s going to take me all of 45 minutes to undo the last two weeks worth of CSS work. I’m going to launch my site. And then, I’m going to go and get a donut.
—
Tables vs CSS: CSS Trolls begone. We use tables for layout in select parts of our apps too. Design is a compromise of both ends and means. When it comes to tables vs. CSS positioning, my #1 criteria is this: Which technique will be easier to work with over time? Tables are different structures with different behavior, and sometimes they’re the simpler and more maintainable means to an end. I also like the “CSS Troll” monicker. It cuts a bit closer to the bone than that lofty alternative: “Purist.”
Tables vs CSS: CSS Trolls begone. We use tables for layout in select parts of our apps too. Design is a compromise of both ends and means. When it comes to tables vs. CSS positioning, my #1 criteria is this: Which technique will be easier to work with over time? Tables are different structures with different behavior, and sometimes they’re the simpler and more maintainable means to an end. I also like the “CSS Troll” monicker. It cuts a bit closer to the bone than that lofty alternative: “Purist.”
Martin Cron
on 02 Feb 09I went through my own HTML purist phase. Glad that’s behind me. It took me a while to come to terms with the fact that tables are perfectly appropriate for tabular data.
Weixi Yen
on 02 Feb 09This quote is talking about tables for layout…
For CSS purists, tables are for tabular data.
Good read for those who don’t want to use tables for vertical centering: http://www.jakpsatweb.cz/css/css-vertical-center-solution.html
Justin Reese
on 02 Feb 09@Martin: Even purists allow tables for tabular data. (In fact, that’s their “pure” use.)
@Ryan: I feel your pain, but you’re still a quitter. ;) Out of curiosity, what’s the layout you weren’t able to accomplish without tables?
Alfredo Mesen
on 02 Feb 09http://shouldiusetablesforlayout.com/
nuf said :P
(make sure to check out the source too _)
Peter
on 02 Feb 09Well, it’s hard to agree with your opinion on “purists/trolls” when Basecamp still* suffers from a buggy textarea script, which doesn’t take the resize property (CSS3) into account. So, do you really care about user experience, or is it just you being selective?
- Sent a bug report with possible solution months ago.All irony aside, I think that a good CSS developer is able to create bulletproof layout without resorting to tables. Can you give an example of some really erroneous layout?
I remember having troubles with form layouts, but you can create a small framework for these things and be done with this once and for all – just reuse the code in projects.
Michael Long
on 02 Feb 09Ditto. Maybe in a few years CSS (and the browser base) with catchup, but the blue-sky designers of CSS did practically everything in their power to make CSS layouts difficult (if not impossible) to use.
Everything from the infamous box model (padding the INSIDE of a box requires a change in it’s OUTSIDE dimensions?) to postioning nonsense (the height of an absolutely positioned object has no effect on its container) contribute greatly to the number of hacks and other measures needed to create even simple layouts.
Add cross-browser-specific nonsense and the whole thing simply boggs down.
Yes, separation of data and presentation is desirable. Yes, it’s POSSIBLE to do so. But all too often it takes round-after-round of testing and retesting, only to find that the Opera patch breaks IE (again).
Peter
on 03 Feb 09Michael:
There’a a CSS3 property that allows to change the box model.
And I don’t think you understand “document flow” if you’re not able to understand why absolutely positioned elements don’t interfere with other elements. BTW, you can use position: absolute for almost every CSS layout you can imagine. But IE6 taught us to belive you can’t specify both left/right & top/bottom properties… so we’re not using it. Time to revise our knowledge.
Using tables is just easier. Create prototypes with them, fine. But there’s a lot of CSS available for you in other serious cases.
Michael Long
on 03 Feb 09“I think that a good CSS developer is able to create bulletproof layout without resorting to tables.”
The issue boils down to just how much time do you want to waste in doing so?
Naveen Dittakavi
on 03 Feb 09I think the moral of the story above is to just focus on getting your project shipped.
Anonymous Coward
on 03 Feb 09Purist vs pragmatic. Get ready for a flame war.
Ryan, your intentions may be good and many people share your perspective (including me); however, this issue has already been beaten to death. Result: do what makes sense to you.
RS
on 03 Feb 09It’s not about what we’re able to accomplish. We can accomplish anything that we put our minds to. The question isn’t “can you do it with CSS?” You can do just about anything in CSS when your chops are advanced enough. The thing is: web development isn’t a chops competition. It’s a service to our customers and our users. And oftentimes the underlying technique just doesn’t make a difference.
Peter
on 03 Feb 09Michael Long: But do you have to write everything from scratch each and every time? There are sites and resources for CSS coders to do their job quickly and painlessly. Testing, experiments and debugging is done in comments under articles and blog posts… you don’t have to do this when you develop.
Jason Pontius
on 03 Feb 09I’m sure there are intricate, precise -based solutions for all these cases. But all this stuff is built into . And all browsers get it. Automatically.
Jason Pontius
on 03 Feb 09Oops— I guess I can’t write out HTML tags in these comments. First word is [table], last bold word is [table], all the other missing words are [div]. Sheesh.
Erik
on 03 Feb 09I think the “css troll” movement has at least quieted in the last few years. At its height, it felt like a giant battle to educate people that “there was a better way” too make websites. Since the browser support stunk, every bit of mind share was gold.
Now that the browsers have caught up with a 4-10 year old spec making CSS viable for general use, it’s pretty much accepted that gratuitous use of layout tables and inline styling are a problem. I’m happy if we can at least agree on that.
As someone who dove into web design just as the standards movement was picking up steam, I’m baffled when someone implies that tables are “the easy way” to do any particular layout. Every time I “give up” and use tables for a particular reason, I spend more time fighting their weird quirks then I would have spent implementing the layout in CSS.
Face it, in general we tend to like what we’re more comfortable with. Web designers spent years learning how to bend tables to their will, they shouldn’t expect to be able to duplicate their old techniques with CSS over night.
Dezmondfinney
on 03 Feb 09I know that it is very difficult to do layout (other than tabular data) in pure CSS. There are browser incompatibilities and CSS quirks and more. And that is if you know CSS very well.
I was a designer before a programmer and I had a hard time wrapping my head around MVC – before rails any way. It was even more difficult because I did not see a “need” for it. If my php got the job done and the site looked OK WTF was the point of strapping myself into MVC? I think that many people feel the same about “pure” CSS.
If you do care about easily maintainable code (and yes it helps to consider your CSS as code – as important as your controllers) use “pure” CSS. If you care about accessibility use “pure” CSS. If you want to be called a CSS Troll – oh, never-mind. LOL
The best thing that I can recommend to help anyone is to “reset” the styles for everything in the browser using a “reset template” at the beginning of your style sheet. This fixes all those crazy thing with padding, margins, and crazy browser differences. More info and a useful example that I simply copy can be found here: http://meyerweb.com/eric/tools/css/reset/
I figure that if I can be a Rails troll (that is what my PHP friends call me when I get on my high horse about the “purity” MVC or refactoring) I can be one about CSS too :))
In any case you can all ways do what fits you best… like my friends who still use Java.
Michael Long
on 03 Feb 09Peter, I know about the CSS3 property, and find it significant that it was proposed and considered at all.
As to document flow, put a table or image within the cell of a table and what happens? Table grows to accomodate. But put any positioned object of height H inside a DIV at Y and what happens? Does the DIV add Y+H and grow? Nope. So absolutely postioned layouts with floating footers aren’t possible.
There’s a difference between impacting the flow of other elements WITHIN a container, and impacting the size OF your container. If I wanted an object completely out of the flow, I could have used the Z-axis. But no, they did it for me, and allowed for no other implementation.
Like I said, if there was a totoally counter-intuitive way of implementing a given set of behaviors, it seems as if THAT’S the one they put into the spec.
Why? Mostly because the majority of CSS designers were “purists” in the sense that they didn’t believe in ANY layout. At all. Print column or fixed layout designs simply had no place in their brave new world…
Michael Long
on 03 Feb 09“You can do just about anything in CSS when your chops are advanced enough.”
Or if you have enough time. But in many projects one faces deadlines, time-to-market issues, and other constraints.
As such, it boils down to what’s “best” for your clients and for your users? Sometimes a quick and dirty solution “now” is better than a perfect one delivered a month later… if at all.
Peter
on 03 Feb 09I must agree, table behavior is quite useful sometimes. But can’t you use `display` property to do that? CSS table layout doesn’t require non-semantic (and sometimes superfluous) markup.
There’s more to websites and webapps than what we’re able to see. Source code is important too.
Glenn Batuyong
on 03 Feb 09Agreed. Tables in HTML were designed for tabular data. However, layout of page elements isn’t considered tabular anything. Visual elements should be controlled by CSS, otherwise you have a mess on your hands in the long run. My favorite quote: “Any website built without web standards in its DNA has a limited shelf life” You’ll find more and more agile developers in the future who will be mystified that table-based designs still exist and correcting layout will be much more cumbersome. Table-based design is inherently not scalable and will weigh down your pages as they become more complex. In addition, troubleshooting may be more difficult.
J Wynia
on 03 Feb 09What’s startling about much of the recent CSS trolling is how often the solutions to things like vertical centering involve CSS settings like “display: table-cell;”.
When tables started getting used for layout, it was subverting the original intent of the <td> tag, but when you directly steal the exact same styling FROM the td tag and just slap it on a div, you have pretty much done the exact same thing as was done in 1997: making the best of a system where achieving your design goals is not made easy.
korbinian polk
on 03 Feb 09using tables for layout is cheating. it gets the job done, but if you want to impress chicks, one has to go the hard way.
Jim Jeffers
on 03 Feb 09I’m not so sure about this train of thought. I think the trolls are the folks spewing out pure laziness. I have been building sites without tables to present the layout for over six years now without having to do this. People are still whining about this? Unless your presenting a table or building a layout for IE 5.5 there is no reason this should even cross your mind – means to an end or just a lack of knowledge?
ia
on 03 Feb 09Interestingly someone pointed me to this:
Why CSS should not be used for layout (blog post)
just a few minutes before I read this post.
I like the point with the trolls, but just because 75% of the Alexa top 20 is doing it doesn’t convince me I should do it too.
guns
on 03 Feb 09For me, there’s nothing remotely easy about using tables for layout. I inherit old sites from time to time that use tables and there is a large mental cost in sorting the whole mess out. Between all the colspans, rowspans, and blank gifs, I can’t imagine why people “give up” and use tables.
If positioning elements is your problem, then nobody taught you how to position with css properly. Read this:
http://www.brainjar.com/css/positioning/default.asp
Key quote:
“There are three positioning modes or schemes in CSS2: normal, float and absolute. Each has its own set of rules. Every box is positioned using one of these schemes but different boxes will use different schemes depending on their position and float style settings.”
Brilliant write-up. Use tables for displaying tables and css for layout.
Lindsey
on 03 Feb 09For me tables take me 2-3x the amount of time than doing a design in pure CSS – even counting troubleshooting.
Every person is different in what they are comfortable using to achieve their design goal. People who started out using tables are obviously more prone to falling back on that when they hit a CSS roadblock.
I believe when you become more comfortable using CSS as the complete backbone for achieving your design the troubleshooting and “breaking” should be so minimal it will kill all the urges one has to use tables.
But – to each his own. I choose to do it one way, the next person does it his way. I don’t believe there is firmly one set way you HAVE to do it to make it work.
rm
on 03 Feb 09The argument of “I’ve been doing CSS layouts for n years with no problem!” is repeated over and over. To those who use it, I say: So what?
Why should anyone care what you have done? Are you working on the same project, with the same time constraints for the same client? No? Then how is your experience relevant?
Every project and every client is unique, and everyone is entitled to an opinion. At the end of the day, the only one(s) who can determine if the solution chosen was right or wrong is the client. If you absolutely feel the need to control how people do layout, by all means hire someone to boss around.
aris
on 03 Feb 09If what you need to display is a tabulated information, use tables.
If your layout will take you a fraction of the time to do using tables compared to divs, use tables.
There are things tables can do that divs can’t and the other way around.
Luke Visinoni
on 03 Feb 09“It’s a service to our customers and our users. And oftentimes the underlying technique just doesn’t make a difference.”
You nailed it. I find that those folks who MUST NOT USE TABLES no matter the cost are rarely doing real work for real clients. I can do anything in CSS. That isn’t the question. The question is, how much time do I have to waste on something the client won’t notice.
I always opt for a pure CSS solution, but if I’m in a crunch, and a table works, then I use one. That’s the real world.
Donnie
on 03 Feb 09I wrote an article about this that was rejected by ALA. Forms ARE tabular data. TH the labels, and TD the form elements. We are used to seeing tabular data in a spreadsheet like format, but a form is simply a differently formatted spreadsheet (if done semantically).
Mat
on 03 Feb 09This post is the saddest thing I’ve read all week.
Michael Long
on 03 Feb 09“My favorite quote: “Any website built without web standards in its DNA has a limited shelf life””
Actually, most web sites have a limited life span. Period.
Another CSS-based design tenet is to use minimal markup. But sites done that way tend to have equally limited life spans-if not shorter-as there’s no room to grow.
Even the shining exemplar of CSS-based development, Zen Garden, double and triple-wraps DIVs, and adds extra DIVs and SPANs and markup.
Unless DESIGNED for extensibility, CSS-based layouts are no guarantee against obsolescence.
David Andersen
on 03 Feb 09Most chicks prefer the house get built and aren’t impressed that you’ve spent 3 extra months making sure every intersection is perfectly level, square, and plumb.
Eric Eggert
on 03 Feb 09As most of 37signals HTML makes no semantic sense at all, e.g. not using lists for lists and leaving out alternative texts for images and just not caring about the quality of the code, that statement is no surprise.
For people with disabilities 37signals apps are a nightmare and could be fixed so easily. It is not harder to use css instead of tables for layout in any way, you should just get a habit of using it. Not caring about just shows that you don’t care about some of your potential customers.
There is a great benefit in reusable, semantic, code with a small footprint.
Robert Hamilton
on 03 Feb 09I love it! My coworker criticized my use of tables on a series of landing pages last week and hes a huge fan of 37signals. The thing to know is that theres a time to use tables and a time to use CSS. Knowing when to use each can cut down on development time while still keeping the style clean & easily edited.
For those who are on the CSS high-horse and say theres no reason to use tables in new sites - proper table use can save you alot of time, and the only people who will notice the table are smug web developers who peek at your source code - not the ‘normal user’.
Weixi Yen
on 03 Feb 09I agree with RS’s comment. It doesn’t matter what you use, just get it done. However one thing to keep in mind is that a page does render differently with tables (tables won’t render until everything inside of it is loaded) so it’s highly discouraged to encapsulate your entire page in a table.
Randall
on 03 Feb 09Would not be complete without: http://giveupandusetables.com/
Bradley Wright
on 03 Feb 09I can’t believe this argument is still ongoing. If you’re bad enough at HTML and CSS that you feel the need to use tables as a design element, then you should consider a new job.
Seriously-tables are not just about “tabular data”, they’re worse for accessibility. If you’d seen someone trying to use Amazon with a screen reader you’d know what I was talking about. So stop blowing your own horn because you’re shooting down “trolls”-you’re making the web a worse place for people who already have pretty bad experiences on it. Congratulations.
James
on 03 Feb 09In my experience, tables are almost always more work when used for layout, with the exception of those times when I use them the way they’re meant to be used: for marking up tabular data.
I can sympathise with your need to get things done efficiently, Ryan, but some of what you’ve said betrays a real lack of empathy with people who (could be) using your apps and websites.
It’s a myth that the type or quality of the code making up your website has no bearing on anyone but the person who maintains it. For example: it’s also important to care whether your HTML degrades gracefully, and whether it’s accessible to disabled people, or people on mobile browsers (not everyone has an iPhone).
I’ve always found that marking up my websites using semantic HTML makes them far easier to maintain. Coming back six months later and seeing a list marked up as a list is ever so much easier than seeing it wrapped in a mishmash of <td> tags. If you disagree, I’d really love to see you post some example code where you use of tables rather than CSS — we could all learn something from a proper insight into an important topic.
dusoft
on 03 Feb 09Those, who are trying to support your measy arguments about tables for layout are forgetting one simple argument against it: accessibility. Tables used for layout are mostly not accessible.
I am really surprised the 37Signals support inaccessible websites in this way. Very uncool.
Richard Amos
on 03 Feb 09You have entirely missed the point in semantics.
It’s nothing to do with being a ‘purist’, semantics is for accessibility, portability, and just using a language properly. It’s a pretty basic concept. Semantics does not define the ease or difficulty of solving an HTML/CSS problem, it just gives you a set of rules in which to implement HTML in. You then style this accordingly.
If you ignore semantics you make as well use h1 tags for paragraphs and input tags for headers. It’s just fundamentally wrong.
Nic
on 03 Feb 09Here’s a true table-supporter!
Michael
on 03 Feb 09Basically, don’t use tables for layout. But every once in a while, some things are easier solved that way and also more reliable. E.g. I have a big client, who has IE5.5 on W2K running on 5%+ inhouse – on rather weak machines. Of course, almost anything can be done without tables – but at what price (in terms of extra css and performance). A mean, check it out: A simple header-3col-footer layout renders very much faster when coded with table-layout vs. css, especially on older/weaker machines, slow networks etc. So, I guess there’s no need to be a fundamentalist about this. It really depends on the situation.
GIANT CAT
on 03 Feb 09sounds like your a lazy fat cunt then, CSS is far superior when used correctly
Ben Darlow
on 03 Feb 09Translation:
Also, referring to folks who do things the right way as “CSS trolls” is what’s known as ad hominem. By demonising them (connecting them with those argumentative sorts on the Internet we don’t like) you’re implying their arguments lack merit.
This is, of course, untrue; but then this whole posting was top-to-bottom so full of bollocks it shouldn’t surprise us to find such illogical cruft in there.
Dan Glegg
on 03 Feb 09What you say makes sense if you ignore inconvenient facts such as the existence of blind people.
Personally, I find it hard to classify an HTML/CSS developer who pays attention to the code they create as a “troll”. Surely they’re just a quality markup coder. Telling people that they are doing it wrong is not trolling – it’s evangelism.
Trolls are people who create posts just to start conflict or to cause upset. Evangelists are people who care enough about their approach to spread it – this is a comparison I would expect the 37s guys to relate to.
Jesse Dijkstra
on 03 Feb 09Ben Darlow makes a good point, and I tend to agree with him. Honestly the way the word troll is used in this point is in my opinion trolling itself. It is basically saying that people who believe anything can be archieved by using CSS and XHTML instead of tables and preach that, is a troll. Does that not make this post trolling as well then?
And other arguments made in the post that has been referenced: I’ve come to the conclusion that so far anything I wanted to work, worked with CSS. Most problems I have encountered or have seen other people encounter is lack of knowledge of CSS. CSS is on it’s own something that requires years of experience to master well. Mind you, a level I still haven’t reached.
Isofarro
on 03 Feb 09rs: “Every project and every client is unique, and everyone is entitled to an opinion. At the end of the day, the only one(s) who can determine if the solution chosen was right or wrong is the client.”
No, a client hires you because you have the knowledge and skill to deliver what he needs. A client is paying you to create the right solution. Although a client is legally responsible for the things he commissions, he has delegated the responsibility of selecting the appropriate solution to you.
There are many cases where contractually supplied products were released by a satisfied client only to be recalled or removed later owing to defects or similar. This quite demonstrates that clients don’t always understand what the best solution is in the long-term, and shows quite effusively that a solution deemed acceptable at the point of delivery may be anything but in the short, medium or long-term future.
There is a price to be paid by making sub-optimal decisions. People who move on from one site to another rarely experience the effects of the damage they cause by short-sighted decisions. “It works for me” is a typical refrain of self-interests over team work and co-operation.
37 signals pay the price of the technical decisions they make, for example the non-idempotent GET. Looking back from now, its easy to see what an idiotic idea it was using links to delete records, but when 37 signals first considered the idea, even though it was strongly discouraged by the HTTP specification, they believed it was the best option. And it quite clearly wasn’t.
datenkind
on 03 Feb 09Source: “Getting Real”, Chapter 3, 37signals
So, please, sirs, don’t be so “§$x%x ridicules about front end development!
Michael
on 03 Feb 09Also, as the HTML/CSS guy in charge, you don’t always have control over how things are done. If within a larger project someone decides e.g to use JSF (Java Server Faces) to render a search result, then you’re stuck with a nested table output for a simple list! At that point I’m already happy if that programmer offers me some hooks to at least style that output. I personally call it “The WOB” ( world of bullshit) – but I have to deal with it a couple of times per year – usually in very well paid projects…
DHH
on 03 Feb 09This thread seems chuck full of exactly what the original poster was ranting about. Our applications is unlikely to ever be usable by a screen reader. The JavaScript alone is surely enough to trip it up.
So is the fact that the apps are as much about interaction as they are about just reading stuff (out loud or otherwise). So decrying the existence of tables as “THIS IS HOW YOU’RE HURTING BLIND PEOPLE” fits the troll bill pretty well.
Keith
on 03 Feb 09A couple observations.
Tables have a place. They are for tabular data. I can’t think of a web application in which there would not be tabular data. Marking that up with CSS doesn’t make semantic sense at all.
There is a difference between using tables and laying out an entire application with tables. This isn’t an all or nothing discussion and tables don’t, on their own, break some sort of unspoken rule about “modern web design” or something.
I don’t see why there is anything wrong with folks wanting to see a Section 508 compliant version of 37s apps.
I’d say that’s a big compliment DHH. It means that the poster cared enough to look at the underlying code and see what it might take to make it work. Now clearly, as you’ve pointed out, there are other things standing in the way that would likely be too complex to rectify the situation.
That said, it speaks volumes about your applications that people would care enough to want to share them out that way.
A couple handy links for those interested: http://www.webaim.org/standards/508/checklist http://www.webaim.org/techniques/javascript/
Dan Glegg
on 03 Feb 09“The JavaScript alone is surely enough to trip it up.”
You do offer fallbacks for when javascript fails or is unavailable, right? That’s one of the many benefits of using respond_to in your controllers.
“So decrying the existence of tables as “THIS IS HOW YOU ’RE HURTING BLIND PEOPLE ” fits the troll bill pretty well.”
No, it doesn’t. Once again, trolling is the act of posting purely to start conflict or inflict upset. Dismissing people as trolls purely because they disagree with you does not put forward a strong case for your argument.
Isofarro
on 03 Feb 09DHH: “Our applications is unlikely to ever be usable by a screen reader. The JavaScript alone is surely enough to trip it up.”
What accessibility issues with your applications do you feel cannot be adequately addressed? We have fairly reliable accessibility mechanisms and techniques in place for user-initiated ajax updates and events, as well as an approach for dealing with asynchronous messages that are not absolutely time critical.
DHH: “So is the fact that the apps are as much about interaction as they are about just reading stuff (out loud or otherwise). So decrying the existence of tables as “THIS IS HOW YOU ’RE HURTING BLIND PEOPLE ” fits the troll bill pretty well.”
Unfortunately I have to concur. Content websites done with tables can provably be as accessible to blind people using screenreaders as a CSS-layout. This is from the most basic premise that the web would be totally unusable for screen reader users if that claim were in anyway true – which is not the case. Screenreaders deal with tables by ignoring them, and allowing the user to turn on tables navigation mode, tables for layout really impacts when tables are also used for tabular data. It’s not an impossible barrier, but one that does require some thought from the user – like any practical usability barrier, as long as it functionally works, a smart user can us it.
So you are correct, the ‘accessibility’ issues being raised here is peanuts compared to the accessibility issues created by your interactivity designs.
Which leads into the logical question: so what are you doing to resolve or alleviate the accessibility issues you are quite well aware of? Do you have a list of documented accessibility issues (e.g. from someone like Joe Clark or a usability testing with disabled people), and which of those have you decided to be ‘unsolvable’?
Sam
on 03 Feb 09I wonder if this conversation would be happenning if IE supported “display: table;” and “display: table-cell;”?
Incidentally, it looks like this is something IE8 will support: http://www.quirksmode.org/css/display.html
pimpmaster
on 03 Feb 09I admit that I was surprised the first time I peeped the source of 37 Signals apps. How could the makers of such innovative products still be rocking HTML from 1992? It seemed a bit ironic, but hey – to each his own.
If you handle projects internally, then IMHO you reserve the right to produce as much non-standard/convoluted/obtrusive code as you please. All that matters is that you ship on time, the damn thing works your customers are happy!
Personally, I don’t miss those pesky tables one fucking bit – and I don’t blame people for advocating clean standards as it makes our code more legible and maintainable.
Correct me if I’m wrong, but isn’t that what inspired Rails to begin with – beautiful, elegant code? Why should our HTML be any different???
Having said that, I can understand why some folks lose patience with pure CSS. The amount of issues with Internet Exploder alone are enough to piss anybody off. It’s a learning curve like anything else, but I have found that once you have the technique down, it’s a cakewalk to produce solid, stable layouts with semantic code in very little time. (MUCH faster than tables)
As you may have surmised, YES I AM A PROUD CSS TROLL. Anyone who disagrees with my markup philosophy is nothing more than an HTML DINOSAUR on the brink of extinction (who probably still listens to Vanilla Ice)
Brade
on 03 Feb 09Agreed with Eric Eggert, Bradley Wright, and Ben Darlow.
Just a cursory glance at this page’s source code reveals such nuggets as [td align=”right” nowrap] used for the simple Jobs/Gigs info at the very top, not to mention that you’re using a freaking javascript file to grab those rather than simply doing that processing on the backend so everyone can be guaranteed to see them… Also loving the [hr noshade], the unclosed [dd] tags, lots of attributes that don’t even exist, and labels on the comment form with “for” attributes that are different from the “name” attributes of the actual fields.
In other words, the most elementary of mistakes exist all over your site, so you are clearly not to be trusted when it comes to advising the rest of us how to develop and markup our websites…
Keith
on 03 Feb 09I don’t understand why this is a debate regarding what 37signals does with their source code.
The awards, national attention, and popularity of this blog suggest that 37s and Co. are right…backends only matter to people who look at those things. The vast majority of successful businesses aren’t selling to “insiders” but rather to consumers with a “I want it to work” attitude.
The issue of 508 compliance is being bungled a bit by the misconception that 508 means having pages that can be read by screen readers. That’s definitely NOT the entirity of the issue.
The bottom line is that HTML & CSS can co-exist. 37signals is pretty much saying:
HTML & CSS are technologies that render websites to a web browser for consumers of the information or service. The ratio of CSS to Tables is irrelevant in a discussion about the usefulness of the page they render.
Peter
on 03 Feb 09Brade: You nailed it.
Mat
on 03 Feb 09“In other words, the most elementary of mistakes exist all over your site, so you are clearly not to be trusted when it comes to advising the rest of us how to develop and markup our websites…”
Couldn’t have been said any better.
Andrew Banks
on 03 Feb 09In this article, I say why you can be a purist and use tables for layout.
http://combatentropy.com/coming_back_to_the_table
Anonymous Coward
on 03 Feb 09Did anyone even read the post? This wasn’t a quote from 37signals. It was a quote from another source.
Dennis Kempin
on 03 Feb 09I think that tables can sometimes be so much easier and faster to implement without any browser incompability issues.
So why not use them? The User does not care about your sourcecode.
Of course tables can have disadvantages, but I think when the website/app can live with these disadvantages there is no need to complain about the sourcecode.
Btw: I have written a few words on that topic these days too. Feel free to have a look!
Regards, Dennis
rvr
on 03 Feb 09“trolls are bad.”
“gee, of course i agree with that.”
“i hate all these css trolls”
“yeah, me too! uh, where are the css trolls? point them out, cuz i really want to hate them. no? you don’t see any? ok, maybe they’re all hiding. sneaky trolls.”
only fanatics like fanatics, and then only the ones that agree with them. so you used a table. great, good for you. you’re worried someone is going to jump all over you for it? why not wait and see if it actually happens, rather than write a defensive blog post about it before it happens?
as for me, i built sites with tables for a number of years. it worked. it was often frustrating. the code was difficult to maintain, and even harder to change. now, i build sites with css. i rarely revert to tables. it’s sometimes frustrating. the code is much easier to maintain and faster to change. i’m happier, which means the stuff i make comes out better, which means my clients/employers are happier. i’m pretty sure that’s the point, and i’m pretty sure that’s what’s known as a business case for using something.
the people who claim the code doesn’t matter are full of b.s. just because your client doesn’t review it, just because 99% of your users don’t understand it, does not mean it doesn’t matter. lack of understanding and experience is not a valid argument against something.
that’s all.
GeeIWonder
on 03 Feb 09The OP was about a guy who cannot(or at least, cannot efficiently) do this particular task with CSS. And it wasn’t until he learned that other people (‘big sites’) use tables that he finally accepted just doing it with the tools he could execute it with might be ok.
my #1 criteria is this: Which technique will be easier to work with over time?
This is probably (understandably) more contentious.
As you may have surmised, YES I AM A PROUD CSS TROLL . Anyone who disagrees with my markup philosophy is nothing more than an HTML DINOSAUR on the brink of extinction (who probably still listens to Vanilla Ice)
I think the only losing camp here is the one that insists on starting crusades between two different approaches. Too often these arguments fall into people repeating viewpoints that they’ve been told to hold, or have assimilated, without any real understanding. Even the OP is sort of monkey-see monkey-doing it. So now he’s changed from one ridiculous ridiculous to another, and he swears an oath against the ‘trolls’ (of which he was one but a minute ago) and takes communion with a donut.
What are HTML/CSS? Language. Why do we use HTML/CSS? To communicate.
This is like arguing that speaking French is better than English because it has a better range of vocabulary. But if you don’t speak French very well, and your audience speaks both, you’re probably better off speaking English.
rvr
on 03 Feb 09well said, @geelwonder. use what you can, but don’t knock the other options because you don’t know them.
to hijack your metaphor, if i go to france i’m going to rely on my english and hope they will understand me well enough and be tolerant. but i won’t expect to communicate fully everything i may want to say, and i certainly won’t criticize them for speaking french.
web standards exist for a reason, and it’s clear communication. do the best you can, and if you need to use a crutch once in a while, we’ll understand. most of us do it sometimes. but let’s be honest and call a crutch a crutch, ok?
Graham
on 03 Feb 09To be blunt and honest with myself, I was once the type who screamed accessibility violations whenever I saw a TD tag or bit of javascript in an app, but honestly, unless you are devoting 50+% of your time to nothing but screen reader research then you are just spouting off about “inaccessible apps”.
Really, anyone who says you don’t care about blind people because you used a table is completed and utterly FULL OF CRAP.
Yes, 27-row deep, horribly organized tables make using a site painful for screen readers, but they can (and do) get around this, most commonly by bypassing the “visual” layout of the page and letting the user jump directly to links and form elements.
Also, using inline styles makes sense in certain cases, and is not nearly as bad a practice as I once thought in my puritanical days.
As its stated though, there isn’t really much you CAN’T do with CSS, but sometimes the best solution is the one that’s the quickest to implement with the smallest cost. Vertical centering is pain in CSS, and sometimes I use a table to line up a 2-col form, but only if I’m feeling the heat of a deadline, or if my column widths are really variable based on the content.
Dennis
on 03 Feb 09I think it all comes down to:
The right tool for the right problem.
When CSS is causing problems (maybe due to browser problems) a table may be the right tool to solve this problem.
Geoff B
on 03 Feb 09I’m coming very late to this discussion, but does anyone have a link to a well articulated reason for using pure css instead of tables for layout? I will google around for this as well, but it would probably be better if someone who advocates for CSS provided it, rather than a newbie like me.
Right now, I’m hearing a lot about how people may “give up and use tables”, but what are we giving up? I’m not much of a designer, so I don’t know.
Some people might look at Struts 2, Spring IOC, Hibernate and JPA, and decide they’re going to “give up” and just use servlets, pojos, and jdbc. In this case, “give up” would be the right way to describe the decision – there are more maintainable frameworks, but it might not be worth learning them for some types of projects.
But suppose the same person said he was giving up and using Rails. Well, for some types of projects, I’d say he isn’t giving anything up at all. He’s benefitting from an approach that is easier to learn with no loss whatsoever, and perhaps (in the opinion of many folks here) a net gain.
So… what do I actually lose when I use tables? You can probably tell from my post that my bias is towards tables, but that’s because they’re easy and appear to do the job. Why do I need to take an approach that feels harder at least in the short term?
Benjamin
on 03 Feb 09As with the Photoshop rant of a few months ago, these are great blog posts for generating comment storms, but not so great for moving the web (or design quality) forward.
Lack of semantics within “deep web” applications might be fine, but on the open web semantic meaning should rule the day.
rvr
on 03 Feb 09@geoff b, this looks pretty good:
http://blog.chromaticsites.com/13-reasons-why-css-is-superior-to-tables-in-website-design/
what are you (or others) giving up? in my experience, and in my opinion:
- maintainability - accessibility - flexibility - control - efficiency - semantics - seo - job opportunities
that said, if you’re building a site for yourself and don’t mind the extra time/effort in the long run, then whatever, you know? tables may be less up-front effort for you now, and maybe that’s all that matters. but the mid- to long-term payoff with css is huge, in my experience. when i have to go back and revise that layout or create a new template, i’m in much better shape. and if you work on a team, simplicity and semantics make it so much easier to collaborate.
MichalT
on 03 Feb 09I would like the CSS gurus to tell me how to create a 500px wide menu that:
- has a variable number of buttons - the button width depends on how long the caption is - the buttons together fill all the available width
...without using a table (which does all of the above automatically).
Mark Weiss
on 03 Feb 09Tables are a tool. If they help you solve what you need to solve then by all means go for it. In the end customers don’t care if you use tables or css. If it works and is useful to the end user then it really shouldn’t matter.
Of course a pure css solution is preferred. But sometimes, you don’t have 2 weeks to figure out a solution.
Weixi Yen
on 03 Feb 09You’d be surprised at how many people think their sites are inaccessible to screen readers and actually are. The tweaks to make things accessible are simple.
Also, you’d be very surprised that table-based sites are actually no less accessible than div-based sites. Strict markup standards have really little to do with accessibility.
RS
on 03 Feb 09Weixi: That sounds like the beginning of a productive conversation. I’d be interested to see some material in support of your point.
StartBreakingFree.com
on 03 Feb 09Haha…this post made me laugh. Div’s seem to piss me off constantly! And I find myself reverting back to tables. Thanks Ryan.
Geoff B
on 03 Feb 09RVR -
Thanks, that was a good link. Of the 13 reasons, I did find some compelling. These were mainly around the ease of updating and/or redesigning the site. As a programmer, I am receptive to the headache of updating a few lines of code all over an app rather than in a single method.
The loading/hosting costs might seem like micro-optimization to me – not sure, I’d need to see some more numbers.
The “Competitive Edge (job security)” seems like the weakest argument. I’ve seen a lot of technology included in Java apps mainly so that the developer could feel like he’d used the latest and greatest. This reduces the maintainability, it doesn’t expand it. Similarly, if a site is very simple and small, and could have worked easily with tables, and CSS gurus are hard to find… well then you just put maintenance outside the realm of someone who knows a bit of HTML. It can be worth it, but it isn’t always – just as it isn’t always worth using an elaborate tag library in a simple app where a bit of JSP scripting would have worked. The latter can be easily maintained by anyone who knows Java.
I’d get a lot out of a longer article. For instance, the “Head First Servlets and JSP” book takes a long look at how a program can get out of control without MVC, then rebuilds it with a custom controller, and finally moves into Struts. It’s a little out of date technically now (and I’d rather just use Rails in the first place), but they do a good job showing exactly how this can help reduce complexity in the long run, even if it does require some additional effort in the short term.
Just to be clear – I’m all for constantly learning. I don’t avoid new technologies because I don’t want to lear. I sometimes avoid them because I always have a stack 10 deep of new things I have to learn, and I’ll never get more than four or five spaces down the stack before new technologies start competing for slots. CSS for tables would require bumping something else from the top five.
Right now (this is off topic, but eh) my list is
1) Struts 2 2) Ajax (outside the GWT context) 3) Spring Security 4) GWT (?) 5) Google Guice as a better DI container (?) 6) JPA/Hibernate through annotations instead of XML 7) CSS…
One reason I like Rails so much is that if I could move over to it completely, my list would be
1) Rails 2) JRuby 2) CSS…
Yeah, I’m compressing a lot into rails that could be broken into a longer list, but I’ve worked with it enough to know that I get far more bang for the book with Rails, and I’d probably be able to move other valuable things into the queue without much loss.
Anyway, sorry for rambling off topic… just hope to give you some perspective on why some devs who are constantly learning still have a default resistance to learning another technology – even a really good one.
kimblim
on 03 Feb 09There is a right way to do things and a wrong way to do things. Using tables for anything else than tabular data is wrong. Period. No but’s, no if’s, it’s wrong.
In business terms I can easily see why you would sometimes prioritize getting things done more quickly, but that does not make it right to use tables for layout purposes – it just means that you should go and revisit that code when you find yourself with 15 minutes to spare.
SS
on 03 Feb 09Several months ago a customer contacted us regarding screen reader support in Campfire, our real-time group chat application. We don’t have permission to post the email here, but the gist of it is that the Jaws screen reader apparently has no trouble reading new chat messages from Campfire as they’re dynamically inserted into a table with JavaScript. In fact, it works so well that the customer wrote us to ask what techniques we were using so that he could employ them in his own software.
We neither test our software with screen readers, nor apply any special workarounds for accessibility purposes. So I’m highly skeptical of the claim that tables and JavaScript are at odds with accessible web applications.
SS
on 03 Feb 09Actually you haven’t peeped the source of our apps. You’ve looked at the end result of hundreds of template substitutions and calls to helper methods.
In a web application, the HTML you see with your browser’s “View Source” is compiled output, not source code. We strive to keep our source code – templates, helpers, controllers, models – beautiful. What ends up being sent to the browser doesn’t matter as long as it displays and behaves properly.
James
on 03 Feb 09You guys have obviously made your minds up on this, which is fine—each to their own, whatever works for you, etc. I can see where you’re coming from; it’s not a clear cut issue and you need to be pragmatic.
It would be nice, though, if you replied a bit more to the commenters who are disagreeing with your points rather than cherry-picking the people who back you up, and labeling the others as trolls.
Also: the language you’re using is interesting. CSS chops need to be “advanced”. Accessibility requires “special workarounds”. It sounds like you’re stuck in 1995. No offense meant or anything—I’m just surprised such a forward-looking company takes such a backward-looking stance on this.
PS: kudos to GIANT CAT for pointing out the ad hominem fallacy. If you want to argue your point, fine, but can we move past shouting insults at people, please? That’s just lazy.
David Kaneda
on 03 Feb 09I have to disagree with SS here, “View source” does provide source code. Maybe not backend source code. But HTML/CSS/Javascript is the source of the page you’re viewing. Saying that “it doesn’t matter as long as it displays and behaves properly” is a slander against modern, semantic web design, promoted and taught by such sites as A List Apart.
People can write Helpers which, in turn, write cleaner HTML. It’s all a matter of choice. Just like, ten years ago, people could choose between bare bones coding and Dreamweaver. Everyone’s choice of Dreamweaver had negative consequences on the industry.
There’s no denying that cleaner HTML loads faster and can be made more accessible, and the same could be said about the inline Javascript used throughout the apps. Just because something’s faster to implement doesn’t mean it is more accessible, sustainable, or better for the consumer.
David Kaneda
on 03 Feb 09Also just wanted to mention that I posted about this (code quality and Basecamp) a few weeks ago: http://www.davidkaneda.com/post/69019175/basecamp-html-js
SS
on 03 Feb 09David, in what way has Basecamp’s markup affected your ability to use it? Can you really claim to know what’s “more sustainable” or “better” without seeing all the underlying pieces and the way they’re put together? Re: accessibility, see my remarks above.
If you’re concerned about repeated code in inline event handlers slowing down the page, there’s a couple of things to keep in mind. One, any redundancy is effectively compressed away since we gzip our markup before sending it to your browser. Two, installing inline event handlers is instantaneous, while querying and iterating over hundreds of DOM nodes and installing event handlers programmatically can be quite slow.
Daniel
on 03 Feb 09AFAICT, the spirit of the post here is “use the right tool for the job” or at worst “be reasonable”.
Unfortunately, the original post the quote is pulled from is clearly a case of “This is hard. Poo. (Cry. Stamp feet. Present argument by cherry picking from well-known or popular sources.)”
The example in the original post is a nested list of comments. If there was ever a great case for CSS over tables for layout, that might be it.
As someone refactoring a 10-year-old user interface built under the attitude “What ends up being sent to the browser doesn’t matter,” I find that statement frightening, and as a loyal reader and customer, disconcerting. “What ends up being sent to the browser” and how “it displays and behaves” make up a system and discounting the former for immediate efficiency is akin to taking a tank to the gun range.
Anthony Green
on 03 Feb 09Rails core chooses to pick a fight with the web standards movement are they fucking insane ?
Bradley Wright
on 03 Feb 09So your entire knowledge (and subsequent “scepticism”) of accessibility is based on a single email about just one technique? That’s very belittling to all the people who spent years perfecting web development techniques aimed at better enabling disabled users on the web.
Bryan Sebastian
on 03 Feb 09I agree with Ryan on this.
The tables vs. CSS debate seems to be a very “religious” to many web developers. I have worked with web developers that have spent hours re-designing a site because it is not “supposed” to use tables (because that is frowned upon), but they had to put together all kinds of crazy CSS styling to get around using a simple table structure.
I always found this practice of fixing something that is not necessarily broken to be a very un-”Getting Real” like approach. I wastes valuable time and money to go in and re-style an entire website because “tables are evil”.
Richard Amos
on 03 Feb 09Tables are not for layout. It really is quite simple. If you use them for layout, you are misusing a language which was designed for access for anyone. You are fundamentally breaking what is so elegant and beautiful about the web and making it ugly.
You use a language, you work to the spec. It’s quite simple. Every other industry manages to work to specifications so why on earth do some web developers think that they can avoid this ‘hindering’ step.
It’s not a religion, it’s a basic understanding of standards, markup schema and accessibility.
Anyone who uses tables for layout has either:
a) Never used a screen reader
or
b) Was listening to themselves talking rubbish instead of listening to the mess you hear on table based sites.
If it wasn’t for people making insane table based sites, screen reader companies could purely focus on usability in their applications as opposed to screwing around with ‘quirks modes’ because some people are too lazy to learn how to code properly. It is a skill but nothing you can’t learn with a bit of patience and a bit less arrogance.
I can’t believe we’re having this discussion in 2009, it’s no wonder thanks to some of the comments here that web developers and their pretty special skills aren’t taken seriously. No wonder it’s hard as a manager to fight for budget for employing talented developers when there’s apparent industry proponents here with attitudes to basic accessibility LAWS being “well, it’s a bit hard to do innit, and what about them CSS trolls?!!?”.
RS
on 03 Feb 09So it looks like this is still a hot topic :)
For perspective, we care about two things:
1. Our apps should work extremely well and give our customers great experiences
2. Our code base should be a pleasure to maintain over time
Everything else is a detail about how we accomplish these two things. When it comes to markup and CSS decisions, the first point means our code should render correctly in the browsers we support and it should be fast. The second point means the code should be easy for us to understand and modify when it’s time to make changes to the app.
The rest are implementation details, and each individual implementation decision has a context. It would take an entire Design Decisions post on each chunk of markup to fully explore why certain decisions were made.
The reason I got a kick out of the article quoted in the original post is that we often forget the freedom we have to make choices case-by-case. Instead there is a strong tendency to cling to totems and taboos so we don’t have to think for ourselves. The important things are customer experience and maintainability. And maybe feeling good enough about what we did that we do like the author of the quote and grab a donut afterward.
GeeIWonder
on 03 Feb 09You can’t celebrate with a donut. Donut’s aren’t for celebrating—they’re for coffee breaks.
He should celebrate with beer.
;)
Bryan
on 03 Feb 09@Richard… I apologize as I was probably need to expand my post.
I do not agree that a developer who uses a table for layout is “unskilled” and arrogant. But, it is your right to have that opinion.
I agree with you about the spec. Anytime a web developer gets a specification for building a website, that specification is most likely bound by constraints on budget and time.
For example, a client may say, my site needs to render in IE6, that most likely will imply more time and require more budget. Another client may say, we do not want to spend the extra time/budget making our site work in IE6.
I believe this requirement holds true for screen readers as well. If the spec states the site has to be accessible for the visually impaired then care must be taken to eliminate tables and do whatever it takes to make the site function to meet that requirement.
However, due to budget and time that may not always be a requirement. Sorry, perhaps it should be, but it is not always the case.
As for as “understanding of standards, markup schema, accessibility”... what standards are you referring to? W3C? I don’t believe they have come out and said if you use tables you are not following standards, unless they have made some standards for accessibility, which they may have.
There is a great deal of playing the accessibility card in this discussion, and perhaps rightfully so. However, I know there are laws/building codes for building structures to be handicapped accessible have certain parking places, bathrooms, etc. Do such “LAWS” exist for website development? I am only asking because I truly do not know the answer that and I am curious to know.
Anthony Green
on 03 Feb 09Molly Holzschlag is running a course just for you guys:
http://www.molly.com/2009/01/08/web-standards-for-web-applications
Anthony Green
on 03 Feb 09In terms of accessibility Derek Featherstone has done a lot of work investigating web applications:
http://odeo.com/episodes/22044226-Derek-Featherstone-Accessible-Web-Applications-in-a-Post-Web-1-0-World
http://simplyaccessible.org/
Bryan
on 03 Feb 09@Ryan… indeed, and for me the “case-by-case” basis is, at the end of the day, did I meet/exceed the client’s requirements/expectation for the work that was done. Thanks for stirring up some interesting discussion.
Last post on this… promise. ;)
Richard Amos
on 03 Feb 09Bryan, in response to your thoroughly polite post, which I appreciate…
Not only has the W3C standards on how to implement HTML and what tags should be used in which instances (this is the spec and the schema), it also has the WCAG which is moving into 2.0 Draft which addresses many of the issues people here seem to be ignoring, including how web applications should ‘work’ in restrictive accessibility-enhancing environments.
There are a lot of laws, especially in the UK governing websites these days. At the moment they are slightly difficult to make out from the trees, but essentially if you are blatantly ignoring the WCAG 1.0 and you are making a large site accessed by the public, especially in the service sector, and someone complains, you are highly likely to suffer heavily in court as a company.
The argument about companies having budget is a null point for me. I have run tech departments at 2 different agencies and at both we significantly shortened development times by continually training, standardising and developing our HTML/CSS skills to the point that even the lowest budget sites could be accomplished to Priority 2 in the WCAG with very little effort.
There is of course the issue that to achieve Priority 3 (some comment that it’s not possible on some sites) you require active client participation but to achieve P1 or even P2 just takes good coding, and that’s it.
To be honest I am not even entertaining the discussion that web applications are inherently inaccessible. This is absolute crap. You build a web application properly and allow it to gracefully degrade and you will have no problems with accessibility. Or, if that’s too hard, make a separate version built on the same model and controllers, it will add 10% to your dev time. Any decent framework and data structure should be able to be manipulated with basic instructions as well as complex Javascript instructions. Even for just simple unit testing of controllers and models this should be done as a matter of course.
Beejamin
on 03 Feb 09When you build a site with HTML, you’re speaking a language. When you build it cleanly, efficiently and to spec, you’re speaking precisely, eloquently and fluently.
When you use a table for mark up you’re using phrases like: “the big, blue thingy”, “er, that gizmo”, and the “other square shaped bit”. Which is fine, if you’re talking with friends over a beer, because they can still get the gist of what you’re saying.
If you talk like that when you claim to be a ‘professional speaker’, you shouldn’t be surprised when your audience make snide remarks about it.
Ossi
on 03 Feb 09The important things are customer experience and maintainability
Both of which you fail instantly by disregarding standards and writing invalid code.
How do you explain that both the html and css for 37signals generate just about 200 errors and warnings when validated against W3?
front page – 79+ Errors, 10 warnings
screen.css – 1 Error, 106 Warnings
It’s not the odd slip here and there either, it’s beginners mistakes of the worst kind. like id’s not being unique, same values being stuffed over and over again in the css completely missing the point of using css in the first place, missing start or end tags and tags simply being left unfinished.
making these kind of mistakes and arguments and then claiming that you know what you’re doing, makes it very clear that you don’t.
Beejamin
on 03 Feb 09and, @Bryan – it’s not the client’s job to care about web standards – it’s your job.
pimpmaster
on 03 Feb 09SS says “We strive to keep our source code – templates, helpers, controllers, models – beautiful. “
I would expect nothing less from you guys, which is why your HTML output is so surprising. As for this:
“What ends up being sent to the browser doesn’t matter as long as it displays and behaves properly”
^^ You just hit on the heart of the controversy. For 37 Signals this translates to the “fuck it, it works” philosophy, which does have its merits. But the contrary argument is that this attitude has an ugly side too.
Think about it, the vast majority of compatibility issues and bad design decisions also spring from this mentality. Look at the IE team and Explorer – for years the bane of the web design industry – how many times I have cursed them I could not tell you. What I can say is that their approach was quite similar to what you advocate here (standards, schmandards who cares if it works?)
Well let me tell you, I am grateful that there are people who DO care about trivial things like semantics and MEANINGFUL code. I think the point that most CSS “trolls” try to drive home is exactly that – if standards are not cultivated and pushed forward, then the whole community takes a huge step backwards, and all of our jobs get collectively harder (and less enjoyable).
Personally I code Rails apps all day long, and I really go out of my way to make damn sure my html output looks just as solid as my MVC ). My sites are valid HTML (thank you HAML!!!) and if there are any pages that aren’t you best believe they are being hunted down and set straight.
Does it matter to the end user?? Probably not that much – but it matters to ME, as an artist/craftsman who takes pride in his trade, and wants to see his industry flourish and evolve in EVERY way.
I’m all for using the best tool for the job, but there is a fine line between “pragmatic” and “plain sloppy”. Your HTML hangs dangerously close to the latter, IMHO
Bryan
on 03 Feb 09@ricahrd… I see what you are saying. Please note that I am going to take something away from this discussion, and that will to try to ensure better accessibility with websites that I develop, and to make sure clients are aware that this needs to be addressed. -thanks for the response… Except I said I was done posting here, rats.
pimpmaster
on 03 Feb 09I’d like to offset my previous remarks by saying that the value provided by 37 signals far outshines their hideous HTML.
Rails alone has made my job so much more fun and manageable, that you guys can use fucking blink tags as far as I’m concerned :p
Please take my criticism with this grain of salt
rm
on 04 Feb 09I do awfully like the “HTML code as art/craft” analogy. Those who consider it art and themselves artists are of course the ones wielding torches and pitchforks, banging at 37signals’ virtual doors. 37signals being the big bad business exploiting “their” art for profit. They’re not being true to the spirit of the art!
But they’re also the ones with the reasonably successful business, reasonably good press, reasonably well-designed products (except maybe for blind people), reasonably happy customers (again, possibly excluding the blind), and this blog you all read and gripe on.
Yes, yes, won’t somebody think of the blind?! Perhaps what 37signals should do is take some of the profits they make by building actual products instead of nitpicking over their CSS (or worse, complaining about it on blogs or in forums) and donate it to organizations who are working on a cure.
Anthony Green
on 04 Feb 09RM like many of the posters its appears you have very little knowledge of accessibility issues and instead chosen to adopt a patronising tone towards the disabled and those that are trying to help them. Accessibility is about trying to provide and improve access to a variety of both people and devices. Solely in terms of disability that can mean more than just ‘taking care of blind people’. There are a range of assistive devices disabled people to access the internet and by adopting web standards you provide a solid ‘api’ that allows manufacturers improvement the quality of these devices. This can also said to be true of the other major field of accessibility research – that of mobile devices and their kin. We cannot be 100% sure what the nature of these products will be, but by adopting a standards we can be pre-emptive it our ability to support them.
Jacquelyn
on 04 Feb 09Ok, here’s my issue with all of this. Everyone wants to think they’re right, and the other side is wrong. I am new to web design. I started less than a year ago. So, I never learned to use tables for layout. The first things I learned were XHTML 1.0 Strict and CSS 2. Because of that, I find it much more difficult to even figure out how to design a site using tables. I guess the same can go for those of you who learned tables and got very familiar with them before attempting CSS. The problem I have with tables is the accessibility issue, and the inline styling issue, and the fact that table layouts take longer to load….So now tell me this, because this is something I have seen recently. Why would someone download a free template (bad enough, it was a commercial project) that was already perfectly valid XHTML transitional and CSS and spend forever converting it to a table layout? The only reason I can see is because that person is just too lazy/stupid to learn CSS. So I will say this, after reading 5,000 of these comments today. I can see some cases where the hacks for CSS just get too ugly and tables might be a better/faster option. But I also see a whole bunch of people who might learn a lot more just by trying (REALLY trying) to learn CSS. It took a 10 week class for me to get it, but I was learning XHTML at the same time. And I don’t think it’s the people who designed CSS or the web standards who are to blame. It is the un-standards-oriented browsers who are to blame.
kimblim
on 04 Feb 09And how would you know that it displays and behaves properly in FF4 or IE8 Final? You wouldn’t, because you didn’t use the proper tools, methods and standards. You might just have saved a little bit of time using tables for something, but that time is going to be spent later on fixing your tables for newer browsers (or devices).
Come on man – there is probably a great reason for you guys to choose to use tables (deadlines, cost etc.) but that doesn’t make it right. It’s a lousy compromise that’s going to come back and haunt you later on.
Samuel
on 04 Feb 09You guys in US are probably unaware of this, but it’s a shame Basecamp is pretty much useless on mobile use due huge download times and badly rendered table layouts. I don’t see why should I shell €15 for Outpost.app for example just to be able to manage stuff on the road. Not to mention our symbian users with even smaller screens. And believe me, this is an issue which will not fade away.
To me it’s not about “CSS puritism”, just common sense and not developing web apps like it’s still 2003. It’s a shame you guys don’t see this. But we’ll switch of Basecamp & 37s apps as soon as someone better comes available. And that time is not far.
Ben Darlow
on 04 Feb 09Translation:
We don’t test for accessibility, but it works anyway; therefore we must be doing it the right way.
37signals: we’re right because we say we are.
John
on 04 Feb 09I used to be a purist, but then I got a boss who wanted things done on time.
Anthony Green
on 05 Feb 09Companies should also give careful consideration to their responsibility to provide accessble access to websites under whatever disablity discrimination laws apply in their country.
Target’s failure to do so cost them 6m:
http://news.cnet.com/8301-1023_3-10028109-93.html
hmpf
on 05 Feb 09http://news.cnet.com/8301-1023_3-10028109-93.html…
Sorry, but that is dumb…
i know it sucks that it did’nt work for them, but now their able to claim money for being blind. My wife was just laid off by Target, perhaps if the greedy blind people didnt file this suite and waste tons of Target’s money on attorneys as well as having to pay this jackass lawsuit she may still HAVE A JOB.
Oh never mind that we can’t afford to feed our kids now, some blind guy can get some income cause he could not read a website… fucking amazing!!!
tre
on 05 Feb 09For the folks that are adamant that anyone using tables for layout is using the “language” incorrectly, and anyone else that is firm that the “specs” and “semantics” are the holy grail of web development - I hate to break it to you, for real world websites - it doesn’t make much of a difference.
We all know the reason why - browser’s still do not render CSS layout the same way - and it may never will. Name one browser that renders 100% according to the latest XHTML and CSS standards. It doesn’t exist—it’s all theory.
We don’t build theoretical website / applications for theoretical audience - we build for real ones. And I can tell you, the average user is NOT running your website code through the W3C validator - if it shows up fine on their browser, they don’t care. That’s reality.
MySpace, Google, Facebook—all high traffic and successful websites and applications with hideous front-end code. I don’t know anyone who’s stopped using any of those services because any of those sites had X number of validation errors.
For the record, I prefer pure CSS layout - but guess what, I know the only people who give a shit about my code - are other front-end coders, not the audience they serve.
Get real (no pun intended).
Chris Carter
on 06 Feb 09Can anyone provide an example (as in, something that actually USES it) of another application using a web sites semantics rather than a provided API?
I mean this as a serious question. And I don’t mean just trite anecdote, I’d like a link to a functioning, well used example. I’ve been hearing the “semantic web” thing for some time now, and other than a cool fake video from Adaptive Path about the “next generation” browser, I haven’t really seen anyone doing anything with it. Except spending 2 or 3x longer getting a “perfect” design in place.
I bought into the whole standards-at-any-cost movement a few years ago, and I consider myself reasonably accomplished with CSS, but frankly I gave up on perfection and settled for getting the job done when I spent too long fighting the *$#x%x browser implementations. And yes, I do test in multiple browsers/versions/OS’s, that’s half the reason it took me so long – I was trying to get the standards to behave across non-standard browsers.
Not to rain on anyone’s parade, or marginalize the disabled, but most of the folks out there tossing the ivory tower standards-adherance aside are businesses that need to bring in some revenue. If accessibility is a requirement (which it sounds like for UK business it may be), then it will get taken care of
Otherwise, I'm sorry, but accessibility falls within the same column as localization - "nice to do, but we have to justify the additional resources with an increase in revenue".Anthony Green
on 07 Feb 09hmpf
I suppose if you wife had worked for John McCain and had just gone laid off it would because of ‘greedy black people’ wanting the right to vote.
Yor right unbelieveable.
This discussion is closed.