Re: Working Group Decision on ISSUE-30 longdesc

Sam Ruby, Wed, 11 Aug 2010 09:16:05 -0400:
> Here is the decision. It has been drafted in HTML format to aid readability.

The decision contradicts itself on an important point. Consider:
	]] alternatives exists (explicit links, aria-describedby,
	   figure captions) [[
Against:
	]] The strongest argument against inclusion was the lack of use
	   cases that clearly and directly support this specific feature
	   of the language [[

Question: If it is uncontested that "alternatives exists", then how can 
it be contested that use cases exists? What exactly do you mean here?

The decision further claims - under the heading "Functions" - that:
	]] It was stated that without this attribute, there is no current
	   way to reference a longer description of an images without 
	   including the content in the main flow of a page. 
		... snip ...
	   While the former is uncontested, ... snip ... [[

I'm sorry, but this seems rather weasel worded. Or, to put it clearly: 
This *is* contested! One can simply do <a href="longdesc"><img src=* 
alt=* ></a> - no need to include any content in the main flow of the 
page. Ian has also, correctly, once mentioned that <object> is an 
alternative - such a thing does not add anything to the main flow of 
the page.

And, by the way, in which objection was the above stated? Did anyone 
say "strawman"?

The most important problem of the decision document is that it lacks a 
focus on semantics. One of the objectors, Lachlan, suggested early on 
that one could do something like this instead of using @longdesc: 
	<a href=* rel=longdesc href=URL ><img src=* alt=* ></a>
And Lachlan's proposal was spot on with regards to the *semantics* of 
@longdesc. It is the best alternative to @longdesc, so far. And, to be 
honest, I am considering accepting this decision, and instead focus on 
registering rel="longdesc" in the link type registry. The only problem 
I have, when I am considering the rel="longdesc" solution, is that your 
decision uses so much energy in stating that there is no use case, that 
I really wonder if if rel="longdesc" would have your support. Or, 
perhaps someone would point to your longdesc decision and reject 
rel="longdesc" on that ground. (Therefore, please clarify the 
contradiction I pointed to above.)

Under the Functions heading, the decision also states:
	   ]] It was further stated that user agents could very well open 
          this content in a new window.  … snip … As to the latter, 
this 
	      was expressed in a hypothetical manner, and therefore was 
          not given much weight. [[

Since this refers to my objection: that was a very bad willed reading 
of what I said! Yes, I said "could very well open in new window". But 
e.g. one paragraph above I said: ]] @longdesc usually works like an <a> 
element with a target="_blanK". (iCab, Jaws and others) [[.

Otherwise, you could just have read the e-mail that was linked to that 
statement, in which I explained how iCab works. But the crucial thing 
is not that it is implemented exactly like that (even though I consider 
such implementations a fine interpretation of the semantics!), but - as 
Gez said in his objection - the alternatives (when we look away from - 
in some fashion - using explicit links) "doesn't allow the user to 
control how they interact with the longer description".

Finally, some notes which goes on the quality of your document:

Under the heading "Implementations" you lower the credibility of the 
decision arguments, with several inaccurate statements:
	]] It was stated that the longdesc feature was implemented multiple 
times successfully. Cited were Opera, Firefox (which apparently 
subsequently removed this feature), Dreamweaver, and XStandard. Newer 
versions of IE may produce a tooltip based on this information under 
certain circumstances. No criteria was provided for the adjective 
"successfully". [[

However, a simple comparison with the actual objections reveals the 
following:
	1: Firefox was never cited as a successful implementation. The only 
one who mentioned it, was Jon, who mentioned it as an *unsuccessful* 
implementation. He did, however, not say in which version of Firefox 
there had been such support. And he also did not state by which 
criteria it was unsuccessful: Was it the fact that their implementation 
was so "poor"? Or was it the fact (?) that it received so little usage? 
Or was it the combination of those to factors? And btw, how was he able 
to *measure* that it "received so little usage"?
	    It is another thing that Firefox has *add-ons* which provide this 
feature (last updated in January 2010). Patrick Lauke's earliest 
version of his longdesc add-on is from March 2005, which is before 
Firefox 1.5 was released. Thus I question whether it is true that 
specifically Firefox has ever implemented @longdesc - perhaps Mozilla 
has, but not Firefox.
	2. Despite stated in the objections, you have overlooked that Jaws was 
cited.
	3. Despite stated in the objections, you have overlooked that iCab was 
cited.
	4. I am unable to see that any objectors have commented on the tooltip 
that newer versions of IE is able to produce. Compared with the many 
times the decision document applies a quite literal and 
not-exactly-good-will reading of the objections, I find it remarkable 
that you, on your own initiative, brings in how Internet Explorer works.
	5. It would have been more relevant to mention that Internet Explorer 
(even in old versions, I believe) when used together with Jaws (a 
combination which Charles mention in his objection) makes longdesc URLs 
accessible to the user.

Sloppy errors like that undermines the trust in the rest of your 
arguments.

As to to the lack of ]] criteria … for the adjective "successfully" [[. 
This does not feel like 100% honest critic.  It is pretty obvious that 
what Charles meant to say in his proposal, was that it is easy to 
implement @longdesc - it is not a complicated feature: It is simple to 
read what HTML4 says about longdesc, and then to implement it. Longdesc 
is even defined in the DOM specifications. Btw, I have previously asked 
iCab's developer, who claimed that longdesc is very simple to add. 

Finally, you cite as uncontested that ]]more work is needed to make 
longdesc useful [[. But of course! The editor has made it obsolete! 
-- 
leif halvard silli

Received on Wednesday, 11 August 2010 23:56:40 UTC