Re: [text] updated draft of clarification on alt validation

Sorry, Judy, I did not manage before 17:00 Boston time ...

Benjamin Hawkes-Lewis, Fri, 29 Apr 2011 21:13:18 +0100:
> On Fri, Apr 29, 2011 at 8:18 PM, Leif Halvard Silli:
>>>> 3. EVIDENCE: LACK OF ALT CHECKING IS HARMING
>>>>   Additionally, since the HTML5 validators does not currently perform
>>>> any validation of whether alt is present at all or of how it is used,
>>> 
>>> This is incorrect. See the "Show image report" feature at
>>> http://validator.nu/.

>> 
>> I maintain that this is correct. There are two validators: validator.nu
>> and validator.w3.org. Only the former has an image report. But the
>> image report is just that - a report.
> 
> Fair response. I still think this compromises the purity of the test.

I'll mention the image report.

>> The selection consists of pages made by "HTML5 pioneers" and people who
>> teach others about HTML5 authoring. These are "to notch" authors and
>> not "average joe".
> 
> I've rarely found tech-hype pages of this sort to be beacons of best
> practice; usually the reverse.
> 
> Top-notch HTML authors shouldn't need a validator to remind them to
> include an @alt.

And (text) authors shouldn't need dictionaries? 

I think everyone needs a validator.

>>>> A generator exception for img elements remains a form of
>>>> versioning.
>>> 
>>> I find this argument sophistic.
>>> 
>>> Document versioning was dumped from HTML because having versions trigger
>>> multiple code paths in user agents did not solve any problems the WG
>>> agreed were worth solving.
>>> 
>>> The generator exception does not require multiple code paths even in a
>>> conformance checker, it's just yet another rule in its ruleset, and it
>>> does *try* to solve a important problem (specifically, the generation of
>>> bogus "alt" text).
>> 
>> * the generator string creates "multiple code paths" in tools which
>> generate web pages
> 
> How? Such tools should apply the generator flag. That's one code path
> not two.

HTML5 doesn't make it *obligatory* for generators to use the generator 
flag. If it were obligatory, the much less should there be a 'generator 
exception'.

>> and in the heads of the authors.
> 
> I don't find this metaphorical leap persuasive.

Another try: If I use HTML4 doctype, then a the '</' in the example 
below, per the HTML4 validator's SGML rules, causes the SCRIPT element 
to end due to little known SGML parsing rules. This, in turne, causes 
the HTML4 validator to see an end tag '</script>', for which it doesn't 
see a start tag.

<script type=type/javascript>
   document.write('</i>');
</script>

This, in turn, causes numerous of questions in the mailing list for the 
W3 HTML validator. In order to understand and solve the problem, 
authors must have two thoughts in their head simultaneously: how the 
validator think and how browsers think. This is always difficult and 
very easy to forget etc. The generator exception creates a similar 
illogical and hard explained gap in the rules. 

>> * by your reasoning here, the difference between 'transitional' and
>> 'strict' is not related to versioning.
> 
> Transitional doctypes triggered almost standards mode in Gecko,
> so they invoked multiple code paths.

And apart from that, they were OK?

> My impression is that the WG rejected versioning to avoid code branching
> in web engines to deal with HTML5 differently than other text/html based
> on some magic string at the top of the file (as originally requested by
> Microsoft, for example). Such code branching is bad because it hurts the
> competiveness of the browser market by significantly increasing the
> burdens on browser makers. I'm not saying there have not been other
> arguments, but that stands out to me as the one that actually mattered
> over the years.

The generator exception would burden developers and authoring tools 
creators. E.g an author who wants full validation must remove the 
generator string via post-editing with a text editor. Or the generator 
must offer a way to not publish the generator string. Or a new kind of 
generator flag would be invented by the tool vendors (e.g. a HTML 
comment ...).

> I don't think the WG will see itself as having nailed itself to the
> cross of making no difference in conformance requirements for different
> situations, so I think trying to hook ourselves to the no-versioning
> cart does us no favors here.
> 
> I think we're stronger making arguments directly from clearly
> articulated user, author, or implementor needs or problems. If we can
> cite specific rationale from past decisions, all the better.
> 
> e.g. Authors expect validators to act in a transparent manner. If the
> validator silently passes over missing @alt in generated code that will
> trick authors who are used to errors raised over their hand coding into
> thinking they haven't missed an @alt.

Good point, that I've also made (but perhaps not in this letter). I'll 
see if I can incorporate it. 

>>>> Authoring tools vendors are not going to be willing to stamp their own
>>>> code as substandard, let alone use their own product names as a
>>>> sub-quality marks.
>>> 
>>> The generator flag doesn't establish two tiers of document quality
>>> beyond the
>>> obvious - generating good text alternatives requires human input.
>> 
>> I don't see that you contradict what the text says.
> 
> I don't think the text is a realistic portrayal of how vendors
> will see the flag. Maybe find some tool vendors who
> would actually refuse to use the flag, so that we have
> specific evidence of this?

I'm not going to look for any authoring tool vendors ... Firstly: what 
should I ask them? Second: I am embarrassed to ask them - I'm ashamed 
about the entire, childish exception. Having to spend hours to get the 
chair to reopen this issue is  ... well.

I do continue to think that the current spec text expresses negative 
thoughts about what code generators allows authors to produce versus 
what code hand authoring authors produce. This is perhaps the real 
problem. I can agree that many authoring tools vendors will probably 
insert the generator string regardless - not least because they won't 
be aware of the very issue or would find it quite stupid. It depends on 
what kind of programme they make, too.

Btw, usually it is said that high level coding/programming languages 
leads to less programming/authoring errors. Clearly, as generator can 
likewise produce much more code of a - in general - higher quality than 
what hand authors can produce.

>>>> C: GENERATOR IS ALREADY IN USE FOR OTHER PURPOSES
>>>>   Authoring tools use the generator string as a kind of signal to
>>>> those who view source - to identify pages made by their product.
>>> 
>>> How many any authoring tools that do not have any features for 
>>> automatically
>>> generating markup insert the generator flag? If they generate markup,
>>> then the generator flag is appropriate.
>> 
>> What is not appropriate is for the spec/validator to draw any
>> conclusions about the @alt usage based on the fact that it is a
>> generator made page.
> 
> I think it is entirely possible to make a good inference about markup
> that does not reflect the intention of an author, so I disagree that
> this is intrinsically wrong. And in this case, we're talking about an
> inference made from a statement by the author (or their tool), rather
> than just some random quirk of the markup.

Elsewhere you have hinted that generators should/must insert a 
generator string. In another thread, Steve and you found that 27% of 
pages have a generator string. Clearly, the real percentage of 
generator produced pages is nearer 72% than 27%. 

The authoring tools that refer to themselves as 'generator' are very 
very diverse. From wiki system and other CMS systems, to e-mail 
conversion tools and other HTML converters to different kinds of 
WYSIWYG-like Web page eeditor that sits on a computer.

The issue taken up under point C is that HTML5 suggests a validation 
criteria be glued on to the very authoring tool identity string. I 
don't think you have denied that this is true. 

It would, in my view, be more honest to forbid the entire generator 
string than to attach a hidden validation criteria to it.
-- 
leif halvard silli

Received on Friday, 29 April 2011 21:09:07 UTC