Re: ACTION-128: Draft @summary voting text in conjunction with PF

On Mon, 6 Jul 2009, Maciej Stachowiak wrote:
> On Jul 6, 2009, at 4:37 PM, Ian Hickson wrote:
> > On Mon, 6 Jul 2009, Maciej Stachowiak wrote:
> > > 
> > > I think highlighting effective alternatives plus optional validator 
> > > warnings will reduce the incidence of incorrect use.
> > 
> > So would you agree to a proposal wherein the spec:
> > 
> > * Gave a long list of possible ways to include explanatory text for
> >   tables (e.g. in <details>, in prose, in <caption>),
> > 
> > * Gave a couple of examples of explanatory text,
> > 
> > * Made the summary="" attribute non-conforming but made it a down-played
> >   error, meaning it would get a more friendly treatment in validators
> >   than a regular unknown attribute,
> > 
> > * Explicitly said that summary="" was obsolete but pointed to a section
> >   on how to give examples, and
> > 
> > * Encouraged authors (with a "should") to include explanatory text for
> >   tables that met certain criteria of complexity.
> > 
> > ...? Or do you think we should actually make summary="" conforming, as 
> > opposed to a down-played error?
> 
> I think the difference between down-played error and regular error is 
> not very meaningful. The actual material difference between different 
> diagnostic classes is not friendliness in the validator, but rather 
> whether authors can still use the feature if they have a requirement 
> (self-imposed or otherwise) to produce fully conforming content.
> 
> Thus, I think a suggested non-error diagnostic would be better than a 
> requirement for a down-played error, in that it would give the advanced 
> experts who choose to disregard the warning the opportunity to have 
> their content be conforming.

I've now made the spec do the following except with the third bullet point 
replaced with:
 
 * Made the summary="" attribute conforming but made with a warning from
   conformance checkers that the attribute is obsolete.


On Wed, 8 Jul 2009, Henri Sivonen wrote:
> 
> I don't like downplayed errors. On one hand they want to be errors but 
> on the other, they are something that are designed to be easily 
> ignorable. I have dragged my feet with them hoping they'd go away. One 
> day I almost started implementing them but then I got a higher-priority 
> item to deal with.

I've replaced downplayed errors with conforming features that trigger 
warnings. I've also taken the opportunity to trim the list of features 
that trigger this behaviour, so that we keep it to a minimum.


> I don't really like spec-prescribed warnings, either, because I fear 
> that if we start doing normative warnings, people start wanting to make 
> failures to adhere to their code style aesthetics as normative warnings 
> when the discussion won't affect valid/invalid.

I intend to avoid adding features to this list. We should definitely not 
add anything syntax-related to the list other than the old DOCTYPEs.


On Wed, 8 Jul 2009, Maciej Stachowiak wrote:
> 
> I think that would be a bad way to use warnings, and I hope that won't 
> happen. If we do introduce them, they should be reserved for things 
> where there is a strong reason to discourage a practice or alert authors 
> to pitfalls, but there are sufficient exceptions that making such 
> content blanket invalid would be excessive. Basically the rough 
> equivalent of a SHOULD NOT. Matters of aesthetics would not qualify. I 
> would hope there is broad agreement on this.

I've in fact used "should not" as the way to "allow" the features on the 
list.


> I also think validators should be free to have ways to turn off some of 
> the otherwise mandatory or spec-suggested warnings, or alternately to 
> treat warnings as fatal at the request of the user - the rough 
> equivalent of -Wno-foo and -Werror in gcc. I think this will further 
> reduce the temptation to use warnings for inappropriate purposes.

I haven't added text specifically about this yet.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 8 July 2009 08:27:31 UTC