Re: Support Existing Content

Hakon,
Apologies, but you're  being a bit too glib here and in the
process papering over quite a few pigs:-)

To clarify:

Håkon Wium Lie writes:
 > Also sprach T.V Raman:
 > 
 >  > 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? 
 > 
 > CSS was designed with error recovery built into the syntax. If
 > an

Not to the same extent that is being demanded of HTML.
Error recovery at the level of "unknown CSS property" should
translate to "unknown attribute" or "unknown element" in HTML. It
should not translate to the kind of tag soup we're talking of
fixing up and blessing as  the new-fangled HTML for the Web.

 > unknown property or unit is used, the CSS specification describes how
 > to handle it.

Draconian error recovery for CSS  to match what is proposed for
HTML would be a *lot* more -- and I'm sure you dont want to go
there:-)

 > 
 > HTML specification didn't have this in the past. (XHTML tried
 > to

Again, this is a second pig that is getting papered over:-)

It has been stated many times here that HTML was under-specified.

I believe that:

A)  HTML (for presentational purposes) was *never* specified,
    since the hope was that presentation would be left to user
    agents. But Web sites went ahead and used it as a
    presentational language anyway, and tagsoup browsers of the
    90's gave authors little help with respect to doing
    otherwise, the rest is history.

B)  CSS provided a glimmer of hope with respect to separation of
    presentation from content,  but the underlying tagsoup mess
    that it had to style, combined with lack of interoperable
    implementations has meant that that dream has never been
    fully (or even partially) realized.

C) Finally, (and for the record I asserted this at the time in
    2000) the transition to XHTML was botched by trying to
    compartmentalize XHTML into a completely separate mime-type
    -- again this is now history and water under the bridge.
 > address it by adding a draconian rule: stop processing once

I believe the draconian rule from XML that you state  would have
    not caused a problem if the transition from HTML to XHTML had
    followed the roadmap that was proposed by many of us in
    1998-99 -- namely,

0) Define error recovery for malformed HTML4; 

1) Implement that error recovery initially in a script tag that
   is placed in the document head while delivering old content to
   new browsers; you find > an error. Authors didn't comply and

2) Once those script-implemented fixups have been proven, move
   their implementation into the browser for speed,

4) While creating new content that is clean and well-formed AKA
XHTML.

See http://www.w3.org/MarkUp/future/papers/adobe-19980427.html

   
>implementations soon started 
> defecting). Some of us think error handling should be added to HTML as 
> well, just like it

So let's make sure we're talking the *same kind* of error handling.

   exists in CSS. From this perspective, HTML isn't 
> special: it, too, needs graceful error handing. Even if the markup 
> doesn't deserve it :-)

Again, graceful error handling is one thing; 
but let's make sure  that the thing doesn't turn into a complete
disgrace;-)
 
> 
 
> -h&kon
 
>               Håkon Wium Lie                          CTO °þe®ª
 
> howcome@opera.com                  http://people.opera.com/howcome

-- 
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 18:14:39 UTC