rc3.org

Strong opinions, weakly held

Tag: Web development (page 4 of 4)

Links for April 6

  • Daring Fireball: Firefox 3 vs. Safari 3. The main sense I get from this review is that I could be getting more out of my Mac.
  • Jason Kottke: Getting into Momofuku Ko. How this small but incredibly popular New York restaurant handles reservations using a Web application. It sounds like the basic model works like Ticketmaster.

There would have been more links in this post, but I’m too old for dangerous sweatshop blogging. Also, people get paid to do this?

HTML really sucks right now

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.

Links from March 18th

  • The senselessness of war: A World War II German fighter pilot just learned that he shot down and killed his favorite author, Antoine de Saint-Exupery, who wrote The Little Prince.
  • Dave Shea on Mediatyping. Presenting the right markup for the user’s device.
  • John McCain seems to have run into the Shiite/Sunni confusion that plagues so many politicians. There’s not really much room for confusion here, and you’d think the senior Republican on the Senate Armed Services committee would have this down pat by now. This wasn’t a gaffe by the way, it betrayed a fundamental lack of understanding of the situation in Iraq and in the Middle East. I really want the person who gets “the call” at 3 a.m. to know that al-Qaeda is a group of radical Sunnis who are at war with the Shiite militias in Iraq that Iran supports. Heck, it would be nice if they knew that al-Qaeda in Iraq is not even formally affiliated with the al-Qaeda that attacked the United States on September 11, 2001.

The implications of IE8

Microsoft’s Monday announcement of the new browser compatibility features in Internet Explorer 8 has set of a torrent of commentary. They described their new approach to markup versioning in an article at A List Apart and on the Internet Explorer blog.

The basic idea is that Internet Explorer 8 will enable you to specify which rendering engine you want IE to use in a meta tag on your page. So you can tell it your markup is IE7 compatible, IE8 compatible, or bleeding edge compatible, in which case it will use whatever the latest and greatest rendering engine is. We can assume that IE9 will retain all of those modes and include a new IE9 mode as well, assuming that Microsoft doesn’t decide it’s too much trouble to maintain all of the different rendering modes and toss some of them out by then. If you don’t include the special meta tag to turn on IE8 rendering mode, IE8 will default to using the IE7 rendering engine.

I appreciate that Microsoft is trying to solve a tough problem here — not breaking the sites of people who have included hacks for specific versions of Internet Explorer while at the same time giving themselves the opportunity to fix bugs and add new features in the browser. I don’t know if it’s an elegant solution, but it is a solution to that specific problem. What I wonder, though, is what this means for Web developers. I imagine the question most developers are asking is, “What’s the most sensible way to write markup, CSS, and JavaScript in the coming browser ecosystem?”

Sam Ruby points out that any DOCTYPE that’s unknown to IE will be rendered with the IE8 rendering engine. So if you want to bank on the improved standards support in IE and avoid using the new meta tag, just pick a DOCTYPE that is correct but that IE doesn’t do anything special with. I have a feeling that’s the approach most standards oriented Web developers will wind up taking.

Those developers whose depends on specific quirks of IE7 will be able to force IE8 to render pages in that mode, and developers who code to standards can pick a DOCTYPE that IE will use to render pages in its newest, most standards compliant mode. That strikes me as a pretty reasonable workaround for the meta tag business, which I don’t see any real need for anyone to use.

The other question I have is how the other browser makers will react. Firefox and Safari seem content to keep improving the standards support in their browsers without dithering over breakage of older pages, but their situation is different than Microsoft’s. For one thing, they have always been significantly more standards compliant than IE, so they don’t inflict severe breakage on people when they change. Secondly, people rarely include Safari and Firefox hacks on their pages. They code to the standards supported by Firefox and Safari, and then include whatever hacks they need to in order to make their pages look right in IE6 and IE7. The developers of WebKit are not going to be adopting the versioned rendering engines approach IE is taking, and really there’s no reason to do so. I expect the Mozilla folks will say the same thing.

The specific bit of good news here is that it should free developers from adding yet one more browser-specific style sheet for IE8. Lots of people these days are using hackish workarounds to make sure their pages look right in both IE6 and IE7. When IE8 is released, you won’t have to do anything to make sure your IE7-specific code doesn’t cause breakage, the way IE6 code did in IE7. And it looks like there is a path to using the latest and greatest features without any of this meta tag foolishness. So I think it’s going to be alright.

There is a whole lot more on this topic just about everywhere, so much so that I’m going to punt on linking to all of the reaction. You’ve probably read it all anyway.

Newer posts

© 2024 rc3.org

Theme by Anders NorenUp ↑