It's a good question, and the answer, I think, is entirely bound up
with pragmatism. It seems dubious that the very same group of people
who have managed to create the current divergent subspecies of HTML
and browser behavior will get it together to agree on a standard
mechanism to describe those differences.
As a server application software author, I would much prefer not
to have to grovel around building (and worse, maintaining) my own
database of browser capabilities, so I see it as very useful to be
able to get this information somehow automatically.
On the other hand, it is pretty ugly to have to consider this.
Certainly it has to be tied to a given content type, so we can
maintain the illusion ... uh, I mean perpetuate the present design that
HTML and HTTP are not inextricably linked.
> Supporting exact capabilities seems to make sense given the current modus
> operandi of adding new functionality to the web by incremental advances -
> a new feature is desired, a new HTML tag or attribute is defined. If
> this is truely the evolutionary path developers want to see HTML and the
> web in general take, then there's not much choice - we have to do it,
> elegance be damned.
>
More to the point, does anyone believe that things are going to be
less out-of-control or become somehow less complicated in the future?
I don't.
> Or, we could decide that HTTP negotiation + simple, solid,
> easily-implementable-to-conformance-levels MIME types provide a better
> evolutionary path, and avoid the cache-busting swamp of capability
> bitmaps.
>
I think we should separate content negotiation from the issue of
browser capabilities. Content-negotiation should be more for
user-preferences, presence or absence of certain helper apps, and
other coarse grained and dynamic decisions that occur at a fairly high
level. Browser capabilities are (a) certain to be too voluminous to
encode in anything like the Accept header mechanism, and (b) are
constant properties of given browsers (down to the platform and
version).
> Let's make a decision on this issue, or we'll be passing the buck until
> the whole deal is irrelevant.
>
> Awaiting the day when browsers aren't responsible for rendering, Brian
>
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> [email protected] [email protected] http://www.[hyperreal,organic].com/
>
It's never too late to procrastinate. Besides, I've heard it said that
programming is the art of putting off decisions until you no longer
have to make them. (To the irony-challenged: I'm joking)
--Shel Kaphan
[email protected]