Fotiman - 3:39 pm on Nov 15, 2006 (gmt 0)

I have to say that in the big picture, unobtrusive JavaScript is probably the way to go, but (maybe due to my ignorance) it still seems like the site owner will be forced to pay for more development time to implement a fully functional site for the visitors that choose to browse without using JavaScript.

I can understand why you might think that, but once you get in the habit of developing in an unobtrusive way I think you'll find that development times may even go down. This line of thinking might be true for "graceful degradation", where development prioritizes presentation, and then has to dumb it down. "Progressive Enhancement", on the other hand, keeps the content as the main focus, and then adds on enhancements. The content is what's really important anyway. Just pretend you're building a website for 1990 to start, and then enhance it once the content is in place. :)

Scalability: working from the lowest common denominator Maybe it is ignorance on my part, but it seems like there is a much bigger investment in time for a site that serves up a set of pages that will scale well on a cellphone browser and still look world-class when served on desktop PCs.

(same argument as above)

I would think it might be cheaper for the web site owner to pay for a different set of pages for the micro browser crowd. (My gut reaction to the current crop of micro devices is that they are "quaint", like a Commodore 64. However, it probably won't be long before they grow up, and then web developers will not only need to include them as the lowest common denominator, we will want to.)

It's quite easy to develop for the lowest common denominator. Just use pure, semantic markup to describe your content. The markup is the foundation. Start with a clean slate, and don't add any presentation (CSS) or behavior (JavaScript) until the core foundation is in place.

For example, suppose I wanted to create an article. The core foundation might look something like this:

<div class="articlehead"> <h1>Progressive Enhancement</h1> <h2>Easier Than You May Think</h2> <p class="dateposted">11/15/2006</p> <p class="author">Fotiman</p> </div> <div class="articlebody"> <p>...</p> <p>...</p> </div>

This is pure markup. From there I can add presentation and behavior. For example, maybe I want to add some special animation effect so that article body appears like a window shade (slides down). Instead of adding that script directly inline, I would keep my markup clean and just attach it via an external script. There was no additional cost to create the initial semantic markup, and now I've got something that works for all types of browsers and can be easily enhanced.

Separation of content, presentation, and behaviors is a good goal.

Cookies optional? What about the site visitor to your ecommerce site that prefers to surf with cookies disabled? I suppose there are ways to code everything server side, but again, this extra development time has to be paid for by the site owner - are they getting a smart return on their investment?

Typically, I think you'd be better off to use session variables instead of cookies. Session variables are basically the same thing as cookies, but they only last the duration of the session and are not written to a file. Users can disable cookies but still use session variables.

JavaScript: vital, fluff, or somewhere between? Why has it become best practice to build sites that will degrade gracefully in every respect if the user turns JavaScript off?

Ah, but it hasn't! Note, you said "degrade gracefully". Progressive Enhancement, though similar, puts the focus on the content first. Here's my favorite quote regarding Progressive Enhancement vs. Graceful Degradation:

These two concepts influence decision-making about browser support. Because they reflect different priorities, they frame the support discussion differently. Graceful degradation prioritizes presentation, and permits less widely-used browsers to receive less (and give less to the user). Progressive enhancement puts content at the center, and allows most browsers to receive more (and show more to the user). While close in meaning, progressive enhancement is a healthier and more forward-looking approach. - From the Yahoo article on Graded Browser Support: [developer.yahoo.com...]

What about the user that decides to turn images off or sound off or CSS off?

This is why you start with pure sematic markup. The site should still make perfect sense even when it can't be enhanced with CSS. And images should have alt tags so they can still be shown when the browser can't show images.

I wouldn't want to project manage a silent music site, or a text-based art site.

Why not? If the content is a picture of artwork, then provide pictures of artwork with meaningful alt text. For example:
<img alt="Painting of a rose" src="rose.jpg">

Just because the user can't see the picture, doesn't mean he/she shouldn't be able to tell what it is. Maybe you want to enhance the site so that the pictures appear in a nice slide show, but your core markup will still be accessible.

I just never understood why JavaScript seemed to be the first technology to be deemed "fluff" by many, and expendable. (Well, it may have been the first, but Flash fell harder.)

Probably because there are a larger percentage of user agents (web browsers, search engines, etc.) that have JavaScript disabled (or no JavaScript capabilities at all) than there are user agents that have images or CSS disabled. Don't think of it as fluff though... think of it as enhancement.

Again, this could be ignorance on my part, and there may be ways to code every site function on the client side without using JavaScript, and I just don't know how to do it. I'll give an example: I have an ecommerce site in progress where the user can search (filter) and sort (order) results. I give the user a primary and a secondary sort, presented in 2 clusters of radio buttons. When the user selects a radio button from one cluster, the illogical choices are disabled in the other cluster. This is done with a JavaScript function. With JavaScript turned off, the user could choose to order the results first by price descending, and second by price ascending. The interface thus makes no sense to the user - they don't know how the results will be sorted.

The interface still makes sense. But the user has chosen to make a selection that doesn't.

Of course, my program logic cannot allow a query like that, so I will force a default of ignoring the secondary sort. This happens in the background, and the user would not know why the results are not sorted by ascending price (which may have been his intent.)

If the user's intent was to sort ascending, then he/she should not have selected both ascending and decending. But lets go ahead and assume the user has JavaScript disabled, and that they suffer from a low IQ. :-) You could, by default, have a short paragraph of text to explain to the user what will happen if they pick 2 contradictory search parameters. The enhancement, then, would be to:

1. Add JavaScript to disable illogical choices
2. Add JavaScript to remove the explanation paragraph, since it's no longer needed.

This is not a vital, life-or-death example, but it is fresh in my mind. The only way I know how to do it client side is by JavaScript, and it seems like a crazy thing to do server side (which would probably be painfully slow on a cellphone browser.)

In this particular case, a simple explanation to the user what will happen if they make idiot choices should suffice. But you could also have the server check to see if the user made idiot choices and redirect them back to the form with a message that says "Don't be an idiot! You can't sort that field both Ascending AND Descending! Choose again!". If it's happening server side, it's not going to be any slower for a cellphone browser than from a PC browser, so I'm not sure what you mean by that comment.

Again, I would think that the decision to pay for the extra development time to make sites accessible on micro devices, or to remain "fully" functional without JavaScript, cookies, CSS, a video screen or monitor, would be a decision for the site owner.

And again, there is no added development time. It's a change in the way you handle the development process. By creating pure markup right up front, you're creating a fully functional site right from the start.