W3C home > Mailing lists > Public > public-html@w3.org > February 2009

Re: "downplayed errors"

From: Charles McCathieNevile <chaals@opera.com>
Date: Thu, 05 Feb 2009 10:44:53 +0100
To: "Ian Hickson" <ian@hixie.ch>
Cc: "HTML WG" <public-html@w3.org>
Message-ID: <op.uovhc3ylwxe0ny@widsith.local>

On Thu, 05 Feb 2009 09:09:30 +0100, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 5 Feb 2009, Henri Sivonen wrote:
>> Recently, though, HTML 5 has gained a list of of downplayed errors[2]
>> which, in my opinion, is partly similarly wishful as deprecation was in
>> HTML 4.01.
>> [2]  
>> http://www.whatwg.org/specs/web-apps/current-work/#conformance-checkers-0
> I agree with that characterisation.
> The intent of the downplayed errors is to make migration easier while not
> leading authors of new documents into the weeds. It's an attempt at
> addressing two mostly-contradictory requirements:
>  1. Don't waste the time of new authors by having them look at features
>     that are useless or otherwise harmful,
>  2. Don't waste the time of authors who are editing existing documents
>     that may contain those mostly pointless features but for which the
>     investment is a sunk cost.

Thinking out loud...

A partial approach is to provide a document like Mike's, which says "as an  
author, use this stuff and you will be fine (but note that you may meet  
other stuff, and the main spec normatively defines what to do with it",  
along with the spec that says "all of this other stuff might appear and  
here is what to do with it". This at least allows authors to write things  
that are correct without baffling them with all sorts of other stuff -  
i.e. meets requirement 1, while alerting them to the fact that editing  
existing content may lead to different things.

I think one of the hard questions that is sometimes being avoided by this  
category is "what is the actual harm that these things do?" - i.e. what  
are the practical problems (framed like use cases) caused by the presence  
of these things (mostly attributes)? In some cases they are things that  
are not well used, and I don't see that this causes practical problems.  
(Funnily enough, I mean the cases where I disagree with their removal in  
the first place ...)

An alternative approach is to stick with HTML 4's notion of deprecating  
things, but make it a requirement that anything deprecated include an  
explanation of what should be done instead - which allows validators to  
have warnings ("this thing is no longer the technique du jour - you may  
want to try XYZ which is what all the cool cats do these days...") as well  
as errors. This might just solve the problem of what to do when alt text  
should be given, but isn't - instead of making it a validation error, thus  
encouraging someone to do the *really* destructive thing of putting  
meaningless text just to satisfy validation, you have a warning.



Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Thursday, 5 February 2009 09:45:43 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:42 UTC