Having not read the session description ahead of time, I was expecting this to be all about browser hacking in the narrow sense: specific tricks, workarounds, and hacks. Instead, it was a much more interesting talk about why this approach to feature development is vital to the web itself.

We are in the midst of an incredible acceleration in the variety of technologies vying to serve as our interface to the cloud. Dillard did a great job characterizing the forces at play (standard vs proprietary, open vs. closed.) He then explained the complicated role that technical hacks play in this ecosystem, since they can both allow developers to adopt standards before browsers support them, and at the same time push the standards themselves (treading dangerously in the territory of proprietary feature sets.)

His advice to developers boiled down to this: Don’t wait for standards, but hack as dangerously close as you can to the bleeding edge of where you think the open web is headed. The most valuable hacks are the ones that bring future standards to today’s (and yesterday’s) browsers.

Do Try This at Home: Ajax Bookmarking, Cross-site Scripting, and Other Web 2.0 Browser Hacks
Development, room 2003, Friday 3:50 PM
Brian Dillard (Pathfinder Associates)

My rough notes are after the jump.

Notes

Dillard’s slides are on SlideShare.

Open web vs. Walled Gardens. Huge movements on both sides of the arms race. Emergence of powerful walled gardens (Facebook, Silverlight, Flex) and also a massive rush to build the open web (four powerful minority browsers, OpenSocial, standards-based coding.)

Dillard is firmly in the open camp, but is pushing devs to try out all the newest implementations of standards, even if these are in minority browsers. Play in the tense space between actual standards and de facto standards.

There are good reasons to do this. Hackers push features. Here are some examples that grew in the wild:

• xmlHttpRequest
• DOMContentLoaded
• Selectors API
• Canvas supplanted SVG
• HTML5 Ajax Navigation (Dillard’s Really Simple History)
• Microformats

Standards are coming out from committee, too. But these are draft specs, and they’re really not that cool until they’ve been implemented.

Google gears given as an example of browser tech being pushed by engineers. It’s a complicated example, since this is proprietary tech in pursuit of standards. This is leading up to Dillard’s point.

Who will play a role in determining the shape of tomorrow’s web?

• Proprietary runtimes are pushing the edge with native UI integration
• Browser vendors and committees do their little dance
• Libraries (Prototype/Dojo) paper over the differences

Example of libraries doing this hard work?

• Offline storage can be done with Dojo Storage, which abstracts away any of a number of methods, depending on which is available (Flash LSOs, IE UserData, Gears, DOM storage, etc.)
• Aforementioned Really Simple History
• Cross-site scripting methods which might be insecure, but very useful. F3 cross-window messaging with HTML5 postMessage API, or xssinterface, a library that does whitelist cross-domain communication using postMessage, Gears, or a cookie hack. (Ha! He calls Crockford the “Nostradamus of web security”)

Best practices?

1. If you’re doing simple, try to use the draft-standard API itself.
2. If you’re building a higher-level abstraction, use draft standards when they’re available.
3. If you’re going for the big hack, follow the conventions of successful libraries. E.g. RSH actually just used UserAgent string instead of object detection, because it was driving them crazy and they found Prototype and JQuery doing it the simple way.
4. If you don’t need to rely on a specific JavaScript framework, don’t.
5. Make informed choices about joining the fray.

Be a part of the conversation

• Build plugins for popular rameworks. Solve a little problem well while looking to HTML 5. Other possibilities:
  • CSSOM (CSS Object Model)
    • CSSOM View Module
    • elementFromPoint for drag/drop
    • Feed it coords, get back a DOM node
  • Web Forms 2.0
• Participate actively in open-source projects. You don’t need to build a Gears module to use one.
• Get down and dirty with beta browsers. File bug reponts. Join forums. Blog about it.
• Read and comment on draft spects (okay, now we’re scraping the bottom of the barrel…)
• Vote with your feet. Use technologies whose philosophy you support.
• Become a beat reporter.
• Stay informed: Oversubscribe to feeds, then filter and skim intelligently (Dillard’s favorites: http://labs.pathf.com/ajax/web20expo/)

Note: all the big browsers now have great debuggers. Use them; don’t just develop in FF and then do last-minute checks in the other browsers.

The message: If you wait for Google, Prototype, the WC3 and Adobe to solve your problems, then you’re missing out.

Related Posts:

• FIle Upload Madness (June, 2007)
• Optimizing the Frontend (April, 2007)
• Factory Porn (November, 2007)
• New Web Inspector for Webkit Browers (June, 2007)
• Building the Facebook Platform (November, 2007)

This entry was posted on Wednesday, April 30th, 2008 at 10:45 am and is filed under coding, instructables, notes. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.