Greg Reimer's Weblog: Web Technologist for Sun.COM Web Design

Not a good way to make friends. This is like saying, "go away, we don't want you" or, "we only want 93% uptime for our website." I think the business case for this is rare indeed.

I like this approach the best. This is known as the "progressive enhancement" method, and it's the best way to build bullet-proof websites in the modern age.

Still not very friendly. This is marginally better than blocking access to the whole site.

Workable, but inefficient. <noscript> functionality is really a suboptimal solution, since it requires you to basically code your functionality into the page twice.

Possibly confusing. Not only do visitors not get the functionality they were looking for, now they're confused as well, without any explanation of why it won't work.

Maybe not the best, but it's an option. JavaScript offers a lot of capability that has come to be expected on the web. Your site might seem outdated without it.

Not a very good approach, IMO. This is the classic mistake of mixing content and presentation. For example, if you want to switch to "orange" instead of "green," then your CSS will have to change from span.green{color:green} to span.green{color:orange}, which is, well... weird.

I overwhelmingly prefer this approach. This allows the utmost flexibility in evolving the presentation and behavior layers independently of the content, plus it has a self-documenting effect on the HTML source code.

Run away! Run away! I hesitate to say that any one development approach is evil, but this comes close. HTML elements such as <h1> have a structural meaning used by search indexers and user agents of all kinds. Breaking away from all but ultra-generic generic <div> and <span> tags breaks searchability and accessibility, as well as the ability to meaningfully syndicate your content via RSS or Atom. It prevents use of your content in ways that you don't anticipate, and in contexts that you might not have considered.

My opinion: this is a nasty, outdated way of doing things that needs to be euthanized ASAP. It's the most prevalent method as of 2007, but mixing scripting commands with HTML is just as bad as mixing presentational commands with HTML, and for the same reasons. Presentation should be removed from content via external CSS files, and behavior should be removed from content via external JavaScript files. Even if it seems justifiable to throw in a quick onclick="" attribute for convenience's sake, it risks getting accidentally overwritten by more sophisticated event attachment methods that deploy via external scripts.

Better, but still nasty, IMO. This method is a vast improvement over inline event handler attributes such as <a onclick="">, but it still only lets you assign one event handler per element, and succumbs to the common problem of events being accidently overwritten, since there is only a single onclick property per element.

My personal favorite. Event attachment lets you assign an arbitrary number of events to the same element. This is especially useful for the window "onload" event, which often needs to spawn multiple actions.

I think this is only partially true. The problem is, as a philosophy, "to add interactivity" doesn't go to the root of the issue. This definition, however, is a sufficient one for those not involved in architecting the front-end.

This is where I set up camp. This way of thinking about JavaScript is now emerging as the Way of Enlightenment, often dubbed "Unobtrusive JavaScript." The web consists of three layers: Content, Presentation and Behavior. These correspond to HTML, CSS and JavaScript, and it's best to keep them separate, living in separate files. The HTML layer is considered the base-functionality layer, and the other layers are considered the enhancement layers. It's a very elegant paradigm.

True, but it doesn't really get us anywhere. While not incorrect, I don't think this distinction is the most significant or useful way of thinking about JavaScript. Perhaps this definition is popular because many programmers code mainly for the server, and tend to contemplate JavaScript in comparison to that task.

As I see it, this is the underlying philosophy of CSS. With CSS managing the details of the presentation, HTML can shed the presentational encrustation it developed during the browser wars, making it more concise and powerful. There's a term for this: Plain Old Semantic HTML, or POSH for short. POSH is easy to produce, maintain, style and script against.

Yes, but I'd clarify this one thing: HTML wasn't supposed to be a visual formatting language in the first place. In fact, the world's first web browser, which Tim Berners-Lee wrote in 1991, actually used stylesheets for the specific purpose of handling presentation. Subsequently, HTML got hacked into the role of handling the presentation during the tumultuous early evolution of the web.

I would somewhat disagree with this for a couple of reasons. A) CSS was meant to control presentation in more than just visual media. For example it can control Aural and Braille presentations. The visual (screen) medium just happens to be the most widely-adopted way of using CSS. B) CSS doesn't necessarily give better control, so much as a better means of control. For better control, we'll have to wait for future versions of CSS to be finalized by the W3C and implemented by browsers.

I would disagree with this. In my experience, if a visual designer is writing CSS, they must understand HTML on a very deep level, and will almost certainly have to muck with the HTML. If, on the other hand, a visual designer is just designing in Photoshop and handing off bitmap comps to front-enders, then CSS is irrelevant to the visual designer anyway.