- From: Chris Adams <chris@tuesdaybegins.com>
- Date: Wed, 16 Apr 2008 16:08:06 -0400
- To: "Jeff Schiller" <codedread@gmail.com>
- Cc: david.dailey@sru.edu, "Olivier GENDRIN" <olivier.gendrin@gmail.com>, "HTML WG" <public-html@w3.org>, "Charles McCathieNevile" <chaals@opera.com>
- Message-ID: <c4b377210804161308k14a87ac5m68a16239c5dece69@mail.gmail.com>
[ quote /] * In the image author case, the 'alternative text' can be defined only one time, but then it is fixed for all possible uses of that image. * In the html author case, the 'alternative text' must be defined by every user of that image, but then different alternative text could be supplied for different audiences. Why can't both be true? I see a huge potential to use embedded data in image gallery applications in which image are quite often uploaded in large quantities. the largest pitfall that I can foresee is to decide if HTML Alt text will override or supplement the embedded data. -Chris On Wed, Apr 16, 2008 at 11:06 AM, Jeff Schiller <codedread@gmail.com> wrote: > It's not clear to me who should supply the alternative text - the author > of the image or the author of the content embedding the image? Of course > this matters more when the authors are different people. > > * In the image author case, the 'alternative text' can be defined only one > time, but then it is fixed for all possible uses of that image. > > * In the html author case, the 'alternative text' must be defined by every > user of that image, but then different alternative text could be supplied > for different audiences. > > What is alternative text - is it meant to be a completely neutral > description of the image or is it a description of the image in the context > of which it was embedded? > > Jeff > > > On 4/16/08, Charles McCathieNevile <chaals@opera.com> wrote: > > > > > > On Tue, 15 Apr 2008 13:30:01 +0200, Olivier GENDRIN < > > olivier.gendrin@gmail.com> wrote: > > > > On Mon, Apr 14, 2008 at 7:18 PM, David Dailey <david.dailey@sru.edu> > > > wrote: > > > > > > > PNG format, for one example, and SVG for another, both allow the > > > > embedding > > > > of metadata into the image itself. Suppose we rewarded the creators > > > > of such > > > > images with built-in metadata, by requiring browsers to access that > > > > data > > > > directly thereby providing a handy and perhaps more explanatory > > > > provenience > > > > and semantics than the web author (who may well not know too much > > > > about the > > > > image's history, shutter speed, IP legacy and meaning). Perhaps this > > > > has > > > > been proposed already, but it would reduce a bit of the reliance > > > > upon the > > > > cursory alt explanations often provided by HTML authors if the > > > > images > > > > themselves came with built-in explanations. > > > > > > > > > > Interesting, but the metadata can't be updated in an HTML editor, and > > > could not fit the context, if I use for example an image from a > > > bank-image, or as decoration (alt=""). > > > > > > > Right. Among other problems. This is indeed a pretty old idea that has > > use cases, but hasn't arrived at a standard treatment. > > > > For example, it isn't clear what browsers should do *by default* with > > desc/title in svg (there are many useful ways of using this stuff, but > > different users actually want different things), something that many > > browsers now implement. It has been a while since I even tested what does > > happen... > > > > cheers > > > > Chaals > > > > -- > > Charles McCathieNevile Opera Software, Standards Group > > je parle français -- hablo español -- jeg lærer norsk > > http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com > > > > > -- Chris@chrisadams-studios.com http://www.chrisadams-studios.com ------------------------------------------------------------------------------------------------- This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error.
Received on Wednesday, 16 April 2008 20:16:06 UTC