- 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>
> -----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 > HTML5 > 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 this! > 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 or 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 J.Ja
Received on Sunday, 10 August 2008 00:31:29 UTC