You're proposing that the current spec be split up into multiple pieces.
would have to read both specs?
>> Specialized expertise in what?  Language design?  Parser design?
>> something other than "prose along with specific error handling".
> or not even incorporating Gecko's in span insertion mode).
> error-recovery to HTML beyond what a DTD can define).
reference to HTML, what would your separate spec actually define?
> fancy error-recovery (like moving input elements outside of tables).
other kind. Why is this distinction relevant, exactly?  HTML needs both.
can do with HTML once all browsers are following the HTML5 parsing spec.
> No, it can be a complete specification of the vocabulary of HTML.
How does that differ from what I said?
to how HTML gets parsed... not if you want to keep document.write().
> Yes, but this is the fancy legacy error-recovery I was speaking about.
> where they were trying to solve certain problems.
I agree. It just needs to support all the existing fancy error-recovery.
> error-recovery in the future.
>> The definition of which?
> not need to define the algorithm for that parsing).
I would love to see this done for document.write as a proof-of-concept.
> the document schema that it is going to de-serialize content into.
document schema altering parser behavior on the fly.
Which can be done; I'm just worried about the complexity.
>> from Mozilla's point of view.
> application design when its abstracted in that way).
compartmentalized, true.  But not easily.
>> parts" meme comes from.
>  From many months of discussing these topics.
I've read every single mail on this list in the last 10 months or so.
Next message: Jonas Sicking: "Re: Comments on HTML WG face to face meetings in France Oct 08"
Previous message: Robert J Burns: "Re: An HTML language specification vs. a browser specification"
In reply to: Robert J Burns: "Re: An HTML language specification vs. a browser specification"
Next in thread: Maciej Stachowiak: "Re: An HTML language specification vs. a browser specification"