Re: Why "Platform Core" and "HTML5" are in the same spec

On Mon, 17 Nov 2008, Nikunj Mehta wrote:
> > 
> > They're not particularily good reasons, but splitting those two parts 
> > up would delay progress by a year or more, and that is unacceptable 
> > IMHO.
> 
> Good to see the confirmation. You seemed to have snipped off my question 
> and I would appreciate a clarification.
> 
> When these features need to be evolved, will we be revising HTML again?

My apologies, I meant the following to be a reply to that question:

> > When work on HTML6 begins, maybe this can be made a priority then.
> 
> I don't understand what is meant by making "this" a priority.

I meant, when work on HTML6 begins, and we want to evolve the features you 
mention, work on splitting these sections out of the specification of the 
markup and vocabulary could be made a priority.

Does that make sense?


> It is safe to assert that a browser standard should provide primitives 
> and leave it to applications to define useful combinations of those 
> primitives. While a video tag or structured storage or DOM represents 
> such a primitive, the current Web application cache appears to be a 
> composition of primitives - storage, background worker threads, local 
> request proxying, and a data format. Why, then, is the Web application 
> cache a part of HTML5?

I guess I disagree with your characterisation of the offline application 
cache feature being a non-primitive feature. It interacts deeply with how 
browsers load pages, I don't really see how one could implement this at 
any other level.


> It would be much better to provide the first three as primitives and 
> leave the fourth to applications and libraries. That would allow 
> developers to experiment with synchronization techniques and offline 
> access. In its current state there is an apparently arbitrary preference 
> at work and not a design principle.

How would you see the features work? I guess I don't really understand 
what other primitive you would want to use here. What would a "local 
request proxying" primitive look like?


> My larger point is that the current scope of HTML5 is rather arbitrary.

Yes, to some extent it is. It is driven by the needs of Web authors.


> Just like HTML5 is a work in progress and constantly informed by 
> implementation experience, why should we not treat the HTML5 charter as 
> a work in progress and improve it when we see the effects of the 
> charter. Much of the debate in this thread, IMHO, is about what the 
> charter of this WG should be now that we know what the charter has led 
> to.

I'll leave this up to the working group chairs.


> > > I understand that many decisions are based on available editors and 
> > > required expertise, but then let's justify it as a design principle.
> > 
> > It's the "Priority of Constituencies" principle.
> 
> My reading of the principle actually leads to the opposite inference - 
> that long term effects on users and authors trump the convenience or 
> expediency for spec authors.

It should; I just don't see splitting the spec up here as being beneficial 
to authors and users as much as, apparently, you do. If anything, I would 
say it might harm them, as DOM2 HTML being split from HTML4 has done.

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

Received on Tuesday, 18 November 2008 02:58:46 UTC