Re: Question on “HTML5 Image Description Extension” Working Draft

Hi Silvia,

On Mon, 27 May 2013 04:03:58 +0500, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> Hi Chaals,
>
> I took the CfC on the Image Description Extension spec as motivation
> to give the spec another read to see where it got to.

Thanks for reading it :)

> I have a question about a non-normative statement and a successive  
> example:
>
> "One of the most common mistakes authors make that is easily repaired
> by user agents is to use a description... Converting such attributes
> to data URLs is a simple repair strategy ..."
>
> This explanation has a subtle implication that you would like to see
> tools that implement fixing for broken longdesc attributes.

I would like to see such tools.

In paticular, I would like to see them in content creation and management  
software, where they can pick up the issue before the general public has  
to face it.

> Further, in the example you provide some JavaScript code to explain
> how a conversion of a plain text longdesc attribute value to a data
> URI could be undertaken.
>
> What are the intentions of these implications? Would you like browsers
> to implement a fix? Would you like to see browser extensions
> implemented to fix it? Or just some sort of greasemonkey script or
> bookmarklet that can fix a page's longdesc values? Or do you expect
> accessibility tools to make these fixes?
>
> I am curious about this, because this seems to be a common cause of
> trouble. Thus,wouldn't it make sense to make it a normative
> requirement on browsers to use the data-URI fix for longdesc attribute
> values that don't parse as a URI, and thus add a parsing step to the
> attribute interpretation? Then, random text would still not be a valid
> @longdesc value (i.e. validators need to flag an error), but it would
> be dealt with by the browser in a useful manner.

The First Public Working Draft had a statement that user agents "may" like  
to fix the problem (but more general than forcing the data-URI fix). The  
i18n group requested that it be converted to SHOULD NOT, on the basis that  
doing this risks legitimising the use of a description instead of a URL,  
and therefore risks inviting that cow path to be paved. Doing so would  
cause particular problems for internationalisation compared to the use of  
a URL.

In the end, we kept the subtle implication that fixing problems is good,  
but drew back from suggesting who should do it and how. An important part  
of the rationale is that there are clearly different ways to do this, and  
the TF didn't feel that any particular error-recovery technique is  
sufficiently well-understood and obviously superior that we want to make  
it a requirement.

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Monday, 27 May 2013 16:55:34 UTC