W3C home > Mailing lists > Public > public-html@w3.org > February 2012

Re: Split Issue 30?

From: Charles Pritchard <chuck@jumis.com>
Date: Fri, 10 Feb 2012 11:25:02 -0800
Message-ID: <4F356F0E.6060702@jumis.com>
To: Maciej Stachowiak <mjs@apple.com>
CC: Laura Carlson <laura.lee.carlson@gmail.com>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, public-html@w3.org
On 2/10/2012 10:48 AM, Maciej Stachowiak wrote:
> On Feb 10, 2012, at 9:43 AM, Laura Carlson wrote:
>
>> Hi Leif,
>>
>>> Well, OK, to the Chairs, then unique use cases for
>>> @longdesc seems to be crucial.
>> I reject the notion that providing unique use cases that *only*
>> longdesc can fulfill is to be the deciding factor for including
>> longdesc in the language.
>>
>> If I misunderstood the original decision and this is the intent and
>> will be the determining factor, perhaps a Formal Objection should have
>> been made after the first decision on that basis instead of the
>> reopen.
> That was indeed the original basis for the decision. While I do not want to prejudge the reopened issue before it goes to survey, I expect there are at least two paths to making a strong case for longdesc:
>
> (1) Show that some valid use cases can *only* be fulfilled by longdesc.
> (2) Show that for some valid use cases, longdesc has significant benefits over other possible solutions, even if it is not the only solution; these claimed benefits would then be weighed against the claimed harmful effects of longdesc.

Why was the large list of valid use cases included in the Change 
Proposal insufficient?

Not only did the longdesc CP include dozens of use cases, active uses, 
and other blocks of information, the other two proposals were analyzed 
and found to be distinct and different from the longdesc semantic.

We are dealing with arbitrary language here. I can claim that my new 
feature "<ItsAllAboutMe arbitrary-attribute=http://url.com>" can fulfill 
the longdesc use case. I can just take longdesc and rename it, and 
fulfill the longdesc use case.
I can say that, well gosh, if we just change the way the anchor tag is 
processed in CSS, and add new css directives, then gosh, longdesc isn't 
needed.

Here: '<a rel="longdesc" href="page.html" 
style="css-ignore-this-tag-in-all-css-selectors: true">'. I've fixed it!
Here: '<img rel="page.html" />'. I fixed it again!
Here: '<img aria-label="My really long description with <em>embedded 
html</em>">'. Yet another fix!
Here: '<img aria-describedby="iframe" /><iframe defer id="iframe" 
src="page.html" />'. I am amazing at this!

Maciej, what you're saying is valid, but it was valid prior to the long 
list of documented reasons for keeping londesc. Now it seems to ignore 
the content presently available in the wiki, and the discussion 
presented on this list.
The reason my four examples don't work has been covered repeatedly on 
this list.

If we allow for re-invention, we're going to keep going in circles. It's 
been established that longdesc's current functionality is not met by any 
other existing semantics. There are some close ones, certainly. Because 
that's been established, the conversation has turned toward improving 
existing semantics so that longdesc can be deprecated. That's circular 
reasoning. It's maddening Maciej, and I am afraid this kind of 
crazy-making leads to hostility and grief in what should be an otherwise 
clean and cooperative process.

-Charles
Received on Friday, 10 February 2012 19:25:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:44 GMT