- From: Nikunj Mehta <nikunj.mehta@oracle.com>
- Date: Mon, 17 Nov 2008 16:27:56 -0800
- To: HTML WG <public-html@w3.org>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>
On Nov 17, 2008, at 3:23 PM, Roy T. Fielding wrote: > > On Nov 16, 2008, at 12:58 AM, Jonas Sicking wrote: >> Roy T. Fielding wrote: >>> On Nov 14, 2008, at 11:24 PM, Jonas Sicking wrote: >>>> How browsers parse HTML *is* how HTML must be parsed. Or at least >>>> that >>>> is the case if you presume that current HTML has been written for >>>> browsers and by testing what works in current browsers. >>> Which is obviously false. Most content is written programatically >>> or >>> for tools that existed in the distant past >> >> This is an interesting assertion. If you are correct then I stand >> corrected and we need to seriously revise how we define HTML5. >> However before we do that though I think we should try to get some >> data as I'm (obviously :) ) less convinced than you are. >> >> What non-browser tools of the distant past was this content created >> for? Do you have any idea how much content were created for these >> tools? Or any ideas for how we would measure that. > > HTML is a mark-up language, > yet HTML5's scope appears to be a whole pile of idiotic features which > have no basis for implementation whatsoever: ping, SQL-storage, > websockets. > workers, ... the list goes on. You aren't defining a mark-up > language, > so stop calling this effort HTML. It just ends up confusing the folks > who work on the Web architecture (the protocols for communicating > between > independent implementations). The architecture is what must work > across > all implementations, not just browsers. A mark-up language is a > standard > that authoring tools need to adhere to, far more so than browsers, and > none of the new features in HTML5 are going to be implemented by > authoring tools. > > Call it an implementation spec for browser developers. I find it odd > that folks want to define such a thing, thereby eliminating > competition > from lightweight clients that don't implement all that crap, but at > least it sets the scope to something on which you might be able to > reach agreement and the rest of us can simply ignore. While it is a commendable effort to support greater programmability of Web pages and the HTML5 effort has highlighted the need to evolve the browser to enable application developers seeking a widely distributed software platform, I cannot help but agree with Roy on his impression of the scope of HTML5. 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. When these features need to be evolved, will we be revising HTML again? 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? 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. I understand that many decisions are based on available editors and required expertise, but then let's justify it as a design principle. Nikunj [1] http://lists.w3.org/Archives/Public/public-html/2008Oct/0274.html [2] http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html
Received on Tuesday, 18 November 2008 00:28:48 UTC