- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Tue, 15 Dec 2009 09:52:31 -0500
On Tue, Dec 15, 2009 at 3:17 AM, Hugh Guiney <hugh.guiney at gmail.com> wrote: > Nor should it. But if you're doing something in JavaScript, there > *should* be a functional alternative in plain HTML when it's turned > off. Functional, sure, except where that's impossible (e.g., a client-side computer game) or you have good reason not to care (e.g., intranet app where you can require JS to be on). It doesn't have to provide all the same features, though. In general that's impossible, which is why we have script to start with. > I don't know that nobody *wants* to do that; I think most of them > simply don't know how. The ones who know how, or could easily find out, still overwhelmingly don't want to. > I don't think it's a square wheel. A square wheel wouldn't work. HTTP > CN works. The fact that people are willing to do something in HTML, > but are unwilling to do the very same thing in HTTP, seems to suggest > a lack of understanding of HTTP and/or its capabilities. A square wheel works, as long as you're willing to do a lot more work. HTTP content negotiation has the following problems compared to an HTML-based solution: * Authors already know how to edit HTML, since they need to for everything else. Changing HTTP headers requires them to also know how to configure their web server, or use a scripting language (which is harder to learn and much less performant than static resources). This makes it automatically harder to learn, which is bad. * Every web server is configured differently. There is no standard for configuring your server to do content negotiation (that I'm aware of). * Many users (e.g., on some shared hosts) don't have the ability to reconfigure their web server, or at least not easily. * Some web servers (e.g., lighttpd last I checked) require that the whole web server be restarted for any config change. * A solution in HTML will continue to work if you just copy the entire directory to a new server. The same is not reliably true of anything that relies on web server configuration. People avoid it for excellent reason. > This is a nice interim solution, but it also forces the user to > download a resource which may not necessarily be the most appropriate > version for them. Only if you use autobuffer, which you don't have to.
Received on Tuesday, 15 December 2009 06:52:31 UTC