Re: Images and alternative text

James Graham writes:

> James Graham wrote:
>
> > Even without this specific example I think using random
> > microsyntaxes in existing attributes is a bad idea for the reasons
> > Philip mentioned.
>
> As an alternative proposal with similar semantics I suggest that
> instead of hacking a microsyntax into alt we add a boolean attribute
> to image called no-text-equivalent (I don't care about the dashes if
> they are considered too unlike other attribute names).

Such an attribute is what Ian first suggested many months ago, where it,
(most unusually for this list) suffered from Warnock's Dilemma[*1], even
after he drew attention to it several times.

So it's somewhat ironic that after Ian has abandoned that proposal,
discussion of his subsequent proposal results in support for the
original one.  (Or maybe that was Ian's cunning plan all along?)

> There are several possible disadvantages / problems:
>
> The name of the attribute is very long. I don't think this is an issue as 
> it is mainly intended for systems where the actual markup is being 
> autogenerated. Optimizing for the few cases where it is needed in hand 
> authored pages seems like the wrong priority.
>
> "The name of the attribute sucks". Well it's based on the spec text for 
> when it is appropriate to use a category rather than a text-equivalent. I 
> think the technical merits of the feature outweigh any aesthetic concerns 
> but I'm not hung up on the name if there is a better one. I certainly 
> don't see that this is a good reason to reject the feature.

I think nobody being able to come up with a good name which conveys what
this attribute means is the major cause of its downfall.  The IRC logs
show there were many suggestions, none of them much liked (by pretty
much anybody).

> "People might just copy and paste the attribute into their content
> without understanding what it does". Well yes that's true. On the
> other hand the same people are just as likely to copy and paste the
> brackets thinking that they are a required feature of @alt in HTML5 or
> something.

True.  But I think the braces are more likely to be copied with the same
alt text (where they still apply), or where somebody uses the existing
alt text as a 'template' and replaces it with something similar (that
is, a category rather than a useful alternative).

Whereas an attribute whose meaning isn't apparent (which it won't be,
unless somebody thinks of an intuitive name for it) is likely to be seen
as 'scary thing which is apparently needed for the image to work, so I
won't touch it'.

> At least a named attribute means that they have a fighting chance of
> understanding what's going on without reading the spec

Only if the name is any good.

> I have seem little evidence that people (at least those who would do
> the random copying and pasting thing) actually think about how their
> alt text looks in the context of the surrounding text, so that doesn't
> seem like a big incentive.

I can remember a decade ago using alt="[photo]" on something; the
brackets seemed to make sense to indicate that 'photo' was a placeholder
for something that wasn't there; they prevent it from looking like it's
supposed to be a sentence, or part of a sentence or anything.

So I think having some kind of brackets (and Ian's explanation of why
braces cause the least confusion) in the visible alt text in this
situation is an advantage of this proposal.  Obviously an HTML 5 browser
could, on encountering the no-text-equivalent attribute, use brackets or
something else to demark the alt text.  But existing browsers don't do
that; whereas putting the braces in the alt text yields an acceptable
result in current browsers.

> I guess the behaviour of IE<=7 with regard to tooltips is a bigger
> incentive not to use unnecessary brackets,

Putting title="" quells the tooltips, and seemingly doesn't cause any
other damage.

Cheers.

Smylers

  [*1] http://en.wikipedia.org/wiki/Warnock%27s_Dilemma

Received on Sunday, 10 August 2008 12:23:24 UTC