Re: Draft 2 of the proposal to encode an EXTERNAL LINK INDICATOR symbol in the BMP

From: Kenneth Whistler (kenw@sybase.com)
Date: Tue Jul 25 2006 - 11:47:04 CDT

  • Next message: Kenneth Whistler: "Re: Draft 2 of the proposal to encode an EXTERNAL LINK INDICATOR symbol in the BMP"

    Karl,

    > After incorporating some hints from the discussion, now the second
    > draft of my proposal to encode an EXTERNAL LINK INDICATOR symbol
    > is found at:
    > http://www.europatastatur.de/material/ExternalLinkProposalDraft2.pdf
    >
    > The main changes:
    > Name of the proposed symbol changed from EXTERNAL LINK.
    > Bidi_mirrored property proposed to be "yes".

    As long as you are actively updating the proposal based on
    feedback from this discussion, I have several more suggestions
    for you.

    1. Some of the respondents in this thread have given links to
    sites using rather different glyphs for this same function.
    The proposal should acknowledge that and give graphic examples
    of such. It should make the case that those are (or are not)
    examples of the same *character* displayed with a different
    glyph. This speaks to the issue of exactly what is being
    proposed for encoding here.

    2. The proposed name EXTERNAL LINK INDICATOR is, IMO, a marginal
    improvement over just EXTERNAL LINK, but is still rather too
    close to suggesting a control function to me, rather than
    a name for a graphic symbol of a particular shape. The
    name precedents involving "INDICATOR" in the standard are:

    00AA;FEMININE ORDINAL INDICATOR;Ll;0;L;<super> 0061;;;;N;;;;;
    00BA;MASCULINE ORDINAL INDICATOR;Ll;0;L;<super> 006F;;;;N;;;;;
    2316;POSITION INDICATOR;So;0;ON;;;;;N;;;;;
    303E;IDEOGRAPHIC VARIATION INDICATOR;So;0;ON;;;;;N;;;;;

    None of these are control functions per se, so that is good.
    However, in each instance, the name itself is suggesting the
    particular function that is the primary use of the character
    in question.

    If EXTERNAL LINK INDICATOR is adopted as the name of this
    symbol to be encoded, its net effect will be to suggest to
    people that its usage is constrained to that function, as
    one expects for the POSITION INDICATOR or the IDEOGRAPHIC
    VARIATION INDICATOR, in particular -- rather than being a
    generic graphic symbol which happens to be the right shape
    to represent the box with an arrow pointing out, which various
    websites are now using to indicate that a link is to an
    external site.

    That appears to be the intent of the proposal, but I'm pointing
    out that that will be questioned in review by the committees.

    3. The change to make this Bidi_Mirrored=Y will provoke another
    fight, particularly in the absence of any evidence of actual
    usage of a mirrored glyph in a right-to-left web context
    as yet. This proposed character is not paired punctuation
    nor a math operator, which are the types of characters currently
    covered by Bidi_Mirrored. Suggesting that it should be
    Bidi_Mirrored, simply because one assumes it would be
    glyphically mirrored in a right-to-left display, opens a
    can of worms about any other such symbols which might not be
    symmetric around a vertical axis, but which are not in the
    classes of characters currently involved with the Bidi_Mirrored
    property.

    4. I share Jukka's concern that this proposal is premature, and
    should await further consensus emerging from the more
    appropriate forum -- namely W3C -- regarding the formalization
    of the convention of usage and of the icon for its display,
    *before* the Unicode Consortium steps in to determine appropriateness
    for encoding as a *character*.

    What is clear to me is that there is a sememe here (the shared
    semantic of indicating the status of a link a pointing to
    an "external" site, meaning not managed here and with no
    guarantee as to content or stability or copyright status, etc.).
    It is also clear that there is an icon here (or possibly several
    related icons), based on the graphical concept of an arrow
    pointing outside of "the box".

    It is also quite clear to me, based on the discussion, that
    there will be a continuing, and probably justified clamor to
    encode a graphical symbol (or perhaps a whole set of them)
    shaped like a square box with an arrow pointing out of it
    (possibly in more than one direction and style) -- since people
    are writing text with such doohickies and don't have any
    appropriate Unicode character(s) to represent such a symbol.

    What *isn't* clear to me yet, and which I think the proposal
    ducks in detail, is the justification for encoding an
    EXTERNAL LINK INDICATOR as a character.

    5. Confusion of icon standardization, character standardization,
    and glyph standardization.

    The proposal states now:

    "As there exists no standardized character now, site authors use
    to create a little graphic which they can use for the external
    link symbol throughout their site. The existence of a standardized
    character as proposed would free the site authors from having to
    reinvent the wheel for that purpose."

    I find this the heart of the motivation of the document, and
    correspondingly problematical. To be convincing, it really needs
    to be elaborated and reanalyzed, to pick apart *what* needs
    to be standardized and how, and whose needs would be met in
    what contexts.

    I contend that site authors need a standardized *icon* to
    represent this semantic function on their sites. The point of
    standardizing it -- as for restroom signs, traffic signs, or
    whatever -- is so you will get universal, quick recognition
    of its meaning by all users of your site (and by transference,
    all users of all other sites using the same conventions).

    Within that context, it isn't clear yet whether a standardized
    *character* is needed or is helpful. In part this is because
    the icon and its usage have been invented and are being used
    and refined, regardless of its non-existence as a character.
    As Jukka pointed out, encoding a character doesn't automatically
    make that character the thing that people *would* use to
    indicate the function on websites, because characters behave
    differently from icons used as graphics.

    Furthermore, making it a character puts the rendering at the
    mercy of its availability in fonts, and opens the question of
    the design of the glyphs in different fonts, even if available.
    A site which is standardized on a particular shape of the icon
    may well stick to that *despite* the availability of such a
    character in fonts, simply because that would impact the
    look and feel of the site as designed.

    And if the Unicode Standard were then to pick a *particular*
    glyph and try to standardize *that* as the obligatory display
    of the character, it would be suborning the purpose of
    the standard a little further. The Unicode Standard is already
    widely misunderstood as a glyph standard, and this would nudge
    it a little further in that direction.

    To sum up: if web site designers need help in standardizing
    their usage, that need should be approached as an exercise
    in standardizing an *icon*. I do not like the approach of
    using the Unicode Standard as a means of accomplishing that
    by encoding a character, attempting to standardize the
    glyph for its display, and then pointing to the Unicode
    Standard as having a character in it which resolves the problem
    of icon design for web designers.

    At any rate, be forewarned that such concerns will be taken
    up by the committees in discussing this proposal, when submitted.

    --Ken



    This archive was generated by hypermail 2.1.5 : Tue Jul 25 2006 - 11:50:12 CDT