Re: "image analysis heuristics" (ISSUE-66)

On Feb 8, 2010, at 7:05 AM, Ian Hickson wrote:
On Mon, 8 Feb 2010, Steven Faulkner wrote:
*Please* explain how would the following text NOT be an improvement on
what is currently in the spec?  (which is nothing)
(...)
Well, first of all, it's not grammatically correct.

Perhaps accurate. Definitely unhelpful. Steve was trying to ask you how adding instructive text is worse than leaving it out. Grammar trolling is uncalled for.

Full text of Checkpoint--

2.3 Render conditional content (P1) Techniques for checkpoint 2.3

Allow configuration to provide access to each piece of unrendered
conditional content "C".
When a specification does not explain how to provide access to this content,
do so as follows:

If C is a summary, title, alternative, description, or expansion of another
piece of content D, provide access through at least one of the following
mechanisms:

(1a) render C in place of D;
(2a) render C in addition to D;
(3a) provide access to C by allowing the user to query D. In this case, the
user agent must also alert the user, on a per-element basis, to the
existence of C (so that the user knows to query D); and
(4a) allow the user to follow a link to C from the context of D.

Otherwise, provide access to C through at least one of the following
mechanisms:

(1b) render a placeholder for C, and allow the user to view the original
author-supplied content associated with each placeholder;
(2b) provide access to C by query (e.g., allow the user to query an element
for its attributes). In this case, the user agent must also alert the user,
on a per-element basis, to the existence of C; and
(3b) allow the user to follow a link in context to C.

I've read tax codes that make more sense than this. Are you seriously
expecting this to result in implementation improvements? The above is
completely incomprehensible.

Ah. Yes. Such an algorithm would be entirely out of place in a specification that has 15 "steps for finding one or two numbers of a ratio in a string", 18 rules (not including subrules) for parsing a list of integers, and 19 rules for parsing a legacy color value.

Honestly, Ian, the "I don't understand" act is really wearing thin. Not only is this passage entirely comprehensible to a mental no-op such as myself, to me it reads no differently from any of the dozens of algorithms present in the document. Somehow this has escalated from one suspect sentence to bashing some other specification for daring to _specify_ something.

Sufficient techniques

To satisfy provision one of this checkpoint, the configuration may be a
switch that, for all content, turns on or off the access mechanisms
described in provision two.
To satisfy provision two of this checkpoint, the user agent may provide
access on a per-element basis (e.g., by allowing the user to query
individual elements) or for all elements (e.g., by offering a configuration
to render conditional content all the time).
To satisfy the requirement of provision two of this checkpoint to allow the
user to view the content associated with each placeholder, the user agent
may either render the associated content in a separate viewport or in place
of the placeholder.

This provides no help whatsoever to implementors.

You have got to be kidding. This is basic stuff for an implementer to know, and in general pretty important for certain groups of users.

I've previously given two reasons why I think referencing UAAG for
specific implementation advice is a bad idea: implementors wouldn't follow
such links [1], and the logical conclusion of such a policy would be a
spec that consists of hundreds of such links, leading to an unreadable
specification [3]. To this, given the information regarding what you think
the useful advice from UAAG actually is, I can now add a third reason:
UAAG provides impenetrable advice that wouldn't help accessibility even if
it _was_ read. We can do better.

Here, the reader is asked to believe that the product of five years' work on helping UAs understand and build toward accessibility in their products is inferior to a single edit, made over the span of five minutes, by the editor who has been so hostile to the requests of the accessibility community in general that they formed a task force simply to resurface all of the friendly proposals he has already rejected.

Wow.

So again, I ask you, since you still haven't actually replied the question
I've been asking: on what basis do you think that referencing another spec
results in more accessible implementations than having inline text?

In a word, provenance. I'll put this as bluntly as possible. You, Ian, by words and actions, have proven yourself not to be a trusted resource for accessibility information. Which makes the belief you appear to have that you, individually, are in fact _the most_ trustworthy resource for accessibility information, all the more abhorrent.

The one thread that runs through all accessibility discussions in this WG has been that you, Ian, have consistently placed your questionable views on accessibility above all others, including impugning the integrity of those who dare to challenge your own bona fides. Until this culture of mutual distrust is broken down, this kind of back-and-forth, on even the most basic requests, is what the HTML WG is going to be wasting its time doing.

And this is just one informative sentence! Not @alt. Not @summary. One sentence. Is this the way things are going to go for the rest of the accessibility issues? If there's been any compromise in the document to date, I haven't seen it.

-
m