Link to home
Start Free TrialLog in
Avatar of tbaum
tbaum

asked on

Links in different colors on same page

When I imbed links in my HTML document, they all appear underlined and in a default/setable color.  Already know about the <LINK> attrib but this affects all links on the page.  I want to be able to specify a different color for one of the links (need to make it stand out).  How?  Thanks.
Avatar of knightEknight
knightEknight
Flag of United States of America image

This will work in IE4:

<A href="myurl.com" style="color:green">
Avatar of davlun20080
davlun20080

knightEknight's answer should work in both 4.x browsers because they both support the style element.
You can also create a specific style for the links you want to have different colors and apply that to any links you want, e.g.

<style>
a.red {color:red}
a.green {color:green}
.important {font-weight:bold}
</style>

<a href="" class="important">a bold link</a>

or,

<div class='important'><a href="" class="green">a bold green link</a></div>

Tom
Or you can just set font colours inside your HREF tags like this:

<A HREF="foo"><FONT COLOR="#FFCC99">Link</FONT></A>

which will work for unvisited links, but not for visited ones.
johnny99 is right, that's the best way to do it (for compatability reasons)
I strongly disagree.  I'd choose (T)Tom's suggestion over the FONT element any day.  why?  it's quite simple.  Cascading Style Sheets which Tom uses separates presentational data and the actual content on a web page.  taken to its extreme you get a web page that's dead simple with straight (and validating) HTML with a style sheet that controls everything.

the FONT element is usable, yes, but it puts presentational data directly into the HTML document (for "What's wrong with FONT" see http://www.mcsr.olemiss.edu/%7Emudws/font.html).  we've had 4th generation browsers for quite a while now, therefore using CSS will in most cases work as you wish.  of course there is caveats with CSS, but in cases like link-coloring things work correctly across platforms.  I could probably write a thesis about CSS, drop by http://www.w3.org/Style/CSS/ for more information.

there's also another advantage to Tom's solution, it works consistently for all links, visited or not.  you can also easily change link colors (and other style properties) using the 'hover' pseudo-class, supported in IE4/5 giving dynamic style for links.

if you have one link that you want to stand out on the page, and coloring and boldface is what you want I'd make the code like this:

<style type="text/css">
a.important { background: black; font-weight: bold; }
a.important:link { color: green; }
a.important.visited { color: blue; }
a.important:hover { color: red; }
</style>

and put that into the HEAD section of the document.  what I do here is to say that all elements named A (anchors) with a class of 'important' get a black background and boldface.  the background is set to the same background color as the rest of the document (black is only an example) to make sure that it doesn't clash with a user-defined style sheet.

then I set the foreground colors for each of the links.  if the important link is unvisited it becomes green.  if it's visited it becomes blue.  when the user moves his cursor over it ('hover') it'll become red (in IE4/5).  I then code the anchor:

<a class="important" href="whateverpage.html">some descriptive link text</a>

I can have more than one important link on my page, I can have several across pages, and when I want to change how they look I simply change the style specification (if I use a linked style sheet I only have to change _one_ document).

it even degrades gracefully. :)
There are only two kinds of web publishers, those who aim for maximum compatibility, and those who say things like "we've had version 4 browsers for a while now".

You're absolutely right, but I'm absolutely right too. My solution will work in more browsers than yours. The best solution, it may be, is to use both...then you're doing twice the amount of work.
Avatar of tbaum

ASKER

WOW!  Thank you everyone for the suggestions!  My coder and I will be going over our options and I will let you know what we wind up doing (and why).  Boy you have GOT to love this kind of thing.
Avatar of tbaum

ASKER

We wound up going with the answer supplied by 'johnny99'.  It was a close call but we went with his answer because we were worried about backward compatibility.

We will save the other answer for future use (when the older browsers die).

Thank you everyone for your answers and help.

If you apply, Johnny99, I will give you the points.
ok, let's take this to the extreme.

if you're seriously worrying about backwards compatibility, FONT isn't an element that should be on your list of usable elements at all.  you should maybe stick to straight HTML 2.0, or maybe HTML 4.0 strict.  neither of those HTML versions have support for manipulation of fonts.

of course the code should validate. http://validator.w3.org/ is the primary tool for that.  you should also run your code through any lint you can find, and check it with any backwards-compatibility tool available.  using Bobby is mandatory.

if you choose to use any CSS make sure to lint it too.  W3C has one tool for that, HTMLHelp has another (http://www.w3.org/ and http://www.htmlhelp.com respectively).

any page you create shouldn't depend on any specific browser version, operating system or setup.  it should work well regardless of the user's preferred font & color setup.  Java, JavaScript, plugins, ActiveX or anything like that is not to be used, since you have no guarantee that the user has support for it.  any scripting needed is done on the server side.

if backwards compatibility is your key interest, the HTML should be as good as possible.  it should be well structured, validate, and the content should be well represented regardless of the user agent (graphical browser, text browser, search engine, etc).  one of the ways to reach that goal is to separate the content (structure) and the layout (presentation).  that's what CSS does.  it leaves the presentation to something that's meant to handle it.  the CSS spec was written with the sole purpose that it should enable web authors to give a good suggestion of how they wanted their content to be presented to the user.

the key here is _suggestion_.  HTML was never written with the intention that every web page should look the same in all browsers.  it was written so that content could be accessible on more platform than one, and that the user sitting on that platform could setup his system so that the information was presented as he wanted it to be.  if somebody were color blind they'd setup the colors so that the text was easy to read for them.  short-sighted people probably use larger fonts.  people with disabilities may have tailor-made solutions (speech-synthesis and browser with support for braille springs to mind).

you'll quickly find out that what you think is a good way to do something isn't at all, since it'll probably result in that your content is unavailable in certain setups (ever tried dropping by your favourite web sites with Lynx lately?).

some of us take backwards compatibility to the extreme.  I'm close to being one of those.  I keep my code validating, and if needed I alter the DTD so my pages still validate.  I make sure the content is available to as many as possible, going to great lengths to test it with several browsers on more than one platform.  I often use Lynx to see how different page setups end up with a text-only browser.  I hate frames since it goes against several key principles for the web.  I hate presentational-oriented HTML even more, since once I don't run IE4/5 or Netscape 4 under Microsoft Windows with the standard setup and a window size of at least 800x600 those sites have content that's close to unreadable.

if you're caring about backwards compatibility, start reading comp.infosystems.www.authoring.html and any serious web-design column you can find.  http://www.w3.org/ should probably be set up as your home page.  read the CSS level 1 and level 2 specs, as well as the HTML 4.0 spec and the WAI (Web Accessibility Initiative).  have several useful sites bookmarked, like http://www.htmlhelp.com/ and http://www.css.nu/.  find some good mailing lists where the readers are concerned about web accessibility.  read Jacob Nielsen's Alert Box every once in a while (http://www.useit.com/).  go back and read up on older Alert Boxes every once in a while to keep your knowledge up-to-date.  many things he says are actually quite smart.  some people disagree with him, which you'll find out quickly if you follow some mailing lists and web columns.

if you continue to focus on how your site looks using old hacks like FONT your not going in the right direction.  from where I'm sitting, CSS is the right direction.  yes, this is a rant, and probably close to a flame.  you might end up agreeing with me, you might end up thinking I'm an idiot.  either way, what's probably going to happen in the future is that people will access the web with more user agents than anyone ever though would exist.  we've got cellular phones, PDAs, set-top boxes like WebTV and the regular browsers running on more than one platform.  if you're concerned about backwards compatibility you design sites that work well for all of them.

we now return to our regular scheduling, film at eleven.
ASKER CERTIFIED SOLUTION
Avatar of johnny99
johnny99

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of tbaum

ASKER

Nettrom, you have a number of valid points but in my case the 'backward compatibility' I am looking for is not that far back.  Our system was designed from day one to work in 800X600 and to use IE/Netscape browsers of version 3.X or better.  I know that is a small set of the available browsers and displays but that is what the target audience uses.

This is not a 'general consumption' site but is dedicated to a specific set of users so we can get away with this kind of restriction.  Also, we go through a third party language so we are not actually written in HTML for the most part either and have little control over the HTML that is actually generated except for when we embed some HTML directly (which is what we will be doing here).

With these restrictions and caveats, we will be going with the '<FONT>' tag for now and in the 'soon' future, migrate to CSS.