in reply to Re^3: Filtering potentially dangerous URI schemas in <a href="...">
in thread Filtering potentially dangerous URI schemas in <a href="...">

That way, neither themes nor CSS will lead to the colour accidentally being overridden.

this is not true. this example style should disprove your case: 

/* color links */
a, a font { color: #457; background: #eee; text-decoration: none; }
a:hover { color: #eee; background: #457; }

/* override <font>...</font> tags */
font, b, strong { color: #457; background: transparent; }

[download]
there are multiple ways to override the font tags in your example. my browser does not display your text in red, as you specified, as all font tags are overridden by a user-supplied style.

as to

a representation that would be completely and entirely unmistakable under any circumstances
... you'll have to aim a little higher ;-)

~Particle *accelerates*

Replies are listed 'Best First'.
Re^5: Filtering potentially dangerous URI schemas in <a href="...">
by Aristotle (Chancellor) on Oct 21, 2002 at 00:00 UTC
    Then how about <font color="#ff0000" style="color: red"> ? But I can't demonstrate that since last I checked, style attributes got stripped from user text.

    Makeshifts last the longest.

[reply]

      And my client-supplied CSS trumps everything you do on the web site. I wouldn't have every known you'd intended that to be differently colored until it came up. In general this is the "don't communicate solely through color" dictum.

      __SIG__
printf "You are here %08x\n", unpack "L!", unpack "P4", pack
  "L!", B::svref_2object(sub{})->OUTSIDE;

      [download]
[reply]
[d/l]
        Then how about class="unsafe"? The default could be bold red, with the "unsafe link" text prepended, and usersupplied CSS could style it as desired.

        Makeshifts last the longest.

[reply]

In Section Perl Monks Discussion