![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
The bar has a black background, |
|
and I'd like the hyperlinked text on it to be white. I'd also the hyperlinked text to not have the underlines underneath it. I'd also like the text to stay white no matter if it has been clicked or not. |
|
I would also like it to not affect any other files that are included. |
#3
| ||||
| ||||
|
|
williamzim2000 (AT) yahoo (DOT) com (Frank) wrote: The bar has a black background, That means trouble. White on black is considerably less readable than black on white, though the problem can mostly be managed if you work carefully. |
|
and I'd like the hyperlinked text on it to be white. I'd also the hyperlinked text to not have the underlines underneath it. I'd also like the text to stay white no matter if it has been clicked or not. That would make it even worse. The texts would not look like links at all. |
|
And the distinction between unvisited and visited links is an essential usability feature. |
|
I would also like it to not affect any other files that are included. You can't do it that way. The inclusion you're using is a server-side issue, and the browser does not even know that some content appears due to such inclusion. The browser only gets what the server sends to it, i.e. a document where the inclusion has already taken place. But you can e.g. wrap <div class="nav">...</div> around the navigation bar, in the included file, and use the selector div.nav in conjunction with other selectors. |
#4
| |||
| |||
|
|
That means trouble. White on black is considerably less readable than black on white, though the problem can mostly be managed if you work carefully. A bit of an exaggeration. White-on-black is not a good idea for large areas of text, but hardly a problem for a navigation bar. |
#5
| |||
| |||
|
|
Stephen Poley <sbpoley (AT) xs4all (DOT) nl> exclaimed in <qpm9jvsa9s2dklkas5eiu296591hobapvf (AT) 4ax (DOT) com>: That means trouble. White on black is considerably less readable than black on white, though the problem can mostly be managed if you work carefully. A bit of an exaggeration. White-on-black is not a good idea for large areas of text, but hardly a problem for a navigation bar. As always, what is and isn't a good idea varies. Several people of my aquaintance who are users of screen magnifying software reconfigure their - often IE - browsers to show white on black. For them, that is "considerably more readable" than the opposite. It is worth remembering that life is grayscale. |
#6
| |||
| |||
|
|
A bit of an exaggeration. White-on-black is not a good idea for large areas of text, but hardly a problem for a navigation bar. |
#7
| |||
| |||
|
|
williamzim2000 (AT) yahoo (DOT) com (Frank) wrote: The bar has a black background, That means trouble. White on black is considerably less readable than black on white, though the problem can mostly be managed if you work carefully. |
#8
| |||
| |||
|
|
"Nick Kew" <nick (AT) fenris (DOT) webthing.com> wrote in message news:1245hb.021.ln (AT) jarl (DOT) webthing.com... In article <qpm9jvsa9s2dklkas5eiu296591hobapvf (AT) 4ax (DOT) com>, one of infinite monkeys at the keyboard of Stephen Poley <sbpoley (AT) xs4all (DOT) nl> wrote: A bit of an exaggeration. White-on-black is not a good idea for large areas of text, but hardly a problem for a navigation bar. Those of us above a certain age remember a time when display technology wasn't all it is today, and flickered a whole lot more. In those days, large areas of light colour (such as a white background) were seriously painful. So some of us grew up with white-on-black, and variants such as green-on-black or amber-on-black. There were screens that had the option of w-on-b or b-on-w, and everyone tried b-on-w exactly once. The white then was not like the plain bg we have now: it was like looking into a light bulb. Black was considered a more restful bg. |
![]() |
| Thread Tools | |
| Display Modes | |
| |