Re: Support Existing Content

Somehow this this "does not compute".

Why aren't we defining Javascript the same way as what you
describe --i.e. make every failing program "somehow work".
Why aren't we even defining CSS that way i.e. "somehow make every
CSS rule parse and mean something."
Why is HTML special? If the argument is "more than programmers
rite HTML",
then it's also amusing to note that all attempts at reducing the
need for scripting get dismissed with "people know to write
scripts ...".

L. David Baron writes:
 > On Tuesday 2007-05-01 09:11 -0700, T.V Raman wrote:
 > > In the IETF world, this is called "be lenient in what you
 > > consume, be strict in what you produce".
 > > 
 > > Failure to correctly document what producers should produce
 > > risks creating a language over time where the sheer bloat created
 > > by exception handling rules will paper over the actual language
 > > --- and by the way this did happen in the 90's during the heyday
 > > of tag-soup browsers; over time, browsers could render malformed
 > > content, but not well-formed content.
 > I think we've already seen that enough producers don't read the
 > documentation that documentation alone is not sufficient to make
 > producers strict.
 > I think that the way to stop *escalating* complexity of error
 > handling rules is to define the error handling rules precisely and
 > have test suites for them.  What leads to the error handling rules
 > becoming bloaty is when implementations repeatedly copy each other
 > without clear understanding of what the others are doing.  If
 > they're all implementing error handling rules defined in the spec,
 > then the complexity of the error handling can be frozen at the time
 > of the spec's writing rather than continually increasing.
 > -David
 > -- 
 > 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:33:28 UTC