Re: An HTML language specification vs. a browser specification

Roy,

Your e-mail seemed to imply a set of fundamental assumptions that I am not 
sure we share. In order to help get a better common understanding, I'd 
like to see if you can explain to me whether I am correct that you have 
those assumptions and if so, why you hold them to be true.

1. Browsers, in particular HTML parsers in browsers, change with 
   regularity in ways that change the rendering of existing pages.

Could you show us a difference in how browsers in 2000 parsed HTML pages 
compared to how browsers in 2008 parse pages that shows how pages from 
2000 now render less well than they did with contemporary browsers?


2. The vast majority of "non-program" content was written long before 
   MSIE6 existed (2001).

My understanding is that content on the Web has been growing exponentially 
year over year, which makes this assumption seem implausible. Could you 
provide us with data that backs up your assertion?

(Data that backs up the opposite assertion would be, for example, that 
search engines around 2000 knew of about a billion pages, whereas search 
engines today know of about a trillion pages, suggesting that the majority 
of content is newer than 2000. [1])

[1] http://googleblog.blogspot.com/2008/07/we-knew-web-was-big.html


3. Authors when writing Web pages do not attempt to make their pages look 
   like they want in the browser they use.

Based on the feedback one sees in authoring community discussion groups, 
it appears that authors do in fact check that their new content renders as 
they desire in contemporary browsers. If you disagree, could you 
demonstrate why you believe this is not the case?


4. A browser that doesn't implement the APIs, vocabulary, and error
   handling that major browsers implement could effectively compete in the 
   marketspace.

Could you provide an example of a competitive browser that doesn't 
implement, as you put it, "all that crap"?


5. A specification that defines how to implement a Web browser would 
   remove competition in the browser space.

Reports from browser vendors suggest that a considerable amount of time is 
spent reverse-engineering other browsers in order to be competitive. HTML5 
attempts to reduce this by doing all this work for them, thus reducing the 
amount of work that it would take to make a competitive browser.

Why do you think that defining these features in detail reduces the 
ability for new competitors to enter the market?


6. Most people don't want a specification that covers the features that 
   HTML5 covers.

I understand that you might not want it, but what evidence do you have 
that the majority of the Web standards community doesn't want it?

(There is counter-evidence, for example the size of the HTML and WHATWG 
working groups and the level of support that HTML5 has had in working 
group votes.)


7. Only browsers need to deal with error handling in parsing.

Why do you think that, for example, search engines, validators, authoring 
tools, data mining tools, and so forth, would benefit from _not_ handling 
errors in HTML documents in the same way as browsers do?


8. Firefox is getting buggier with every release.

Could you provide examples showing that Firefox is regressing?


9. Firefox market share has flatlined.

Could you provide evidence showing that the market share of Firefox has 
stopped increasing? The aggregate data at Wikipedia's "Usage share of web 
browsers" page shows continuing growth. How is this data wrong?


10. HTML5 will stop innovation.

Why would HTML5 stop innovation? Why did HTML4+DOM2HTML not stop 
innovation? What is the difference?


11. Many of HTML5's features have no demand.

Why do you think that features like Web Sockets, Workers, SQL storage, 
etc, have no basis for implementation? I am especially curious about this 
claim since for all of these features I have heard huge amounts of demand 
from authors, as well as reports of demand from Web browser vendors.


12. It is more important that authoring tools implement HTML correctly 
    than browser vendors implement HTML correctly.

Could you explain this position? It would seem to me that it is equally 
important that both implement it correctly. The point of specifications is 
interoperability, one doesn't get that if only half of the tools implement 
the specification.


13. None of the features in HTML5 are going to be implemented by authoring 
    tools.

Could you explain why you think this? It seems that features like 
<section>, <article>, <details>, etc, the new form controls, the menu 
widgets, contentEditable, drag and drop, etc, would all be things that 
authoring tools would want to expose to their users, so that they can 
create more semantic pages and more interactive pages.


I look forward to your explaining these assumptions (or correcting me if 
you do not in fact hold these assumptions to be true).


On Mon, 17 Nov 2008, Roy T. Fielding wrote:
> 
> HTML is a mark-up language

HTML5 is not, and has never been intended to be, limited to a markup 
language. It is an application and document publishing platform. Indeed 
the specification used to be called "Web Applications 1.0"; it was renamed 
to "HTML5" after a W3C working group vote.


> yet HTML5's scope appears to be [...]

The document describes the scope. You may disagree with it, but it 
certainly hasn't been a secret -- heck, it's even in our charter, and has 
been supported by vote multiple times.


> You aren't defining a mark-up language, so stop calling this effort 
> HTML.

I can't change the name, it was agreed to by the working group through a 
vote (that I abstained from!). If you would like the name changed back to 
its original name, Web Applications 1.0, I would be happy to ename the 
spec, but you'll have to convince the working group chairs.


> It just ends up confusing the folks who work on the Web architecture 
> (the protocols for communicating between independent implementations).

Can you provide links showing this confusion?


> The architecture is what must work across all implementations, not just 
> browsers.

I agree, that's why this isn't a browser specification.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 18 November 2008 00:45:53 UTC