|
Convenient web based access to our favorite web design Usenet groups
|
 |
This is Interesting: Free Magazines for Graphics designers and webmasters
| Author |
| Thread |
 |
|
|
|
|
|
|
|
 |
Descendant selector for nested classes |
 |
|
 |
|
|
|
 06-22-04 - 04:15 AM 
|
I'm trying to localize the setting of colors on a series of webpages
by defining color palettes that will be used for various page areas.
I've defined some palette classes like .clrLt, .clrMd, .clrDk and
associated link colors using selectors. One of the aims is to ensure
that matching text color, background, and link colors are maintained.
These palettes are applied as multiple classes to various page modules
which also have abstract classes that define other characteristic.
Modules may contain other modules.
The problem that I run into is that my link colors are not changing
based on their immediate container's class. If a link is inside a
.clrLt container, which is itself inside a .clrMd container, the link
colors are defined by the .clrMd selector. It appears that the
browsers don't consider an immediate dependacy to be a significant as
which class was defined last. If I could use a child selector ">" I
might be able to override this, at least for links directly in the
parent container. The same thing happens with other nesting and color
combinations. If I reorder the class definition, I get different
results, but they always favor the last define class.
I thought about defining special case nesting selectors like ".clrDk
.clrLT a:link" but there is no systematic way to predict that and the
combinations get out of hand very quickly.
Any ideas?
= simplified css example =
.clrLt{
background-color: #FFFFFF;
color: black;
}
.clrLt a:link,.clrLt a:visited, .clrLt a:active, .clrLt a:hover{
color: red;
}
.clrMd{
background-color: #666666;
color: #CCFFFF;
}
.clrMd a:link, .clrMd a:visited, .clrMd a:active, .clrMd a:hover{
color: yellow;
}
.clrDk{
background-color: #000000;
color: #FFFFFF;
}
.clrDk a:link, .clrDk a:visited, .clrDk a:active, .clrDk a:hover{
color: Aqua;
}
= simplified html example =
<body class="clrLt">body content with light background
<div class="nav clrDk">
<a href="#">link</a>
<a href="#">link</a>
<a href="#">link</a>
</div>
<div class="content clrMd">
some content with medium background "><a href="#">link</a>
<div class="inset clrLt">some inset content with light background <a
href="#">link</a>
</div>
</div>
</body>
|
|
|
| [
Post Follow-Up to this message ]
|
|
|
|
|
|
|
|
Re: Descendant selector for nested classes |
|
|
|
|
|
|
|
06-22-04 - 12:14 PM
|
terry.gilbert@XXXXXXXXXX (tagbert) wrote:
>I'm trying to localize the setting of colors on a series of webpages
>by defining color palettes that will be used for various page areas.
>
>I've defined some palette classes like .clrLt, .clrMd, .clrDk and
>associated link colors using selectors.
In general this is not considered best practice. Think about defining
your class names based on what the element is (.navigation, .footnote,
etc) rather than on its presentation (which may vary as the site is
restyled).
>One of the aims is to ensure
>that matching text color, background, and link colors are maintained.
Then why, in the styles you posted, do you not specify a
background-color everytime you specify a color?
>The problem that I run into is that my link colors are not changing
>based on their immediate container's class. If a link is inside a
>.clrLt container, which is itself inside a .clrMd container, the link
>colors are defined by the .clrMd selector. It appears that the
>browsers don't consider an immediate dependacy to be a significant as
>which class was defined last.
This is correct behaviour as per the CSS spec.
Descendent selectors apply to all descendents, no matter how many
generations removed. So your selectors are all equally specific and
hence the last specified in the stylesheet takes precedence.
>I thought about defining special case nesting selectors like ".clrDk
>.clrLT a:link" but there is no systematic way to predict that and the
>combinations get out of hand very quickly.
Without seeing your pages it's hard to make recommendations but I
would suggest being a bit stricter and placing limits on which
combinations are permitted. It doesn't do your users any favours to
have multiple link colours scattered at random throughout your pages.
Especially as your already harming usability by using the same colour
for unvisited and visited links.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <steve@pugh.net> <http://steve.pugh.net/>
|
|
|
| [
Post Follow-Up to this message ]
|
|
|
|
|
|
|
|
Re: Descendant selector for nested classes |
|
|
|
|
|
|
|
06-23-04 - 12:23 AM
|
Steve Pugh <steve@pugh.net> wrote in message news:<02ufd0p5tf9t06t5p7kudfsmja2a0eoqec@4ax.c
om>...
> terry.gilbert@XXXXXXXXXX (tagbert) wrote:
>
>
> In general this is not considered best practice. Think about defining
> your class names based on what the element is (.navigation, .footnote,
> etc) rather than on its presentation (which may vary as the site is
> restyled).
>
>
> Then why, in the styles you posted, do you not specify a
> background-color everytime you specify a color?
>
>
> This is correct behaviour as per the CSS spec.
> Descendent selectors apply to all descendents, no matter how many
> generations removed. So your selectors are all equally specific and
> hence the last specified in the stylesheet takes precedence.
>
>
> Without seeing your pages it's hard to make recommendations but I
> would suggest being a bit stricter and placing limits on which
> combinations are permitted. It doesn't do your users any favours to
> have multiple link colours scattered at random throughout your pages.
> Especially as your already harming usability by using the same colour
> for unvisited and visited links.
>
> Steve
Sorry, those were 'streamlined' class definitions just as the html
was. I had condensed this down to a minimum for illustrative purposes.
The problem still exists in this version.
The whole point of this is to keep color combinations together. To
make sure that background, text, and link colors are compatible within
a given area of the page. If we change the colors, we will only change
them as a group. If we change which set of colors is used for an area
of the page, then we will either treat it as an exception and use id
to override the class or we may be restructuring that page and will
need to re-evaluate the color usage anyway. I also collapsed the link
styles down into a single definition, though in the real stylesheet,
they are separate.
I see what the browser is doing. I just hadn't expected that behavior.
I had assumed that it did some weighting based on the nesting
structure. I guess not. I'll probably have to define separate link
classes for links on each background color.
Thanks, anyway.
|
|
|
| [
Post Follow-Up to this message ]
|
|
|
|
|
|
|
|
|
| All times are GMT. The time now is 04:17 AM. |
|
|
|
|
|
| |
|
