Re: Question on "HTML5 Image Description Extension" Working Draft

On Mon, May 27, 2013 at 11:54 PM, Charles McCathie Nevile
<chaals@yandex-team.ru> wrote:
> 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.

In which case it shouldn't be a talking about "..that is easily
repaired by user agents", but say something more appropriate towards
content creation and management software, should 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.

Fair enough. Thanks for the clarification.

Cheers,
Silvia.

Received on Tuesday, 28 May 2013 08:14:30 UTC