Re: img@relaxed CP [was: CfC: Close ISSUE-206: meta-generator by Amicable Resolution]

On Tue, 07 Aug 2012 19:12:33 +0200, Leonard Rosenthol <lrosenth@adobe.com>  
wrote:

>> I don't think adding this attribute to the HTML language would be  
>> inherently harmful or bad. That said, I do think we if we add it to the  
>> spec, we should do it >on a provisional basis, with a plan to look at  
>> the effects of it a year or two from now a evaluate whether it's been a  
>> success or not, and drop it if it turns out >to not have worked out the  
>> way we'd hoped.
>>
> Which would seem to imply that moving this discussion to HTML.next would  
> make more sense than trying to deal with it, at this late date, in HTML5  
> proper - since, as you rightly note - we don't know how this would work  
> in the real world.

The issue is what should be moved to HTML.next and what we should have in  
HTML in the meantime. A couple of people who make validators have said  
that there is a problem where they believe that giving warnings for a  
common error leads to authors adopting a bad "solution" to suppress the  
warnings. You and Steve have pointed out that this hasn't affected key  
tool-generators. It seems almost everyone wants to remove the existing  
meta-generator exception, but some people believe we *need* a replacement.

Personally, I am unconvinced by the logic or what data I have seen, and  
would be happy to remove meta generator and not add a replacement. But I  
think it is useful to agree on an outcome, and despite a lot of  
reservations I can live with a marker attribute . Given that what we are  
doing is trying to influence behaviour, it certainly makes sense to review  
whether we succeeded much as we have looked at the "meta generator" stuff  
that has been in HTML draft versions for a few years, and decided that it  
makes no sense and should be removed.

>>> Wouldn't be in everyone's (users, developers, standards writers, etc.)
>>> to simply invest in the creation of an accessibility checker?
>>
>> Yeah it certainly would.
>>
> Which would also be a great project to kick off as part of the HTML.next  
> work on this topic...

I strongly support continued development in this area. But I am very  
skeptical that this is a real solution - it would be great, but so would a  
perpetual motion machine. One reason there is a healthy competitive market  
in this area is because there are many possible acceptable outcomes, and  
while there is general agreement on the difference between good and bad  
there is no such agreement on the difference between truly excellent and  
almost perfect.

It seems that we are looking for ways to convince people that adding  
alt="" or alt="(something)" to *look* like you have resolved the issue is  
worse than just not completing the task of adding useful alt in the first  
place. It seems that the ATAG requirement along those lines, which is over  
a decade old, or parallel efforts along the same lines, has managed to  
convince a number of key developers. It seems to me that while it is also  
not a perfect approach, that effort might actually be the one that  
achieves the real goal here.

In the meantime, nothing has ever stopped validator makers adding an  
option to ignore some error and re-validate - and the "old" HTML validator  
always provided a few functions like that (for things like doctype and  
encoding). If the question is whether we should allow validators to  
automatically apply such an option and still claim to be properly  
validating, I think we're looking in the wrong direction...

cheers

Chaals

-- 
Chaals - standards declaimer

Received on Wednesday, 8 August 2012 11:32:48 UTC