- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 18 Nov 2008 00:45:17 +0000 (UTC)
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: HTML WG <public-html@w3.org>
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