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

Hi Leif (and whomever else is still thinking of 
updating their sections of the text),

At 11:08 PM 4/29/2011 +0200, Leif Halvard Silli wrote:
>Sorry, Judy, I did not manage before 17:00 Boston time ...

That's why I'd phrased my timeline request carefully... I'd said:

>(for practical purposes on this round, 5pm 
>Boston time, or please drop me a note if you're 
>expecting to send something later Friday evening),

I know it's late your time Friday evening, but 
please let me know if you've got some text that 
might be coming over. Otherwise I'll plug in 
fresh text that I receive by 9am Boston time on 
Saturday, but I'd rather not wait longer than 
that to update the draft clarification reply 
since I want people to have it before Monday's 
text alternative sub-group meeting (for which 
I'll be sending a notice out shortly).

Thanks,

- Judy


>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:18:57 UTC