Re: Support Existing Content

I disagree that it's doing what I asserted ---

To Clarify:

A) Define a lean,clean language.
B) Define how legacy bits map to the clean language.

is *not equal to*

1) Take legacy tag soup and map it to a DOM
2) Serialize that DOM as XML.


Steps A->B has the hope of creating over a time a clean, lean new
language, with browsers being able to support the legacy Web by
applying the "map legacy to new content map".

Following steps 1->2 leads to a well-formed serialization that
includes *every* authoring idion ever attempted on the Web, --
that is unlikely to lead to a leaner, cleaner language. This is
because at any given point in time T,
authors will never know which piece of the language is a piece of
deprecated history from the past vs a "shiny new feature" ---
and you therefore get the self-fulfilling  prophesy  --- "to
browse the Web, you need a browser that 
contains the union of all previously deployed browsers".

L. David Baron writes:
 > On Tuesday 2007-05-01 09:05 -0700, T.V Raman wrote:
 > > implementations to emerge over time, I think we would be
 > > well-served by defining:
 > > 
 > > A)  A clean, lean language
 > > B)  A mapping from today's mess to (A)
 > I think this is what the WHATWG spec [1] is already doing.  It
 > defines how to parse tag-soup HTML into a tree structure, but then
 > defines the rest of the spec in terms of that tree structure.  It
 > also defines an XML serialization that uses XML rules to build the
 > tree structure.
 > -David
 > [1]
 > -- 
 > L. David Baron                                <URL: >
 >            Technical Lead, Layout & CSS, Mozilla Corporation

Best Regards,

Title:  Research Scientist      
Google: tv+raman 

Received on Tuesday, 1 May 2007 17:30:57 UTC