I'm experiencing something strange...
Here is what I have going on:
-page1.html that links to page2.html (target is same window, no frames)
-for page1.html I have defined a:link, a:visited, a:hover, and a:active (in that order)
-the links on page1.html are grouped in a <table>
-I click on a link and page2.html comes up...when I link back to page1.html, all the links within the table are colored as a:visited.
-Ideally, when I return to page1.html, I'd like to see the unvisited links remain as the a:link color.
Anyone have an idea what is happening? Fixes?
Thanks!
..AndyFor starters, which browsers did you test with? This sounds like a possible browserbug.
You have an URL to the page?put: <body vlink="color">Originally posted by Dave Clark
I heard once that order was important (I'd call that a bug, really).
It's not a "bug", it's an very central and important part of the CSS language. Infact it's so important that the C in CSS actually stands for this feature, called Cascading.
The Cascading concept means that a later rule always overrides a previous rule (of the same specificy/importance).
Without this feature CSS would only be a fraction as powerfull as a language as it is with this feature.
I take advantage of the cascading heavily on basicly every webpage I make, especially to work around browserbugs in an effective manner.
I have a page that uses them in this order:
a:link { text-decoration: none; }
a:hover { text-decoration: underline; }
a:active { text-decoration: line-through; }
a:visited { text-decoration: none; }
That is the wrong order for how most people would want it to work.
If you have it like that, once a link has been visited it will NEVER get the underline or line-though rules applied (in a nonbuggy browser).
This is becuse the last rule that applies to the link is a:visited { text-decoration: none; }
Most times you probably want this order (that amui stated at the top)
a:link
a:visited
a:hover
a:activeI don't have it public just yet...heheh, for obvious reason that I have a problem.
Yeah, I messed with the ordering of the a: styles, but like the docs and stefan said, the latter does supercede the formers.
I'm testing the page with IE6.0, which is why I'm confused why I'm getting this type of behavior. Checked out cnn.com and yahoo.com and they seem to have the right idea...
I'm probably going to fiddle with a simple test page to see if I can repeat the phenomenon. Stay tuned, and if anyone has any input, much appreciated!!!Silly mistake on my part. So the CSS does not seem to distinguish <a href=http://www.webdeveloper.com/forum/archive/index.php/"page2.html#article1"> from <a href="page2.html#article2">. Since both links point to page2.html, all the links are considered visited.
Anyone know a way to increase granularity to the anchor?
Thanks,
..AndyOriginally posted by amui
Since both links point to page2.html, all the links are considered visited.
Anyone know a way to increase granularity to the anchor?
Sadly the implementation of the visisted state is up to each browser AFAIK, and the defacto standard is that if you visited the page, all links to the same page show up as visited.Originally posted by Dave Clark
I changed the order, as recommended, and it does work even better now. Thanks.
There is other states and combinations one can use too with links that are quite nice, however IE is buggy with anything but the simplest of codes. On one site I use eg this (all rules with html>body is stuff IE doesn't implement correctly)
.nav a:link,
.nav a:visited { color:#53533C; background:#dda; }
.nav a:hover { color:#000; background:#ffc; }
html>body .nav a:focus { color:#FFF; background:#636347; }
html>body .nav a:hover:focus { color:#222; background:#85b7fe; }
.nav a:active { color:#FFF; background:#636347; }
html>body .nav a:hover:active { color:#222; background:#9cf; }Neither, read the specification: <!-- m --><a class="postlink" href="http://www.w3.org/TR/REC-CSS1#color-units.I">http://www.w3.org/TR/REC-CSS1#color-units.I</a><!-- m --> only know two correct ways to write hex colours:
#XXXXXX
Ie. six hex chars. This is the normal representation for 24bit colour.
#XXX
Three hex chars. This is a shorthand and the "safe" way to define a colour.
The three hex chars format is expanded in the following fashion:
#ABC becomes #AABBCC
#FFF becomes #FFFFFF
#000 becomes #000000
#13D becomes #1133DD
Why? well, as you might notice, now you have only 16^3 colours to work with, instead of 16^6
To the human's eye colours, such as #AAA and #AAB will look only slightly different, while we probably would not notice a colour change at all when we are writing #AAAAAA and #AAAAAB. So the second notation takes more time for the brain to figure out. The main reason: to ensure that older monitors produce the same colour as you intended.
Note: this is for CSS only, the same doesn't work for HTML
Here is what I have going on:
-page1.html that links to page2.html (target is same window, no frames)
-for page1.html I have defined a:link, a:visited, a:hover, and a:active (in that order)
-the links on page1.html are grouped in a <table>
-I click on a link and page2.html comes up...when I link back to page1.html, all the links within the table are colored as a:visited.
-Ideally, when I return to page1.html, I'd like to see the unvisited links remain as the a:link color.
Anyone have an idea what is happening? Fixes?
Thanks!
..AndyFor starters, which browsers did you test with? This sounds like a possible browserbug.
You have an URL to the page?put: <body vlink="color">Originally posted by Dave Clark
I heard once that order was important (I'd call that a bug, really).
It's not a "bug", it's an very central and important part of the CSS language. Infact it's so important that the C in CSS actually stands for this feature, called Cascading.
The Cascading concept means that a later rule always overrides a previous rule (of the same specificy/importance).
Without this feature CSS would only be a fraction as powerfull as a language as it is with this feature.
I take advantage of the cascading heavily on basicly every webpage I make, especially to work around browserbugs in an effective manner.
I have a page that uses them in this order:
a:link { text-decoration: none; }
a:hover { text-decoration: underline; }
a:active { text-decoration: line-through; }
a:visited { text-decoration: none; }
That is the wrong order for how most people would want it to work.
If you have it like that, once a link has been visited it will NEVER get the underline or line-though rules applied (in a nonbuggy browser).
This is becuse the last rule that applies to the link is a:visited { text-decoration: none; }
Most times you probably want this order (that amui stated at the top)
a:link
a:visited
a:hover
a:activeI don't have it public just yet...heheh, for obvious reason that I have a problem.
Yeah, I messed with the ordering of the a: styles, but like the docs and stefan said, the latter does supercede the formers.
I'm testing the page with IE6.0, which is why I'm confused why I'm getting this type of behavior. Checked out cnn.com and yahoo.com and they seem to have the right idea...
I'm probably going to fiddle with a simple test page to see if I can repeat the phenomenon. Stay tuned, and if anyone has any input, much appreciated!!!Silly mistake on my part. So the CSS does not seem to distinguish <a href=http://www.webdeveloper.com/forum/archive/index.php/"page2.html#article1"> from <a href="page2.html#article2">. Since both links point to page2.html, all the links are considered visited.
Anyone know a way to increase granularity to the anchor?
Thanks,
..AndyOriginally posted by amui
Since both links point to page2.html, all the links are considered visited.
Anyone know a way to increase granularity to the anchor?
Sadly the implementation of the visisted state is up to each browser AFAIK, and the defacto standard is that if you visited the page, all links to the same page show up as visited.Originally posted by Dave Clark
I changed the order, as recommended, and it does work even better now. Thanks.
There is other states and combinations one can use too with links that are quite nice, however IE is buggy with anything but the simplest of codes. On one site I use eg this (all rules with html>body is stuff IE doesn't implement correctly)
.nav a:link,
.nav a:visited { color:#53533C; background:#dda; }
.nav a:hover { color:#000; background:#ffc; }
html>body .nav a:focus { color:#FFF; background:#636347; }
html>body .nav a:hover:focus { color:#222; background:#85b7fe; }
.nav a:active { color:#FFF; background:#636347; }
html>body .nav a:hover:active { color:#222; background:#9cf; }Neither, read the specification: <!-- m --><a class="postlink" href="http://www.w3.org/TR/REC-CSS1#color-units.I">http://www.w3.org/TR/REC-CSS1#color-units.I</a><!-- m --> only know two correct ways to write hex colours:
#XXXXXX
Ie. six hex chars. This is the normal representation for 24bit colour.
#XXX
Three hex chars. This is a shorthand and the "safe" way to define a colour.
The three hex chars format is expanded in the following fashion:
#ABC becomes #AABBCC
#FFF becomes #FFFFFF
#000 becomes #000000
#13D becomes #1133DD
Why? well, as you might notice, now you have only 16^3 colours to work with, instead of 16^6
To the human's eye colours, such as #AAA and #AAB will look only slightly different, while we probably would not notice a colour change at all when we are writing #AAAAAA and #AAAAAB. So the second notation takes more time for the brain to figure out. The main reason: to ensure that older monitors produce the same colour as you intended.
Note: this is for CSS only, the same doesn't work for HTML