By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,852 Members | 955 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,852 IT Pros & Developers. It's quick & easy.

why doesn't my css change link color?

P: n/a
very simple thing (I hope)

I've got a css style sheet that starts like this:

______________

A:link {
color: cc9933;
}
A:vlink {
color: cc9933;
text-decoration: none;
}

A:active {
color: cc9933;
text-decoration: none;
}

..catalog {

position: absolute;
left: 180;
top: 570;
display: block;
text-align: center;
text-indent: 0.000000pt;
margin-top: 0.000000pt;
margin-bottom: 0.000000pt;
margin-right: 0.000000pt;
margin-left: 0.000000pt;
font-size: 10.000000pt;
font-weight: bold;
font-variant: small-caps;
font-style: normal;
color: cc9933;
text-decoration: none;
vertical-align: baseline;
text-transform: none;
font-family: "arial";
letter-spacing: 0.1em;

}
_________________
Then a Web page that's linked to it with entries like this:

<P CLASS="catalog"><A HREF="catalog.html"> catalog</A></P>

Everything works fine EXCEPT: why can't I override the link colors on
my browser? (IE 5.5) No matter what I try, the settings locally on the
browser determine the link color. The visited link color seems to pick
up from the CSS, but the link color changes to whatever the browser
settings are. I want the color in all cases to be cc9933. What am I
doing wrong? Thanks
please reply to:

jf****@yahoo.com
Jul 20 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a
jf****@yahoo.com wrote:
A:link {
color: cc9933;
}
Error. Should be #cc9933;

Should also have a background colour to avoid clashes with user
stylesheets.

.catalog {

position: absolute;
left: 180;
top: 570;
Error. Must always include units with all lengths. Is that 180 miles
or 180 Angstrom?
display: block;
text-align: center;
text-indent: 0.000000pt;
margin-top: 0.000000pt;
margin-bottom: 0.000000pt;
margin-right: 0.000000pt;
margin-left: 0.000000pt;
A simple 0 would suffice.

Do I detect MS Office extruded styles?
font-size: 10.000000pt;
pt are a unit from the print media, they are not well suited to screen
displays.
font-weight: bold;
font-variant: small-caps;
font-style: normal;
color: cc9933;
text-decoration: none;
vertical-align: baseline;
Vertical align has no effect on block elements.
text-transform: none;
font-family: "arial";
letter-spacing: 0.1em;

}

Here's a useful tool:
http://jigsaw.w3.org/css-validator/

please reply to:

jf****@yahoo.com


Ask the question in public, get the answer in public.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Jul 20 '05 #2

P: n/a
Stephen Poley schrieb:

On 28 Jun 2003 01:30:00 -0700, jf****@yahoo.com wrote:
very simple thing (I hope)


Yes, it is.
I've got a css style sheet that starts like this:

A:link {
color: cc9933;

...
What am I doing wrong?


Submit your CSS to the validator:

http://jigsaw.w3.org/css-validator/validator-uri.html

and all will be revealed.


I know the W3C themselves call it a "validator", but you can't really
"validate" CSS.
Matthias
Jul 20 '05 #3

P: n/a
On Sat, Jun 28, Matthias Gutfeldt inscribed on the eternal scroll:
I know the W3C themselves call it a "validator", but you can't really
"validate" CSS.


Not in the precise SGML sense, no, but the term "validate" does have a
more general meaning too.

This one certainly does CSS syntax checking, and some other kinds of
checks too. While it's a pity that the term "validator" has been
misused by some people in HTML/SGML/XML contexts, where it has a
precise technical meaning, that surely doesn't IMHO rule out its use
in other technical contexts where the concept of SGML validity does
not apply.

cheers
Jul 20 '05 #4

P: n/a
Alan J. Flavell wrote:
On Sat, Jun 28, Matthias Gutfeldt inscribed on the eternal scroll:

I know the W3C themselves call it a "validator", but you can't really
"validate" CSS.

Not in the precise SGML sense, no, but the term "validate" does have a
more general meaning too.

This one certainly does CSS syntax checking, and some other kinds of
checks too. While it's a pity that the term "validator" has been
misused by some people in HTML/SGML/XML contexts, where it has a
precise technical meaning, that surely doesn't IMHO rule out its use
in other technical contexts where the concept of SGML validity does
not apply.


Yes, I can understand that point of view. But blurring the line between
validation and "validation" can lead to misconceptions down the road, so
that even webdesigners no longer seem to know there is a difference.

For example:

"Validate the CSS
CSS can be validated with for example the W3C CSS validator. This is
much the same as HTML validation, except that I have not yet come across
any good reason for using any invalid CSS declarations."
<http://www.xs4all.nl/~sbpoley/webmatters/checklist.html#css>

This otherwise fine text ignores the big difference between HTML
validation and CSS "validation" completely, and states they are "much
the same", which they clearly are not. (Just using this example to
illustrate my point, I'm not trying to pick on you Stephen!).
Matthias

Jul 20 '05 #5

P: n/a
On Mon, 30 Jun 2003 09:04:32 +0200, Matthias Gutfeldt <wo***@gmx.at>
wrote:
"Validate the CSS
CSS can be validated with for example the W3C CSS validator. This is
much the same as HTML validation, except that I have not yet come across
any good reason for using any invalid CSS declarations."
<http://www.xs4all.nl/~sbpoley/webmatters/checklist.html#css>

This otherwise fine text ignores the big difference between HTML
validation and CSS "validation" completely, and states they are "much
the same", which they clearly are not. (Just using this example to
illustrate my point, I'm not trying to pick on you Stephen!).


Always willing to learn. How would you explain the difference in a few
words? Bearing in mind that this is intended to be from the viewpoint of
the *user* of the validator/whatever, not from the viewpoint of the
author of it.

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/
Jul 20 '05 #6

P: n/a
Stephen Poley <sb*****@xs4all.nl> wrote:
This otherwise fine text ignores the big difference between HTML
validation and CSS "validation" completely, and states they are
"much the same", which they clearly are not. (Just using this
example to illustrate my point, I'm not trying to pick on you
Stephen!).
Always willing to learn. How would you explain the difference in a
few words?


May I? It's my pet peeve, after all. :-)

There is no such thing as HTML validation, much less CSS validation.
There's SGML and XML validation, which might be used for DTDs developed
for (or, rather, retrofitted to) HTML, but surely not for any DTD
developed for CSS, since there isn't any.

For an indirect explanation - via explaining what validation is and
what it isn't - in far more words, see
http://www.cs.tut.fi/~jkorpela/html/validation.html

Many people say that I'm nitpicking and that any checking can be called
"validation". I wonder why we would say "validate" if we _mean_
"check", which is a nice, well-known monosyllable. But apparently it
lacks the technospirit that makes things sexy and cool. Anyway, _I_
still say "check" when I mean 'check', and use "validate" _in the Web
context_ in one of the well-defined technical meanings as a _term_.
(There's enough confusion already when HTTP has "validation", but most
Web authors don't have (or need) a clue of _that_ validation.)
Bearing in mind that this is intended to be from the
viewpoint of the *user* of the validator/whatever, not from the
viewpoint of the author of it.


From the viewpoint of the user, both validation and other checks are
worse than useless if the user does not understand what's going on,
i.e. does not know the rules of the notation (or "language", to use the
common misnomer) he's using and _how_ the validator or checker checks
against the rules, and which part of which rules. Calling CSS checkers
"validators" tends to make such understanding harder.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Jul 20 '05 #7

P: n/a
Christoph Paeper wrote:
*Evertjan.* <ex**************@interxnl.net>:
A:active {
color: #cc9933;
}

A:hover {
color: #00ff00;
}

Will the hyperlink ever have the colour #C93?
:active and :hover are not mutually exclusive states (:link and :visited
are), thus the latter overwrites the former. In most cases the correct order
of pseudo classes for links is :link, :visited, :hover, (:focus,) :active.

Well, with keyboard navigation or the like you'd probably see the :active
style, but never the :hover.


I always understood that :active (ie. the period while the user holds
down the mouse button) overrode :hover.

Certainly it works this way under Mozilla 1.3 for the following code:

<body>
<style>
<!--
a:hover { color: #00DD00 }
a:active { color: #00DDDD }
-->
</style>

<a href="#">link here</a>
</body></html>

Jul 20 '05 #8

P: n/a
GuruJ <Gu***@mbox.com.au> writes:
I always understood that :active (ie. the period while the user holds
down the mouse button) overrode :hover.
Not necessarily.
Certainly it works this way under Mozilla 1.3 for the following code: <style> <style type="text/css">, surely. a:hover { color: #00DD00 }
a:active { color: #00DDDD }
</style>

<a href="#">link here</a>


Try swapping the two lines in the stylesheet and you'll discover that
it doesn't *always* work that way.

The later style overrides the earlier style for the same specificity.

--
Chris
Jul 20 '05 #9

P: n/a
On Mon, 30 Jun 2003 11:36:28 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:
Stephen Poley <sb*****@xs4all.nl> wrote:
This otherwise fine text ignores the big difference between HTML
validation and CSS "validation" completely, and states they are
"much the same", which they clearly are not. (Just using this
example to illustrate my point, I'm not trying to pick on you
Stephen!).
Always willing to learn. How would you explain the difference in a
few words?


May I? It's my pet peeve, after all. :-)

There is no such thing as HTML validation, much less CSS validation.


Well, we've been here before. All I can say is that I have never met
anyone outside the c.i.w.a.* groups who considered validation to refer
exclusively to validation against a DTD. But that wasn't quite my
question.

<snip>
Bearing in mind that this is intended to be from the
viewpoint of the *user* of the validator/whatever, not from the
viewpoint of the author of it.

From the viewpoint of the user, both validation and other checks are
worse than useless if the user does not understand what's going on,
i.e. does not know the rules of the notation (or "language", to use the
common misnomer) he's using
I'd more or less agree with that - though it may still be useful if it
simply brings to the attention of the user that he does not know (some
of) the rules and prods him/her to rectify that situation.

But nothing in what you say indicates to me that there is any difference
between HTML and CSS in this respect. In both cases the user of the
validator^W program uses it to identify syntax errors which can then be
corrected. In both cases they concern errors which could lead to
undesirable rendition in some/all browsers. I can't yet see why my
phrase "much the same" is incorrect from the point of view of the user.
and _how_ the validator or checker checks
against the rules,
This I don't understand at all. It seems equivalent to suggesting you
shouldn't catch a train until you know how a locomotive works.
and which part of which rules.


--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/
Jul 20 '05 #10

P: n/a
Chris Morris wrote:
GuruJ <Gu***@mbox.com.au> writes:
I always understood that :active (ie. the period while the user holds
down the mouse button) overrode :hover.

Not necessarily.

Certainly it works this way under Mozilla 1.3 for the following code:


<style>


<style type="text/css">, surely.
a:hover { color: #00DD00 }
a:active { color: #00DDDD }
</style>

<a href="#">link here</a>

Try swapping the two lines in the stylesheet and you'll discover that
it doesn't *always* work that way.

The later style overrides the earlier style for the same specificity.


So I see! Reversing the order means that you only see the 'active'
color once you click, then move the mouse off the active element (ie.
stop 'hovering' over the element).

So, is this interpretation correct: *Both* CSS conditions trigger, but
as the browser has to decide between two conflicting conditions, the
later rule wins?

For example, if the style is modified to be:

a:hover { color: #00DD00 }
a:active { font-weight: bold }

then we will see a coloured, bold link?

-- GuruJ.

Jul 20 '05 #11

P: n/a
GuruJ <Gu***@mbox.com.au> writes:
Chris Morris wrote:
Try swapping the two lines in the stylesheet and you'll discover that
it doesn't *always* work that way.
The later style overrides the earlier style for the same specificity.
So, is this interpretation correct: *Both* CSS conditions trigger,
but as the browser has to decide between two conflicting conditions,
the later rule wins?


Since the two conditions have the same specificity (read the CSS spec),
then yes.

As another example, try
html a:active { color: 00DD00 }
a:hover { color: 00DDDD }

In this case the increased specificity of the :active rule means that
it overrides the :hover rule even though it is later in the file.

Perhaps slightly neater to simply specify in the appropriate order
anyway, though.
For example, if the style is modified to be:

a:hover { color: #00DD00 }
a:active { font-weight: bold }

then we will see a coloured, bold link?


Yes, when both :hover and :active are satisfied, obviously.

--
Chris
Jul 20 '05 #12

P: n/a
Chris Morris wrote:
As another example, try
html a:active { color: 00DD00 }
a:hover { color: 00DDDD }


You seem to have dropped a couple of "#"

--
David Dorward http://david.us-lot.org/
Redesign in progress: http://stone.thecoreworlds.net/
Microsoft announces IE is dead (so upgrade):
http://minutillo.com/steve/weblog/20...ces-ie-is-dead
Jul 20 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.