Re: An HTML language specification vs. a browser specification

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