Over the past year or so I’ve come to realize that getting the markup right is the most difficult part of building Web applications. Had you asked me back a year ago, I’d have guessed that working with JavaScript was the most difficult, but now I know better.
Server side development is in many ways the easiest. For one thing, the tools are great. These days it’s easy to set up a full server environment on your laptop, and the tools for working with code are incredible. Whether you’re a Ruby developer working in Textmate or a Java developer working in Eclipse, NetBeans, or IDEA, the tools are out there to amplify your productivity. The pace of innovation in the server space is incredible as well. Good ideas are being transported from one platform to another at an incredible pace. (Ruby on Rails stole just about everything good from the Java stack, and now the Java folks are stealing all the good ideas they can from Ruby on Rails. PHP is benefitting from both as well.)
The most powerful advantage of working on the server, though, is that it’s empirical. Does this SQL query return what I expect? Does the markup emitted by this method look like what I think it’ll look like? It’s easy to answer these questions, and it’s advisable to write automated tests to verify that the answers to those questions haven’t changed.
JavaScript was once painful to write. You had to write a lot of code to accomplish simple things, the JavaScript implementations varied widely between browsers, and it was difficult to debug your JavaScript code. Most people got by on scripts of dubious quality that they copied from other web sites. Two things have changed, though to make life much easier for JavaScript developers.
The first is that there are now a number of incredibly powerful JavaScript libraries available. They make it easy to accomplish big things with just a little code, and they abstract away the browser differences that made programming in JavaScript so difficult. The second is that the tools have gotten better. FireBug brings a lot of the key features of a good IDE to Firefox. Having a real debugger is a huge help in working out where issues lie in your code. (You can only take window.alert() for so long.)
These days, I find working in JavaScript to be a pleasure, and I never thought I’d say that.
That brings us to HTML and CSS. Given a design, I’m starting to find that it’s not even possible to guess how long it’ll take to get the design to work across all of the common browsers in use today. Generally, I leave the markup to the experts, but for the past couple of months I had to delve deep into CSS and HTML myself. The first thing I discovered is that even making simple stuff look the same in Internet Explorer 6 and Firefox is a challenge. The next thing I learned is that it’s not even easy to make things look the same in Internet Explorer 6 and Internet Explorer 7.
When I went to people who know a lot more about cross-browser issues than I do, even they had to do a lot of experimentation to get things even close to looking right. And the secondary problem is that there don’t seem to be any sort of systemized tools or techniques to make any of this stuff much easier. Yes, FireBug is essential (how else are we supposed to know when styles are being overridden or aren’t being applied), but it seems like we need a lot more help if we want to make writing markup easier.
Is it really as bad as it seems, or am I missing something here? Because it sure strikes me as a rough time if markup is your medium.
March 26, 2008 at 9:55 pm
I’m knee deep in HTML and CSS every day. And your right it can be a pain even if you do it every day.
IE6 is the biggest offender and matching IE6 and anything else is often the hardest.
I think it’s bad to complain about the code between IE6 and IE7 though as the IE team made so many advances in IE7 that it’s better not to hold them to the past.
The problem can also be even more fudemental. The things that baffles me is always how even the same version of FireFox can look really different between windows and linux.
I think until the W3C gets it’s act together and browser makes get in the habit of releasing complete, bug free HTML upgrades then this problem will consist.
But if HTML 5 comes out and browser makers still only add parts of it then this problem will continue.
I have not heard a good answer about why it’s so hard to just get the spec right. I know partly it’s that the W3C did not do a good job of being specific. I personally think the HTML is also so sprawling and large that they can’t find every bug before a final release.
And then who knows how much backwards compatibility comes in to play. You hear the IE team talk about it a lot but not as much from the FireFox, Opera and Safari teams.
March 27, 2008 at 7:03 am
Heh. You’re the second programmer I’ve heard say such a thing this month (the first was Simon Willison at SXSW). I hope the folks signing the checks are listening! 😉
March 27, 2008 at 11:27 am
We’ve found that the YUI Library CSS (Reset, Base, Fonts, Grids) helps us deal with browser display issues. http://developer.yahoo.com/yui/
March 27, 2008 at 9:00 pm
I have also found quicksmode.org very helpful when trying to determine behavior or implementation differences between browsers.
Generally I write things to work in Firefox, then correect things that are broken in IE. That’s been easier than the reverse.
March 28, 2008 at 1:02 am
<p>JOS has a great post on <a href="http://www.joelonsoftware.com/items/2008/03/17.html" rel="nofollow">why W3 standards are doomed</a>.</p>
<p>Essentially, the web started off on the wrong foot. Invalid markup <em>should</em> have been punished by the browsers (mosaic, et al) and not rendered at all.</p>
<p>Instead, they guessed and made up for sloppy coding. Today, we have most of the internets running invalid markup (don’t believe me? just add the <a href="http://users.skynet.be/mgueury/mozilla/" rel="nofollow">html tidy extension</a> to Firefox and watch it while you surf. You’ll rarely see the green ball.</p>
<p>If MS (or Mozilla) tried to release IE 8 or FF3 with the "code it correctly or forget about seeing content) attitude," no one would use that browser. Users don’t care about markup, as long as the website "works"; the people who care–those of us who have to code the stuff and deal with browser incompatibilities–are punished, but nobody cares about us.</p>