Re: Alternate proposal for ISSUE-30 longdesc

On Mon, Feb 22, 2010 at 4:44 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>> The first one is
>>
>> "A handful of sites (organizations for the disabled, government
>> entities, nonprofits, etc) go far beyond the norm in trying to provide
>> a good accessibility experience. They may be relying on longdesc to
>> improve the experience, and it would be disruptive to immediately make
>> such content nonconforming."
>>
>> This seems to me to be an argument to allow implementations to
>> implement it, but as far as I can see is not an argument to keep it
>> valid. Compare for example to the bgcolor attribute, many sites use
>> it, and implementations are allowed to implement it, but it is still
>> specced as non-conforming and I don't hear anyone argue that it
>> shouldn't be.
>
> bgcolor was deprecated in HTML4.01, "Deprecated" being the closest status
> HTML4.01 had to HTML5's "Obsolete but conforming". So my proposal would
> actually treat longdesc the exact same way we have treated bgcolor, just one
> spec cycle behind.
>
> I do believe that other presentational attributes from HTML4.01 are
> nonconforming in HTML5, even though they were not previously marked
> Deprecated. An example would be the "height" and "width" attributes on the
> <img> element. I would distinguish that case because presentational
> attributes in general have been discouraged for a long time. Furthermore, it
> is generally considered that even the intent of presentational attributes
> is, in retrospect, a bad one. In general, there isn't a valid reason to use
> them instead of using a stylesheet, even in pre-HTML5 content. But longdesc
> had a beneficial intent, even if the outcome was often poor due to the
> design details in the feature. So it's possible someone may be using
> img@longdesc well, but we would not consider any use of img@height to be
> using it well.

The argument brought forward in the change proposal was "sites are
using it". However we know that sites use a lot of other attributes
that are marked as non-conforming. Such as many presentational
attributes. However it doesn't seem like this WG has elsewhere
considered this to be a strong enough argument to keep a feature in
the spec.

My feelings as an implementor with many users is that existing usage
of a feature is an argument to allow, or even require, implementations
to implement a feature. However it does not seem like an argument to
keep the usage conforming.

It seems like you are here additionally arguing that making a feature
non-conforming, without first publishing one version of HTML where the
feature is deprecated, is bad. If you are indeed making this argument
then it might be worth putting in the change proposal.

Personally I'm not a big fan of this argument either. I much prefer to
have a feature be conforming if there are technical reasons to do so.
In this case, if it helps accessibility.

>> The second argument in the change proposal is:
>>
>> "Some laws, regulations and organizational policies may refer to
>> longdesc by name."
>>
>> Using this as argument for keeping any feature seems very sad to me.
>> The idealist in me strongly prefers to add accessibility features
>> based on what helps people with accessibility needs, rather than what
>> local laws say. I realize that we need to be practical and not just
>> idealist, however I think the argument needs to be stronger than "laws
>> may exist".
>
> I concede this is a pretty weak argument by itself.
>
>> So this seems to leave us with the a
>
> Looks like this sentence got cut off.

I think this was a half-sentence left in by accident. Please ignore :)

/ Jonas

Received on Monday, 22 February 2010 14:07:37 UTC