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

Re: An HTML language specification vs. a browser specification

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 18 Nov 2008 10:10:41 +0000 (UTC)
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: HTML WG <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0811180927050.25579@hixie.dreamhostps.com>

On Mon, 17 Nov 2008, Roy T. Fielding wrote:
> On Nov 17, 2008, at 4:45 PM, Ian Hickson wrote:
> > 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.
> I made no such claim.


Could you elaborate on what you meant by the following, then?:

| In order for me to design my content for testing on current browsers, 
| I'd have to regenerate it every six months (more frequently during the 
| cycles when competition between browser vendors is relevant).
 -- http://lists.w3.org/Archives/Public/public-html/2008Nov/0216.html

> > 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
> Written programmatically includes everything rendered by blogging
> software, content management systems, Google, Yahoo, Facebook,
> YouTube, Word's "save as HTML", and regurgitated by sites that
> transclude other sites.
> The billion or so pages of information growth is almost entirely
> placed into HTML form by authoring tools that do not give authors
> control over the HTML form.  Those tools are developed based on
> language specifications and generic templates, not by "designing
> for current browsers" which didn't exist at the time and not by
> "testing what works in current browsers" that have a lifetime far
> shorter than the information produced by authoring tools.

To clarify, is it therefore the case that you subscribe to the following 

2a. What works in contemporary browsers at a time t1 is not necessarily a 
    subset of what works in browsers at a significantly later time t2.

2b. Authoring tools and templates are written according to the standards 
    and are not tested against browsers contemporary to their creation.

> > 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?
> Of course they do.  They also think that adding an entry using Wordpress 
> is authoring HTML.  What's your point?

I have no point here, I'm trying to understand where you are coming from.

So to clarify, you disagree with the above statement that authors do not 
attempt to make their pages look like what they want in the browser they 
use? That is, do you subscribe to the following?:

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

> > 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"?
> No.  The Web would be better off without that crap, but I have no 
> objection to you putting all that crap into a browser spec if you think 
> all browsers need to implement it.

So do you believe the following statement?:

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

That is, do you believe in statement 4, or statement 4'?

> That is in contrast to HTML, the language, which is something that my 
> software does generate and needs to remain compliant with, and thus it 
> does cause a great deal of harm for you to add a bunch of procedural 
> nonsense to the declarative language definition.

I don't understand. Could you elaborate on how DOM APIs cause harm?

> > 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?
> Because defining error behavior as the standard makes it very
> difficult for applications that are error-free to be approved
> for use within the environments that require adherence to standards
> (including the stupid ones).

I don't understand. Could you provide an example?

> > 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?
> Because not a single expert in the Web standards community that I have 
> talked to in the past two years has supported the current work in HTML5.
> The single most common reaction to the features that you have wedged 
> into HTML5 is abject laughter and disdain for this process.

Hm, this is in stark contrast to the feedback I have received (from 
literally hundreds of people).

It is obviously of critical importance to me that HTML5 addresses the 
needs of the wide Web community. Clearly, we have received different 
feedback from different parts of this community. I would like to receive 
feedback from the the people to which you have been talking. Would it be 
possible for you to point me in the right direction to obtain this 
feedback? Are there mailing lists where it would be appropriate to request 
constructive feedback from these people?

Do you have any suggestions for how we could obtain a representative 
sample of people to determine once and for all what fraction of experts in 
the Web standards community are in favour of the current direction of 
HTML5 and what fraction are opposed to 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.)
> You aren't listening to the objections.

I'm trying, but you're not making it easy. For example, in this e-mail 
alone you have referred to parts of HTML5 as "crap", "nonsense", and have 
said that these features receive nothing but "abject laughter" and 
"disdain" and that they "trash" previous HTML work. You have not made a 
single constructive statement in this entire thread as far as I can tell.

I have feedback saying that HTML5 should have these features, giving use 
cases, reasons, technical arguments, supporting data, etc. Your feedback 
consists of "you should remove these features because they are crap". I 
hope it is clear that from a purely logical point of view, your arguments 
hold less weight when put forward in this manner.

> Nothing I have said here hasn't been repeated several times already and 
> reinforced by a dozen others, and yet you have not made a single change 
> to the document that represents those WG opinions.

I have had the opposite feedback from hundreds of other people, far more 
than a dozen. Why should I ignore the majority in favour of the minority, 
especially when the majority has a more technically sound and more 
logically argued position?

> > 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?
> They all handle errors in different ways.

But why is this a good thing?

> It would be utterly stupid for an authoring tool to generate 
> error-filled HTML just because the browser spec says that it must 
> auto-adjust the DOM (which it doesn't even have) rather than simply fix 
> the HTML or print an error.

Would it be correct to say that you assume the following?:

7a. The HTML5 spec requires authoring tools to generate error-filled HTML 
    and not correct markup errors.

7b. The HTML5 spec requires authoring tools to have a DOM.

> Error handling in entirely dependent on context.

So would it be correct to say then that you believe that:

7'. Search engines and data mining tools should use different error 
    handling rules than browsers.

> > 8. Firefox is getting buggier with every release.
> > 
> > Could you provide examples showing that Firefox is regressing?
> I didn't say that, but my personal experience of watching the process 
> with top and one crash per day with Firefox 3.0.3 has not been happy. 
> The 3.0.4 experience has been much better so far in terms of 
> reliability, but a resident memory size of 141M is ridiculous. YMMV.

Is this relating to standards conformance? That is, do you believe that 
Firefox has regressed its standards support, or just general stability and 
memory use?

> > 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?
> It isn't wrong.  Usage share of wikipedia doesn't match the authoring 
> share of my customers (for whom Firefox was more prevalent two years ago 
> than it is today).  I don't wish that to be the case.

So to clarify, when you said "Firefox usage hasn't increased since it 
decided to be no better than the others", you meant this only with respect 
to the usage statistics of sites you have developed, not as a general 

> > 10. HTML5 will stop innovation.
> > 
> > Why would HTML5 stop innovation? Why did HTML4+DOM2HTML not stop 
> > innovation? What is the difference?
> I didn't say it would stop innovation.

Ah, I misread what you wrote. Do you believe the following?:

10'. The intention of the HTML5 effort is to prevent fresh ideas on 
     browsing implementations that disagree with the desires of the
     vendors whose browsers currently have the most market share.

> HTML5 defines HTML as a behavioral process within a DOM-implemented 
> browser.

Do you believe this? That is, do you agree with the following statement?:

10a. The HTML5 specification as it stands today is limited to defining 
     HTML in terms of what it means for browsers, and does not cover the 
     requirements for other tools such as HTML data mining applications.

> It trashes the successful work on HTML standards in order to satisfy the 
> whims of a few browser implementors that have never implemented the 
> standards as they existed.

Do you believe the following statement, therefore?:

10b. HTML4, despite never having been implemented by the browsers that 
     have the most market share, can be considered a success.

If so, could you elaborate on how you define "success"?

Do you also believe the following?:

10c. HTML5 discards the progress from HTML3.2 to HTML4 and from HTML4 to 
     XHTML1, and is not strongly influenced by HTML4 or XHTML1.

And the following?:

10d. HTML5 does not cater to the needs of Web authors and users, only to 
     the needs of major Web browser vendors.

> The fact that those few vendors who had been consistently ignoring 
> standards for the Web would take it upon themselves to redefine what 
> HTML means rather than implement it correctly is not a sign of good.

Do you agree with the following two statements?:

10e. The major browser vendors do not implement HTML4, CSS2, HTTP1.1, DOM2 
     Core, DOM2 Events, XML, and ECMAScript.

10f. Firefox, Safari, Opera, and IE have not substantially improved their 
     standards support over the past decade.

> The difference is that I cannot implement HTML5 as it has been 
> specified

Could you elaborate on exactly what it is you cannot implement? What tool 
are you trying to write, and what requirement applicable to that tool can 
you not implement, and why?

> nor would I care to do so, and will object to its publication for as 
> long as that is the case.

That is, naturally, your right. I would encourage you to bring the many 
other people you say disagree with HTML5 and have them also take part in 
the process and object to HTML's publication, so that we can see a more 
representative sample of the opinions of the Web's experts.

> > 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.
> Because you don't listen to objections.

You believe that these features have no basis for implementation because I 
don't listen to objections? I'm confused. I literally spend 100% of my 
work time listening to objections and attempting to address them. It's 
pretty much all I do.

Could you elaborate?

> > 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.
> Data lasts longer than processes.

So you do agree that it is more important that authoring tools implement 
HTML correctly than browser vendors implement HTML correctly, despite the 
earlier complaints you made about browser vendors not implementing HTML 
correctly? (The two positions aren't mutually exclusive, I just want to 
make sure I completely understand your position.)

> > 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.
> Most of those are mark-up features (or at least could be defined as such).
> I said "ping, SQL-storage, websockets, workers, ... the list goes on."
> Those features have no basis for being in HTML.

Do you believe these features have no basis for being part of the Web 
platform at all, or are you only objecting to the editorial decision to 
have these features be in the same specification?

If the latter, why do you mention Workers, which are not in the HTML5 
core document?

Do your objections extend to other features, e.g. XMLHttpRequest and SVG?

> > > 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.
> So, change the title back.  It wouldn't be the first time that a W3C 
> working group held a vote without having a clue about the consequences.

I would be happy to do so. I am not the one you need to convince. You do 
not appear to have made any effort to convince the working group as a 
whole; indeed, as far as I know, you have not approached the chairs about 
this at all.

> > > 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?
> This thread is enough of a link to document that.

I don't see confusion in this thread (well, not from you; I am confused 
about several things). I see disagreement, for sure, but not confusion. 
Could you give more precise pointers?

> > > The architecture is what must work across all implementations, not 
> > > just browsers.
> > 
> > I agree, that's why this isn't a browser specification.
> Then it shouldn't be specified in a way that only a browser can comply 
> with.

Could you give precise feedback on what it is you believe that only 
browsers can comply with?

Obviously, there are parts of the spec that are specific to browsers, just 
like there are parts specific to data mining tools, search engines, 
validators, authors, etc. Is that all you are referring to?

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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:39 UTC