Re: "downplayed errors"

On Fri, 06 Feb 2009 10:55:19 +0200, Henri Sivonen <hsivonen@iki.fi> wrote:

>
> On Feb 5, 2009, at 11:44, Charles McCathieNevile wrote:
>
>> 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".
>
>  From the point of view of a validator developer, placing stuff into  
> another document doesn't help, since the validator developer still needs  
> to understand what the specs made conforming and what non-conforming.

Right. But I don't think Mike's approach is meant to help a validator  
developer - you should read the full spec.

 From the point of view of many people, knowing that some simple document  
describes enough for them to generate conformant content is valuable.

>> 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.
>
> Validators can already issue warnings for anything that the developer of  
> the validator thinks is appropriate and the users of the validator  
> accept without changing validation providers.

Fine. But the HTML Working Group *could* also decide that some things  
should "generate warnings" - i.e. be conformant, but not recommended.

For example, I think we could get consensus that img with no al attribute  
is "conformant but not recommended". I don't think we will get consensus  
that img with no alt is conformant and recommended, and I am dubious about  
consensus that it is non-conformant.

It's up to the working group to decide whether it has a single conformance  
level or seventeen. It is up to the working group to decide whether some  
things are non-recommended practice, and to decide whether they want to  
specify that a conformant validator or authoring tool or browser or  
tutorial actually has any requirements for how it deals with such things.

>  From my point of view as a validator developer, it would be easier to  
> assess opinions formulated in terms of "a validator must report  
> condition foo as an error" or "foo is non-conforming" rather than  
> formulating things in terms of deprecation, since it seems that people  
> have a different idea of what functional requirements on validators  
> deprecation entails.

Sure. And from my point of view a a browser developer I would like to see  
all authoring tools marked as "conformant" or "non-conformant", since  
people have a clearly different idea of the functional requirements on  
browsers in the face of tools which don't generate correct markup. (HTML5  
is in part a reaction to the fact that I have never had that wish granted,  
and an attempt at an alternative approach).

> In the case of HTML 4.01, deprecation meant the creation of two distinct  
> validation targets: Transitional and Strict. Experience with HTML 4.01  
> shows that authors prefer the more permissive target.

What experience exactly? Mine it shows that authors more often *use* the  
more permissive target. Asserting from that what they prefer is unsound  
logic. You may have additional evidence for your statement, but you should  
either adduce it or clarify your terms.

> For HTML5, I'd like to avoid the introduction of multiple validation  
> targets if feasible even if that meant making the one target lenient  
> about stuff like <img border=0> and <applet>.

Fair enough. I would like HTML5 to clearly push against such things. The  
point of the working group is to reach consensus on our various and  
desires.

> (To be clear, <basefont> and the axis attribute are not the same kind of  
> stuff as <img border=0> and <applet>. :-)

To be clear, that depends on your perspective :-) Validators, browsers,  
tutorial writers, hand-coding developers, people who rely on their  
suppliers to make a decent authoring or transformation tool all have  
somewhat different perspectives (even if you assert that for example one  
browser maker can speak for "browser makers" - and my experience suggests  
that you would have to search for a while to find more obviously wrong  
things to say)...

cheers

Chaals

-- 
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 Tuesday, 10 February 2009 02:19:10 UTC