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

On Nov 17, 2008, at 5:36 PM, Ian Hickson wrote:

> On Mon, 17 Nov 2008, Nikunj Mehta wrote:
>>
>> What Ian considers Platform core [1] as listed in [2] includes a wide
>> variety of things that don't have much to do with HTML at all. SQL
>> (5.10.2) and unstructured storage (5.10.1) are good examples. The  
>> only
>> reasons for keeping these parts in the HTML5 spec that I have seen  
>> are
>> that these pieces are stable and the same editor would be working on
>> these sections as the Platform Core. Neither sound good enough  
>> reasons
>> to me.
>
> 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?

>
>
> 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.

>
>
>
>> Another pet peeve I have is that the discrimination of what is in and
>> what is outside the scope of HTML5.
>>
>> 1. The distinction of a primitive from a specific use of the  
>> primitive
>> is rather arbitrary.  For example, it is not clear why offline Web
>> application caching is treated as a primitive. If anything, the
>> primitives are local proxying and background worker threads. Why  
>> should
>> application manifest and GET request proxying be built in to HTML and
>> not another data format or another set of methods?
>
> I don't really understand the question. Could you elaborate?

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? 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. My larger point is that the current scope of HTML5 is  
rather arbitrary.

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.

>
>
>
>> 2. Current features of browsers are sometimes being standardized in
>> other specs. As an example, XMLHttpRequest is not a part of HTML5  
>> even
>> though that is part of most current browsers and is core to the  
>> browser
>> platform.
>
> XHR was part of HTML5. It was extracted because someone volunteered to
> edit it. That's really all it takes.
>
>
>> 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.

>
>
>   http://www.w3.org/html/wg/html5/principles/#priority-of-constituencies
>
> Concerns of the spec authors (my having time to do the actual  
> editing, in
> this case) are higher in priority than theoretical correctness of  
> design
> (having the "right" split between spec components).

Sorry I just don't get this. Can someone show me the inference chain  
from this principle to what Ian says above?

Received on Tuesday, 18 November 2008 02:44:25 UTC