It is very common to see an image as a link on many web pages.
Authors create them by putting an <img> tag inside a <a> tag.
This is very much extra use of another tag.

But why browsers dont support href attribute for <img> tag?

Whether at any time this came up at W3C?

biju wrote:
> It is very common to see an image as a link on many web pages.
> Authors create them by putting an <img> tag inside a <a> tag.
> This is very much extra use of another tag.

No it isn't. You *can* have an IMG by itself inside an A, but you can
also have

<a href="something">text<img src="blah" alt="blah">more text<img
src="foo" alt="bar">and even more text</a>

There isn't any reason to have another way to do the same thing. An
image is an image, a link is a link.

On Apr 6, 9:54pm, Harlan Messinger
<hmessinger.removet...@comcast.net> wrote:
> <a href="something">text<img src="blah" alt="blah">more text<img
> src="foo" alt="bar">and even more text</a>

Yes in that case we need <a> tag.

But I was talking about the case in lot to web pages where we only see
just a single <img> tag and no text content or any thing else insde a
<a> tag.
Like:-
<a href="some_page.html"><img src="blah_image.jpg" alt="blah"></a>

biju wrote:
> On Apr 6, 9:54 pm, Harlan Messinger
> <hmessinger.removet...@comcast.net> wrote:
>> <a href="something">text<img src="blah" alt="blah">more text<img
>> src="foo" alt="bar">and even more text</a>
>
> Yes in that case we need <a> tag.
>
> But I was talking about the case in lot to web pages where we only see
> just a single <img> tag and no text content or any thing else insde a
> <a> tag.
> Like:-
> <a href="some_page.html"><img src="blah_image.jpg" alt="blah"></a>

As I asked you: why does there have to be another way to do the same
thing? Saving a tag is not exactly the Holy Grail.

On 7 Apr, 02:36, biju <bijumaill...@yahoo.com> wrote:
> It is very common to see an image as a link on many web pages.

It's part of HTML (and the W3C's mental model of how things ought to
work) that specifications should be "simple" (in formal terms as a
protocol) rather than "simple" for users to hand code.

There have been intentions at various times to roll up all of the
"link" elements, <a>, <img>, <link> into one (maybe <object>) and to
treat _everything_ as "some sort of link to an extenal resource". An
<img> would become "The resource link that imports the resource
immediately and renders it", <a> would become "A link to a resource
that's only traversed if the user activates it" and <link> would be "A
resource link that's retrieved but not rendered directly".

Thinking in these terms, we see a logical interpretation of why <a>
and <link> use href (be aware of this linked resource, but don't show
it) and <img> uses src (render this resource right now). Within this
view, it would indeed be possible to do what you describe, and to make
the behaviour (now or later) explicitly coupled to the attribute(s)
used. <img src="..." href="..." > could easily be defined to normally
show the image from src, then traverse the link from href if
activated. As the behaviour is then only dependent on the attributes,
we could roll all of these behaviours into <object> (or "<foo>") and
ditch <img> and <a> altogether. If you look around XHTML 2.*, then
you'll see thoughts in this direction.

However HTML is also bound by its legacy behaviour. This stuff just
ain't going to happen. Nor (IMHO) should it. Having both <a> and
<img>, and their use of different attribute names, just isn't a big
enough problem to beginners to worry about changing it.

Scripsit biju:

> It is very common to see an image as a link on many web pages.

It's common and it's generally bad practice. To begin with, it makes it
impossible to use (or let browsers use by default) the _simple_ ful
features of changing link color after the link has been visited or on
mouseover. You would have to do take extra trouble to create a plastic
imitation of such functionality when you use images as links.

Links want to be text links. See "Links Want To Be Links",
http://www.cs.tut.fi/~jkorpela/www/links.html

> But why browsers dont support href attribute for <img> tag?

As Andy explains, such things have been proposed and they have even made
their way to the XHTML 2 draft, which will hopefully expire in a puff of
reason.

In addition to simplicity (use one link element, though foolishly named
<a>, for any link), there's a deeper reason. The linking element should
logically have the href attribute (though this attribute was poorly
named from the beginning - a simple "ref" would have been better), but
it should specify the _image_ address. There is no good reason for using
"src" as the attribute name.

In the original design, an <img> element was a link in a broad sense. It
is different from an <a> link in the sense that graphic browsers are
supposed to _automatically_ follow the <img> link and to render the
image. To quote the first HTML specification, HTML 2.0:

"The IMG element refers to an image or icon via a hyperlink (see section
Simultaneous Presentation of Image Resources)."

http://www.w3.org/MarkUp/html-spec/h...5.html#SEC5.10

The section cited explains:

"An HTML user agent may activate hyperlinks indicated by IMG and INPUT
elements concurrently with processing the document; that is, image
hyperlinks may be processed without explicit request by the user. Image
resources should be embedded in the presentation at the point of the
tail anchor, that is the IMG or INPUT element."

(In fact, some browsers that have special kind of support to images have
implemented <img> elements in a very link-like manner: the alt text or
other identifying text is presented to the user, who may then follow it
as a link, opening the image, possibly in an external viewer.)

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Jukka K. Korpela wrote:
> Scripsit biju:
>
>> It is very common to see an image as a link on many web pages.
>
> It's common and it's generally bad practice. To begin with, it makes it
> impossible to use (or let browsers use by default) the _simple_ ful
> features of changing link color after the link has been visited or on
> mouseover. You would have to do take extra trouble to create a plastic
> imitation of such functionality when you use images as links.

In other words, if Barnes & Noble (bn.com) had simple text links for
Books, DVDs, Music, etc., and I went to their site to buy the Counting
Crows album that had just been released, and I discovered that the Music
links was purple, I would say, "Oh, I guess I've been to their music
page before" and forget about buying the Counting Crows album--never
mind that the link is purple because three days earlier I was browsing
for samba music.

There are links, and then there are links. There are sites and there are
sites. Not all sites need to be arranged so that, like a resident of
Konigsburg traversing its bridges, one can make an Eulerian game out of
visiting every page on the site without visiting any of them twice.

On 4/7/2008 3:48 AM, Andy Dingley wrote:
> On 7 Apr, 02:36, biju <bijumaill...@yahoo.com> wrote:
>> It is very common to see an image as a link on many web pages.
>
> It's part of HTML (and the W3C's mental model of how things ought to
> work) that specifications should be "simple" (in formal terms as a
> protocol) rather than "simple" for users to hand code.
>
> There have been intentions at various times to roll up all of the
> "link" elements, <a>, <img>, <link> into one (maybe <object>) and to
> treat _everything_ as "some sort of link to an extenal resource". An
> <img> would become "The resource link that imports the resource
> immediately and renders it", <a> would become "A link to a resource
> that's only traversed if the user activates it" and <link> would be "A
> resource link that's retrieved but not rendered directly".
>
> Thinking in these terms, we see a logical interpretation of why <a>
> and <link> use href (be aware of this linked resource, but don't show
> it) and <img> uses src (render this resource right now). Within this
> view, it would indeed be possible to do what you describe, and to make
> the behaviour (now or later) explicitly coupled to the attribute(s)
> used. <img src="..." href="..." > could easily be defined to normally
> show the image from src, then traverse the link from href if
> activated. As the behaviour is then only dependent on the attributes,
> we could roll all of these behaviours into <object> (or "<foo>") and
> ditch <img> and <a> altogether. If you look around XHTML 2.*, then
> you'll see thoughts in this direction.
>
> However HTML is also bound by its legacy behaviour. This stuff just
> ain't going to happen. Nor (IMHO) should it. Having both <a> and
> <img>, and their use of different attribute names, just isn't a big
> enough problem to beginners to worry about changing it.

In general, I much prefer tags that are mnemonic. I manually code my
HTML in a Wordpad window, so mnemonic tags me to remember what the
markup is all about. That's why I continue to use the deprecated <font>
tag instead of <span> even when the content is merely a class or style
attribute.

Eliminating <img>, <a>, etc would make reading HTML difficult for humans
even if the machines don't care.

--
David Ross
<http://www.rossde.com/>

Have you been using Netscape and now feel abandoned by AOL?
Then use SeaMonkey. Go to <http://www.seamonkey-project.org/>.

Thanks all for the valuable answers.

On Apr 6, 10:34pm, Harlan Messinger
<hmessinger.removet...@comcast.net> wrote:
> As I asked you: why does there have to be another way to do the same
> thing? Saving a tag is not exactly the Holy Grail.

the reason why I asked is long story.
This is a general problem with all tags in HTML
but I come across issue more often with <img> tag.
Recently I had to work on an intranet site done by somebody else with
lot of <a><img></a>.
What ever be the language COBOL, C, JavaScript, HTML or XML, I prefer
to see code pretty, formatted, well intended etc.
Other wise it irritates me.

So if there is HTML sniplet <xxx>iiii<yyy>oooo</yyy>iiii</xxx>
I would like to reformat it as
<xxx>
iiii
<yyy>oooo</yyy>
iiii
</xxx>

But this will create a display issue. ie, the former will display as
"iiiiooooiiii" and later will display as " iiii oooo iiii ".
On a HTML document most time this is not an issue because we need
space between words.

But for <img> in side <a> tag when we convert <a href=""><img src=""></
a> to
<a href="">
<img src="">
</a>
the focus ring on the <img> tag will have a irregular shape to include
the space before closing </a> tag.

Two more tags I wish there is href attribute, they are <li> and <tr>,
that is totally different reason.

1) For <li> the reason is...
When you make few links as <li> items, something similar to page
content boxes at wikipeda
http://en.wikipedia.org/wiki/Wikipedia#toctitle
the item numbering wont become link, or to achieve that we have to do
manual
numbering text inside <li> items, like span.tocnumber at wikipedia

2) For <tr> the reason is...
Many times on a page we list prominent fields of a record as a row on
a table
and want to allow user to drill down to see details on another page by
clicking on the row.
at present we do this by using onclick javascript event of the
corresponding <tr>.
As there is no way to define a href for <tr> elements, this wont work
without javascript enabled.

So in general I wish href is there for every tag, but that may be over
ambitious, so I just asked you guy about <img> tag.


On Apr 7, 3:32 pm, "Jukka K. Korpela" <jkorp...@cs.tut.fi> wrote:
> Links want to be text links. See "Links Want To Be Links",http://www.cs.tut.fi/~jkorpela/www/links.html

Thanks for the link, so far I read, it is a good article.

But I have a comment, "underline for link" is not always a good idea.

Example:
1. In hand written Malayalam when we do underline we dont draw it
continuously,
because it cuts thru characters and will looks ugly.
please see http://ml.wikipedia.org/

2. Underline in Hindi text makes it difficult to read.
please see http://hi.wikipedia.org/

I think Chinese and Japanese with underline also looks horrible.
see http://zh.wikipedia.org/
and http://ja.wikipedia.org/
http://ko.wikipedia.org/

in comp.infosystems.www.authoring.html, Harlan Messinger wrote:

> In other words, if Barnes & Noble (bn.com) had simple text links for
> Books, DVDs, Music, etc., and I went to their site to buy the Counting
> Crows album that had just been released, and I discovered that the Music
> links was purple, I would say, "Oh, I guess I've been to their music
> page before" and forget about buying the Counting Crows album--never
> mind that the link is purple because three days earlier I was browsing
> for samba music.

No, you remember that you were there 3 days ago, so you can only scan
purple links when looking music section, and you are there faster than
without. After music link, you may see links like:

rock
rumba
samba

And wonder if you already looked the rock section. Or come back next day,
and wonder which one was it, which you followed yesterday.

If you don't know how to categorize music (like me), or music you wish to
buy don't categorize well (also me), knowing where you have been s
you find 'new' content, or 'old' content. But it is just a hint, you can
easily ignore it, when looking specific content.

> There are links, and then there are links. There are sites and there are
> sites. Not all sites need to be arranged so that, like a resident of
> Konigsburg traversing its bridges, one can make an Eulerian game out of
> visiting every page on the site without visiting any of them twice.

You see visiting color only hint for not visiting some page again. It is
also hint to visit it again. Of course it may not always , but it
hardly confuses either, as far as difference is not too drastic.


--
Lauri Raittila <http://www.iki.fi/lr>

On Apr 8, 2:34 pm, biju <bijumaill...@yahoo.com> wrote:
> Thanks all for the valuable answers.
>
> On Apr 6, 10:34 pm, Harlan Messinger
>
> <hmessinger.removet...@comcast.net> wrote:
> > As I asked you: why does there have to be another way to do the same
> > thing? Saving a tag is not exactly the Holy Grail.
>
> the reason why I asked is long story.
> This is a general problem with all tags in HTML
> but I come across issue more often with <img> tag.
> Recently I had to work on an intranet site done by somebody else with
> lot of <a><img></a>.
> What ever be the language COBOL, C, JavaScript, HTML or XML, I prefer
> to see code pretty, formatted, well intended etc.
> Other wise it irritates me.
>
> So if there is HTML sniplet <xxx>iiii<yyy>oooo</yyy>iiii</xxx>
> I would like to reformat it as
> <xxx>
> iiii
> <yyy>oooo</yyy>
> iiii
> </xxx>

You are dealing with a document markup language, not a computer
programming language. Whitespace necessarily has an effect on the
presented result beyond it's purpose in a programming language simply
as part of the syntax.


> But this will create a display issue. ie, the former will display as
> "iiiiooooiiii" and later will display as " iiii oooo iiii ".
> On a HTML document most time this is not an issue because we need
> space between words.
>
> But for <img> in side <a> tag when we convert <a href=""><img src=""></
> a> to
> <a href="">
> <img src="">
> </a>
> the focus ring on the <img> tag will have a irregular shape to include
> the space before closing </a> tag.

So remove empty whitespace after coding and before putting it on the
server.



> Two more tags I wish there is href attribute, they are <li> and <tr>,
> that is totally different reason.
>
> 1) For <li> the reason is...
> When you make few links as <li> items, something similar to page
> content boxes at wikipedahttp://en.wikipedia.org/wiki/Wikipedia#toctitle
> the item numbering wont become link, or to achieve that we have to do
> manual
> numbering text inside <li> items, like span.tocnumber at wikipedia
>
> 2) For <tr> the reason is...
> Many times on a page we list prominent fields of a record as a row on
> a table
> and want to allow user to drill down to see details on another page by
> clicking on the row.
> at present we do this by using onclick javascript event of the
> corresponding <tr>.
> As there is no way to define a href for <tr> elements, this wont work
> without javascript enabled.
>
> So in general I wish href is there for every tag, but that may be over
> ambitious, so I just asked you guy about <img> tag.

Allowing nested links is a particularly bad idea - if you have an
image in an A in an LI in a TR and the user clicks on the image, which
link should a browser follow?

How do you click on a TR without clicking on a TR?


--
Rob

Lauri Raittila wrote:
> in comp.infosystems.www.authoring.html, Harlan Messinger wrote:
>
>> In other words, if Barnes & Noble (bn.com) had simple text links for
>> Books, DVDs, Music, etc., and I went to their site to buy the Counting
>> Crows album that had just been released, and I discovered that the Music
>> links was purple, I would say, "Oh, I guess I've been to their music
>> page before" and forget about buying the Counting Crows album--never
>> mind that the link is purple because three days earlier I was browsing
>> for samba music.
>
> No, you remember that you were there 3 days ago, so you can only scan
> purple links when looking music section, and you are there faster than
> without. After music link, you may see links like:
>
> rock
> rumba
> samba
>
> And wonder if you already looked the rock section. Or come back next day,
> and wonder which one was it, which you followed yesterday.
>
> If you don't know how to categorize music (like me), or music you wish to
> buy don't categorize well (also me), knowing where you have been s
> you find 'new' content, or 'old' content. But it is just a hint, you can
> easily ignore it, when looking specific content.

I didn't *say* it was *never* useful. Read my message again and note
what it was I was responding *to*--Jukka's absolutist rant about it
always being important for every link.

in comp.infosystems.www.authoring.html, Harlan Messinger wrote:

> I didn't *say* it was *never* useful. Read my message again and note
> what it was I was responding *to*--Jukka's absolutist rant about it
> always being important for every link.

Then why did you give example on case where it is useful? Give example
where it is worse than having it, and you might actually have some point.


--
Lauri Raittila <http://www.iki.fi/lr>

On 8 Apr, 01:54, "David E. Ross" <nob...@nowhere.not> wrote:

> In general, I much prefer tags that are mnemonic. I manually code my
> HTML in a Wordpad window, so mnemonic tags me to remember what the
> markup is all about. That's why I continue to use the deprecated <font>
> tag instead of <span> even when the content is merely a class or style
> attribute.

The problem with mnemonics is when they make you remember the _wrong_
thing.

<font> isn't a substitiute for <span>, even though they have the same
content model and both support %coreattrs;. The semantics of <span>
are deliberately neutral, those of <font> are a bogus coupling between
markup and presentation.

Lauri Raittila wrote:
> in comp.infosystems.www.authoring.html, Harlan Messinger wrote:
>
>> I didn't *say* it was *never* useful. Read my message again and note
>> what it was I was responding *to*--Jukka's absolutist rant about it
>> always being important for every link.
>
> Then why did you give example on case where it is useful?

Huh? I made it clear why in the case I described it isn't particularly
useful, certainly not enough for its absence to be a problem. I didn't
say anything about the links for types of music--you brought those up.

On your stereo, you have buttons to set which input you want to
hear--the DVD player, the radio, the television. Would it be useful for
each of these buttons to change color after the first time you press it,
so that from then on you would know, for example, that you don't need to
press the DVD button again because you've already listened to a DVD once
before? Of course not. The buttons aren't for the purpose of browsing a
fixed set of information, where it's useful to avoid rereading the info
you've already seen. Controls that serve a similar purpose on a website
likewise don't need color-coding to show that you've used them before.

> Give example
> where it is worse than having it, and you might actually have some point.

Where *what* is worse than having it?

The *advantage* of using an image is visual appeal (and even in
assisting the user in grasping the layout of the screen). There isn't
anything wrong with that. If it visual appeal didn't have value then
we'd just do everything in a single font, at a single size and in a
single color. In other words, we wouldn't have bothered with graphical
browsers and everyone would use Lynx.

On Apr 8, 2:26am, RobG <rg...@iinet.net.au> wrote:
> So remove empty whitespace after coding and before putting it on the
> server.

apparently that is what I am doing now.

> Allowing nested links is a particularly bad idea - if you have an
> image in an A in an LI in a TR and the user clicks on the image, which
> link should a browser follow?

I would take the inner most.

> How do you click on a TR without clicking on a TR?

Sorry, I did not understand this question.

Harlan Messinger wrote:
> The *advantage* of using an image is visual appeal

It goes beyond that.

In the example given earlier, if I see an image of the album art of the
album I want to buy, clicking on the album art is intuitive. I expect to
be able to click on the album art image to go to a page where I can
purchase the album. If the image is not a link, I might be confused
about what I should click on.

Scott Bryce wrote:
> Harlan Messinger wrote:
>> The *advantage* of using an image is visual appeal
>
> It goes beyond that.
>
> In the example given earlier, if I see an image of the album art of the
> album I want to buy, clicking on the album art is intuitive. I expect to
> be able to click on the album art image to go to a page where I can
> purchase the album. If the image is not a link, I might be confused
> about what I should click on.

Well ... if every album cover has a link beside it that reads "Buy this
album" I don't think you'll have any trouble. Nevertheless it's useful
to link the image as well.

Harlan Messinger wrote:
> Well ... if every album cover has a link beside it that reads "Buy
> this album" I don't think you'll have any trouble. Nevertheless it's
> useful to link the image as well.

The first thing I think to do is click the image. If that does not work,
I look for a "Buy this album" link, which is usually an image that looks
like a button.

People will figure it out quick enough. I'm jut arguing that a clickable
image is sometimes more intuitive than a text link. The best option is
these cases is to provide both.

biju wrote:

>But why browsers dont support href attribute for <img> tag?
>
>Whether at any time this came up at W3C?

Somewhat different yet similar question: why do some tags have a HREF
attribute (for example LINK) while others have SRC for the very same
purpose? Why is it not SRC for LINK?

Why does the OBJECT tag have neither but instead has a DATA attribute
for the URL?

--
Bart.

Scripsit Harlan Messinger:

> In other words, if Barnes & Noble (bn.com) had simple text links for
> Books, DVDs, Music, etc., and I went to their site to buy the Counting
> Crows album that had just been released, and I discovered that the
> Music links was purple, I would say, "Oh, I guess I've been to their
> music page before" and forget about buying the Counting Crows
> album--never mind that the link is purple because three days earlier
> I was browsing for samba music.

Similarly, if you visit a news site and they have a link "Sports", which
is purple, you will apparently refrain from clicking on that link, since
you realize that you already saw the sports news. It's really up to you.

Others may use the color clue when they get acquainted with a news site
and wish to check all the major subpages - a useful idea. The color
clues them see at a glance which subpages they already checked.

Links colors are very useful clues. There is always the option of
missing clues or faking to misunderstand them.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Scripsit RobG:

> You are dealing with a document markup language, not a computer
> programming language.

Yes, but computer "languages" have much in common, though perhaps in a
Wittgensteinian "Familienählichkeit" sense (they are like members of a
family, connected, with shared properties, but not necessarily so that
any property is common to all of them).

> Whitespace necessarily has an effect on the
> presented result beyond it's purpose in a programming language simply
> as part of the syntax.

No, this by no means follows from the _idea_ of document markup
language. There is no compelling reason to treat whitespace the way
SGML, XML, and HTML do (which are somewhat different ways but mostly the
same). A markup language might even disallow the space as a data
character (and e.g. require that it be always presented using an entity
or character reference). That wouldn't be practical, but a markup
language does not _logically_ need to have HTMLish whitespace rules.

In fact, browsers generally misbehave by _not_ observing all the HTML
whitespace rules. This is particular important when dealing with images.
By HTML whitespace rules,

<img src="foo" alt="bar">
<img src="foo" alt="bar">

is identical to

<img src="foo" alt="bar"><img src="foo" alt="bar">

but browsers often treat it as

<img src="foo" alt="bar"> <img src="foo" alt="bar">

(I.e., with a space between the tags, typically causing some small gap.
This used to be known as a common special case of the Whitespace Bug.
The name isn't used much, but the bug is still with us.)

> Allowing nested links is a particularly bad idea -

Maybe, but not that apparently.

> if you have an
> image in an A in an LI in a TR and the user clicks on the image, which
> link should a browser follow?

That's to be decided when defining the markup language. HTML actually
already has a very analogous problem with event attributes. It has not
been solved, probably because people who designed HTML didn't see the
problem or lacked energy to discuss it. Think about a TR element with an
ONCLICK attribute and a TD element inside it, with an ONCLICK attribute.
Which event should be triggered by clicking inside the cell? If both
events, in which order? In scripting, the order may be all-important.
And what about TITLE attributes for nested elements? If implemented as
"tooltips", which of the tips should be shown?

> How do you click on a TR without clicking on a TR?

I fail to see the point in your question. The problem posed was making
it possible to turn an entire table row into a link. It's a genuine
problem, and the obvious workaround of making each TD or TH contents a
link to the same destination is awkward.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

On Wed, 9 Apr 2008, Jukka K. Korpela wrote:

> "Familienählichkeit"

Familienähnlichkeit
if someone might want to look up this word.

--
In memoriam Alan J. Flavell
http://groups.google.com/groups/sear...Alan.J.Flavell

Scripsit biju:

> What ever be the language COBOL, C, JavaScript, HTML or XML, I prefer
> to see code pretty, formatted, well intended etc.

The rules of a language set limitations on prettyprinting possibilities.
Besides, HTML (and SGML and XML) was not designed so that you _can_
write it by hand, but it wasn't the expectation that people would widely
do so. As we know, people often have to write markup by hand, because
editors are limited or because people want to play at the markup level

>> Links want to be text links. See "Links Want To Be
>> Links",http://www.cs.tut.fi/~jkorpela/www/links.html
>
> Thanks for the link, so far I read, it is a good article.
>
> But I have a comment, "underline for link" is not always a good idea.

The only reason why underlining is good for links (and bad for anything
else) is that it is widely recognized as indicating a link. Originally,
it was a very bad idea. But bad practice may become good practice just
because it becomes common.

Actually, it makes sense to remove the underline on mouseover (i.e.,
just the opposite of what so many authors do, misguidedly). The
underline draws attention to "linkness", and then it can be removed so
that the user sees the link text without disturbance.

> 1. In hand written Malayalam when we do underline we dont draw it
> continuously,
- -
> 2. Underline in Hindi text makes it difficult to read.
> please see http://hi.wikipedia.org/
>
> I think Chinese and Japanese with underline also looks horrible.

It's probably not great for Arabic either.

I have no good answer to the question how links should be indicated in
such scripts. When I wrote about underlining, and when early browser
designers decided to user underlining, the focus (no pun intended) was
on the Latin and maybe Greek and Cyrillic script. And even for them,
it's a disturbance, but usually tolerable.

Encyclopedias often have a small right-pointing arrow or similar icon to
indicate a cross-reference. Such presentation could be used for links
too. This however has the drawback of not indicating what exactly is the
link text and, more importantly I guess, that it's not noticeable
enough. And, most of all, it's not common and conventional.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Jukka K. Korpela wrote:
>
> Actually, it makes sense to remove the underline on mouseover (i.e.,
> just the opposite of what so many authors do, misguidedly). The
> underline draws attention to "linkness", and then it can be removed so
> that the user sees the link text without disturbance.

Now *that's* stupendously inconsistent with your philosophy on using
link color to reflect links to pages that have already been visited. You
expect a user to need a cue (differently-colored links) to remind him
which links he's already *clicked*, which pages he's already *visited*,
but you think that when the same user moves the cursor across the screen
he can be expected to memorize