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.

Sorry but Hixie's opinion is not what decides the matter here. This  
just totally tosses out my understanding of the W3C process out the  
window. IIUC, the role of the editor is to take technical inputs about  
the specification and weave it together into a coherent whole, not  
also to define the process and make decisions. The former is done by  
the W3C/WG and the latter by the WG chairs based on consensus/up down  
vote. BTW, where /is/ the HTML WG chair in this period of tempest?

> When work on HTML6 begins, maybe this can be made a priority then.
>
>
>> 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 really simple - I claim that the offline application caching  
behavior as specified in the current draft is not a primitive enough  
behavior to be included in HTML5. Instead of this, the primitives  
should be the ability to perform background network interaction and  
intercept HTTP requests in a program provided in some library. One  
such library can be implemented to perform the current behavior  
specified as Section 5.7. Gears [1] and AtomDB [2] satisfy the test of  
utility for interception inside current browsers, which provide means  
of intercepting requests, and using which Gears and AtomDB perform  
offline serving. However, the HTML5 has declined to consider the  
interception behavior as a standard primitive and instead focuses on  
define a far more complex standard, that in my opinion does not pass  
Occham's razor. Another example of the same failure is Section 7.2 --  
Server-sent events.

This should provide basis to make the case that the present  
opportunistic, and "theoretically" imprudent organization of HTML5 is:
1. leading to spec bloat - a completely wrong level of detail being  
specified as standard and primitive - and
2. preempting innovation

>
>
>
>> 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 am sure there are some in this WG and outside who would be willing  
to help edit parts of this spec (even though they may get carved out  
of this HTML5 spec). Seemingly random scope definitions and section  
splits, decisions about what is in and what is not, and ownership  
decisions are turning them off. I know that the number is non-zero,  
because I am one of them.

[1] http://gears.google.com
[2] http://oracle.com/technology/tech/feeds/

Received on Wednesday, 19 November 2008 01:10:47 UTC