W3C home > Mailing lists > Public > public-html@w3.org > November 2008

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

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 19 Nov 2008 03:24:42 +0000 (UTC)
To: Nikunj Mehta <nikunj.mehta@oracle.com>
Cc: HTML WG <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0811190312300.25579@hixie.dreamhostps.com>

On Tue, 18 Nov 2008, Nikunj Mehta wrote:
> 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.

Well, it decides it as much as yours, right?

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

With the exception that the intercepts are a static URL to content 
mapping, how is this different than what we have now?

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

I don't really see how what you describe is any more primitive or any 
simpler than what the offline feature currently has. I agree that it is an 
alternative way of doing things.

I recommend putting forward a more concrete proposal and trying to get 
buy-in from the browser vendors. The offline stuff isn't cast in stone; if 
browser vendors prefer and are willing to implement another mechanism, we 
should do that instead.

> Another example of the same failure is Section 7.2 -- Server-sent 
> events.

Could you elaborate?

> 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

I don't really follow, but in any case I recommend bringing up these 
issues as separate threads. Just mentioning them in passing and saying 
that the spec is therefore bloated and preempting innovation isn't going 
to fix anything.

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

Please, if you are willing to take over editing one of the sections 
described in this mail:


...then let us know. I would be more than happy to spread the workload 
and work with you on this.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 19 November 2008 03:25:20 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:39 UTC