Re: Please explain the role of the W3C in the continuing development of HTML

On Fri, 25 Feb 2011, Danny Ayers wrote:
> On 25 February 2011 09:45, Ian Hickson <ian@hixie.ch> wrote:
> > On Fri, 25 Feb 2011, Danny Ayers wrote:
> >> On 25 February 2011 03:26, Ian Hickson <ian@hixie.ch> wrote:
> >> > On Fri, 18 Feb 2011, Danny Ayers wrote:
> >> >>
> >> >> At the other end of the scale, at the 'living spec' end, what 
> >> >> safeguards are there to prevent a single vendor setting the agenda 
> >> >> with the features it has in the pipeline?
> >> >
> >> > They're all always trying to do that. That's what competition is 
> >> > about. This happens regardless of the spec (indeed, it happens even 
> >> > without specs). It's not a problem specific to the "living 
> >> > standard" model.
> >>
> >> But with a versioned spec there is a finite boundary for a particular 
> >> version, and while a single vendor may still dominate there's only 
> >> going to be room for features A, B and C. With a "living standard" 
> >> it's open-ended, a single vendor can continually influence the 
> >> trajectory by proposing features D, E, F...
> >
> > Well sure, but in the time that the "living standard" would have those 
> > six features, the versioned spec would have had two versions each with 
> > three features, right? So the effect seems identical to me.
> 
> Not quite identical. Implementers are able to work against the first 
> version, rather than having to play catch-up in real time.

It doesn't work like that in the market. People care about what the 
features are, not about whether they're in a versioned standard or not. 
Case in point, look at the way browsers were competing on the HTML5 
feature set back when it was still versioned but long before being a REC 
was even a remotely scheduled milestone.


> > The specs follow the market, not the other way around.
> 
> For the most part I agree, but the specs must surely have some influence 
> on the market - otherwise why bother?

Their influence is merely a matter of helping the browsers converge on an 
interoperable set of details. If someone specs something the market 
doesn't want, the spec isn't going anywhere. There's lots of examples of 
that in the work I've done -- the original WebSocket work, many parts of 
WF2, all of XBL2, WebSQL... I just cut my losses as soon as I realise it's 
not going to get implemented, and move on to other things. (With some of 
the more subtle aspects, I sometimes try harder to get the browsers to 
converge on particular details than if entire features are blown off, but 
even then, there are many examples of places where I've given up and done 
what the browsers wanted, e.g. from the past few weeks, EventTarget's 
place in the interface inheritance hierarchy and from earlier today, how 
meter's IDL attributes work.)


> > At any particular time, a useful spec is being dominated by whatever 
> > the most innovating user agent is.
> 
> I'm not sure about that, seems to me the utility of a spec comes more 
> from common ground rather than unilateral innovation.

The utility of a spec comes from the implementors being able to converge 
on specific behaviour. However, the spec is only useful if it describes 
behaviour the browsers actually want to converge on in the first place.


> Think engineering - if you're making screws, you mostly need to think 
> about today's screwdriver/thread specs rather than tomorrow's.

I'm not familiar with standardisation of screws, but I wouldn't be 
surprised if the dynamic there was quite different.


> > Whether we just have one document that's continually updated or 
> > whether we such a document but describe as unstable and publish the 
> > occasional snapshot that we stop updating and describe as something 
> > more mature seems to be orthogonal to market forces.
> 
> I'm beginning to wonder what you see as the purpose of specifications.
> 
> As I see it, by designing to a (good) stable specification, you can 
> offer the guarantee of interoperability of your system with other 
> systems designed to the same spec.

Specifications offer no such guarantees, at least in the Web space.


> If I was writing a Web agent (which incidentally I am, though it's only 
> tangentially in this domain) I'd prefer to design it against fixed 
> requirements, so I knew anything I implemented today will work tomorrow. 

A set of fixed requirements does not grant such knowledge. For example, if 
you were to blindly follow HTML4's "fixed" requirements you would 
implement <link> as having a "media" attribute whose default value is 
"screen". This would be singularily useless as in practice, no other 
browser implements it that way and thus millions if not billions of Web 
pages rely on browsers not treating the default as "screen". (The "real" 
default is "all".)


> Regarding market forces, under normal circumstances investors are likely 
> to prefer designs which offer such guarantees. But if there isn't a 
> stable spec, the only way you can make any such guarantees is by having 
> direct influence over the direction of the specs. It's not hard to see 
> where the big players are likely to position themselves in such a 
> scenario. Far from being orthogonal to market forces, the "living" 
> approach will encourage big vendors to further insert themselves into 
> the loop - and it's a positive feedback loop.

This assumes an operational model that has never existed. In the past, 
when specs were not living documents but were instead fixed, the result 
was that the specs became less and less related to reality, culminating in 
the ultimate failure that were XHTML2 and XForms.


> While the past situation may have been far from ideal, the HTML5 effort 
> seems to addressed many of the systematic problems. It is allowing space 
> for innovation (I'll overlook the distributed extensibility issue here 
> :) while paving the cowpaths. It's helping level playing field for tool 
> builders and publishers.
> 
> On the other hand, a "living" spec would be a significant optimisation 
> in favour of a monopoly/oligopoly kind of market. A big step in the 
> opposite direction. That strikes me as potentially harmful for the Web 
> at large.

I believe the reality is quite the opposite in practice.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 18 August 2011 07:42:39 UTC