W3C home > Mailing lists > Public > public-html@w3.org > August 2008

RE: Images and alternative text

From: Justin James <j_james@mindspring.com>
Date: Sat, 9 Aug 2008 20:30:44 -0400
To: "'Philip Taylor'" <pjt47@cam.ac.uk>
Cc: <public-html@w3.org>
Message-ID: <0a8501c8fa80$5393c450$fabb4cf0$@com>

> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
> Behalf Of Philip Taylor
> Sent: Friday, August 08, 2008 4:26 PM
> To: Justin James
> Cc: public-html@w3.org
> Subject: Re: Images and alternative text
> Justin James wrote:
> >
> > I am beginning to wonder how much more brainpower we wish to bring to
> bear
> > on this extraordinarily specialized, specific, and niche use case.
> I raised this case because it is an instance of a more general problem.
> Just as photo-sharing sites like Flickr are a specific use case
> demonstrating the more general problem where a tool outputting HTML
> cannot provide a true textual alternative to all its images (hence
> adding a feature to better address that problem), the LaTeX-to-<img>
> case demonstrates the more general problem where HTML 5's approach of
> applying different meaning to a specific syntax in attribute values
> makes it harder to write a conforming markup generator.

Ah, I thought that you were seriously looking for a way to gracefully do

> There are other instances of the same problem - e.g. if I write a Web
> 2.0 Logo Generator that converts a user's text into an image in a
> certain typographical style, I would decide to set the alt text to be
> what the user typed in, because that's the closest the tool can get to
> an equivalent of the image; but then if the user types in some funky
> name for their site like "{Cuilr}", it'll trigger the special
> alt-attribute-gives-kind-rather-than-textual-equivalent processing in
> HTML 5 UAs, which is inappropriate and harmful here, so I'd have to
> worry about preventing that situation.
> The use of special syntax in the attribute value inconveniences every
> tool that generates markup based on user input, even when they have no
> need for or interest in the feature which that syntax is for.

I think anything that takes a type of "string" and then tries to perform
special tricks on it based upon some special formatting of said string is an
extraordinarily bad idea, as I believe your use case demonstrates (so well,
in fact, that it is what I was reacting too!). Frankly, if someone wants a
special way to interpret this attribute, I think they would be much better
off inventing an attribute which would then be ignored by any UA that isn't
aware of the new bogus attribute (in this case, @alt-tex-source or
something...). Then people with these really nice use cases could then
simply write their own browser plugin or something.

At the end of the day, any given industry can find a whole slew of
specialized use cases for HTML. We on this group hear a lot about the
scientific/math communities because a lot of the folks on this list are part
of those communities. Believe me, some of the HTML authors I know (clue: the
domain names are "not appropriate for the work place") could dream up some
special use cases of their own for things, but I doubt that we are going to
start catering to them. We can either provide HTML with the flexibility to
allow those groups of people to do what they need to do, or we can attempt
to take every special need into account. I think that, in this case, trying
to take every special need into account is either:

a) a dodge around the extensibility issue


b) trying to codify in the spec certain business logic so that Web browser
vendors will be forced to support it to be HTML 5 compliant, and therefore
getting them to do the work that an independent group would otherwise need
to write a browser plugin

Received on Sunday, 10 August 2008 00:31:29 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:36 UTC