[Bug 21987] Consider adding a sister attribute to act as a toggle to trigger longdesc discoverability.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21987

--- Comment #6 from Charles McCathieNevile <chaals@yandex-team.ru> ---
(In reply to comment #5)
> Hi Chaals,
> 
> (In reply to comment #4)
> >>> (In reply to comment #3)
> >> (In reply to comment #2)
> >> > even so, script is not within the realms of everyone.
> >> 
> >> This is true. Not all authors know JavaScript or CSS. I don't see why the
> >> browser couldn't provide an easy way to do this, for authors of limited
> >> skill sets.
> 
> > The browser could.
> 
> Yes. I believe that getting it implemented is what Chris had in mind.
> Specifying a new attribute would allow browsers to enable a *super simple* 
> way for *authors* to explicitly trigger longdesc discoverability on
> individual images.

Sure, but it is just as easy for browsers to enable the discoverability based
on the presence of the longdesc attribute itself. And more reliable - browsers
will be unhappy if you ask them to do this, and they start seeing
"longdesclink" attributes when there is no actual longdesc.

I also think it will actually confuse authors and there will be 

<img src="..." longdesc="oops I put a description in here"
londesclink="http://example.com/what/should/have/been/in/the/longdesc/attribute.html"
...

> It would provide author control of design in a granular
> manner.

Yeah, but this is misxing presentation back into the structure, which I think
is a bad idea.

> > The simplest way to do that, of course, is an extension.
> 
> Do you mean a browser extension or an authoring tool extension? 

browser extension, but the same applies to authoring tool extensions

> As you already know and as previously noted we already have various browser
> extensions that enable direct user discoverability in browsers  [1]. 

yep.

> Does your code do anything different than provide direct user
> discoverability? 

No, that sample provides the discoverability you're looking for in a browser,
based on the presence of a longdesc attribute. With an extra simple function,
it can checkthat the attribute is valid in the first place, and if it isn't,
e.g. it is a description instead of a link, it could convert that to a data URL
(using the code example in the spec draft already) and still add the link...

> Does it allow authors or authoring tools to simply add a sister attribute
> (whatever it be named) into their markup in a conforming way that will make
> longdesc discoverable? Again, the idea of the sister attribute is to allow
> authors to easily surface discoverability in browsers by adding a simple
> sister attribute. Then if that sister attribute was present, browsers would
> do something: add the link or a border or an icon or whatever in whatever
> way was agreed upon for that particular device.

I don't think it should be done this way. If authors want to surface
discoverability, they can write CSS. If users want to do so, they can install
user CSS or a JS extension, depending on their needs and desires. To make this
possible I think the right way is to use the presence of the longdesc attribute
itself as the trigger.

(I agree that easy discoverability is important. I think I wrote the first
implementation that provided it. I just thinkthat an extra attribute is not a
good way to do it, since you can do it with the existing attribute - and in
practice, more effectively IMHO).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 13 May 2013 11:52:29 UTC