Are files referenced in LONGDESC attributes supposed to be pure text; can or
should they have either block or inline HTML tags; can or should they be set
up as a fully W3C compliant web page (with DOCTYPE, <html>, <body>, etc.)?
--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.
51  3854 
Harlan Messinger wrote: Are files referenced in LONGDESC attributes supposed to be pure text; can or
should they have either block or inline HTML tags; can or should they be set
up as a fully W3C compliant web page (with DOCTYPE, <html>, <body>, etc.)?
<http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html#h-13.2>
I think you can choose this for yourself, since it is undefined. For
some descriptions, plain text is the most accessible solution, though
some descriptions will require some markup ("this is
<strong>important</strong>").
If you need this extra markup, it needs to be a fully W3C compliant
page, which does not require per specification to add <html> and <body>,
this is compliant as well:
<http://annevankesteren.nl/test/css/at-rule/import-001.htm>
--
Anne van Kesteren
<http://www.annevankesteren.nl/>
"Anne van Kesteren" <ma**@annevankesteren.nl> wrote in message
news:bq**********@reader08.wxs.nl... Harlan Messinger wrote: Are files referenced in LONGDESC attributes supposed to be pure text;
can or should they have either block or inline HTML tags; can or should they be
set up as a fully W3C compliant web page (with DOCTYPE, <html>, <body>,
etc.)?
<http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html#h-13.2>
I think you can choose this for yourself, since it is undefined.
That's the frustrating part! It leaves me wondering whether readers are
likely to assume plain text only. I would have thought so because (1) it's
more or less meant to be a large ALT substitute, and ALT, AFAIK, is plain
text only, and (2) if HTML is allowed, then it means the long description
itself can contain all kinds of inaccessible code (like more <img> tags),
which would defeat the purpose.
For
some descriptions, plain text is the most accessible solution, though
some descriptions will require some markup ("this is
<strong>important</strong>").
If you need this extra markup, it needs to be a fully W3C compliant
page, which does not require per specification to add <html> and <body>,
this is compliant as well:
<http://annevankesteren.nl/test/css/at-rule/import-001.htm>
I did not know that!
Harlan Messinger wrote: "Anne van Kesteren" <ma**@annevankesteren.nl> wrote in message
news:bq**********@reader08.wxs.nl...
Harlan Messinger wrote:
Are files referenced in LONGDESC attributes supposed to be pure text;
can or
should they have either block or inline HTML tags; can or should they be
set
up as a fully W3C compliant web page (with DOCTYPE, <html>, <body>,
etc.)?
<http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html#h-13.2>
I think you can choose this for yourself, since it is undefined.
That's the frustrating part!
Specifications are always frustrating IMHO, since they don't explain
every little fact about it. The leave a lot open for you own interpretation.
It leaves me wondering whether readers are
likely to assume plain text only. I would have thought so because (1) it's
more or less meant to be a large ALT substitute, and ALT, AFAIK, is plain
text only,
In some way, yes. Though ALT can contain encoded characters, like <
(<), which is not equal to 'plain text'.
and (2) if HTML is allowed, then it means the long description
itself can contain all kinds of inaccessible code (like more <img> tags),
which would defeat the purpose.
Correct.
--
Anne van Kesteren
<http://www.annevankesteren.nl/>
"Harlan Messinger" <h.*********@comcast.net> wrote: I think you can choose this for yourself, since it is undefined.
That's the frustrating part!
No, I would say that the frustrating part is that few browsers support
the longdesc attribute in a useful way, and this will hardly improve.
Well, the specification is vague too, and the whole idea is obscure.
For accessibility, it would be best if longdesc were forgotten. And
this does _not_ mean adopting the [D] link trickery.
Simply include a normal link, named in a reasonable no-nonsense manner
(that spells "no 'click here'"). For some more notes and examples on
this, check http://www.cs.tut.fi/~jkorpela/html/alt.html#content
It leaves me wondering whether readers
are likely to assume plain text only.
It would be unnatural to assume plain text. This is about HTML, and it
is natural to expect that HTML would primarily be used for such
purposes, though it _could_ be e.g. an audio file.
Contrary to popular belief, plain text is _less_ accessible than
properly written HTML.
I would have thought so
because (1) it's more or less meant to be a large ALT substitute,
The alt attribute itself is a clumsy and poorly designed idea. It's a
_problem_ that the replacement for an image is an attribute and
therefore plain text. The object element was meant to allow much more
flexibility.
2) if HTML is allowed,
then it means the long description itself can contain all kinds of
inaccessible code (like more <img> tags)
Just as an alt attribute can be worse than useless. Abusus non tollit
usum.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
On Mon, 01 Dec 2003 19:24:28 +0100, Anne van Kesteren wrote: Specifications are always frustrating IMHO, since they don't explain
every little fact about it. The leave a lot open for you own interpretation.
Not to mention the "Standards are great! There're so many to choose
from!" factor.
Cheers,
Owen
On Mon, 1 Dec 2003, Anne van Kesteren wrote: Specifications are always frustrating IMHO, since they don't explain
every little fact about it. The leave a lot open for you own interpretation.
I see what you mean; but since the specifications only establish a
framework, into which it is supposed to be possible to accommodate all
possible content, it's evidently not feasible to define everything
down to the last electron.
Harlan Messinger wrote: It leaves me wondering whether readers are
likely to assume plain text only. I would have thought so because (1) it's
more or less meant to be a large ALT substitute,
That's a somewhat broad-brush assertion. The ALT text is an
unfortunate piece of work, tagged-on to the NCSA-Mosaic design for
<img..> only as a palliative, that should long since have been
supplanted by <object>..fallback..</object>
But we're stuck with it, around a decade later. Sigh.
It's additionally unfortunate that the HTML spec itself, and the WAI
recommendations, seem to keep harping on this supposed role of the ALT
text as a "short description", although they do occasionally manage to
refer to it as "alternative text", which is IMHO a much better
interpretation of its purpose.
Or, to quote myself, if I may:
The most common mistake (if used at all!) is to provide a description
of the image, without considering what job the image was doing on the
page, leading to results that can range from the incongruous to the
absurd. The ALT text is intended to be a suitable textual alternative
to the purpose of the image: sometimes that might turn out to be a
description of the image, but in practice that choice seems to be
wrong far more often than it's right.
and some of the resulting howlers can be reviewed amongst the examples
at http://ppewww.ph.gla.ac.uk/~flavell/...t.html#howlers
So, I'd say it's best to treat the ALT and the LONGDESC as items in
their own right, rather than trying to make them out to be short and
long forms of each other - as appears to be happening here.
and ALT, AFAIK, is plain text only,
I must say, I find that a strange line of reasoning.
In some way, yes. Though ALT can contain encoded characters, like <
(<), which is not equal to 'plain text'.
Agreed. But the longdesc takes a URL, and I don't see any good reason
why that URL shouldn't call out an HTML page, provided of course that
the page has been designed accessibly.
> and (2) if HTML is allowed, then it means the long description
itself can contain all kinds of inaccessible code (like more <img> tags),
which would defeat the purpose.
Correct.
It's true that it *could* contain inaccessible stuff, yes, but surely
an author would take care not to do that?
No, I'm sorry, I really don't see any general grounds for not using
HTML markup in a LONGDESC document. It would be a great place for
proposing an audio stylesheet, for example, and you couldn't do that
in amy useful way with plain text. In a sense you'd be offending
against the W3C's WAI guidelines to use plain text, since guideline
6.3 says "use markup and stylesheets", and plain text is really _less_
accessible than when properly marked-up with HTML.
cheers
(Is somebody DoS-ing the W3C just now? I can't seem to get much out
of its web server.)
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote in message
news:Pi*******************************@ppepc56.ph. gla.ac.uk...
[snip]
Or, to quote myself, if I may:
The most common mistake (if used at all!) is to provide a description
of the image, without considering what job the image was doing on the
page, leading to results that can range from the incongruous to the
absurd. The ALT text is intended to be a suitable textual alternative
to the purpose of the image: sometimes that might turn out to be a
description of the image, but in practice that choice seems to be
wrong far more often than it's right.
and some of the resulting howlers can be reviewed amongst the examples
at http://ppewww.ph.gla.ac.uk/~flavell/...t.html#howlers
As far as that goes, I've realized that coming up with good ALT text is an
art form. Regarding some of your examples, though, I feel I have to put the
blame and the onus on the user agents. I'm referring to "Photo of a bull in
the water canoeing" and "MIT/LCSINRIAKeioDARPACEC". Designing a
usable/accessible web page is tricky enough without, on top of everything
else, having to make it work successfully as a rebus. In my tentative [sic]
opinion, it's the job of the user agent to demarcate alternate text: in a
Lynx-like browser, with [IMAGE]alt-text-here[/IMAGE] or some such device,
and in speech synthesis with whatever preference the user has indicated,
whether it's a spoken marker like "image!", a change in pitch or speed, or a
tone.
So, I'd say it's best to treat the ALT and the LONGDESC as items in
their own right, rather than trying to make them out to be short and
long forms of each other - as appears to be happening here.
and ALT, AFAIK, is plain text only,
I must say, I find that a strange line of reasoning.
In some way, yes. Though ALT can contain encoded characters, like <
(<), which is not equal to 'plain text'.
Agreed. But the longdesc takes a URL, and I don't see any good reason
why that URL shouldn't call out an HTML page, provided of course that
the page has been designed accessibly.
> and (2) if HTML is allowed, then it means the long description
itself can contain all kinds of inaccessible code (like more <img>
tags), which would defeat the purpose.
Correct.
It's true that it *could* contain inaccessible stuff, yes, but surely
an author would take care not to do that?
No, I'm sorry, I really don't see any general grounds for not using
HTML markup in a LONGDESC document. It would be a great place for
proposing an audio stylesheet, for example, and you couldn't do that
in amy useful way with plain text. In a sense you'd be offending
against the W3C's WAI guidelines to use plain text, since guideline
6.3 says "use markup and stylesheets", and plain text is really _less_
accessible than when properly marked-up with HTML.
Thanks to you and the others for your explanations.
"Harlan Messinger" <h.*********@comcast.net> wrote: As far as that goes, I've realized that coming up with good ALT
text is an art form.
In part yes, but it's basically a matter of understanding the purpose
and actual use of ALT attributes, then applying one's share of common
sense.
Regarding some of your examples, though, I
feel I have to put the blame and the onus on the user agents.
Alan's howlers have little to do with user agent deficiencies.
I'm
referring to "Photo of a bull in the water canoeing" and
"MIT/LCSINRIAKeioDARPACEC".
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. Anything else would be contrary
to the meaning and purpose of alt attributes. A browser is not to be
blamed for displaying what the author had actually written, instead of
what he should have written.
The second is similarly a correct rendering of <img> elements with no
whitespace between them.
Designing a usable/accessible web page
is tricky enough without, on top of everything else, having to
make it work successfully as a rebus.
So don't make it a rebus. If it helps, design _first_ the page with
speech rendering in mind, then use CSS and images to tune the visual
alternative. That way, you would consider which texts might have image
alternatives, instead of the opposite approach, which so often tends to
become a useless play with attributes without thinking _why_ you are
writing them.
In my tentative [sic]
opinion, it's the job of the user agent to demarcate alternate
text: in a Lynx-like browser, with [IMAGE]alt-text-here[/IMAGE] or
some such device, and in speech synthesis with whatever preference
the user has indicated, whether it's a spoken marker like "image!",
a change in pitch or speed, or a tone.
No, that would be very disturbing. Although it might occasionally be of
interest that some text comes from an alt attribute, the rendering of
documents without images should not be an attempt to explain what the
page would look like if you would look at it with images.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
On Mon, 1 Dec 2003, Harlan Messinger wrote: As far as that goes, I've realized that coming up with good ALT text is an
art form.
I'm sorry if I make it seem that way. Perhaps I've been studying it
too long. In truth I'm trying to say that _if_ approached in the
*right* frame of mind then it should fall into place naturally; but if
it's approached as "a short description of the image", then it'll go
wrong more often than it comes out right, and sometimes so wrong as to
be laughable.
Regarding some of your examples, though, I feel I have to put the
blame and the onus on the user agents.
This has been discussed in both directions for many years, I assure
you. I commend Hixie's FAQ for content (though I don't commend the
fact that it's in plain text) - http://www.hixie.ch/advocacy/alttext
I'm referring to "Photo of a bull in
the water canoeing" and "MIT/LCSINRIAKeioDARPACEC". Designing a
usable/accessible web page is tricky enough without, on top of everything
else, having to make it work successfully as a rebus.
With respect, you're trying to make this harder than it is. Just view
the page in a text-mode browser and the situation will become clear.
Or indeed approach it as Jukka has suggested, starting from a pure
text composition and then applying image alternatives to some of the
text content...
In my tentative [sic] opinion, it's the job of the user agent to
demarcate alternate text:
It's a point of view, but I disagree with it quite strongly, and
you'll see the same from Hixie, for example, who's been rather
influential on this part of Mozilla's design. The text-mode page
should be a fully viable text-mode page in its own right - not adorned
with lots of furniture that screams out "there's an image here but you
can't see it".
If the reader _wants_ access to the images, then their client agent
should offer them facilities for doing that (in Lynx it's the "*"
keycommand). It's not the page author's responsibility.
If the browser were to supply its own demarcation, then there's
nothing an author can do to take that away when it needs to be absent
(and there surely are situations where that is wanted). On the other
hand, if the content needs punctuation of some kind (which was indeed
needed in the examples you quoted), the author should provide it, I'd
say.
That's modulo any contribution from a stylesheet, for sure.
Lynx-like browser, with [IMAGE]alt-text-here[/IMAGE] or some such device,
Heavens, no. Sorry.
all the best
Alan J. Flavell wrote: On Mon, 1 Dec 2003, Harlan Messinger wrote:
As far as that goes, I've realized that coming up with good ALT text is an
art form.
I'm sorry if I make it seem that way. Perhaps I've been studying it
too long. In truth I'm trying to say that _if_ approached in the
*right* frame of mind then it should fall into place naturally; but if
it's approached as "a short description of the image", then it'll go
wrong more often than it comes out right, and sometimes so wrong as to
be laughable.
I really don't see what you're getting at... sometimes it's pretty
difficult to make the alt text to fall inline with content.
For example, say there's a page about the technique of galloping. Under
the heading 'position', they'd have a person seated properly on a horse
while galloping. The description of the picture would be "a man seated
on a galloping horse". The only alternative text I can think up is
something alone those lines--a man on a galloping horse.
But in a text-based browser, we'd have:
Be careful to position yourself on the horse properly. A man on a
galloping horse. As shown above, make sure you're looking up and forward..
So should the alt text just be ""? The picture is not decoration, but it
doesn't really add content apart from the visual cue.
Alan J. Flavell wrote: On Mon, 1 Dec 2003, Harlan Messinger wrote:
This has been discussed in both directions for many years, I assure
you. I commend Hixie's FAQ for content (though I don't commend
the fact that it's in plain text) -
http://www.hixie.ch/advocacy/alttext
Quite an interesting read. Note that my take is in part a response to
Hixie's document.
Just view the page in a text-mode browser and the situation will
become clear.
In my tentative [sic] opinion, it's the job of the user agent to
demarcate alternate text:
It's a point of view, but I disagree with it quite strongly, and
you'll see the same from Hixie, for example, who's been rather
influential on this part of Mozilla's design.
<aside>
Mozilla seems broken in this regard. If I turn images off, I don't
see the alt text. I only see alt text if image loading is turned on,
but the image is missing (e.g., cannot be found by server). Moz
1.3/Win2k.
</aside>
The text-mode page should be a fully viable text-mode page in its
own right
That's modulo any contribution from a stylesheet, for sure.
That has presented problems for me. If I float an image in css, than
the alt text will be in one place in a graphical browser, in a
different place in a text browser such as Lynx. Writing alt text for
Lynx seems more straightforward then writing it for the case where it
will be in a box on the left or right.
--
Brian
follow the directions in my address to email me
JustAnotherGuy wrote:
sometimes it's pretty difficult to make the alt text to fall inline
with content.
Especially when css comes into play.
For example, say there's a page about the technique of galloping.
Under the heading 'position', they'd have a person seated properly
on a horse while galloping. The description of the picture would be
"a man seated on a galloping horse". The only alternative text I
can think up is something alone those lines--a man on a galloping
horse.
I think something better might be "The proper riding position while
galloping is to crouch in the stirrups, about 10cm away from the saddle."
But in a text-based browser, we'd have:
Be careful to position yourself on the horse properly. A man on a
galloping horse. As shown above, make sure you're looking up and
forward..
Be careful to position yourself on the horse properly. The proper
riding position while galloping is to crouch in the stirrups, about
10cm away from the saddle. Make sure you're looking up and forward..
(NB: I deleted "as shown above")
--
Brian
follow the directions in my address to email me
On Mon, Dec 1, JustAnotherGuy inscribed on the eternal scroll: For example, say there's a page about the technique of galloping. Under
the heading 'position', they'd have a person seated properly on a horse
while galloping. The description of the picture would be "a man seated
on a galloping horse". The only alternative text I can think up is
something alone those lines--a man on a galloping horse.
That's because you're still thinking in terms of "a short description
of the image" instead of "a textual alternative for the information".
But in a text-based browser, we'd have:
Be careful to position yourself on the horse properly. A man on a
galloping horse. As shown above, make sure you're looking up and forward..
So should the alt text just be ""?
Be careful to position yourself on the horse properly.
<img src="..." title="Illustration of correct deportment"
alt="Make sure you're looking up and forward"
longdesc="..." <-- optional
(along with any appropriate style attributes...)
The picture is not decoration,
Agreed, but it contains relevant information. The alt text should
provide that relevant information.
but it doesn't really add content
Oh, but it does, and the alt text should add that content, unless it's
already in the text anyway - in which case your alt="" is OK.
Of course we're now going to get some smart alec telling us that this
is for blind readers, and they couldn't be looking forward if they
wanted to. Well, no, sorry: this is textual information for all
readers. Sometimes it won't quite work out for everyone, but the
information is the same, nevertheless.
--
Procrastination gives you something to look forward
to putting off tomorrow. -spotted on ahbou
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message
news:Xn****************************@193.229.0.31.. . "Harlan Messinger" <h.*********@comcast.net> wrote:
As far as that goes, I've realized that coming up with good ALT
text is an art form.
In part yes, but it's basically a matter of understanding the purpose
and actual use of ALT attributes, then applying one's share of common
sense.
Regarding some of your examples, though, I
feel I have to put the blame and the onus on the user agents.
Alan's howlers have little to do with user agent deficiencies.
I'm
referring to "Photo of a bull in the water canoeing" and
"MIT/LCSINRIAKeioDARPACEC".
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.
You say it's the correct behavior, but it's that behavior that causes the
problem. So why is it the "correct behavior"?
User agents are supposed to use tags to provide users with the cues they
need to understand the content of the page. How would one rate a browser
that reads a properly constructed HTML list with no cues indicating that all
the items constitute a list rather than one drawn-out sentence? How would
one rate a visual browser, whether graphical or text-based, that deleted all
the punctuation and capitalization and ran paragraphs together?
With <p> and <li> and <strong> and <table> and such attributes as title and
caption and lang, the page creator is already providing the cues necessary
for the software to render the page in an intelligible manner, and a
properly designed user agent uses them to cue the user. Why, with the <img>
tag and the alt attribute, is the agent designer suddenly absolved of
responsibility for providing the necessary cue(s) to the user?
Anything else would be contrary
to the meaning and purpose of alt attributes.
The purpose of the alt attribute is to provide the same information as is
conveyed by the image, which may or may not consist of *describing* the
image. The purpose is not to pretend that the image doesn't exist or that it
can be treated as in-line with the flow of the page's text when it can't be.
A browser is not to be
blamed for displaying what the author had actually written, instead of
what he should have written.
In the case of the bull and the canoe, for example, there is probably
nothing out of the ordinary with their juxtaposition on the graphically
rendered page. There is nothing wrong with their descriptions. They are not
meant to be read in-line with the page's text. As I said before, the page is
not a rebus.
The second is similarly a correct rendering of <img> elements with no
whitespace between them.
Designing a usable/accessible web page
is tricky enough without, on top of everything else, having to
make it work successfully as a rebus.
So don't make it a rebus. If it helps, design _first_ the page with
speech rendering in mind, then use CSS and images to tune the visual
alternative.
I really don't care to be blamed for designing sites primarily for graphical
browsers rather than taking an ivory tower approach. Each time someone says
this to me, my reaction is the same as if I were a TV writer asked to write
my scripts primarily for closed caption users (whether for the hearing
impaired or for people watching in a noisy bar) or primarily for those
members of the audience who can only appreciate the audio portion (whether
the visually impaired or sighted people who like to keep the TV on while
they're doing something else).
That way, you would consider which texts might have image
alternatives, instead of the opposite approach, which so often tends to
become a useless play with attributes without thinking _why_ you are
writing them.
I'm sorry, but I'm not going to buy into a theory that the purpose of images
is solely to substitute for text.
In my tentative [sic]
opinion, it's the job of the user agent to demarcate alternate
text: in a Lynx-like browser, with [IMAGE]alt-text-here[/IMAGE] or
some such device, and in speech synthesis with whatever preference
the user has indicated, whether it's a spoken marker like "image!",
a change in pitch or speed, or a tone.
No, that would be very disturbing.
I think the idea that a page would be rendered as a single, solid stream of
text all the way through without delimitation is disturbing. In your theory,
is the user also supposed to guess where the links are?
Moreover, I don't understand your theory in light of my actual experience
with non-graphical browsers because when I used Lynx many years ago it
indicated just fine where images, as well as links, were, and the
speech-synthesizing browsers I've used let the user indicate how to cue him
to images and links.
Although it might occasionally be of
interest that some text comes from an alt attribute, the rendering of
documents without images should not be an attempt to explain what the
page would look like if you would look at it with images.
I disagree.
Harlan Messinger wrote: I'm referring to "Photo of a bull in the water canoeing" and
"MIT/LCSINRIAKeioDARPACEC".
User agents are supposed to use tags to provide users with the cues
they need to understand the content of the page. How would one rate
a browser that reads a properly constructed HTML list with no cues
indicating that all the items constitute a list rather than one
drawn-out sentence?
As a deficient browser. A ua should indicate to the user that it is a
list. UL means, semantically, here is an unordered list. But IMG
does not, by itself, convey semantic meaning. The content of the
image does that. How can a ua determine the meaning of the content of
a jpeg image by itself? It cannot, of course. It is left to the
author, who is in the best position to provide the meaning for
situations where images are not rendered.
How would one rate a visual browser, whether graphical or
text-based, that deleted all the punctuation and capitalization
Silly argument. How does deleting content (punctuation) relate to alt
text?
and ran paragraphs together?
That would be a failure to provide visual clues to the semantic
meaning of a paragraph. <P> conveys semantic meaning. <IMG> does not.
The purpose is not to pretend that the image doesn't exist
If there is no inline image support, or image loading is off, then
pretending is not the issue. The image contents are irrelevant, and
the alt text is relevant.
In the case of the bull and the canoe, for example, there is
probably nothing out of the ordinary with their juxtaposition on
the graphically rendered page. There is nothing wrong with their
descriptions.
I think the point is that descriptions are generally not appropriate
for alt text.
<img src="bull.jpg" alt="On a recent trip, I saw a bull in the water.">
<img src="canoeing" alt="My friend and I paddled a 15 foot wooden canoe.">
--
Brian
follow the directions in my address to email me
Harlan Messinger wrote: "Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message
news:Xn****************************@193.229.0.31.. .
[snip] That way, you would consider which texts might have image
alternatives, instead of the opposite approach, which so often tends
to become a useless play with attributes without thinking _why_ you
are writing them.
I'm sorry, but I'm not going to buy into a theory that the purpose of
images is solely to substitute for text.
[snip]
I agree. My photograph pages are there to display my photographs! Everything
else is subsidiary.
My standard mark-up for the photographs on those pages is:
<h1><img ........ alt="....."></h1>
Some browsers display the alt text in the format of a heading if the image
isn't there. So I do try to make the alt text suitable for use in a heading. I
don't know how that corresponds to Jukka's principle.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
"Brian" <us*****@julietremblay.com.invalid-remove-this-part> wrote in
message news:hR2zb.199346$Dw6.743973@attbi_s02... Harlan Messinger wrote: I'm referring to "Photo of a bull in the water canoeing" and
"MIT/LCSINRIAKeioDARPACEC". >
User agents are supposed to use tags to provide users with the cues
they need to understand the content of the page. How would one rate
a browser that reads a properly constructed HTML list with no cues
indicating that all the items constitute a list rather than one
drawn-out sentence?
As a deficient browser. A ua should indicate to the user that it is a
list. UL means, semantically, here is an unordered list. But IMG
does not, by itself, convey semantic meaning. The content of the
image does that. How can a ua determine the meaning of the content of
a jpeg image by itself? It cannot, of course. It is left to the
author, who is in the best position to provide the meaning for
situations where images are not rendered.
How would one rate a visual browser, whether graphical or
text-based, that deleted all the punctuation and capitalization
Silly argument. How does deleting content (punctuation) relate to alt
text?
Punctuation isn't "content" any more than tags are. Both are cues that help
the reader interpret text as something other than an unbroken,
undistinguishable torrent of words.
and ran paragraphs together?
That would be a failure to provide visual clues to the semantic
meaning of a paragraph. <P> conveys semantic meaning. <IMG> does not.
Of couse it does. It means precisely, "Hey, this isn't part of the main flow
of the text, it's a separate piece of information." Just like "<p>" means,
"Hey, I've just gone on to a different idea here."
The purpose is not to pretend that the image doesn't exist
If there is no inline image support, or image loading is off, then
pretending is not the issue. The image contents are irrelevant, and
the alt text is relevant.
In the case of the bull and the canoe, for example, there is
probably nothing out of the ordinary with their juxtaposition on
the graphically rendered page. There is nothing wrong with their
descriptions.
I think the point is that descriptions are generally not appropriate
for alt text.
I think this falls into the "damned if you do, damned if you don't"
category. I could say, "Well, the blind can't appreciate illustrations, so
I'll just use alt=" " and then they won't know that the illustrations are
there." But then I'm told that even the blind are entitled to know about
everything significant that's on the page. Well, just as a cigar is
sometimes just a cigar, an illustration is sometimes just an illustration.
Its meaning lies entirely in what it depicts. So the alt text describes the
photo. And then you tell me it shouldn't.
<img src="bull.jpg" alt="On a recent trip, I saw a bull in the water.">
<img src="canoeing" alt="My friend and I paddled a 15 foot wooden canoe.">
Nowhere is the principle stated that the alt information should provide
*more* information than the image! If I'm not telling the typical IE user
that the bull in the picture happens to have been seen by me, then why does
that need to be spelled out to the Lynx user? 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?
Harlan Messinger wrote: "Brian" wrote
Harlan Messinger wrote:
> I'm referring to "Photo of a bull in the water canoeing"
> and "MIT/LCSINRIAKeioDARPACEC". How would one rate a visual browser, whether graphical or
text-based, that deleted all the punctuation and capitalization
Silly argument. How does deleting content (punctuation) relate
to alt text?
Punctuation isn't "content" any more than tags are.
Of course it is. The author, not the ua, puts in periods, question
marks, and so on. (The <q> element tried to change that, and has failed.)
Both are cues that help the reader interpret text as something
other than an unbroken, undistinguishable torrent of words.
Interogative pronouns are cues that help the reader interpret text as
a question, and not a statement. Such pronouns are content added by
the author, not the ua.
That would be a failure to provide visual clues to the semantic
meaning of a paragraph. <P> conveys semantic meaning. <IMG>
does not.
Of couse it does. It means precisely, "Hey, this isn't part of the
main flow of the text, it's a separate piece of information."
Precisely? Where did you read that? Here's what I found in the html
4.01 spec.
<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;
it is usually replaced inline by the image designated by the src
attribute, the exception being for left or right-aligned images that
are "floated" out of line.
</quote>
Note the part that says, "The IMG element has no content." As such,
how can a ua confer meaning upon it?
<img src="bull.jpg" alt="On a recent trip, I saw a bull in the
water."> <img src="canoeing" alt="My friend and I paddled a 15
foot wooden canoe.">
Nowhere is the principle stated that the alt information should
provide *more* information than the image!
Whenever possible, it should provide the same information, not more,
not less. I was imagining a context for the images. When writing alt
text, ask yourself why you're putting that image there. Why might
someone put an image of a bull in the water on a web page? Perhaps to
share with readers what he saw on a camping trip? Then the alt text I
wrote is appropriate. Obviously, if the context is something else,
than the alt text must be written differently.
If I'm not telling the typical IE user that the bull in the picture
happens to have been seen by me, then why does that need to be
spelled out to the Lynx user?
That was an example of alt text that might be appropriate if the page
were about a camping trip, on which the author canoed down a river and
saw a bull in the water. Of course it's hypothetical, since I didn't
see the bull in question. Did you mistake me for the author of the
original html document? I can't imagine you did, and thus can't
imagine what you're scolding me for.
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.
--
Brian
follow the directions in my address to email me
"Brian" <us*****@julietremblay.com.invalid-remove-this-part> wrote in
message news:WV4zb.394924$HS4.3204510@attbi_s01... Harlan Messinger wrote: "Brian" wrote
Harlan Messinger wrote:
>> I'm referring to "Photo of a bull in the water canoeing"
>> and "MIT/LCSINRIAKeioDARPACEC".
How would one rate a visual browser, whether graphical or
text-based, that deleted all the punctuation and capitalization
Silly argument. How does deleting content (punctuation) relate
to alt text?
Punctuation isn't "content" any more than tags are.
Of course it is. The author, not the ua, puts in periods, question
marks, and so on.
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.
In fact, whether something is "content" is not defined by who puts it there.
(The <q> element tried to change that, and has failed.)
Both are cues that help the reader interpret text as something
other than an unbroken, undistinguishable torrent of words.
Interogative pronouns are cues that help the reader interpret text as
a question, and not a statement. Such pronouns are content added by
the author, not the ua.
Who was talking about pronouns?
That would be a failure to provide visual clues to the semantic
meaning of a paragraph. <P> conveys semantic meaning. <IMG>
does not.
Of couse it does. It means precisely, "Hey, this isn't part of the
main flow of the text, it's a separate piece of information."
Precisely? Where did you read that? Here's what I found in the html
4.01 spec.
<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;
it is usually replaced inline by the image designated by the src
attribute, the exception being for left or right-aligned images that
are "floated" out of line.
</quote>
Note the part that says, "The IMG element has no content." As such,
how can a ua confer meaning upon it?
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 ...>
while "has content" means that it can also be used in the form
<tag ...>stuff</tag>
(or
<tag ...>stuff
if the ending tag is optional).
That has nothing to do with the content of a communcation as distinguished
from such other characteristics of a communication as intonation, gestures,
cues, cadence, pitch, non-verbal oral utterances, punctuation, font, size,
style, color, or layout.
<img src="bull.jpg" alt="On a recent trip, I saw a bull in the
water."> <img src="canoeing" alt="My friend and I paddled a 15
foot wooden canoe.">
Nowhere is the principle stated that the alt information should
provide *more* information than the image!
Whenever possible, it should provide the same information, not more,
not less. I was imagining a context for the images. When writing alt
text, ask yourself why you're putting that image there.
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. You don't want to
write, "Bulls are commonly associated with Spain" or "Bullfighting is the
Spanish national pastime" if your page has nothing about bulls on it. Your
reader will wonder why you're bringing up bulls out of the blue. Yet someone
seeing the image will know perfectly well that it's a simple illustration.
You see, the person who put the image there might assume that most people
know perfectly well that bulls have a particular association with Spain.
Therefore, a picture of a bull is a good general illustration for a page
about Spain. Now, what to do about someone who isn't viewing images? You
either tell him nothing, or you tell him there's a picture of a bull. Those
are your choices.
Why might
someone put an image of a bull in the water on a web page?
Perhaps to
share with readers what he saw on a camping trip? Then the alt text I
wrote is appropriate. Obviously, if the context is something else,
than the alt text must be written differently.
If I'm not telling the typical IE user that the bull in the picture
happens to have been seen by me, then why does that need to be
spelled out to the Lynx user?
That was an example of alt text that might be appropriate if the page
were about a camping trip, on which the author canoed down a river and
saw a bull in the water. Of course it's hypothetical, since I didn't
see the bull in question. Did you mistake me for the author of the
original html document? I can't imagine you did, and thus can't
imagine what you're scolding me for.
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.
Care to explain how to avoid that? The "howler" is supposed to be based on
the premise that that is automatically how the browser will read the alt
text.
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. But if it amuses you...
Both are cues that help the reader interpret text as something other
than an unbroken, undistinguishable torrent of words.
If it makes you any happier, I'll go along with that for the purposes
of discussion.
<P> conveys semantic meaning. <IMG> does not.
Of couse it does. It means precisely, "Hey, this isn't part of the main flow
of the text,
As HTML is defined, the <img...> , in and of itself, is flowed into
the text. You have to take deliberate actions to get it out of the
flow if that is your intention.
It works best, IMHO, if the alt text (used instead of the image) can
also flow into the context, unless the image has been taken out of the
flow, in which case the alt text would be taken out of the flow too.
The idea seems to me to be coherent, anyway.
it's a separate piece of information."
No more than each word is a "separate piece of information", as far as
HTML markup is concerned.
Just like "<p>" means, "Hey, I've just gone on to a different idea
here."
There's a reason why <p> is characterised as a block-mode element,
whereas <img...> is characterised as an inline element which can be
flowed into text at any point.
I think this falls into the "damned if you do, damned if you don't"
category. I could say, "Well, the blind can't appreciate illustrations, so
I'll just use alt=" " and then they won't know that the illustrations are
there." But then I'm told that even the blind are entitled to know about
everything significant that's on the page.
Some take that view, indeed, and we have the title= attribute for
supplying additional information about the element to which it's
applied, above and beyond the "alternative text" which we say is the
intent of the alt= attribute.
Others take the view that the important thing to them is the
information, and that text and images (and possibly optional sound)
are alternative ways of conveying information. They'd find it
unnecessarily distracting to be presented with much detailed chatter
about the visual appearance of the page, when all that they wanted was
the information contained in it. Ergo, there need to be user agent
options so that the reader can get what they're seeking; and the
author needs to take care to put the right stuff into the right places
so that those with such configurable browsers can retrieve it.
an illustration is sometimes just an illustration.
Its meaning lies entirely in what it depicts.
There are such cases, indeed. Let them not be used to defeat the
intent of the alt= attribute in general, though.
So the alt text describes the photo. And then you tell me it
shouldn't.
I tell you that, in relation to images in general, "that seems to be
wrong more often than it's right". Of course, for someone whose main
business is the production of pictures, this might seem an unbalanced
opinion; but IMHO most people put pictures into their web pages to
illustrate some information - using that term in its most general
sense - rather than to supply a purely visual experience for which
there can be no verbal substitue.
YMMV and IMHO, keep cool after opening...
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote in message
news:Pi*******************************@ppepc56.ph. gla.ac.uk... 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.
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.
But if it amuses you...
Both are cues that help the reader interpret text as something other
than an unbroken, undistinguishable torrent of words.
If it makes you any happier, I'll go along with that for the purposes
of discussion.
<P> conveys semantic meaning. <IMG> does not.
Of couse it does. It means precisely, "Hey, this isn't part of the main
flow of the text,
As HTML is defined, the <img...> , in and of itself, is flowed into
the text.
You're failing to distinguish layout flow from logical flow. They aren't the
same thing. Maybe that's the problem here. You call it "quibbling about
semantics", but it's not just a quibble. Look at Brian's failure to
distinguish the content of a tag from the content of a communication.
You have to take deliberate actions to get it out of the
flow if that is your intention.
It works best, IMHO, if the alt text (used instead of the image) can
also flow into the context, unless the image has been taken out of the
flow, in which case the alt text would be taken out of the flow too.
The idea seems to me to be coherent, anyway.
it's a separate piece of information."
No more than each word is a "separate piece of information", as far as
HTML markup is concerned.
Just like "<p>" means, "Hey, I've just gone on to a different idea
here."
There's a reason why <p> is characterised as a block-mode element,
whereas <img...> is characterised as an inline element which can be
flowed into text at any point.
"Block" and "in-line" are layout concepts. You are confusing them with
communication concepts.
I think this falls into the "damned if you do, damned if you don't"
category. I could say, "Well, the blind can't appreciate illustrations,
so I'll just use alt=" " and then they won't know that the illustrations
are there." But then I'm told that even the blind are entitled to know about
everything significant that's on the page.
Some take that view, indeed, and we have the title= attribute for
supplying additional information about the element to which it's
applied, above and beyond the "alternative text" which we say is the
intent of the alt= attribute.
Others take the view that the important thing to them is the
information, and that text and images (and possibly optional sound)
are alternative ways of conveying information. They'd find it
unnecessarily distracting to be presented with much detailed chatter
about the visual appearance of the page, when all that they wanted was
the information contained in it. Ergo, there need to be user agent
options so that the reader can get what they're seeking; and the
author needs to take care to put the right stuff into the right places
so that those with such configurable browsers can retrieve it.
an illustration is sometimes just an illustration.
Its meaning lies entirely in what it depicts.
There are such cases, indeed. Let them not be used to defeat the
intent of the alt= attribute in general, though.
It seems to me that this is the tail wagging the dog.
Harlan Messinger wrote: "Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote in message
news:Pi*******************************@ppepc56.ph. gla.ac.uk... 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.
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.
it is is it
it is, is it?
it is "is it"
--
William Tasso - http://WilliamTasso.com
Harlan Messinger wrote: "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.
<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. <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."
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 ...>
My bad. I wasn't thinking in terms of sgml. When writing alt text, ask yourself why you're putting that image
there.
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.
Sometimes, alt="" is the most appropriate choice. 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.
Care to explain how to avoid that?
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.
--
Brian
follow the directions in my address to email me
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote: Harlan Messinger wrote: "Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message
news:Xn****************************@193.229.0.31.. . [snip] That way, you would consider which texts might have image
alternatives, instead of the opposite approach, which so often
tends to become a useless play with attributes without thinking
_why_ you are writing them.
I'm sorry, but I'm not going to buy into a theory that the purpose
of images is solely to substitute for text.
[snip]
I agree.
You agree with the strawman argument?
My photograph pages are there to display my photographs!
If you wish to put it that way, yes. Then comes the fact that the page
may and will be accessed by user agents that do not display them, or by
software that doesn't even try to present the document to anyone. What
would you say to such visitors? It depends on your photographs, but I
guess it boils down to a set of texts that describe which photographs
you have. You are not expected to explain their content in words.
Instead, you would give the metainformation. So there you have the
basic text, where you then provide graphic alternatives to some text,
namely the actual photos.
My standard mark-up for the photographs on those pages is:
<h1><img ........ alt="....."></h1>
Are all your photos first level headings? Doesn't sound reasonable.
Some browsers display the alt text in the format of a heading if
the image isn't there.
Well, that's part of the problem - unless your photos are something
rather special.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
"Harlan Messinger" <h.*********@comcast.net> wrote: 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.
You say it's the correct behavior, but it's that behavior that
causes the problem. So why is it the "correct behavior"?
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.
Similarly, if you write <h6>some text</h6> in a misguided attempt to
make text smaller, 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.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
> 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. Anything else would be contrary
to the meaning and purpose of alt attributes. A browser is not to be
blamed for displaying what the author had actually written, instead of
what he should have written.
It of course is highly subjective what is correct behaviour. I am sure we
all agree that alt text is indeed there to be used when the images are not
displayed (there is also no reason why a browser shouldn't use it in some
way when they are displayed should it so wish, as long as it honours the
primary use) but how it is used is another matter. I disagree with the idea
of "acting as if the elements would be replaced by their alt texts". The
alt text is an alternate rendering of the img element but the important
thing is that it is still the img element being rendered. It seems quite
reasonable for browsers to provide some acknowledgement of that.
As it happens I consider running the alt text into the flow is a perfectly
reasonable thing to do as img is an inline element after all, but the fact
that it is still an img element should not be lost if there are ways of
indicating this. The user should be made aware directly or indirectly that
this is an img element.
"Graham J" <me@privacy.net> wrote: It of course is highly subjective what is correct behaviour.
Not really, in this case.
I am
sure we all agree that alt text is indeed there to be used when the
images are not displayed
I hope so. That _is_ the correct behaviour, and there's nothing
subjective about it, but people have got a wrong idea, often a
_completely_ wrong idea about this, and that's probably the main reason
behind the alt text problem.
but how it is used is another matter.
There are some liberties in rendering text, but if we can agree on the
principle, then the question _is_ about rendering text, is it not? You
seem to wish to convert it to a different question.
I disagree with the idea of "acting as if the
elements would be replaced by their alt texts".
What else would it be? That's just a paraphrase of the principle we
just agreed on.
The alt text is an
alternate rendering of the img element but the important thing is
that it is still the img element being rendered.
An img element has two attributes that specify its information content,
the alt attribute and the src attribute. They are defined to be used as
alternatives, in different rendering situations. While it might be
useful, and indeed recommendable as browsers go, to _allow_ an
_optional_ access to the other alternative and thereby to make such
information available _upon request_, it would be just confusing in
most situations to tell people who are not looking at the image (and
quite possibly couldn't look at it) that the text they see or hear or
read with their fingertips is actually a replacement for some image.
Admittedly, sometimes an alt text is neither a complete replacement for
the information content nor just a description (like "[my photo]"),
e.g. when the image is a pie chart and the alt text just explains the
_main_ point in the data. But in such cases, knowing that some text is
a replacement for an image is not really useful. What the user would
need is, for example, an explicit link to a separate HTML document that
contains the complete data in a non-graphic format (or, if someone
believes in the longdesc theory, an implicit longdesc link to it).
As it happens I consider running the alt text into the flow is a
perfectly reasonable thing to do as img is an inline element after
all, but the fact that it is still an img element should not be
lost if there are ways of indicating this. The user should be made
aware directly or indirectly that this is an img element.
Why? Should all those spacer images be announced that way too? And all
purely decorational images? What about images that contain just text
in a particular appearance? I think it would be completely nonsensical
to tell the user that the text he hears is a replacement for an image
in such cases. And browsers could hardly be expected to distinguish
between different relationships with an alt text and the image.
Finally, the point was, in the examples where this started, that an
author had sloppily written <img> elements without thinking what sense
they make when their alt texts are read in succession. Spaces and
punctuation are relevant in alt texts as elsewhere.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
Jukka K. Korpela wrote: "Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote:
[snip] My photograph pages are there to display my photographs!
If you wish to put it that way, yes. Then comes the fact that the page
may and will be accessed by user agents that do not display them, or
by software that doesn't even try to present the document to anyone.
What would you say to such visitors? It depends on your photographs,
but I guess it boils down to a set of texts that describe which
photographs you have. You are not expected to explain their content
in words. Instead, you would give the metainformation. So there you
have the basic text, where you then provide graphic alternatives to
some text, namely the actual photos.
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. My standard mark-up for the photographs on those pages is:
<h1><img ........ alt="....."></h1>
Are all your photos first level headings? Doesn't sound reasonable.
The photograph is the reason the page exists. There is no text that could
sensibly serve as a heading. So if there is to be a first level heading, it is
the photograph. (Previously I didn't having headings on those pages). Some browsers display the alt text in the format of a heading if
the image isn't there.
Well, that's part of the problem - unless your photos are something
rather special.
Who is to say whether they are rather special? They are to me. Photographers
like looking at one-another's work. I like seeing photographs of a good size,
for example 700 x 500 or larger. I produce my photographs to look best on a
calibrated monitor that can show such a size without scrolling. I don't stop
people looking with less ideal equipment, but I don't care if they don't get
the benefits. If they are not prepared to make the effort, they are probably
not part of my target audience.
Perhaps this photograph is a bit special. It is in the December 2003
Dutch-language edition of National Geographic. They found it via a web search.
(Obviously they didn't print this low-resolution web version. They started
with the 3750 x 2646 version). http://www.barry.pearson.name/photog...95_26_11_3.htm
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
> > It of course is highly subjective what is correct behaviour.
Not really, in this case.
True. I left a critical "the" out. I meant to refer to your expression
"_the_ correct behaviour" when what you were describing was "_a_ correct
behaviour".
I am sure we all agree that alt text is indeed there to be used when the
images are not displayed
I hope so. That _is_ the correct behaviour, and there's nothing
subjective about it,
Yes I agree.
but how it is used is another matter.
There are some liberties in rendering text, but if we can agree on the
principle, then the question _is_ about rendering text, is it not? You
seem to wish to convert it to a different question.
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.
That is _a_ correct behaviour and you might even consider it the best way to
do it. However graphical browsers displaying the text inside image place
holders, or text ones displaying it as [alt text] or giving it a colour, or
speech browsers changing the emphasis or phrasing for it are all also
correct behaviours. You might not like them but they aren't actually wrong
and others may prefer it.
I disagree with the idea of "acting as if the
elements would be replaced by their alt texts".
What else would it be? That's just a paraphrase of the principle we
just agreed on.
Not at all. You talk about acting as if the original <img> element never
existed and there was only the alt text. I say that that the association
with an <img> element shouldn't be lost as it might be important.
it would be just
confusing in most situations to tell people who are not looking at the image (and
quite possibly couldn't look at it) that the text they see or hear or
read with their fingertips is actually a replacement for some image.
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.
Why? Should all those spacer images be announced that way too? And all
purely decorational images? What about images that contain just text
in a particular appearance? I think it would be completely nonsensical
to tell the user that the text he hears is a replacement for an image
in such cases.
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. The chances are it needn't be shown at all.
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.
Sure there are cases where well written alt text can adequately replace the
image without needing highlighting in some way. 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.
Finally, the point was, in the examples where this started, that an
author had sloppily written <img> elements without thinking what sense
they make when their alt texts are read in succession. Spaces and
punctuation are relevant in alt texts as elsewhere.
Yes, and the suggestion was made that browsers were contributing to the
problem by failing to provide any indication that said text was alt text.
It was originally put stronger than that which I would disagree with, but
otherwise I consider the suggestion perfectly reasonable. Some seem to
consider that browsers behaving like that are doing the right thing. 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. At the very least they should allow the user to
decide whether alt text should be identified in some way.
"William Tasso" <ne****@tbdata.com> wrote in message
news:bq*************@ID-139074.news.uni-berlin.de... Harlan Messinger wrote: "Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote in message
news:Pi*******************************@ppepc56.ph. gla.ac.uk... 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.
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.
it is is it
it is, is it?
it is "is it"
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>
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message
news:Xn*****************************@193.229.0.31. .. "Harlan Messinger" <h.*********@comcast.net> wrote:
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.
You say it's the correct behavior, but it's that behavior that
causes the problem. So why is it the "correct behavior"?
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.
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.
Similarly, if you write <h6>some text</h6> in a misguided attempt to
make text smaller,
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.
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.
"Brian" <us*****@julietremblay.com.invalid-remove-this-part> wrote in
message news:ga8zb.403734$Fm2.411705@attbi_s04... Harlan Messinger wrote: "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.
<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.
<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."
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 ...>
My bad. I wasn't thinking in terms of sgml.
When writing alt text, ask yourself why you're putting that image
there.
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.
Sometimes, alt="" is the most appropriate choice.
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.)
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.
Care to explain how to avoid that?
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.
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.
Harlan Messinger wrote: 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.
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.
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.
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,
I'd agree.
* (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.
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.
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.)
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"><IMG
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.
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.
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
"Brian" <us*****@julietremblay.com.invalid-remove-this-part> wrote in
message news:WIozb.290359$9E1.1489334@attbi_s52... Harlan Messinger wrote: * (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.
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.
I'll have to look back at the resource from which I got this information.
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.)
It's not an empty string, of course, it is a space.
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.
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"><IMG
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.
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.
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.
Barry Pearson wrote: 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.
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).
Are all your photos first level headings? Doesn't sound reasonable.
The photograph is the reason the page exists.
So that would mean the photograph is the content on the page, not the
top-level header of the content of the page.
There is no text that could
sensibly serve as a heading.
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
"Graham J" <me@privacy.net> wrote: 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.
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">ucca 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.
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.
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.
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.
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!).
The chances are it needn't be shown at all.
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.
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.
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.
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.
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.
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.
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
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message
news:Xn****************************@193.229.0.31.. . 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">ucca said that...</p>
intended to create a decorative initial.
*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.
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.
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?
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."
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.
"Harlan Messinger" <h.*********@comcast.net> wrote: <p><img alt="Y" src="Y.gif">ucca said that...</p> intended to
create a decorative initial.
*This* strikes me as a hack that shouldn't be expected to work,
It should work and it does work. Not optimally e.g. on IE in no-images
mode, but otherwise pretty well.
with the "Y" treated not only in the flow, but *as part of the word
to which it is adjacent*.
Of course. It's similar to
<p><font style="initial">Y</font>ucca said that...</p>
If you want drop-caps, wait until browsers
implement the CSS standard that supports them.
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. 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.
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?
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). 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."
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.
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
On Thu, 4 Dec 2003, Harlan Messinger wrote: "Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message common constructs like
<p><img alt="Y" src="Y.gif">ucca said that...</p>
intended to create a decorative initial.
*This* strikes me as a hack that shouldn't be expected to work,
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.
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.
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?
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).
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."
For a speech synthesizer, that's no help.
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.
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.
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.
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote 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">ucca said that...</p>
intended to create a decorative initial.
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.*********@comcast.net> wrote:
*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*.
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.
If you want drop-caps, wait until browsers implement the CSS standard that
supports them.
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.
On Thu, 4 Dec 2003 23:03:56 +0000,
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote: 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.
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.
On Wed, 3 Dec 2003 13:40:04 -0000,
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote: 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.
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.
Jukka K. Korpela wrote: "Harlan Messinger" <h.*********@comcast.net> wrote:
<p><img alt="Y" src="Y.gif">ucca said that...</p> intended to
create a decorative initial.
This strikes me as a hack that shouldn't be expected to work,
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.
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.
Tim wrote: On Wed, 3 Dec 2003 13:40:04 -0000,
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote:
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.
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.
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="Magnificent Frigatebird" title="Magnificent 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/photog...95_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/
Tim <ad***@sheerhell.lan> wrote: Using normal typing brackets (thus) is probably better than square
brackets.
I don't think so, because alt="(...)" makes perfect sense when "..." is
a genuine replacement for an image, conveying the same message as the
image instead of just naming the image. The parentheses would just
indicate the text as, well, parenthetic.
It should stand a better chance of being read out in a
less intrusive manner
That's the _problem_ with it. The user would not distinguish between
the renderings of
(foo bar)
and
<img src="..." alt="(foo bar)">
and would have little way of guessing what's going on.
But now that I think of it, maybe alt="photo of..." or alt="image
of..." or something like that is sufficient, and should be less
intrusive. That is, _if_ there is no alt text that could adequately
_replace_ the image, then using an alt text formulation that explicitly
uses a word like "image" or "photo" is suitable.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote: 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".
That statement of mine was meant to be provocative, though mainly as
regards to provoking thoughts. :-)
But for my photograph pages, the
photographs are primary and the text is subsidiary.
Certainly. But design-wise, and to people who cannot see the images,
the texts rather than the images are the solid basis. You could design
and implement the page well before having uploaded (or selected, or
even _taken_!) the actual images.
That way, the page will work in no-images mode from the very start, and
search engines could index it early, and people could see what has been
planned to appear there. Of course, if images have caption texts (as I
think they should in most photo galleries), then these texts will
largely duplicate the alt texts - and one might even say that in such
cases you could use alt="", but it's probably clearer to use
"redundant" alt texts that duplicate the caption (often in an abridged
form).
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
Jukka K. Korpela wrote: "Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote:
[snip] But for my photograph pages, the
photographs are primary and the text is subsidiary.
Certainly. But design-wise, and to people who cannot see the images,
the texts rather than the images are the solid basis. You could design
and implement the page well before having uploaded (or selected, or
even _taken_!) the actual images.
[snip]
I believe proper design only makes sense in the context of a target audience.
Otherwise, you can't select from alternative methods, or evaluate whether the
design has met its objectives.
And the target audience for my photographs are sighted people. It sounds
harsh, but really that is the nature of photography. They are also people
prepared to wait while a 100 KB image is downloaded. And then have a
large-enough viewport. Rather than spend extra time trying to reach people
outside that group, I am better off producing more content for that group.
These characteristics appear to break a number of the guidelines about
developing web pages. But I believe too many of those guidelines are presented
as though they apply generally. Some guidelines appear to assume that the web
is about text, for example. Perhaps in most cases - but certainly not all. In
fact, there are various "communities" on the web, sometimes "implicit
communities", who can be perfectly happy ignoring those guidelines, and
perhaps have different guidelines. Not for everything they ever do - just when
they are pursuing a particular activity. I have different design criteria &
guidelines for different web sites. This is just "marketing" - the need for
that hasn't gone away.
(I don't take photographs specifically for the web. I take them mainly to be
projected, perhaps 150cm x 150cm, or printed, perhaps A3 or larger).
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote: And the target audience for my photographs are sighted people. It
sounds harsh, but really that is the nature of photography.
It's not harsh at all. But these sighted people might be using a text-
only browser, or a speech browser, or a graphic browser configured not
to show images, or a search engine. Or a blind person might stumble
across your page, hears that you have a photograph of
/Cryptavis rarissima/, and remembers that this is just the species that
a friend of his has been extremely interested in.
Of course, using _either_ image caption texts (as normal textual
content) _or_ alt attributes will help in each case. But as mentioned,
it's best to use both.
But the principle of designing first a text-based version also helps in
making the content appear in an order that is suitable for linear
consumption and making things verbally explicit. For example, if all
the images are photos of birds of a specific genus, it might seem
redundant to mention this, since the user can see that at a glance. But
if you think about textual access, it suddenly makes quite some sense
to include a descriptive heading and perhaps a short explanatory
paragraph.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message
news:Xn****************************@193.229.0.31.. . "Harlan Messinger" <h.*********@comcast.net> wrote:
<p><img alt="Y" src="Y.gif">ucca said that...</p> intended to
create a decorative initial.
*This* strikes me as a hack that shouldn't be expected to work,
It should work and it does work. Not optimally e.g. on IE in no-images
mode, but otherwise pretty well.
with the "Y" treated not only in the flow, but *as part of the word
to which it is adjacent*.
Of course. It's similar to
<p><font style="initial">Y</font>ucca said that...</p>
If you want drop-caps, wait until browsers
implement the CSS standard that supports them.
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.
<chuckle> I realize all of you here aren't the same person, so this response
isn't personal, but your comment is ironic given that this is the newsgroup
where a bunch of people have berated me for defending the carrying over of
effective, time-honored graphical techniques into web publishing.
The prevailing philosophy here has been to avoid the use of HTML for
formatting or layout. No <font>s, use <em> instead of <i> and <strong>
instead of <bold>, and then use CSS or let the browser do what it wants.
From that perspective, I'd expect that using an <img> tag to insert a
depiction of a letter as a literal part of the text would be anathema. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Mike |
last post by:
I am sure that I am making a simple boneheaded mistake and I would
appreciate your help in spotting in. I have just installed
apache_2.0.53-win32-x86-no_ssl.exe
php-5.0.3-Win32.zip...
|
by: Xah Lee |
last post by:
here's a large exercise that uses what we built before.
suppose you have tens of thousands of files in various directories.
Some of these files are identical, but you don't know which ones are...
|
by: Tom Lee |
last post by:
Hi,
I'm new to .NET 2003 compiler. When I tried to compile my
program using DEBUG mode, I got the following errors in the
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7
\include\xdebug...
|
by: JKop |
last post by:
Here's what I know so far:
You have a C++ project. You have source files in it. When you go to
compile it, first thing the preprocessor sticks the header files into
each source file.
So now...
|
by: Lars Eighner |
last post by:
I'm using the HTML 4.01 strict DTD.
I have a few questions about the longdesc attribute when used
with the IMG element.
I understand that longdesc takes a uri for a value.
1) What kind of...
|
by: pooja |
last post by:
Suppose i have created a class c1 with f1()in c1.cpp
and included this c1.cpp in file1.cpp file , which is also having
main() by giving the statement #include "c1.cpp".
the same i can do by...
|
by: UJ |
last post by:
Folks,
We provide custom content for our customers. Currently we put the files on
our server and people have a program we provide that will download the
files. These files are usually SWF, HTML or...
|
by: theintrepidfox |
last post by:
Hi Guys
Is there any way to set 'alt', 'longdesc' attributes and an AccessKey
property for a MenuItem? I need it to make it to comply with
accessibility guidelines for impaired users.
Any...
|
by: aRTx |
last post by:
I have try a couple of time but does not work for me
My files everytime are sortet by NAME.
I want to Sort my files by Date-desc.
Can anyone help me to do it?
The Script
<?
/*
ORIGJINALI
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
