W3C home > Mailing lists > Public > public-html@w3.org > May 2007

Re: Support Existing Content

From: T.V Raman <raman@google.com>
Date: Tue, 1 May 2007 10:33:05 -0700
Message-ID: <17975.31185.59425.872657@retriever.corp.google.com>
To: dbaron@dbaron.org
Cc: public-html@w3.org, raman@google.com


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: http://dbaron.org/ >
 >            Technical Lead, Layout & CSS, Mozilla Corporation

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Received on Tuesday, 1 May 2007 17:33:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:44 UTC