Re: LONGDESC: some current problems and a proposed solution added to the wiki

HI Ben,

First, I am so happy you're picking up on this. I feel like I've been  
repeating this and repeating it without any traction. I think your  
logic may explain in a better way than I've been able to do.

On Jun 30, 2007, at 10:50 AM, Ben Boyle wrote:

>
> I concur with these sentiments for a <picture> or similar.

Let me just add a two more related themes I've been trying to convey  
along with this.

1) <img> had fallback content added to it twice. Once as @alt and  
once as @longdesc: each has strengths and weaknesses. @alt is loaded  
right there with the other content, but has no rich semantic  
capabilities. While @longdesc has rich semantic capabilities but is  
either loaded from an entirely separate page or an element within the  
same page that now must have iss display or visibility property  
managed (presumably hidden by default). By following the <object>  
element method this gains the benefits of both @alt and @longdesc but  
without an of their drawbacks.

However, this division of fallback methods on the <img> element has  
also lead to a divergence in practice: in other words different use- 
cases for the two different fallback methods. @allt is expected bo be  
short and sweet. While @longdesc is expected to point to a more  
elaborate fallback description.

So the other question I"ve been trying to raise is whether @alt may  
be needed on all of the other embedded content elements in addition  
to the elements contents. We also have @title that serves a similar  
role (so that suggests maybe we don't). But if we don't need @alt on  
these other elements (to serve as this secondary abbreviated fallback  
description) than do we really need it on <img> (at least an <img>  
that already has @longdesc)?  Again, I don't have an answer to this,  
I'm just posing it to hopefully help make the language cleaner in  
some distant future.

2) Based on my understanding for the rationale for listing elements  
and attributes as omitted (i.e., we omit @style not because it won't  
be there for use, but because we feel its not best practice for  
authors once the alternative HTML5 mechanisms are sufficiently  
implemented).,So, do we need another category for something like  
<embed>.. Here we have an element where we need to add @alt and  
@longdesc (most likely) and call for UAs to implement those on this  
element. At the same time its an element(along with <img>) that  
should not be used in best practice in the future (like @style).  
(Note, I'm not saying we've made any decisions on any of these I'm  
speaking hypothetically about decisions we might make and how we  
should best handle them).  So in this case we would need to omit  
<embed> while at the same time add @longdesc and @alt to it.  
Similarly we would be omitting <img> and with that @longdesc. Again,  
I'm just trying to facilitate some discussion of these issues and get  
us all on the same page.

Take care,
Rob

Received on Saturday, 30 June 2007 16:50:53 UTC