Re: Working Group Decision on ISSUE-30 longdesc

Maciej Stachowiak, Wed, 11 Aug 2010 23:41:58 -0700:

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

How does FO differ from Appeal of Chair's Decision? Reading this did 
not make me wiser:
http://www.w3.org/2005/10/Process-20051014/policies#WGAppeals

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

You want us to trust a change proposal system, were you are evaluating 
the arguments - evenly and accurately - on behalf of the group. You 
must therefore accept that the quality of your evaluations are 
discussed. And that is what I did and do.

In my view, "new information" includes documentation of errors and 
fallacies in the decision. And I note that both you as well as Sam have 
agreed that I have pointed out some inaccuracies.

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

Started: 
http://www.ietf.org/mail-archive/web/link-relations/current/msg00047.html
 
> Regards,
> Maciej
> 
> 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.

I know that he knows about the mechanical details. And that is why I 
tried to focus on the *semantical* differences. (Sorry to have gone 
into unnecessary detail.)

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

It is directly relevant in the sense that <a href=* rel="longdesc"> is 
meant to have the same function and semantics as @londesc="*" has. I 
believe it is correct to consider @longdesc as simply a strange looking 
and less explicit (thanks to lack of implementation etc) link. As 
Tantel said in his objection: the name «seems to imply a "long 
description" as even this survey misstates it whereas it is actually a 
URL.»

And this goes directly on to my question to Sam about what his 
definition of "require" is. The decision claims that there are no use 
cases which "require" @longdesc ... I continue to wonder what it means 
by that. When we focus on the function (URL) and semantics (a longer, 
supplemental description, according to HTML4), then there is is nothing 
which can serve as replacement (yet). Thus, currently - and also to 
some degree technically - if one wants to retain that combination of 
function and semantics in the HTML langauge, then @longdesc is required.

> Also, the possibility of rel="longdesc" does not 
> seem like it would affect the decision on the longdesc attribute.

Accepted.

> It 
> does not appear to relate to any of the arguments actually made.

Not accepted, since I see @longdesc and <a rel="longdesc" href="*"> as 
functionally and semantically equivalent - much the same way that 
<area> and <a> are equivalent. (A "perfect" equivalent also includes 
the @target attribute - <a rel="longdesc" href="*" target=_new >)

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

It is - thank God - not an 100% consistent viewpoint ... But I am very 
happy to hear this. :-D

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

So why do you talk about rel="longdesc" after I have described how 
wrong Sam has described Charles' statements? We cannot accept that 
decisions are based on straw man descriptions of the arguments.

> I believe Sam accurately summarized the arguments actually 
> presented.

Then we disagree: I believe that the summarizing of Charles' objection 
qualify as a straw man. There are other summaries I disagree with as 
well - but I'll spare you (for now at least ...)

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

Yes. But most of them are _not_ raised and addressed in the _decision_ 
- as the decision does not focus on semantics. That's why I asked Sam 
to describe the semantics.

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

I did not get the impression that what was said about Internet Explorer 
was meant to be something which supported inclusion. But perhaps I was 
wrong there.

Otherwise: there are many things that have been said in the debate. 
Even if Lachlan and I forgot to talk about rel="longdesc" in the 
survey, that does not mean that it can't be found by googling the 
mailing list. My point being: If the chairs are unable to ask for the a 
definition of "successfully", then perhaps there is an answer in the 
mailing list? Whereas if a chair does his own independent research on a 
user agent (instead of googling and asking the members for they have 
already found out), then the members are not given a way to 
discuss/contest these findings. (Other than in a formal objection or 
something like that.)

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

Where am I then to make such fair points? 

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

I found my own improvement suggestions to be quite specific - I even 
filed 2-3 bugs while I wrote my objections. (And I am now wondering 
what impact this decision eventually will have on those bugs ...)

With regard to "more work is needed": About some _included_ features 
(such as <figure>), you considered - but decided to put aside - the 
"more work is needed" line of thought (a.k.a. 'halfbaked') as an valid 
argument for throwing it out. However, when it comes to longdesc, then 
we are talking about a feature which is not included yet, and which the 
editor therefore has not lifted a finger to specify, yet. Instead, all 
editor energy has gone into telling how bad the feature is. longdesc 
isn't even half baked - it is instead an interesting raw material has 
been left to rot in a junk yard.

It goes without saying that to juxtapose the more work that longdesc 
requires with the more work that an already specified and included 
feature requires, must end up looking unfair. I consider it entirely 
_unvalid_ to point out that something that hasn't been worked on at 
all, yet, requires more work.

Besides, we have some design principles that we sometimes hold high and 
which states that more work for the editor is not something that cane 
be used as argument against a feature.

>> As long as @longdesc is obsolete, we cannot even implement the lowest 
>> hanging fruit: URL validation, which is something Validator.nu 
>> 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
-- 
leif halvard silli

Received on Friday, 13 August 2010 00:21:17 UTC