[whatwg] Quality Values for Media Source Elements

[Aryeh Gregor]

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.