Aw: Re: Re: [EXTERNAL] Re: External Link Symbol
Asmus Freytag
asmusf at ix.netcom.com
Thu Apr 18 12:31:40 CDT 2024
In this context it is interesting that RFC7992 suggests use of a
character code and, incidentally, makes the case that there are
use-cases where reliance on external images is explicitly ruled out.
This underscores the "chicken-and-egg" problem we so often encounter in
character encoding. Unless a character is encoded, it can't be used in a
text-only environment.
In this particular case, my reading would be that there's nothing
inherently favoring an image-only solution. It just happens that this
was the only way to go in early implementations, but as RFC7992 reminds
us, there are use cases where that is not an option.
As a result, as I wrote in an earlier part of this thread, I can't get
the warm and fuzzies about applying the "app iconography" principle
here. Particularly not for something that always appears in connection
with and part of a text block. There are many other examples that are
much more removed from text and to which that principle is more properly
applicable.
A./
On 4/18/2024 10:13 AM, Peter Constable wrote:
>
> > If I were a submitter, I would treat something like the citation of
> RFC7992 then not as something that "settles" an encoding question, but
> one that calls for further research to see whether that particular
> convention is found in (enough) other places to help reach a decision.
>
> Completely agree with that.
>
> However, there is another factor in this that UTC will consider and
> _/has/_ considered: is the symbol used in public text data
> interchange. Wrt external link symbol, UTC has previously decided that
> this falls into the general class of symbols used in app iconography
> and that that evidence based on such usage is not sufficient for
> encoding as a textual character.
>
> Peter
>
> *From:*Asmus Freytag <asmusf at ix.netcom.com>
> *Sent:* Wednesday, April 17, 2024 5:56 PM
> *To:* Peter Constable <pgcon6 at msn.com>; Marius Spix <marius.spix at web.de>
> *Cc:* unicode at corp.unicode.org
> *Subject:* Re: Aw: Re: Re: [EXTERNAL] Re: External Link Symbol
>
> This spells out what I tried to imply by warning against
> overinterpreting this example. However, whether something is a
> normative specification, and the limits of its normative scope is
> always only one aspect. Another aspect is whether it represents a
> record of somebody's explicit convention for what to do for a given
> feature, such as "anchor" links in the current example.
>
> Having a written convention that documents intent is preferable over
> relying on mere observation, for example, noticing that certain
> documents or certain platforms just happen to behave in a certain way.
> But, on it's own, just because something is written down is certainly
> not enough to suggest that the convention is common, let alone universal.
>
> From Unicode's perspective, a convention does not have to be normative
> for general purpose documents to be taken into account in making
> informed encoding decisions. The degree to which it is followed in
> practice (both in its original domain as well as in analogous cases)
> is usually more important.
>
> If I were a submitter, I would treat something like the citation of
> RFC7992 then not as something that "settles" an encoding question, but
> one that calls for further research to see whether that particular
> convention is found in (enough) other places to help reach a decision.
> Alternatively, it might serve as a data point for the conclusion that
> there's no single convention (with further research needed to find out
> whether this represents a case of a small number of alternate
> coexisting conventions, or the case of something where the real world
> hasn't settled on anything).
>
> A./
>
> On 4/17/2024 5:32 PM, Peter Constable wrote:
>
> Let’s be clear: all that RFC 7992 is doing is documenting the
> conventions used in the non-canonical HTML versions of IETF RFCs.
> Unless in some other context there is a specification that
> normatively references RFC 7992, it has no real import beyond the
> HTML versions of IETF RFCs.
>
> Peter
>
> *From:*Unicode <unicode-bounces at corp.unicode.org>
> <mailto:unicode-bounces at corp.unicode.org> *On Behalf Of *Asmus
> Freytag via Unicode
> *Sent:* Monday, April 15, 2024 7:35 AM
> *To:* Marius Spix <marius.spix at web.de> <mailto:marius.spix at web.de>
> *Cc:* unicode at corp.unicode.org
> *Subject:* Re: Aw: Re: Re: [EXTERNAL] Re: External Link Symbol
>
> On 4/15/2024 6:55 AM, Marius Spix wrote:
>
> The pilcrow sign is offically mentioned in RFC 7992. See
> section 5.2. So I would consider it the conventional
> representation for anchor links.
>
> I would agree that it is "a convention" for representation of
> anchor links. It happens to work for English, as the pilcrow sign
> conventionally means "paragraph" and the intent in RFC7992 is to
> provide links to all paragraphs.
>
> However, the formatting of RFCs provided as HTML is a different
> beast from generic prescription for formatting all HTML documents.
> So this should not be over interpreted.
>
> A./
>
> *Gesendet:* Freitag, 12. April 2024 um 18:46 Uhr
> *Von:* "Asmus Freytag via Unicode" <unicode at corp.unicode.org>
> <mailto:unicode at corp.unicode.org>
> *An:* unicode at corp.unicode.org
> *Betreff:* Re: Aw: Re: [EXTERNAL] Re: External Link Symbol
>
> The first and last choice are arguably not the most
> conventional representations for these. They are, at best,
> fallbacks.
>
> A./
>
> On 4/12/2024 12:31 AM, Marius Spix via Unicode wrote:
>
> For all these types of links existing characters can be used:
>
> anchor links: U+00B6 ¶ PILCROW SIGN
>
> local links: U+1F517 🔗LINK SYMBOL
>
> broken links (also known as red-links): U+26D3 U+200D
> U+1F4A5 CHAINS + ZERO WIDTH JOINER + COLLISION SYMBOL
>
> external links: U+2192 →RIGHTWARDS ARROW
>
> *Gesendet:* Donnerstag, 11. April 2024 um 21:05 Uhr
> *Von:* "Asmus Freytag via Unicode"
> <unicode at corp.unicode.org> <mailto:unicode at corp.unicode.org>
> *An:* "Tom Moore" <tom.moore at microsoft.com>
> <mailto:tom.moore at microsoft.com>, "Sławomir Osipiuk"
> <sosipiuk at gmail.com> <mailto:sosipiuk at gmail.com>, "Asmus
> Freytag via Unicode" <unicode at corp.unicode.org>
> <mailto:unicode at corp.unicode.org>
> *Betreff:* Re: [EXTERNAL] Re: External Link Symbol
>
> On 4/11/2024 11:47 AM, Tom Moore wrote:
> > Then multiply that by 2, for links that navigate current
> tab vs. request to open a new tab.
>
> Is there a link to samples for all of these as used in
> practice, or is
> this just a theoretical distinction?
>
> A./
>
> >
> > -----Original Message-----
> > From: Unicode <unicode-bounces at corp.unicode.org>
> <mailto:unicode-bounces at corp.unicode.org> On Behalf Of
> Slawomir Osipiuk via Unicode
> > Sent: Thursday, April 11, 2024 9:28 AM
> > To: asmusf <asmusf at ix.netcom.com>
> <mailto:asmusf at ix.netcom.com>; Asmus Freytag via Unicode
> <unicode at corp.unicode.org> <mailto:unicode at corp.unicode.org>
> > Subject: [EXTERNAL] Re: External Link Symbol
> >
> > There are actually three kinds of links that are
> distinguishable from each
> > other:
> >
> > - A link to a different location in the current document
> (anchor link/jump
> > link)
> > - A link to a resource on the same network/domain as the
> current document (local link/relative link)
> > - A link to a resource on a different network (external
> link)
> >
> > All those can appear as symbols, used contrastively,
> within a run of text.
> > I'm very surprised these haven't already been encoded
> and that there is any controversy. The consortium doesn't
> care much for precendent, but come on, we have "play"and
> "eject" symbols encoded!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20240418/e332c990/attachment.htm>
More information about the Unicode
mailing list