Re: Working Group Decision on ISSUE-30 longdesc

Hi Leif,

Thanks for taking an interest in the ISSUE-30 decision. At this point in the process, the kind of input we need is one of two things:

(1) A Formal Objection (or the similar but subtly different Appeal of a Chair's Decision) from anyone who cannot live with the decision and wishes to escalate it to the next level.
(2) New information that could lead to the issue being reopened.

Since you didn't formally object, I tried to review your message to see if there was relevant new information. It did not seem that way to me -- see specific comments below. In future messages, please think about whether you are adding relevant new information.

On one particular point you raised, the idea of an <a rel=longdesc> link relation, I believe this decision has no bearing on whether such a relation could be registered. In fact, if you believe it is a valuable addition to the language, then now seems like a good time to register it, since we are interested in having a fair test of the registry.


On Aug 11, 2010, at 8:10 PM, Leif Halvard Silli wrote:

> Sam Ruby, Wed, 11 Aug 2010 21:22:03 -0400:
>> 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.  
> This is much too unprecise. Longdesc is not for "providing textual 
> descriptions". It is for providing an _longer alternative_ to an 
> existing textual description.
> In contrast, there is no guarantee that aria-describedby provides the 
> user with a long variant of the existing short description. An 
> aria-describedby attribute can contain references to several fragments 
> of a page - no one knows exactly what to expect from it. Same with a 
> general link - its relationship is not always clear. When it comes to 
> <figure>, then I don't quite understand how it can be associated with 
> longdesc.

I don't think this particular point is providing new information. It's true that Sam could have chosen different wording, but I know he is well aware of the potential alternatives to longdesc and the fact that their mechanical details are in each case somewhat different.

>> 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.
> Is longdesc anything _but_ a link of long description type for the IMG 
> elment and frames? Are you willing to restate the above as follows: 
> "None of the use cases described clearly and specifically required the 
> addition of *a* longdesc *link type* to the language" ?? (I hope not.)
> The lack of longdesc link that can be attached directly to the IMG, 
> means that e.g. in a collection of images, the ones *with* a long 
> description will have to be marked up in a way different from those 
> without a long description.
> Mind you: rel="longdesc" is not part or HTML5. Thus, that option is not 
> amongst the "multiple ways", yet. Are you rejecting longdesc because it 
> hypothetically can be solved in a different way?

The idea of rel="longdesc" is an interesting one. However, it doesn't seem directly relevant to the decision. The decision does not rule out adding new mechanisms to the language, either to the core spec, or as an extension. Also, the possibility of rel="longdesc" does not seem like it would affect the decision on the longdesc attribute. It does not appear to relate to any of the arguments actually made.

And, to be absolutely clear: this decision has no bearing on a future rel="longdesc" proposal. The chairs will not assume that there is a WG objection to registering such a rel value; it is up to individual WG members to discuss the idea.

>>> 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"?
>> Charles McCathieNevile point 2.
> OK. But my critic were on you, for accepting that that claim is 
> "uncontested". 
> Secondly, you are - again - disappointingly inaccurate: Charles 
> statement was an objection towards the null change proposal, about 
> which he said "This proposal fails to adequately address two 
> functionalities of the longdesc attribute." And then he cited "A method 
> to reference a longer description of an image, without including the 
> content in the main flow of a page" as one of those two 
> functionalities. Where in this did Charles state what you attribute to 
> him?

I don't believe this adds relevant new information either. The decision is only about the three proposals actually on the table: one to restore longdesc as conforming, one to make it nonconforming, and one to make it conforming with a warning. No one submitted a proposal suggesting use of a brand new mechanism, such as rel="longdesc". So the fact that it could match some of the functionality is not relevant. I believe Sam accurately summarized the arguments actually presented.

>>> 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.
> From "expressed in hypothetical manner" to "we agree"? 
> You complain about lack of definition of "successful". But where is 
> your definition of "require"? 
> Do you see any good in longdesc at all? Are you able to see what it 
> was/is meant to be? Can you describe how to do it in another way? Yes, 
> we can remove longdesc. But that requires that we replace it with 
> something equivalent. If - of course- we are able to spot a use case 
> for it. If there is no use case, then there really are no other way to 
> do it either - talking about alternatives becomes meaningless.
> Gez describes it the best way: Longdesc gives the user a choice: he/she 
> can read the alt text. And if he/she wises, the user can open the long 
> description as well. ARIA does not provide this, says Gez. <object> 
> also doesn't, I say. Object gives you the long description at once. 
> Well, it is always possible to place a short description as fallback of 
> OBJECT, and then have a link to somewhere else, inside the <object>. 
> However, HTML5 is geared towards IMG. 

I don't think this adds new information either. Most of these questions were raised and addressed already in the survey.

>>> 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.
>> 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.
> You demand perfection from the arguments. But you yourself serve us a 
> document which states that someone has claimed that Firefox had a 
> successful implementation. Which no one has claimed.

I believe Sam did his best to list every longdesc implementation that was cited, and even tried to do research to find more. If anything, being more generous in counting implementations would cut against the decision.

So, while I think you have a fair point here, I don't think it provides relevant new information.

>> 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:
> And have you tested whether that holds true?
> When IE8 came out, its claimed longdesc support created a puzzle. If 
> you look at the work blog of Steve, you will find there, somewhere, a 
> post about his investigation of in what way IE8 does (not) support 
> longdesc. I guess there is a reason for why no one has brought IE to 
> the table as the successful implementation. IE also has unsuccessful 
> implementations of a whole range of other things.
>> You are correct that iCab and Jaws should have been cited.
>> The existence of addons wasn't mentioned in any objection or change 
>> proposal.
> Why weren't efforts made mention in the decision? Why did you not 
> investigate what Jon said about Firefox?
>>> 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.
> The string "deploy" does not appear a single time in the decision 
> document. Nor amongst the objections. Nor in Charles proposal. Charles 
> talked about "implemented multiple times successfully". It is not clear 
> to me how "deploy" is relevant (but that might because I don't fully 
> understand what it means). 
> In principle, how it should best be implemented, can be discussed. The 
> implementations I have seen implements it in the chrome and/or in 
> contextual menus. But authors may also use CSS to make readers aware of 
> it - plus that there is a DOM interface for it.
>>> 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
> The decision document clearly cites "more work is needed" as something 
> which opposes inclusion of longdesc. However, pointing out that more 
> work is needed is about being honest. It would be dishonest to say that 
> there is no problem.
> The more work that is needed would primarily fall on the editor and on 
> conformance checker developers.

I believe the chairs have been consistent in counting "more work is needed" as an argument against new features, but a relatively weak one, particularly when there is no specificity about the particular work needed.

> As long as @longdesc is obsolete, we cannot even implement the lowest 
> hanging fruit: URL validation, which is something 
> implements for all other attributes which take a URL. It seems to be 
> uncontested that URL validation is one of the thing that longdesc needs 
> the most. (But for some reason, you chose to not say the same thing.)
> I don't understand your point about the editor. My point was only that 
> as long as it is obsolete, the feature is simply parked, and nothing to 
> improve it happens.
> Finally, I find the point that uses are not aware of this feature as 
> pretty moot: Users don't care how thing is implemented. We don't need 
> that users know that there is something called @longdesc.
> -- 
> leif halvard silli

Received on Thursday, 12 August 2010 06:42:33 UTC