From: Curtis Clark (jcclark-lists@earthlink.net)
Date: Mon Jul 24 2006 - 09:25:16 CDT
I find it unusual to disagree with Jukka on anything, but in this case I
disagree with most of what he says.
On 2006-07-24 01:24, Jukka K. Korpela wrote:
> The description of existing practices shows that some web authors use
> images of a certain type to mark external links as external. This does
> not demonstrate existing usage of a _character_, since authors use
> rather varying designs. Picking up just one class of designs seems
> premature.
In fact it exactly demonstrates a character, not a glyph. The glyph
variants IMO support that it is a character.
> Most web pages do not distinguish external links from
> internal links using any markers.
Many lack the need. Some have the need, but their authors are unaware of
the possibilities. And entering all those graphics by hand is
non-trivial, so that the character is most often used on
automatically-generated sites.
> The distinction between external and internal links can be important,
> though often it's important just to site management, not to users, who
> surf around the web and don't pay much attention to the "site" concept.
It's most important for sites that maintain a common navigation
throughout the site, and that have links in text. Users could select
either of two apparently identical links, and one would lead to another
page with the same navigation structure, but another would lead to a
different type of page. These things are important to ease the user
experience, even (especially!) when the users don't notice them consciously.
> (What matters is support in fonts that web users have in their
> computers, and such things change slowly, even if good fonts were
> available for free.)
I actually agree with this part, although I've never thought that
otherwise good proposals should be held hostage to font support.
> The concept "external" is somewhat vague in this context. Apparently it
> means "external to the current site", but what is a "site", really? If
> we expect that the new character will become widespread, or even
> "standard" marker, it should perhaps have more definite meaning.
Like the definite meaning of "a" or "♂", perhaps. :-)
> Using a marker - whether an image or a character - makes the distinction
> part of the document's content in a manner that prescribes a particular
> visual rendering. This is contrary to modern structured and
> device-independent approach. The distinction, if relevant, is primarily
> a metadata issue, and an attribute (in hypertext markup, e.g. HTML or
> XML) could be used for the purpose. This would leave it to user agents
> to render the distinction in a manner suitable for a particular browsing
> situation. If a visual marker is used, it would most appropriately be an
> image specific to the browser, i.e. part of the browser's user
> interface. Thereby, it would perhaps not be suitable to treat it as a
> _character_, even though it may appear in the midst of text. (External
> links could also be indicated by the use of colors, for example, or they
> might look similar to other links until the cursor is moved over the link.)
>
> I think it basically belongs to the scope of the World Wide Web
> Consortium to discuss whether a uniform, universal symbol is a desirable
> way to indicate a link as external and whether the symbol should be part
> of a document or part of a user agent's interface. Only after resolving
> that could we adequately discuss whether that symbol should be encoded
> as a character.
There are some good points here. I've used color on a site, but it also
required title attributes since color alone violates accessibility
requirements. It might be useful to have perhaps an additional attribute
for the <a> tag to deal with such cases. But a possible behavior would
be to postpend the external link *character*, which would still need to
be encoded.
>> One quibble: it is "web page" or "World Wide Web page", not "Internet
>> page".
>
> The difference between external and internal links can be relevant on
> intranet pages, too, and in documents such as "standalone" HTML, XML,
> Word, PDF, etc., documents. [...]
The Internet is better seen as a collection of protocols than a
collection of document types (some of the protocols don't even support
documents in the ordinary sense of the word). What I was referring to
was http, which transports the bulk of all linked, human-readable
documents on the Internet (even the links in smtp-transported documents
are ordinarily http links).
>> 1. It will take a while for such a character to find its way into
>> ubiquitous fonts, so web developers will need to use the graphic for a
>> while longer. I don't see this as an argument against; *without* the
>> character, they will have to wait forever.
>
> I'm afraid that if the character were introduced, it would only be used
> by a small minority of web authors, among the minority that marks
> external links as external in the first place. In effect, it would be
> yet another (and rarely used) symbol acting as external link marker,
> rather than a "standard" marker.
Perhaps you are right, but this is a more general question for Unicode.
If we *don't* build it, they *can't* come.
> As an aside, I think the name EXTERNAL LINK would not be quite adequate.
> The name would suggest that the character _is_ a link (as it might
> actually be, though more often it would be either part of the link text
> or adjacent to it). So EXTERNAL LINK MARKER or EXTERNAL LINK INDICATOR
> would be more descriptive. Perhaps even HYPERLINK instead of LINK, since
> the word "link" as such is rather polysemic.
I agree.
>> 2. A graphic can have alternate text, such as "external link" for
>> users who can't view images.
>
> We have the unfortunate situation that in HTML, an image can have
> alternate text but there is no corresponding construct for a character.
> There is no way of specifying that if a particular character cannot be
> displayed (or otherwise rendered) by a user agent, then a particular
> replacement string (which would presumably contain "safe" characters only)
> be rendered instead.
Such a feature would indeed be useful in even broader contexts than what
we discuss here. There is of course the title attribute, which can be
applied to any tag, but not all user agents render it by default. And in
fact the entire issue falls on the user agents more than the markup.
> This is one reason why authors so often use images
> for symbols that actually exist in Unicode as characters, such as simple
> arrows.
The two primary reasons, though, are (1) they don't know that the
characters exist, and (2) their version of the chosen font doesn't
support the characters, so they assume the characters won't work.
>> It will take a while for screen readers to be programmed to have a
>> pronunciation of the new character (I'm not sure how JAWS, the
>> commonest screen reader in the United States, deals with symbol
>> characters).
>
> That's really an understatement. [...]
I agree totally (not to mention that the common ones ignore aural CSS).
>> But again, this would eventually happen, and during the period after
>> the availability of fonts, and before updates to screen readers, web
>> developers could use the "title" attribute to identify the character.
>
> The "title" attribute is an unreliable method. Although many
> speech-based user agents are able to read its value, they are typically
> configured not to do that by default. On visual user agents, the "title"
> attribute does not affect the normal rendering at all; its value may be
> displayed as a "tooltip" on mouseover, so it _may_ solve the puzzle _if_
> the user sees a suitable symbol of a missing glyph or unrecognized
> character _and_ the user suspects that moving the pointer over the
> mystery may reveal something.
Kind of like "...they might look similar to other links until the cursor
is moved over the link." :-)
-- Curtis Clark http://www.csupomona.edu/~jcclark/ Web Coordinator, Cal Poly Pomona +1 909 979 6371 Professor, Biological Sciences +1 909 869 4062
This archive was generated by hypermail 2.1.5 : Mon Jul 24 2006 - 09:29:21 CDT