Re: longdesc Re: Clarification of rational for deprecation...

On Wed, 06 Feb 2008 16:25:55 +0530,  
<stephane.deschamps@orange-ftgroup.com> wrote:

> -----Message d'origine-----
> De : Charles McCathieNevile
>
> Charles said music to mine ears, among which:
>
>> So while some things (especially while they were not well supported)  
>> have resulted in abuse, I don't think it follows that we should
>> therefore assume there is no baby in the bath, and just tip it all
>> out - especially, if the actual cost of the abuse is low, and in the
>> longdesc case I claim that the real cost of abuse compared to the
>> benefit of good use is vanishingly small even when most usage is
>> incorrect.
>
> True, we *should* keep the mechanism.

Which is music to *mine* ears.

> (sorry for the bad-bad-bad quoting, my email client is not up to par)

( Quel glandage... just manually edit it llike I do :P )

> I've been pondering for a little time now, and read
> http://esw.w3.org/topic/HTML/LongdescRetention
...
> In the wiki, someone suggested using <div role="longdesc">. I'm not a big
> fan of it as it complicates CSS implementation
...

I'm not sure it does, but I am not a fan of the mechanism for the same  
reason I am not rapt in the following proposal:

> What about simply introducing an optional <longdesc> container for inline
> and block-level content as a child of <figure>:
>
> <figure>
>   <img src="rintintin.jpg">
>   <legend>The almighty RinTinTin</legend>
>   <longdesc>
>     <p>This is a black-and-white photo of Rintintin, a german shepherd
> featured in a TV sereies somewhere in the sixties</p>
>     <p>It shows the dog, sitting, its tongue out of its mouth. Its eyes  
> say
> "I love you". Silly dog, really.</p>
>   </longdesc>
> </figure>

IMHO, the reason not to do this is twofold.

One is that you have a new element that won't be recognised by existing  
authoring tools, user agents, assistive technologies, educational  
material, etc - so you slow down quite considerably getting back to the  
small but important gains longdesc has given.

In addition, this is replicating what longdesc does, but a magical  
parent-child relationship seems harder to deal with than an attribute that  
is a pointer. For instance, if I had a full description page (rich media,  
not just a few lines of text) describing my drawing of Guerníka, but  
didn't want to put that content in the same container element as the  
image, what would I do in the proposed model? In the existing longdesc, I  
put it somewhere else and add a pointer - people who want it get it, the  
rest are free to ignore it and see my drawing in its original visual  
framing as god and nature intended.

Conversely, if I have the description anywhere on the page - even in the  
third and fourth paragraphs after the image appears, in a different part  
of the table - with the existing attribute I can just point to it.

> Also, it would be simpler to implement in industrial CMS's, who are
> notoriously bad at providing easy longdesc mechanisms.

I am not sure that this is the case. (I agree CMS' have done a terrible  
job so far, but I don't see how the current model is easier or harder than  
your proposed one).

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Received on Wednesday, 6 February 2008 12:21:43 UTC