Re: An HTML language specification vs. a browser specification

Roy T. Fielding wrote:
> They all handle errors in different ways.  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

Of course.  Where do you see HTML5 requiring authoring tools to generate 
"error-filled HTML"?  What it _does_ require is that an HTML byte stream 
be parsed in a certain way.  It's defined by reference to a DOM, but can 
be mapped onto any other object model or sufficiently rich callback system.

>> 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.

You explicitly said, in the context of a discussion of web standards 
that "Firefox is getting buggier with every release."  None of the 
things you mention above have anything to do with web standards.  (The 
141MB number is also meaningless without information about how many 
windows you have open and such, but let's not worry about that.)

-Boris

Received on Tuesday, 18 November 2008 14:22:50 UTC