A specified set of columns and rows with cells that automatically and fairly smartly expand to fit their contents; cells can span rows or columns; the table as a whole can be treated as one block, and cells can contain tables. A table is a metaphor for visually laying out 2-dimensional content.
cascading style sheets; not floating divs, not any specific markup, but just the concept of the visual display of markup specified by a series of rules that are kept separate from the markup they operate on, generally in an external linked file or a style tag in the head of the document.
Talking Past Each Other
CSS is (for various reasons cited elsewhere ad nauseam), in most cases, the more optimal technological approach. That’s not to say that the existing state of the CSS language is perfect. In fact, even the most vocal CSS advocates regularly assert that there are deep problems with the existing spec and browser support.
Tables are (for various reasons cited elsewhere ad nauseam), in most cases, a more optimal metaphor than any of its rivals. There’s nothing inherently wonderful about the tags themselves. In fact, even the most vocal table advocates regularly assert that the markup is ugly.
Therein lies the crux of the problem. CSS is a great technological approach, and tables are a great metaphor. The question then usually becomes,
Should I mark up my content using , which really means,
<div> tags or
Is the separation of style from content more or less important than using the optimal layout metaphor? The debate goes a little like this:
This layout metaphor is better, so you should use these tags. All you idealists are unrealistic! (Also, if you think markup matters, you believe in fairies. It so doesn’t!)
Metaphor shmetaphor! You don’t care about the sanctity of data or code quality. Think of the maintenance! (Also, if you can’t do it with divs, you’re stupid. It’s so easy!)
The Right Answer, it would seem, is to use the table metaphor with the CSS technology. In the ideal world, you’d always mark up your content using the tags that would communicate your meaning most clearly to your intended user agents. Then you’d tell user agents how to treat those tags visually. To describe this visual display, you should be able to use the table metaphor, or the float metaphor, or absolute and relative positioning, or anything else, but that should not be done by your markup.
In the real world, it’s not so nice. The CSS specification has a set of display values designed to mimic the table tags, but they aren’t well supported, and anyway, it’s an imperfect imitation of a hack that was not really intended to be used the way we all ended up using it.
In other words, CSS is not an ideal example of what CSS aims at, and the table/tr/td tags are not an ideal implementation of the table/grid metaphor. CSS tables, though they are clever and in some cases quite useful, take it from bad to worse.
The state of the CSS art is not at a point where you can realistically expect to make any significant stylistic changes to your pages without altering the markup. If you need to move the navigation bar from the right to the left, or re-skin the page with dropshadows instead of rounded corners, or convert your gradients from 2-tone to 3-tone, or make your boxes vertically centered instead of top-aligned, you’re probably going to have to change your markup, at least a little.
In theory, it’s possible. I know a handful of my colleagues will vehemently disagree and point at countless approaches to enable virtually any kind of reskinning using only CSS changes. (I’ve used Leslie Sommer’s CSS Mojo technique to great success in the past; we used it for pretty much everything on Yahoo! Buzz.) But let me tell you, from years of experience building production sites with CSS, most of the time, in reality it just doesn’t work that way.
And why should it? What kind of crazy lunatic writes all their HTML by hand in text files, anyhow? Clearly you have some kind of back-end engine spitting it out from templates, so you just change the template, and voilà!, the markup is changed everywhere.
A Very Blue Bike Shed
Working at Yahoo, I’ve met some webdevs with truly incredible CSS ability, who crank out live code under real deadlines to exacting standards. They use CSS, and not tables, and they Get Shit Done. There are a lot of them, more than I can list here, but Nate Koechley, Matt Sweeney, Hedger Wang, and Leslie Sommer all deserve a special mention. I came to Yahoo knowing CSS pretty well, but I became an expert largely as a result of working in such a highly skilled community of developers.
Also due to my time at Yahoo, I’ve seen some absolutely crazy debates about markup and coding standards on the devel-frontend mailing list. I mean, you think this little flare-up in the blogosphere is anything? You got no idea, buddy. Seriously. And these are coworkers who (for the most part) really like and respect one another.
You wanna know a secret? It makes no difference.
Language is as language does. If everyone uses the
<table> tag for markup, guess what happens:
<table> is now a semantically meaningless (or at least, semantically vague) tag, and any user agents that might care about navigating tabular data have to deal with that fact. It becomes just another
<div>, for all intents and purposes, but a little less flexible, and with a default styling that makes it handy for layout.
The passion for the rants comes from the fact that it is meaningless! Of course it’s a fertile ground for bikeshedism!
That’s right: It doesn’t matter.
Use whatever tags work for you. I don’t care. You’ll still be a good person.
Write code that you can maintain, that is flexible enough to let you change it without sacrificing the stability of your product. Test it in the user agents that you expect to support. Stop debating the color of this bikeshed.
If there’s ever a good reason to go back and change your tables to divs, or vice versa, you can do that. Hell, plan for that, because whether you use CSS for layout or not, you’re going to need to touch your markup sometimes. It is much much harder to build a product people want than it is to build a product that works in Browser X.
David Spade will forever have a special place in my heart for what he did in the movie Tommy Boy. I’m not sure if it was his creation, but in that movie, Spade delivered a line that added one of my favorite words to the english language:
My fellow nerds and I will retire to the nerdery with our calculators.
I saw the movie back in high school when it was in the theater. Immediately—I mean, before we had gotten out of our seats—we were using “nerdery” to refer to our pack of nerds . It’s like there was a linguistic void waiting to be filled, one that we had somehow never noticed before, and that term came to our rescue, identifying and defining a concept that we all knew but could never properly articulate.
It’s interesting that he’s clearly talking about a location in the quote, and not necessarily a pack. Nevertheless, the longing for this term is clear in the fact that literally every single person I know has exactly the same concept of what it means , despite having grown up in different parts of the world. That’s pretty rare for a concept so squishy, even if the term is only 13 years old.
Nerds are humans, and humans travel in tribes. Nerds may fail at popularity, but the human qua πολιτικὸν phenomenon is inescapable. We are social creatures, by our nature. You can’t keep up with it all on your own, which is why your lazyweb is smarter than google.
It’s kind of easy bait to just say that nerds fail at people, but to stop there is missing the point . The lack of popularity doesn’t change the need for polis; it simply changes the types of people that nerds tend to associate with. Given the right conditions, we clump together, and form nerderies.
If nerds didn’t need people, we wouldn’t clump. We’d all be loners. And really, deep down, we’re not, no matter what we may tell ourselves.
You can do things with a nerdery that you can’t do alone. Hacking on your own can be fun, but no matter what it is, projects really take the fuck off when a few heads are working together. That’s how you get explosive momentum. No matter how smart or driven you are, you cannot do it alone. The genius of the future stands on the shoulders of everyone.
In high school, I was a part of a quality nerdery. We were the kids who sat in the back of the class in AP Calculus, who stopped doing homework so we could study harder and get a 5/5 on The Test. We made web pages and played dungeons and dragons. We ran with the artists and freaks.
But it was high school. Things were awkward and weird. We knew each other too well, and yet not at all. After graduation, I fell out of touch with most of those guys. Maybe there was a really strong tribe there, and I was just never quite in it. Or maybe we just grew up, and our interests diverged.
In college, I lived in Neff Hall, the designated geek dorm. It really was. The top two floors were even preferentially assigned to Honors College students. In my second year, we reached Critical Mass. We were a tribe, Tre Neff. We had a call. We organized acts of benevolent mischief. A decade later, I follow a bunch of them on twitter, and comment on their blogs. I moved to California with one of them, and we all know each other, an extended family of sorts.
Connecticut is beautiful, and great for a lot of things. I’m glad to have grown up there, and I would recommend that anyone spend their college years in New Haven. But it’s a terrible place to be a grown-up hacker. When I moved out to San Diego, I was sans-nerdery. Lone wolves catch no caribou.
Transporting my tribe to California was a pleasant fantasy, but not realistic. They all had their own lives. Some of them moved to Boston. Others were still in school in New Haven or elsewhere. Wasn’t gonna happen. Even if we were all local, we’d grown up, and we weren’t into the same things any longer. We were still friends, but not a nerdery.
So, that meant building a new one. When I got a job at a little windows shop, I thought
Well, a nerdery just kinda happened in high school, and another one just kinda happened in college, seems reasonable that I’ll find one at a software company. Lotta geeks there. Ha. How very naïve. My god, we do fail at people.
There were about 30 people at that company, and I did meet more nerds there. A few became friends and are still. But somehow, it lacked cohesion.
One day, a woman named Amy emailed me about a position at Yahoo. I interviewed, and an invitation to the technopolis fell into my lap. 3 years later, I’m still here, and my unwillingness to leave has even attracted some attention, temporary though it may be.
Stars and Nets
I’ve met a lot more high quality nerds here at this company, more than I can link to in one sentence. Since moving to Silicon Valley, I’ve also found other hacker groups and interest meetups and so on.
For whatever reason, it seems like only about 10% of the people we meet have friend potential, and only maybe 10% of those fall into the right blend of coincidence to actually result in any kind of useful relationship. Maybe these numbers are skewed down by the fact that I’m talking specifically about nerds, but I suspect that, for anyone, the vast majority of acquaintances and colleagues never make it to “friends”. There are only so many hours in the day, and relating takes time. We are limitful creatures.
Nevertheless, that 1% turns out to be quite enough, if you’ve got access to a big enough population. It’s quite helpful to start out at a large software company or a college that attracts technical talent. It’s easy to meet a few like-minded friends if you are exposed to a few hundred likely contacts. I didn’t realize at the time that the difference between college and that first software company was mostly scale; 30 employees vs 30,000 students. (It was a state university—at a place like MIT or Stanford, the pool would probably not need to be so large.)
Cohesion happens in the progression from “star” to “net”. In this extremely technical diagram, the red dots are people, and the blue lines are relationships between them. A person’s group of friends and associates starts out as a star. We relate to people who might not relate much with one another, and who have associations with other people outside the group, that we don’t know.
The ideal net is where each of the points interacts with all or most of the others. That’s where the good stuff happens. We can spend less time relating, and get more value from it. See how all the blue lines cross over one another? Ideas flow across those channels, and they pollute one another as they bounce around. Conversations produce accidental ideas, and the more collisions, the more accidents are liable to occur. Nets tighten. Things get caught in nets. Tasty things.
I suspect that a functional group also can’t really be without a function. It has to start as bonding over some purpose, or else it just doesn’t get there. It’s hard to organically attract the right blend of skills without some need for those skills.
The way to get from star to net is just to get bigger. Meet more people, stick with the ones that seem the most interesting. As the star grows more dense, the spokes bump into one another, and it collapses in gradual steps. At some point, it’s ripe for being drawn together by some unifying project or task, and the right members join together to make it happen. Some pieces fly off, and the rest is pulled into the new shape.
The best communities organize themselves.
- For the sake of brevity, I’ve skipped the tired and boring “nerd vs geek” semantic hair-splitting. They mean roughly the same thing, depending on who you ask, and that’s not what this is really about, anyhow. #back
- A friend of mine pointed out that “nerdery” is like “club”, in that it can both refer to the location where the group congregates, as well as the group that congregates in the location. Seems reasonable. #back
- It is not my intention to imply that Paul Graham’s nerds essay misses any kind of point. He does some very good analysis of the reasons behind the phenomenon. #back
Until recently, I was spending a lot of time building one brand site after another. There’s nothing at all wrong about making a big deal and then building a one-off site. We were making money doing this, and making money is what a company is, ultimately, all about. Anything else is irresponsible and rather mean to our stockholders. As a stockholder, I am quite personally vested in Yahoo’s financial behavior.
However, as a web developer, our extremely short timelines were rough, and didn’t allow any time to re-think the approach and come up with a more sustainable plan. When the plan was, “We’re going to do a few of these, and then reevaluate, and build a platform,” it was fine. But changes in leadership (and accordingly, changes in strategy) led to a change in direction for our team. At least in the near- to mid-term, we would be continuing to build these sorts of (largely, very successful) branded world sites. After all, if a team of 3 can deliver on a high-six-figure deal in 2 weeks, well, that’s the kind of gravy businesses dream about. Again, as a stockholder and an employee of this company, I think that’s great. But this project certainly didn’t scratch my itch as a developer, and the stressful timelines were making me a bit crazy. I literally had nightmares about these sites.
The problem with working hard on a team of dedicated engineers is that it can be hard to fail. How can you hope to learn what’s wrong with your process, if it keeps working? Is there anything wrong with a process that keeps delivering on its promises?
Sometimes, yes. And a good old-fashioned wallop of a failure is traditionally what sets a product back on track. However, without too much back-patting, the team that I was working on was completely stocked with talented and dedicated engineers who simply would not allow failure to happen, even if it meant working late nights and weekends. The result? We worked late nights and weekends, and stressed out over these projects. This wasn’t the project we agreed to work on, and we were getting a bit fed up. The burn-out was starting to set in. More than once, my wife got exasperated with me over my lack of enthusiasm about anything. The body’s natural defense against being over-worked is to let all the energy go out of the machine.
Luckily, I work at one of the best companies to work for, and the management here always astonishes me. Despite the endless seas of cubes, this is not a Dilbert-esque code factory where engineers’ souls are systematically crushed. Starting today, I’m working on a new project (which I don’t think I can talk about yet, but I will as soon as I can,) and the work of cranking out brand sites is already being distributed in a more sustainable fashion.
A message to companies out there: Don’t eat your brains. Your talented workers are what keep you in business. It is your responsibility to use them, and push them, and guide them in productive directions. But don’t kill the golden goose. Yahoo probably extended my employment here considerably, and certainly increased my morale greatly, by just finding something else for me to do. Just ask them now and then what they want and how they feel about what you’re doing, and you’ll probably find that they could be even more valuable than they are.
For the last several years, there’s been a lot of talk about why web standards are generally a good thing. And I agree with the vast majority of it. Writing clean code that sticks to a widely accepted standard is a very good way to help the future programmers who will invariably be touching your stuff once you’re gone (or yourself fixing a bug next month or year later.) In this sense, web standards are a sort of “kindness in coding.”
However, as with the OOP zealotry that started 20 years ago and is still going strong today, this set of very useful guidelines has turned into a movement. It has gained enough followers and momentum, and in many cases, seems to have become and End In Itself.
Movements are like organisms. They survive because the cells that make them up all continually and unthinkingly chant the mantras and make the arguments. Ideas can be good. Critically examining them is good. Being passionate about a good idea is good. But movements, more often than not, become problematic.
Software is the most complicated thing that humans build, and we haven’t really figured it out. You could even make the argument that we probably never will fully figure out how to create software in a way that doesn’t suck to some degree. That’s not to say we don’t create some great software, great websites, great programs, etc. But there are always bugs, and delays, and general chaos along the way, and I believe that there always will be. The process involves an unknown number of unknowns. Software is more complicated than the human brain can handle, and that’s the only kind of brain that we have.
So, how do you solve a problem when you don’t know all the factors, and only have a vague idea of what success looks like? It’s like climbing a mountain when you can’t see the top. You can still see the slope, and can occasionally get glimpses of where you’re going, or at least, you know that it’s higher up. If we are to approach quality software, then we must treat this exceedingly complicated problem in a manner that at least approaches quality heuristically, perhaps organically.
Software is a process of making decisions, and then codifying and saving those decisions. Bad decisions must be pruned ruthlessly, and good ones must be recognized and reused. In a general sense, this is the heuristic that leads to quality software (or quality anything for that matter.) The question of what makes a decision “good” or “bad” is itself a decision that needs continual evaluation. And that’s where movements get into trouble.
It’s easy to say,
If it conforms with the w3c’s (or Microsoft’s or whoever’s) standards, then it’s good. I think that this might be a good start, but it’s basically an argument from authority. The w3c is a group of humans. So is Microsoft. Humans make mistakes, and have plenty of limitations; that’s why we need a heuristic in the first place.
It’s also easy to say,
If it loads fast and looks right, then it’s good. Sure, but how easy is it to debug it when it doesn’t work as expected? Can new developers add to it easily? Is it expensive to maintain or re-purpose?
Or, even worse,
This was written in (Rails, VB, Django, PHP, C#, valid CSS) so it’s good. I think that a lot of the worst examples of Microsoft horrors were the result of a fanatical attachment to Visual Basic. I’ve seen (ok, “written”) some terrible CSS that was, nonetheless, technically “valid” according to the W3C’s validator.
Sadly, most developers judge decisions based on their feelings rather than any kind of objective analysis.
I wrote this, and it’s clever, and it makes me happy, so it’s good. There is no surer way to end up with a pile of garbage than this approach. It’s hard to let go of something that you worked on, and coders are certainly not the only culprits. I’ve seen execs spend countless hours on a deal that never yielded any value for the company, and designers fight tooth and nail for a visual approach that just didn’t work. Hell, we all have a relative or two with a recipe for something that they love, but which everyone knows is terribly bland.
It’s really really hard to let go of this emotional attachment to work. The reason we feel good when we succeed is that our emotions are attached to our work. It’s why I get up in the morning. But it’s better to attach your feelings to how harsh you are on your code. Understand that we all write terrible code, but that the difference between bad and good is that good coders recognize this fact and deal with it.
Because of the incredible complexity in software development of any kind, there simply is no room for mindless zealotry or attachment to a movement. Every project, every site, every module is a little different, and has a slightly different standard of quality. (Even the rule “always head upwards” doesn’t work for climbing all kinds of mountains.) Keep the goal in mind, and think about the best way to get there. Sometimes it’ll be the accepted standards, hell most of the time it probably will be, but sometimes it might not. It’s our job to know the difference.
Every once in a while, take a moment to re-evaluate your methods for evaluating the quality of your code. You may have to let go of something comfortable, and it may sting, but in the end, you’ll be better at what you do.
This is a comment on the A List Apart article, Evangelizing Outside the Box: Web Standards and Large Companies, by Peter-Paul Koch. I posted the comment on their site on June 04, 2007.
Yahoo is a huge proponent of web standards, for very pragmatic reasons. On most teams, you can’t get hired as even a junior web developer without a solid background in standards and CSS. At the same time, we host countless 1990-style table-based layout pages, and most of them probably won’t be changed any time soon. And yes, some of our internal web apps are simply godaweful.
The all-too-common focus on refactoring legacy pages is misguided and hopeless. There is little, if any, benefit to make up for the herculean effort. However, web companies are typically in the business of creating new pages, and this is where the standards movement should move. When an old system is refactored, it’s often a wholescale redesign, and that’s when a proper approach should be used. Extending a system should almost always use the language of the existing system, and sometimes, yes, that means that you implement the 254th page as table-soup so that it matches the pattern of the other 253.
When it comes to new development, it’s a much easier sell. First, you say, “I’m going to implement this using web standards because it’s better.” (Or don’t say it—just do it.) If that doesn’t work (and it usually does), then you point to the huge sites that have used web standards to great advantage—sites like Yahoo, Blogger, ESPN, and others. Talk about their agility, their reach, how this is the new standard. Get involved in the hiring process, and try to hire developers who know about standards. (Usually they’re the best choice anyhow.)
If that doesn’t work, then build a resume in modern HTML and CSS, put it online, and get ready to move to California. (Seriously, as more employers move to using web standards, it’s getting harder to find good web developers these days. You’re valuable!) As more standards-using webdevs reach career-maturity, web companies will necessarily shift in that direction, and devs who don’t use these methods will find themselves working somewhere else.
Lastly, please, abandon the religious viewpoint. Software is the art of effective trade-offs. It’s not math, and there is usually not just one right answer. It does so happen that web standards can be leveraged in many cases to make a big profit in time, effort, and features, but if you’re in this business long enough as one of PPK’s “invisible professionals,” you’ll eventually find a case where you need a layout table to achieve a certain effect, or where a table-based approach is faster/easier/more maintainable, and the costs are reasonable. W3C approval doesn’t not make something necessarily a good method. If you’re going to be a zealot, be a zealot about writing high-quality code—usually that means standards, but standards are not a valid end in themselves. I feel like blogging a big fat rant when I can’t buy movie tickets on my Blackjack, but web standards zealotry is perceived as naive and misguided by managers and customers alike.