LONGDESC files

[Harlan Messinger]

Re: LONGDESC files


"William Tasso" <news27@tbdata. com> wrote in message
news:bqj2o8$22p 357$1@ID-139074.news.uni-berlin.de...[color=blue]
> Harlan Messinger wrote:[color=green]
> > "Alan J. Flavell" <flavell@ph.gla .ac.uk> wrote in message
> > news:Pine.LNX.4 .53.03120219455 70.20227@ppepc5 6.ph.gla.ac.uk. ..[color=darkred]
> >> On Tue, 2 Dec 2003, Harlan Messinger wrote:
> >>
> >>> Punctuation isn't "content" any more than tags are.
> >>
> >> Let's not get side-tracked with quibbles over semantics. Written or
> >> printed texts are usually shown with punctuation, and without markup
> >> being visible. I'd say that puts the punctuation closer to being
> >> content than being markup.[/color]
> >
> > Not at all. The whole point of markup is to tell the rendering agent
> > that there is some useful demarcation or classification. It leaves it
> > up to the agent to determine *what* to do with that information, but
> > if a browser pretends it's not there and doesn't pass it on in some
> > useful form, what good is it?
> >
> > "Content" is the information--the words AND sometimes the
> > illustrations. Punctuation and HTML are both information *about* the
> > information--metadata.
> >[/color]
>
> it is is it
> it is, is it?
> it is "is it"[/color]

He spoke to my uncle.
He spoke to my <q>uncle</q>. [Maybe it's a family friend I consider my
uncle.]
<em>He</em> spoke to my uncle.
He <em>spoke</em> to my uncle.
He spoke to <em>my</em> uncle.
He spoke to my <em>uncle</em>.
<h2>He spoke to my uncle.</h2>
<li>He spoke to my uncle.</li>

[Harlan Messinger]

Re: LONGDESC files


"Jukka K. Korpela" <jkorpela@cs.tu t.fi> wrote in message
news:Xns9446101 0ECF1Fjkorpelac stutfi@193.229. 0.31...[color=blue]
> "Harlan Messinger" <h.messinger@co mcast.net> wrote:
>[color=green][color=darkred]
> >> What's wrong with the first one, as user agent behavior? There are
> >> two <img> elements separated by whitespace. The correct behavior,
> >> when a browser does not display the images, is to act as if those
> >> elements would be replaced by their alt texts.[/color]
> >
> > You say it's the correct behavior, but it's that behavior that
> > causes the problem. So why is it the "correct behavior"?[/color]
>
> It is correct behavior because it conforms to the letter and spirit of
> the specifications. It is not a user agent's job to guess that the
> author meant something else than what he marked up.[/color]

But it is guessing. It's guessing, quite mistakenly, that my images are
meant to be construed as an integral part of the contiguous text.
[color=blue]
>
> Similarly, if you write <h6>some text</h6> in a misguided attempt to
> make text smaller,[/color]

There's no misguided attempt involved with an <img> tag. It is, first and
foremost, an image. The alt attribute is, first and foremost, a tool for
providing information that would be lost without the image. There's no
obvious reason why that can only be done by treating the alt text as part of
the text flow.
[color=blue]
> then a browser behaves correctly when it actually
> renders the text in a manner suitable for _headings_ (though low-level
> ones). If browsers guessed that the author meant 'make this small',
> then it would go all wrong in all those cases where the author really
> meant 6th level heading when he said 6th level heading.[/color]

[Harlan Messinger]

Re: LONGDESC files


"Brian" <usenet2@juliet remblay.com.inv alid-remove-this-part> wrote in
message news:ga8zb.4037 34$Fm2.411705@a ttbi_s04...[color=blue]
> Harlan Messinger wrote:[color=green]
> > "Brian" wrote:
> >
> > You're going to have to be consistent one way or the other. The web
> > page author puts in the <img> tag. If whether something is
> > "content" is determined by who put it there, either punctuation and
> > <img> tags are both content or neither are.[/color]
>
> <img> is a tag. Question marks, periods, etc., are not tags. They
> are the content that goes inside an element's tags, just like letters
> and numbers.
>[color=green][color=darkred]
> >> <quote> The IMG element embeds an image in the current document
> >> at the location of the element's definition. The IMG element has
> >> no content; </quote>
> >>
> >> Note the part that says, "The IMG element has no content."[/color]
> >
> > ROFL. Good grief! That's a completely different use of the word
> > "content". To say an HTML tag (or any SGML tag, I suppose) "has no
> > content" means that it can only be used in the form
> >
> > <tag ...>[/color]
>
> My bad. I wasn't thinking in terms of sgml.
>[color=green][color=darkred]
> >> When writing alt text, ask yourself why you're putting that image
> >> there.[/color]
> >
> > Sometimes it's just visual appeal. It's as simple as that. Maybe
> > you're illustrating a page about Spain with a picture of a bull.
> > Your page is not *about* bulls. There is no mention of a bull in
> > your text.[/color]
>
> Sometimes, alt="" is the most appropriate choice.[/color]

I wouldn't argue that point, except out of sensitivity to potential
disability-related concerns, to which I don't know the "right" answer, and
to which there may not *be* a "right" answer. Graphics used as borders and
dividers so forth are generally best left with alt=" ".* But if all the
sighted people know there's a picture of a bull on the page, and the blind
person doesn't know there's a picture of a bull, I *imagine* some might say
that we are not providing the same information. I guess one could say that
an image conveys two kinds of information: the information conveyed by the
depiction, AND the fact that the image is THERE. I would make the case that
the latter kind of information does not need to be conveyed in most cases,
but I'm probably not the last word on that!

* (Not alt="", by the way. To the browser, that's the same as not having an
alt attribute at all, and *that* will cause some browsers to display or
speak "[IMAGE]" or some such thing, which *is* disruptive. Instead, use
alt=" ", with a space, which the browser will then display or speak as the
empty string that it is, which means, as nothing.)
[color=blue]
>[color=green][color=darkred]
> >>> And since when does "On a recent trip, I saw a bull in the
> >>> water" necessarily merge intelligently with the text that
> >>> happens to surround it?
> >>
> >> It only merges with the text if the author writes it to merge
> >> with the text.[/color]
> >
> > Care to explain how to avoid that?[/color]
>
> Avoid it? I'm not sure how one would avoid it. Do you want to know
> how to prevent alt text from being rendered inside e.g. a pargraph?
> The same way as for the image that would replace it, no? Float or
> position it.[/color]

Oh. Well, of course. Unless you *are* making a rebus, I *assume* that the
image is floating (align="left" or some such thing) or is on its own line
due to use of <p>. I thought that the premise behind all the examples in the
bloopers document was that the images in question *were* marked up this way.
Well, not necessarily with consecutive images on the same line, such as the
bull and the canoe, but with images adjacent to text, I took that for
granted.

[Brian]

Re: LONGDESC files

Harlan Messinger wrote:[color=blue]
>[color=green][color=darkred]
>>> Sometimes it's just visual appeal. It's as simple as that.
>>> Maybe you're illustrating a page about Spain with a picture of
>>> a bull. Your page is not *about* bulls. There is no mention of
>>> a bull in your text.[/color]
>>[/color]
> But if all the sighted people know there's a picture of a bull on
> the page, and the blind person doesn't know there's a picture of a
> bull, I *imagine* some might say that we are not providing the same
> information.[/color]

If it's merely decorative, then you're not providing the same
appearance. But if the page is not about bulls, you probably are
providing the same information. The context is what counts, naturally.
[color=blue]
> I guess one could say that an image conveys two kinds of
> information: the information conveyed by the depiction, AND the
> fact that the image is THERE. I would make the case that the latter
> kind of information does not need to be conveyed in most cases,[/color]

I'd agree.
[color=blue]
> * (Not alt="", by the way. To the browser, that's the same as not
> having an alt attribute at all, and *that* will cause some browsers
> to display or speak "[IMAGE]" or some such thing, which *is*
> disruptive.[/color]

I know of no such browser. Lynx displays nothing when the alt text is
empty (alt=""). It seems to do the same when there are spaces in the
alt attribute. Only when the alt is missing does the name of the file
(without extension), appear. This is without having made any changes
to my configuration.
[color=blue]
> Instead, use alt=" ", with a space, which the browser will then
> display or speak as the empty string that it is, which means, as
> nothing.)[/color]

It's not an empty string, of course, it is a space. I'd think that a
conforming agent should do something with it. But Lynx does not
behave the way I'd expect.

<P><IMG SRC="/portfolio/images/apple.jpg"
WIDTH="400" HEIGHT="400" ALT="apples"><I MG
SRC="portfolio/images/colin11.jpg" WIDTH="400" HEIGHT="400"
alt=""><IMG SRC="portfolio/images/drink.jpg"
WIDTH="400" HEIGHT="400" alt="drink"></P>

produces, in Lynx/Win

apple drink

with a space in between.
[color=blue]
> I *assume* that the image is floating (align="left" or some such
> thing) or is on its own line due to use of <p>. I thought that the
> premise behind all the examples in the bloopers document was that
> the images in question *were* marked up this way. Well, not
> necessarily with consecutive images on the same line, such as the
> bull and the canoe, but with images adjacent to text, I took that
> for granted.[/color]

I think, according to the css spec, if an image is floated, then a box
with the alt text should also be floated when the image is not
displayed. At least, that's what hixie argued for in bugzilla.

--
Brian
follow the directions in my address to email me

[Harlan Messinger]

Re: LONGDESC files


"Brian" <usenet2@juliet remblay.com.inv alid-remove-this-part> wrote in
message news:WIozb.2903 59$9E1.1489334@ attbi_s52...[color=blue]
> Harlan Messinger wrote:[color=green]
> >[/color]
>[color=green]
> > * (Not alt="", by the way. To the browser, that's the same as not
> > having an alt attribute at all, and *that* will cause some browsers
> > to display or speak "[IMAGE]" or some such thing, which *is*
> > disruptive.[/color]
>
> I know of no such browser. Lynx displays nothing when the alt text is
> empty (alt=""). It seems to do the same when there are spaces in the
> alt attribute. Only when the alt is missing does the name of the file
> (without extension), appear. This is without having made any changes
> to my configuration.[/color]

I'll have to look back at the resource from which I got this information.
[color=blue]
>[color=green]
> > Instead, use alt=" ", with a space, which the browser will then
> > display or speak as the empty string that it is, which means, as
> > nothing.)[/color]
>
> It's not an empty string, of course, it is a space.[/color]

Empty of anything to be spoken, that is, by a speech browser. In a text
browser, it would display as a space, though if there were white space on
either side, it would be elided, and if there isn't, it's probably OK
anyway.
[color=blue]
>I'd think that a
> conforming agent should do something with it. But Lynx does not
> behave the way I'd expect.
>
> <P><IMG SRC="/portfolio/images/apple.jpg"
> WIDTH="400" HEIGHT="400" ALT="apples"><I MG
> SRC="portfolio/images/colin11.jpg" WIDTH="400" HEIGHT="400"
> alt=""><IMG SRC="portfolio/images/drink.jpg"
> WIDTH="400" HEIGHT="400" alt="drink"></P>
>
> produces, in Lynx/Win
>
> apple drink
>
> with a space in between.
>[color=green]
> > I *assume* that the image is floating (align="left" or some such
> > thing) or is on its own line due to use of <p>. I thought that the
> > premise behind all the examples in the bloopers document was that
> > the images in question *were* marked up this way. Well, not
> > necessarily with consecutive images on the same line, such as the
> > bull and the canoe, but with images adjacent to text, I took that
> > for granted.[/color]
>
> I think, according to the css spec, if an image is floated, then a box
> with the alt text should also be floated when the image is not
> displayed. At least, that's what hixie argued for in bugzilla.[/color]

[Isofarro]

Re: LONGDESC files

Barry Pearson wrote:
[color=blue]
> The sole reason that those pages exist is so that people can look [sic] at
> my photographs. If people can't see them for any reason, there is no point
> in going there.[/color]

Yet you don't employ a simple robots.txt file to tell search engines not to
index those pages. (Search engines can't see images, so - in your position
- there's no point indexing your pages).
[color=blue][color=green]
>> Are all your photos first level headings? Doesn't sound reasonable.[/color]
>
> The photograph is the reason the page exists.[/color]

So that would mean the photograph is the content on the page, not the
top-level header of the content of the page.
[color=blue]
> There is no text that could
> sensibly serve as a heading.[/color]

Care to point out in the HTML specification where it states emphatically
that top-level headers are mandatory. Heck, I'll be generous - I'll even
accept a reference in a W3 Recommendation to the extent of "Top level
headers should not be used in an HTML document unless ...".


--
Iso.
FAQs: http://html-faq.com http://alt-html.org http://allmyfaqs.com/
Recommended Hosting: http://www.affordablehost.com/
Web Design Tutorial: http://www.sitepoint.com/article/1010

[Jukka K. Korpela]

Re: LONGDESC files

"Graham J" <me@privacy.net > wrote:
[color=blue]
> I was challenging the assertion that _the_ correct behaviour was
> just to render alt text in the flow of the document as if the img
> never existed.[/color]

I guess we partly disagree on formulations, not subject matter - maybe
an image could clarify this, they say that an image says a thousand
words? :-)

Seriously, I may have misformulated my point. What I meant was
primarily related to the problem of adjacent <img> elements and whether
their alt texts should be considered as adjacent too. I still think
they should. Otherwise there would be quite unnecessary problems with
common constructs like
<p><img alt="Y" src="Y.gif">ucc a said that...</p>
intended to create a decorative initial. (Well, this is a simpler case
but the principle is the same I think: the alt text _should_ be
regarded as part of the text flow, with no implied spaces just because
it's an alt text.)

But I didn't mean that user agents should not give any indication of
some text being the result of using an alt attribute in place of an
image, in some visual way (or even auditive way). I just think it's
normally not desirable.
[color=blue]
> Ah well that is where we differ. I consider that it is very
> important to know that the text is replacing an image. I want to
> know it is alt text just as I like to know where links are or
> emphasised text or headings.[/color]

I used to think along such lines, being frustrated with the phenomenon
that when a page is viewed without images, you really don't know what
you're missing. Then again, there are people who are blind or with very
low vision or in some situation unable to view images on a browser, and
they mostly don't want to know what they are missing. Nowadays I think
this is something that an author needs to address when designing the
page. I have suggested the convention of putting an alt text into
brackets when it is actually just a description and not a replacement,
e.g. alt="[my horses], as opposite to alt="I have three horses." (when
the purpose of an image is to say just that, in a visual way if
possible, though we might argue that a photo of three horses inevitably
gives more information than just that). It would of course be just a
clumsy convention, while waiting for something better to be invented in
the field of markup.
[color=blue]
> If the images are spacers or decorational I would say it is
> critical to tell the user that any text shown is an image
> replacement because it is likely to be nonsensical otherwise.[/color]

Pardon? Do you really mean that a page with a hundred spacer images
(not uncommon!) should be read by spelling out each spacer somehow?
Well, you can do that for your pages by using
alt="spacer image"
and some people actually do that (probably feeling righteous and
thinking they promote accessibility!) .
[color=blue]
> The chances are it needn't be shown at all.[/color]

Sorry, you lost me here. _Of course_ spacer images and decorational
images should have alt="" (or sometimes alt=" ") and this in turn
should be presented (when the image is not displayed) as if the
<img> element were not there. If that's what you mean by "needn't be
shown at all", I don't understand what you wrote before that.
[color=blue]
> What about a case where you are talking about a footballer who
> looks like a horse? You have a picture of the footballer and a
> picture of the horse. It is a visual joke so it would make sense
> to know that the page contains img elements.[/color]

I don't see much joke in that, and maybe I wouldn't see even if I could
see the pictures. But assuming it's a joke worth telling somehow, then
you have several choices:
- try to say it in words in an alt text (I cannot imagine that, since
I cannot see the joke)
- decide that the joke is just visual extra and use alt=""
- indicate it as something that cannot be replaced by words, and name
it suitably, e.g. alt="[A footballer who looks like a horse.]" and
alt="[A horse.]"; in this case, the images would probably be preceded
or accompanied with some words that refer to them, so nonempty alt
texts are more or less mandatory to avoid confusion.
[color=blue]
> However in very many cases even the best written alt text can never
> adequately replace it and it is important to know the image is
> there.[/color]

For the bulk of images on Web pages, I would say it's just the
opposite. Most images are decorations or spacers or presentations of
text in a particular style, and then there are image galleries where it
is pretty evident anyway that most texts are just names for images,
though this could be clarified by suitabke design. Situations where the
alt text is a _partial_ replacement are possible but surely not the
most common case.
[color=blue]
> I, and it seems others, consider that
> if, for example, text browsers are capable of drawing attention to
> links and emphasised text then they are also capable of doing the
> same for alt text and that they should do as otherwise they are
> dropping information.[/color]

No, they are conveying the information that the author provided as the
textual replacement. If that's not adequate, blame Can^H^H^Hthe author.

Sure if a page has <img src="home.gif" alt="Home"> and home.gif is
an unintentiolly naive drawing of a house with the text "Home" in some
fancy, barely readable style, a text browser is dropping essential
information if it renders the element as if the document actually
contained the word "Home" in its place. The user may miss quite a bit
of the pseudoartistic and modernistic impression. But that happens out
of necessity. If there was something _relevant_ in the image beyond
what is conveyed by the word "Home", it was the author's responsibility
to consider the issue and do something about it.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Harlan Messinger]

Re: LONGDESC files


"Jukka K. Korpela" <jkorpela@cs.tu t.fi> wrote in message
news:Xns94474C6 1B8E2jkorpelacs tutfi@193.229.0 .31...[color=blue]
> Seriously, I may have misformulated my point. What I meant was
> primarily related to the problem of adjacent <img> elements and whether
> their alt texts should be considered as adjacent too. I still think
> they should. Otherwise there would be quite unnecessary problems with
> common constructs like
> <p><img alt="Y" src="Y.gif">ucc a said that...</p>
> intended to create a decorative initial.[/color]

*This* strikes me as a hack that shouldn't be expected to work, with the "Y"
treated not only in the flow, but *as part of the word to which it is
adjacent*. This is the kind of thing I meant when I said that browsers
should not assume that the default use of images is to create a rebus. If
you want drop-caps, wait until browsers implement the CSS standard that
supports them.
[color=blue]
>
> But I didn't mean that user agents should not give any indication of
> some text being the result of using an alt attribute in place of an
> image, in some visual way (or even auditive way). I just think it's
> normally not desirable.[/color]

This is confusing me. If you think it's not normally desirable, isn't that
the same thing as saying you think they shouldn't do it?
[color=blue]
>
> I used to think along such lines, being frustrated with the phenomenon
> that when a page is viewed without images, you really don't know what
> you're missing. Then again, there are people who are blind or with very
> low vision or in some situation unable to view images on a browser, and
> they mostly don't want to know what they are missing. Nowadays I think
> this is something that an author needs to address when designing the
> page. I have suggested the convention of putting an alt text into
> brackets when it is actually just a description and not a replacement,
> e.g. alt="[my horses], as opposite to alt="I have three horses."[/color]

For a speech synthesizer, that's no help. As for text browsers, I don't see
how it makes things any clearer, since the user has no way to know that the
brackets represent an alt attribute rather than actual brackets in the text.

[Jukka K. Korpela]

Re: LONGDESC files

"Harlan Messinger" <h.messinger@co mcast.net> wrote:
[color=blue][color=green]
>> <p><img alt="Y" src="Y.gif">ucc a said that...</p> intended to
>> create a decorative initial.[/color]
>
> *This* strikes me as a hack that shouldn't be expected to work,[/color]

It should work and it does work. Not optimally e.g. on IE in no-images
mode, but otherwise pretty well.
[color=blue]
> with the "Y" treated not only in the flow, but *as part of the word
> to which it is adjacent*.[/color]

Of course. It's similar to
<p><font style="initial" >Y</font>ucca said that...</p>
[color=blue]
> If you want drop-caps, wait until browsers
> implement the CSS standard that supports them.[/color]

Whether you like the idea or not, it is valid markup with well-defined
meaning. Besides, the use of highly decorative initials is hundreds of
years old (you remember the old printed books with hand-painted
initials?), and if someone wants to imitate that, he will be suggesting
an image to replace a letter. Just what <img ...> does. Doing the same
in CSS might sound more modern to some people, and I agree, but there
won't be any effective way of doing that on the WWW for years.
[color=blue][color=green]
>> But I didn't mean that user agents should not give any indication
>> of some text being the result of using an alt attribute in place
>> of an image, in some visual way (or even auditive way). I just
>> think it's normally not desirable.[/color]
>
> This is confusing me. If you think it's not normally desirable,
> isn't that the same thing as saying you think they shouldn't do it?[/color]

No. It's OK for user agents to let the user request for such
indication, but hardly OK to do that by default or, worse still, do
that no matter what (as IE does in its tragicomic implementation of alt
attributes).
[color=blue][color=green]
>> I have suggested
>> the convention of putting an alt text into brackets when it is
>> actually just a description and not a replacement, e.g. alt="[my
>> horses], as opposite to alt="I have three horses."[/color]
>
> For a speech synthesizer, that's no help. As for text browsers, I
> don't see how it makes things any clearer, since the user has no
> way to know that the brackets represent an alt attribute rather
> than actual brackets in the text.[/color]

Speech synthesizers can read punctuation, and they often do, in
different ways. As regards to the other objection, it is true that this
convention should be widely adopted to be really useful, but at least
the brackets are a hint. And what else could we do? Maybe
alt="A picture of my horses is available on this page."

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Alan J. Flavell]

Re: LONGDESC files

On Thu, 4 Dec 2003, Harlan Messinger wrote:
[color=blue]
> "Jukka K. Korpela" <jkorpela@cs.tu t.fi> wrote in message[color=green]
> > common constructs like
> > <p><img alt="Y" src="Y.gif">ucc a said that...</p>
> > intended to create a decorative initial.[/color]
>
> *This* strikes me as a hack that shouldn't be expected to work,[/color]

I wouldn't encourage its use except in specialised circumstances; but
the idea has surely been familiar since the early days of the Netscape
corp, when everyone and his dog was putting notices about their site
being <img src="Nlogo.gif" >etscape-enhanced.

Even if they had the wit to add alt="N", the then-current indexers
would file them under "etscape".

Somehow that specific example seemed to die out after about 1997
(possibly something to do with a competing browser gaining those types
of authors as fans?), but if I do a search for "etscape" now, there
seems to be a crop of fresh examples.
[color=blue][color=green]
> > But I didn't mean that user agents should not give any indication of
> > some text being the result of using an alt attribute in place of an
> > image, in some visual way (or even auditive way). I just think it's
> > normally not desirable.[/color]
>
> This is confusing me. If you think it's not normally desirable,
> isn't that the same thing as saying you think they shouldn't do it?[/color]

Don't try to make design decisions overly simplistic! It's not all
black or white (nor is it supposed to be, unless you happen to have a
b/w display - pages should be designed such that even in that case,
you still shouldn't be missing substantive content).
[color=blue][color=green]
> > page. I have suggested the convention of putting an alt text into
> > brackets when it is actually just a description and not a replacement,
> > e.g. alt="[my horses], as opposite to alt="I have three horses."[/color]
>
> For a speech synthesizer, that's no help.[/color]

I don't grasp your meaning. Now sure - by default when IBM HPR was
presented with that, it bawled out LEFT SQUARE BRACKET etc. in a very
intrusive way, but it can be taught to do what the user wants, and the
convention mentioned by Jukka is indeed a long-standing one on the
WWW. Sometimes it can be better to follow an accepted convention even
if you wouldn't have chosen it as your own preference.
[color=blue]
> As for text browsers, I don't see how it makes things any clearer,
> since the user has no way to know that the brackets represent an alt
> attribute rather than actual brackets in the text.[/color]

Nor indeed that the vertical bars inserted by some text browsers for
tabular data are not present in the original text. Be reasonable:
these kinds of text browsers only have character cells to play with,
they can't display anything that isn't a text character. It comes
with the territory; they have to work with the materials to hand.

[Tim]

Re: LONGDESC files

"Jukka K. Korpela" <jkorpela@cs.tu t.fi> wrote
[color=blue][color=green]
>> Seriously, I may have misformulated my point. What I meant was
>> primarily related to the problem of adjacent <img> elements and whether
>> their alt texts should be considered as adjacent too. I still think
>> they should. Otherwise there would be quite unnecessary problems with
>> common constructs like
>> <p><img alt="Y" src="Y.gif">ucc a said that...</p>
>> intended to create a decorative initial.[/color][/color]

I'd expect the image, or the alternative text, to be in the same place
that the <img> element is, so long as you've not done something else to
reposition the image (e.g. floated it to the right, or added padding).
Just the same as we'd expect any other properly placed HTML element to
be where it's place in the source, relative to what comes before and
after it; taking the usual white space rules into account.


"Harlan Messinger" <h.messinger@co mcast.net> wrote:
[color=blue]
> *This* strikes me as a hack that shouldn't be expected to work, with the "Y"
> treated not only in the flow, but *as part of the word to which it is
> adjacent*.[/color]

Why, though? Images are inline objects; they can be in-line with some
text, it has an alternative, and there's no significant white space
either side of the image, either.

I wouldn't call it a hack, it's doing precisely what the specifications
allow. Whether it's a brilliant idea, or not, is another matter. Then
you're into the realms of opinion.
[color=blue]
> If you want drop-caps, wait until browsers implement the CSS standard that
> supports them.[/color]

The image may not necessarily be attempting to do that.

--
My "from" address is totally fake. (Hint: If I wanted e-mails from
complete strangers, I'd have put a real one, there.) Reply to usenet
postings in the same place as you read the message you're replying to.

[Tim]

Re: LONGDESC files

On Thu, 4 Dec 2003 23:03:56 +0000,
"Alan J. Flavell" <flavell@ph.gla .ac.uk> wrote:
[color=blue]
> I don't grasp your meaning. Now sure - by default when IBM HPR was
> presented with that, it bawled out LEFT SQUARE BRACKET etc. in a very
> intrusive way, but it can be taught to do what the user wants, and the
> convention mentioned by Jukka is indeed a long-standing one on the
> WWW. Sometimes it can be better to follow an accepted convention even
> if you wouldn't have chosen it as your own preference.[/color]

Using normal typing brackets (thus) is probably better than square
brackets. It should stand a better chance of being read out in a less
intrusive manner, perhaps just with sufficient pauses, and perhaps
without the surfer having to specially configure the browser.

--
My "from" address is totally fake. (Hint: If I wanted e-mails from
complete strangers, I'd have put a real one, there.) Reply to usenet
postings in the same place as you read the message you're replying to.

[Tim]

Re: LONGDESC files

On Wed, 3 Dec 2003 13:40:04 -0000,
"Barry Pearson" <news@childsupp ortanalysis.co. uk> wrote:
[color=blue]
> The sole reason that those pages exist is so that people can look [sic] at my
> photographs. If people can't see them for any reason, there is no point in
> going there.[/color]

Somebody might *FIND* your pictures by searching for something, and it
might be the alt text the correlated your picture with their query.
Especially if someone were presenting the images with the minimum of
text (normally) showing on the page).

There's plenty of other reasons to bother to provide alt text for
photographic images.

--
My "from" address is totally fake. (Hint: If I wanted e-mails from
complete strangers, I'd have put a real one, there.) Reply to usenet
postings in the same place as you read the message you're replying to.

[Philipp Lenssen]

Re: LONGDESC files

Jukka K. Korpela wrote:
[color=blue]
> "Harlan Messinger" <h.messinger@co mcast.net> wrote:
>[color=green][color=darkred]
> >> <p><img alt="Y" src="Y.gif">ucc a said that...</p> intended to
> >> create a decorative initial.[/color]
> >
> > This strikes me as a hack that shouldn't be expected to work,[/color]
>[/color]
[color=blue]
>
> Whether you like the idea or not, it is valid markup with
> well-defined meaning. Besides, the use of highly decorative initials
> is hundreds of years old (you remember the old printed books with
> hand-painted initials?), and if someone wants to imitate that, he
> will be suggesting an image to replace a letter. Just what <img ...>
> does. Doing the same in CSS might sound more modern to some people,
> and I agree, but there won't be any effective way of doing that on
> the WWW for years.
>[/color]

If you don't expect too much, the first-letter pseudo-element does a
good job in CSS. I find it pretty annoying to present text as an image
and that goes for single letters too, though it's relatively harmless
compared to putting a complete paragraph into an image.

[Barry Pearson]

Re: LONGDESC files

Tim wrote:[color=blue]
> On Wed, 3 Dec 2003 13:40:04 -0000,
> "Barry Pearson" <news@childsupp ortanalysis.co. uk> wrote:
>[color=green]
>> The sole reason that those pages exist is so that people can look
>> [sic] at my photographs. If people can't see them for any reason,
>> there is no point in going there.[/color]
>
> Somebody might *FIND* your pictures by searching for something, and it
> might be the alt text the correlated your picture with their query.
> Especially if someone were presenting the images with the minimum of
> text (normally) showing on the page).
>
> There's plenty of other reasons to bother to provide alt text for
> photographic images.[/color]

I always do provide alt text for photographs. Perhaps I mislead you about the
point I was making.

I was really responding to the view "So there you have the basic text, where
you then provide graphic alternatives to some text, namely the actual photos".
But for my photograph pages, the photographs are primary and the text is
subsidiary. The photograph isn't in some sense an "optional extra" to the
text. What I put in the alt text is approximately what I would put in a header
or the page's title. In fact, typically I use the same text for the title,
(and some of it in the keywords meta tag), and the photograph *is* the page's
<h1>!

For thumbnails, I have a more complicated policy. I use both alt text and
title text. For example, for the thumbnail for the photograph at the URL
below, these are:
alt="Magnificen t Frigatebird" title="Magnific ent Frigatebird, Fregata
magnificens"
I experimented switching off image loading, and with IBM's Home Page Reader,
to judge the balance between what should be read out loud or displayed if a
photograph is not displayed, and what should appear as a tool-tip in suitable
browsers. (I have also experimented with including file sizes, but I haven't
adopted this as a policy. I tend to have some generic site information about
typical image sizes).

And people *do* find my photographs by searches. The people who buy them tend
to have top-end equipment & good eyesight. I spend a lot of time trying to
ensure that both the Google web search and the Google image search can index
my photographs, especially those of living things. For example, this
photograph was found by a search, I believe using the species name, and
appears in the December issue of the Dutch-language version of National
Geographic:

http://www.barry.pearson.name/photography/pictures/eg95/eg95_26_11_3.htm

In fact, on the Birds and Animals site, if you go to the photograph pages, I
even include pre-configured Google searches using the species name, so that
people can discover more about the animal I am showing, and see other
photographs of the same subject. Quite often, (unfortunately not always!), my
own page is in the results. (In one or two cases I claim to have the best
photograph found by the search! Perhaps I'm biased?)

http://www.birdsandanimals.info/galleries.htm

All my photograph pages (I hope) validate as 4.01 Strict, so that *have* to
have an alt attribute. I don't think any of them have null alt text. Certain
thumbnails that link to galleries, not to photographs, *do* have null alt
text, where there is a textual explanatory link alongside the thumbnail. In
that case the thumbnail is a genuine optional extra. See the URL just above.

I keep meaning to write this up. I found it hard to identify an "off the
shelf" policy published on the web that photographers building thumbnail
galleries can adopt. There is some generic advice, but little that says "do
this for this reason and this is what happens".

--
Barry Pearson

http://www.Barry.Pearson.name/photography/

http://www.BirdsAndAnimals.info/

http://www.ChildSupportAnalysis.co.uk/