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

Hi everyone,

It sounds to me like we're not coming to consensus on a single change to the spec here. Thus, it may be that the best next step is to formally write up some of the different options. In the meantime, I think this thread is verging on sniping. I'd like to commend Steve and Ian for keeping their lengthy exchange polite, but even there it seemed like the same points were getting repeated.

So, let's cool down a bit and only post if we have new information to add, and can do so in an even-tempered way. And let's prepare to describe and justify our preferred approaches in writing.

Thanks,
Maciej


On Feb 8, 2010, at 2:15 PM, Matt May wrote:

> 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