W3C home > Mailing lists > Public > www-html@w3.org > July 2004


From: Ian Hickson <ian@hixie.ch>
Date: Thu, 29 Jul 2004 21:41:00 +0000 (UTC)
To: Christian Ottosson <christian@ottosson.name>
Cc: www-html@w3.org
Message-ID: <Pine.LNX.4.61.0407292135370.26359@dhalsim.dreamhost.com>

On Thu, 29 Jul 2004, Christian Ottosson wrote:
>> Specifications should define what UAs should do in _any_ scenario. The 
>> CSS, XML, and SVG specs are quite well defined in that regard. The HTML 
>> specs have traditionally been quite vague in that area.
> It has been argued that the UA should bail out and not render an invalid 
> document, especially as XHTML is an XML application.

But the XHTML spec doesn't require this -- it only requires wellformedness 

> Couldn't this be the case even when DOM manipulation make the 
> construction invalid?

It could -- and indeed in SVG, it is (SVG requires that SVG documents be 
continuously valid).

However, personally I think users should not be exposed to authoring 
errors. IMHO, specifications must specify exact error recovery behaviour 
for each possible error scenario, and error handling should IMHO for the 
most part be defined in terms of graceful error recovery (as in CSS), 
rather than obvious and catastrophic failure (as in XML).

I think the "handle all input at all costs" attitude is one of the major 
reasons for HTML's success. It lowers the barrier to entry to such a low 
level that almost anyone can write pages.

Ideally, IMHO, languages should be defined so that any content is valid, 
so that there isn't really a question of "what should we do with invalid 
content". CSS partially goes in that direction (if your document isn't 
valid CSS, as far as the UA is concerned, that just means it's CSS 
conforming to some future specification it doesn't yet know about).

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 29 July 2004 17:41:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:08 UTC