Re: Bidirectional text and URLs

["Stephen J. Turnbull" <stephen@xemacs.org>]

Eli Zaretskii writes:

 > > Note that RFC 3987 specifies that bidirectional IRIs must *always* be
 > > displayed with the UBA, and as if in an LRE embedding.  I'm not sure
 > > how you would enforce it, but I believe this would defang larsi's
 > > example (ie, at the start of the URI proper in logical order insert a
 > > LRE, and at the end a PDF -- any directional format characters between
 > > those points are nonconforming to RFC 3987, section 4.1, last
 > > paragraph).
 > 
 > Using an LRE..PDF embedding is a possibility, but it can be defeated:
 > the UBA mandates that any embeddings above some predefined fixed depth
 > are to be ignored.  So a malicious code could insert a large enough
 > number of RLOs such that any LRE would be ignored.

Note that RFC 3987 is a MUST, and OTOH does not specify an
implementation (probably precisely because of the nesting issue).

 > That's one of the reasons why I prefer not to poke the text with
 > additional directional controls.

You don't need to poke them into the text.  You just MUST display IRIs
"as if" there were an effective embedding.  I'm aware of the GNU
mantra "standards are sometimes not a terrible idea -- but only
sometimes".  But in this case I think conformance is a very good idea.

 > > If they're inside the IRI, they're non-conforming and therefore bogus,
 > > and would be caught by the tooltip.
 > 
 > Yes, but tooltips could be overlooked (or even disabled globally by
 > the user).

I think for the cases we've identified so far (LTR-only text in a RTL
context, RTL-only text in an LTR context, and directional controls
embedded in an IRI) you probably want to require the user who clicks
on them to confirm that they want to follow this misleading link,
anyway.