Re: ISSUE-30 (Longdesc) Change Proposal

On Mon, Oct 26, 2009 at 3:51 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> Jonas Sicking On 09-10-26 22.55:
>
>> On Mon, Oct 26, 2009 at 11:26 AM, Leif Halvard Silli
>> <xn--mlform-iua@xn--mlform-iua.no> wrote:
>>>>
>>>> However, it has been implemented multiple times successfully. The fact
>>>>  that there is bad data associated might account for low overall usage,
>>>> but
>>>>  has relatively little impact on implementations, which can readily
>>>> choose
>>>>  to simply ignore values which are not URIs, or even to present the
>>>> value
>>>>  to the user, and relatively little impact on the user, who can still
>>>>  benefit from a *good* usage.
>>>>
>>>> This would require conformance checking to accept the attribute as
>>>> valid,
>>>>  and would imply maintaining the existing requirement on Authoring
>>>> Tools[2]
>>>>  to allow the author to use this functionality. It would maintain
>>>>  conformance of HTML-4 tools and content, rather than the current
>>>> expected
>>>>  change leaving them non-conforming.
>>>
>>> Another argument for this feature is, I think (as have been mentioned
>>> earlier) that aria-describedby="" can be used for the same thing.
>
> I found Lachlan's comment in September: [1]
>
>> That would just be reinventing longdesc with a different name without
>> solving any of the problems that longdesc has.
>
> However, upon rereading, it seems like Lachlan was actually expressing
> satisfaction that describedby and longdesc has not been defined the same
> way. There are other comments in that same thread expressing similar things.
>
>> Wouldn't that be an argument *against* either @longdesc or
>> @aria-describedby? Having two features with the same purpose seems
>> like a bad thing. Or am I misunderstanding something?
>
> You at least found this part of my reply more interesting to comment than
> the rest of my message ...
>
> Hypothetically, *if* @aria-describedby and @longdesc were the same thing,
> then it would have meant that in 2009, a W3 working group has found the
> @longdesc feature worth specifying, again. That would be a tribute to
> longdesc, I think. We could then have offered @longdesc a luxury pension:
> obsolete but valid.
>
> However, as the rest of my letter hinted, @longdesc and aria-describedby are
> different. @longdesc has a much more fixed behavior than aria-describedby
> has - and is much more single purposed than aria-describedby. See the other
> replies in this thread. The primary specialty of longdesc is simply that it
> is only meant for IMG, FRAME and IFRAME - the rest of its inherited behavior
> follows from that.

I agree that @longdesc and @aria-describedby aren't exactly the same.
However they are very similar. They were both designed to solve the
problem: "provide a description for an element". The only differences
that I see is that @longdesc only solves the problem for a small set
of elements.

Also, syntactically @aria-describedby has a larger syntax if the
description is in an external document. I don't know why WAI chose to
use this syntax rather than that of @longdesc. However I would assume
that they did consider the @longdesc syntax and felt that the current
@aria-describedby syntax is superior.

Given that, it seems to me wasteful to have two features with such a
large overlap. Further it seems like technically @aria-describedby is
a better technical solution since it's available on all elements. Thus
the only reason I can see for keeping is if removing support for it
breaks a lot of web pages. From what I understand data doesn't
indicate that there is a lot of usage out there?

I don't think the fact that "there are several implementations" is a
good argument for keeping @longdesc. This simply proves that the
feature can be implemented. However using that as a criterion for
putting a feature in the spec is IMHO a low bar.

> I think now that we have gotten aria-describedby, we do not need to "bend
> over backwards" for either of them, but can let each of them have their own
> specialties.

Features are not free. There's a significant cost to documenting,
evangelizing, testing, implementing and QAing a feature. And that's
just the upfront costs. It's impossible to know what the costs are in
the future. For example if one UA implements @longdesc wrongly (due to
a bug or misunderstanding the spec), this can lead to content coming
to depend on this new behavior. This leads to implementations having
to reverse-engineer each other and many times more complex behavior.

There's also a risk that the feature will get in the way of future
features due to name collisions or due to feature overlap.

For what it's worth, I feel the same way about @summary, which is also
better solved by @aria-describedby.

/ Jonas

Received on Tuesday, 27 October 2009 01:45:24 UTC