Re: An HTML language specification vs. a browser specification

HI Boris,

On Nov 16, 2008, at 1:39 PM, Boris Zbarsky wrote:
>
>> The key thing is that we would be able to make the draft(s) serve  
>> the needs of users and authors and not only a few browser  
>> implementors.
>
> Good luck getting consensus on any of that, then.  Or better yet,  
> implementations...
>
> Note that the draft(s) do need to serve all three constituencies,  
> but they also need to be implementable.  The other option, of  
> course, is to retrace the steps of XHTML2.

Again, you're creating false dichotomies. I never once suggested that  
the parsing should be done in a way that in not implementable or  
doesn't serve the implementor constituency What I'm saying is that  
parsing should:

1) be compatible with existing content
2) improved to allow for forward migration
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).

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

Take care,
Rob