Re: Working Group Decision on ISSUE-30 longdesc

On 08/11/2010 07:56 PM, Leif Halvard Silli wrote:
> 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?

Key phrase: "that clearly and directly support this specific feature of 
the language"

There certainly are use cases for providing textual descriptions.  There 
are multiple ways to provide such.  None of the use cases described 
clearly and specifically required the addition of a longdesc attribute 
to the language.

> 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"?

http://www.w3.org/2002/09/wbs/40318/issue-30-objection-poll/results#xkeepnew

Charles McCathieNevile point 2.

> 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".

An attempt was made to determine what use cases require longdesc. 
Apparently we agree that "opening in a separate window" is not one of them.

> 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.

http://www.w3.org/html/wg/wiki/ChangeProposals/longdesc

The rationale consists of two paragraphs.  The first contains some 
background context.  The second makes two points, one concerning 
implementations, and one concerning benefits.  Neither are substantiated 
in the the change proposal itself.

Efforts were made to identify what implementations could have been 
referenced by this rationale.  Eventually, trying to determine whether 
or not IE supported longdesc lead to the following page:

http://msdn.microsoft.com/en-us/library/ms534132%28VS.85%29.aspx

You are correct that iCab and Jaws should have been cited.

The existence of addons wasn't mentioned in any objection or change 
proposal.

> 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.

It is neither obvious nor generally agreed upon that longdesc has been 
deployed successfully.

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

Improving (as opposed to replacing) was a point that Laura repeatedly 
made.  That point had nothing to do with the editor.

- Sam Ruby

Received on Thursday, 12 August 2010 01:22:31 UTC