Re: Versioning and the end user

Preston L. Bannister wrote:
> Please keep in mind that what matters the most is the end user.  

In my mind, what matters the most is keeping the web usable and at the same time 
preventing any one entity from having a chokehold on the way people access 
information that has been placed on the web or the way they place information on 
the web.

Now this does mean that end users matter very much.  But so do content authors. 
  Almost as much, in fact.  And so does having more than one way to access data 
from the web.

> Standards and implementations are a means to an end, not the end 
> itself.

Agreed.

> Not breaking existing web applications is primary.

It's about as important as not breaking _future_ web applications.  Or more 
importantly as allowing said future applications to be created.  If the cost of 
creating a web application that works for most users becomes too high, I would 
say we have failed.

There is thus a fundamental tension between only having only one client (makes 
it easier to create applications) and not giving any single entity control over 
the web.

At the same time we want to allow innovation in the user-agent space.  For 
example, I'm still waiting for someone to come up with a good session history 
design or equivalent.  But I have hope, since new UAs can be created.

Standards are how we address the tension between wanting to enable creation of 
new innovative UAs and having the requirements that existing content work for 
users of those UAs and that web application writers and web content producers 
should have a low barrier to entry.

> Put simply:  Don't screw the user.

While also not screwing the people producing the content the user consumes.

Alternately, you could define "user" to mean both content producers and 
consumers, since with blogging so many people have become both.

>    1. Folk representing non-IE browsers would like to render existing
>       web applications that work with IE. 

I would insert "most" before "web applications".  The more the better, of 
course.  But no one, for example, is aiming to render applications that try very 
hard not to render with anything other than IE (e.g. use many different sniffing 
techniques to lock out other UAs).  Working with those is no a technological but 
a social problem, since it means, for example, not implementing any features IE 
doesn't have.  Thankfully such applications are rather rare.

I'm also going to assume you're OK with replacing "applications" with "content". 
  If you're not, we need to back up a few more yards.  ;)

>    3. Folk (web authors mainly) who would like a cleaner HTML spec with
>       better compliance from all browsers.

This is a prerequisite for lowering barriers to application authoring and 
user-agent creation.

> I suspect that to the folk implementing other browsers, 
> interoperability with IE is (and should be) the single most significant 
> problem in their world.

It used to be.  For the existing UAs (Opera, Safari, Mozilla) I'm not sure how 
true this is.  A bigger problem is that the UA (and sometimes the web in 
general) doesn't do what the user wants them to do.

> To achieve this means throughly describing the 
> current behavior of IE (no matter how ugly). 

Yes.  And then deciding how feasible it is to implement parts of that behavior.

> Note also that goal (1) must be achieved without any version specifier 
> other than those already in use.

Yep.

> The goal (2) of not breaking the web, or more to the point, not screwing 
> the end user - must be absolute.

If you accept extending the term "end user" to include content creators, I would 
almost agree.  This goal must be tempered by the requirement that there be more 
than one functioning UA capable of letting users access the web.  If the two 
requirements prove incompatible, we have a serious problem, of course.

> Note that changing any existing browser behavior absolutely requires 
> some means of explicit "opt-in" from web authors. 

Unfortunately, I don't feel that this is a feasible approach assuming we have 
more than one UA (which I feel is one of the goals), unless either UAs ship with 
no bugs or UAs don't fix any bugs.

The alternative is that content creators you would have to opt in to every UA 
point release for every single UA.  Or create different sites for different UAs 
(with different opt-ins).  Or something.

UAs not fixing any bugs also raises the barrier on content creation.

Thus we end up protecting end-users and current-and-past content creators at the 
expense of future content creators.  This is not necessarily a good tradeoff, 
and not necessarily a bad one.  The decision should be made on a per-feature basis.

> The usual way to be 
> this is via a version identifier (i.e. <!DOCTYPE HTML PUBLIC 
> "-//W3C//DTD HTML 5.0//EN">).

As pointed out, that has relevance to the document content, not to the UAs 
rendering the content.  In other words, you can't use a single identifier to 
reasonably opt in for multiple UAs, each of which has several releases.

I agree that the compatibility problem is a real one.  What I don't see is how 
versioning the HTML specification necessarily solves it.  It doesn't really seem 
to address the concerns Chris had, for example -- if partway through the 
implementation of HTML5 by browsers it gains enough critical mass, he would have 
to freeze the then-current IE bugs, even though the version of HTML is not 
actually changing at all.  Then what?

-Boris

Received on Tuesday, 17 April 2007 02:31:28 UTC