Re: Images and alternative text

Ian Hickson wrote:
> I have changed the spec to cater to the case of images whose content is 
> unknown by saying that in such cases the type of image should be given as 
> the alt text, with curly braces on either side. (Research has indicated 
> that this pattern is rather rare, so it shouldn't really affect many 
> pages, relatively speaking.)
> User agents are required to clearly indicate an image is present when the 
> alt text uses this pattern.

(I'm not sure if this point has been mentioned before, but it was 
brought up on IRC so I'll repeat it here: )

It might not affect much content, but it affects all tools that might 
possibly ever interact with such content.

If I am writing a tool that converts LaTeX to HTML, using <img> for 
equations (because the tool has to work in real life and therefore can't 
use MathML), it's reasonable that when a user types in

   $\pi \approx 3$

the output is

   <img src="auto-generated-png" alt="\pi \approx 3">

which is suitable alt text because it's providing equivalent information 
to the image, in a form that anyone can learn to read, though the 
graphical representation is clearer for users who are able to consume 
it; and it's easy to implement, since the alt attribute accepts 
free-form text and all I have to do is make sure I escape " and & 
characters; and you're not going to convince me to do anything much 
fancier when it affects so few readers. But a user might type in

   ${x \over y} = {1 \over {y \over x}}$

in which case the output

   <img src="..." alt="{x \over y} = {1 \over {y \over x}}">

would be non-conforming HTML 5 because the alt text is of the form 
"{...}", and it would trigger incorrect processing in some UAs. It would 
be quite confusing to users if most equations on a page looked like 
plain text, but a few were given special indicators that an image was 
present and were displayed with the outermost braces removed.

Since I am (hypothetically) a careful conscientious thorough tool 
author, I don't want this error to ever occur when a user gives me 
perfectly legitimate input, so I'll have to think up some hack to make 
this work (like appending a space to the attribute value).

I'll also have to spend some of effort carefully checking for any other 
cases in HTML 5 where certain syntax has an unexpected special meaning 
that affects UAs, to make sure I never accidentally output code matching 
that syntax; and also watch out for future versions of HTML redefining 
the processing of values that follow some other new syntax, to make sure 
my tool's output never conflicts with that either.

So, the claim that the "{...}" syntax is rare is irrelevant to tool 
developers since they have to handle it anyway -- overloading syntax 
adds real complexity to tools even when they don't care about the new 
feature, particularly frustrating the few developers who are actually 
trying to follow the spec. (When a developer has to write code to work 
around a feature of the spec that isn't implemented in any UAs, I would 
expect they're quite likely to just disregard the spec, which is a 
situation we should avoid encouraging.)

(This specific case affects Wikipedia, which does exactly the equation 
thing described above, and so would have to add code to work around this 
HTML 5 feature. I expect the same argument would apply to any other 
overloading of the alt attribute value syntax.)

Philip Taylor

Received on Thursday, 7 August 2008 15:56:21 UTC