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

Actually, that was on purpose. That way, neither themes nor CSS will lead to the colour accidentally being overridden. I was aiming for a representation that would be completely and entirely unmistakable under any circumstances.

Makeshifts last the longest.

  • Comment on Re^3: Filtering potentially dangerous URI schemas in <a href="...">

Replies are listed 'Best First'.
Re^4: Filtering potentially dangerous URI schemas in <a href="...">
by particle (Vicar) on Oct 20, 2002 at 23:53 UTC
    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*

[reply]
[d/l]
[select]
      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]

In Section Perl Monks Discussion