Re: An HTML language specification vs. a browser specification

Robert J Burns wrote:
> 3) abstracted from the HTML vocabulary (markup vocabulary and DOM) and 
> the browser behavior (what browsers do with the objects created 
> according to the specified vocabulary once parsed).

I'm still not seeing how this one can work, honestly.

> The presumption you're conveying is that these first two cannot be done 
> simultaneously, and that's simply not true (e.g, Gecko already does some 
> things that the HTML5 parsing algorithm doesn't support and should 
> support, yet those things do not break existing content).

You're assuming that they don't break existing content.  Groundlessly, 
as far as I can tell.  In practice, we have a number of known 
compatibility issues in parsing in Gecko, but we've been holding off on 
fixing them pending a finalization of the HTML5 parsing algorithm, when 
we'll have more confidence (based on the reverse-engineering work 
performed) that we won't just be flailing away and breaking more things 
than we fix.

If you feel that particular parts of the algorithm as specified by 
reverse-engineering are not needed for website compat, then by all means 
raise those as issues.  Data indicating why you think the behavior is 
not needed to successfully parse the web is always welcome.  I think all 
of us would prefer a simpler parser to a more complex one, all else 
being equal.

-Boris

Received on Sunday, 16 November 2008 22:16:44 UTC