css selectors

[Jon Slaughter]

Is it possible to refer to an a parent element and modify its attributes?

Say I have a ul with some links in it:

<ul>
<li>
SomeText
<a href="...">Link</a>
</li>
</ul


Now I want to change the color of SomeText depending on if a is hovered. (My
problem is more complicated than this so don't take this example at face
value... I know its easy to solve here but that is not what I'm asking)

so if I do something like

ul li a:hover
{

}

Then the style references everything in a. is there any way to tell it to
reference li instead?

I know in this example I can do it easy but in my problem I have nested ul's
and I need to change the color of a link in the first list when there is a
hover over a link in the second list(which is a sub list).

So essentially I want to change the color of a link when a completely
disjoint link is highlighted.

Is it possible with css?

Thanks,
Jon

 

[Ben C]

Is it possible to refer to an a parent element and modify its attributes?

Say I have a ul with some links in it:

<ul>
<li>
SomeText
<a href="...">Link</a>
</li>
</ul


Now I want to change the color of SomeText depending on if a is hovered.

Not possible with pseudos. Change in pseudo-state can only affect styles
that apply to descendents, the adjacent sibling, and the descendents of
the adjacent sibling. Never ancestors.

 

[Toby A Inkster]

ul li a:hover
{

}

Then the style references everything in a. is there any way to tell it to
reference li instead?

No, but you have two options:

ul li:hover
{
/* Styles go here.
* However, there is no way of knowing whether the <a> element
* is also being hovered. The cursor might be over the <li> but
* not over the <a>. If you want the <a> to fill he entire area
* of the <li>, then set it to display:block;height:100%;
*/
}

Or attach a small Javascript function to the onmouseover/onmouseout events
for the <a> element which toggles the class of its parent element.

--
Toby A Inkster BSc (Hons) ARCS
http://tobyinkster.co.uk/
Geek of ~ HTML/SQL/Perl/PHP/Python*/Apache/Linux

* = I'm getting there!

 

[Bernhard Sturm]

ul li:hover
{
/* Styles go here.
* However, there is no way of knowing whether the <a> element
* is also being hovered. The cursor might be over the <li> but
* not over the <a>. If you want the <a> to fill he entire area
* of the <li>, then set it to display:block;height:100%;
*/
}

which will not work in IE6 as IE6 does only understand pseudo-classes
attached to the a-element. so you need to rely on a JS-function.
see for example: son of suckerfish
(http://www.htmldog.com/articles/suckerfish/dropdowns/)

cheers
bernhard

 

[Jonathan N. Little]

which will not work in IE6 as IE6 does only understand pseudo-classes
attached to the a-element. so you need to rely on a JS-function.
see for example: son of suckerfish
(http://www.htmldog.com/articles/suckerfish/dropdowns/)

Or take advantage of MSIE's proprietary HTC file... My take on Vladdy's
solution

LI{ behavior: url(IEFixes.htc);
/* more specific */
LI.specialfx{ behavior: url(IEFixes.htc);

##### IEFixes.htc:

<public:component>
// For MSIE use JScript to attach JS functions to compensate
// for missing pseudo-class support
// from Vladdy http://www.vladdy.net/Demos/IEPseudoClassesFix.html
// updated for html4.01 jnl 3/06
<public:attach event="onmouseover" onevent="DoHover()">
<public:attach event="onmouseout" onevent="RestoreHover()">
<public:attach event="onmousedown" onevent="DoActive()">
<public:attach event="onmouseup" onevent="RestoreActive()">
<script type="text/jscript">
function DoHover(){
element.className += ' hover';
}
function DoActive(){
element.className += ' active';
}
function RestoreHover(){
element.className = element.className.replace(/\shover\b/,'');
}
function RestoreActive(){
element.className = element.className.replace(/\sactive\b/,'');
}
</script>
</public:component>

 

[Jon Slaughter]

I have no idea why css can't have an selector algebra? Why not (li>a) +
(ul -li div a)

with - selecting the elements where the expression evaluates to true. I
suppose it could be a drag on the system in some cases but it would be nice.

So the above expression would select all list elements who has a list
element above it with a link in it and who itself is of a child of a user
list and contains a div which contains a link.

This would allow one to get very specific selection but still retains
backwards compatibility. I'm not sure about the complexity involved as there
might be traversal issues but I'm sure it could be very useful.

Jon

 

[Andy Dingley]

I have no idea why css can't have an selector algebra?

1. Because it just doesn't. Don't ask us, we're just the monkeys who
use it. If you want it to have one, then you have to change the CSS
recs (and browsers) rather than just writing pages in some new
invented syntax.

2. Because it doesn't need one. The level at which HTML works is
supposed to be pretty dumb and close to the "end result" of a finished
document. CSS is supposed to be (in the great architectural view)
simple and efficient to implement, rather than powerful

If you need a magic selector, stick it into the HTML (class / id etc.)
and use trivial CSS to select it. If you need lots of these selectors,
then generate them from some precursor format to HTML (which might
also be HTML or XHTML) and get them into the final HTML document
before the CSS ever sees it.


If you care about this stuff, I strongly recommend that you read Hakon
Lie's PhD thesis on the design of CSS and the precursor technologies
that it was either based on, or deliberately rejected. What you
describe has some commonality with DSSSL's approach. As we know how
successful _that_ was, CSS deliberately avoided that route.

 

[Jon Slaughter]

1. Because it just doesn't. Don't ask us, we're just the monkeys who
use it. If you want it to have one, then you have to change the CSS
recs (and browsers) rather than just writing pages in some new
invented syntax.

um...

2. Because it doesn't need one. The level at which HTML works is
supposed to be pretty dumb and close to the "end result" of a finished
document. CSS is supposed to be (in the great architectural view)
simple and efficient to implement, rather than powerful

um... you do realize that if its completely backwards compatible then it
cannot hurt anything? You like being dumb just for fun? That is, if it lets
css be dumb for those who want it but allow those who don't then it can't
hurt.

If you need a magic selector, stick it into the HTML (class / id etc.)
and use trivial CSS to select it. If you need lots of these selectors,
then generate them from some precursor format to HTML (which might
also be HTML or XHTML) and get them into the final HTML document
before the CSS ever sees it.

If you care about this stuff, I strongly recommend that you read Hakon
Lie's PhD thesis on the design of CSS and the precursor technologies
that it was either based on, or deliberately rejected. What you
describe has some commonality with DSSSL's approach. As we know how
successful _that_ was, CSS deliberately avoided that route.

I just don't see whats wrong with it if its completely backwards compatible.
There might be issues involved with it but you haven't pointed them out. It
does offer many advantaged and clearer code. CSS might be for the dumb but
if it can be transparently modifed to make it more powerful then there
should be no reason not to. Its not a good idea to be dumb for its own
sake.

 

[Ben C]

I have no idea why css can't have an selector algebra?

[...]
2. Because it doesn't need one. The level at which HTML works is
supposed to be pretty dumb and close to the "end result" of a finished
document. CSS is supposed to be (in the great architectural view)
simple and efficient to implement, rather than powerful

um... you do realize that if its completely backwards compatible then it
cannot hurt anything?

I don't. Please explain that principle.

You like being dumb just for fun? That is, if it lets
css be dumb for those who want it but allow those who don't then it can't
hurt.

What if users don't know if they're dumb or not or which features are
the dumb ones they're supposed to stick to?

The standards are already quite complicated enough.

[...]

I just don't see whats wrong with it if its completely backwards compatible.
There might be issues involved with it but you haven't pointed them out. It
does offer many advantaged and clearer code. CSS might be for the dumb but
if it can be transparently modifed to make it more powerful then there
should be no reason not to. Its not a good idea to be dumb for its own
sake.

Some wise quotes from Dijkstra:

Simplicity is prerequisite for reliability.

The competent programmer is fully aware of the limited size of his own
skull. He therefore approaches his task with full humility, and avoids
clever tricks like the plague.

How do we convince people that in programming simplicity and clarity --
in short: what mathematicians call "elegance" -- are not a dispensable
luxury, but a crucial matter that decides between success and failure

 

[Andy Dingley]

You like being dumb just for fun?

Simple doesn't mean dumb.

'Tis a gift to be simple.

I just don't see whats wrong with it if its completely backwards compatible.

Then read what I told you to read.

 

[dorayme]

Some wise quotes from Dijkstra:

Simplicity is prerequisite for reliability.

The competent programmer is fully aware of the limited size of his own
skull. He therefore approaches his task with full humility, and avoids
clever tricks like the plague.

How do we convince people that in programming simplicity and clarity --
in short: what mathematicians call "elegance" -- are not a dispensable
luxury, but a crucial matter that decides between success and failure

Wise indeed. Funny how they are so easily ignored, not only in
programming, but in many other earthly endeavours.

 

[mbstevens]

Wise indeed. Funny how they are so easily ignored, not only in
programming, but in many other earthly endeavours.

....and let's not forget C.A.R. Hoare's important dictum that inside every
large program there is a small program trying to get out.

Other goodies here:
http://www.adrianmccarthy.com/blog/?p=15

 

[dorayme]

...and let's not forget C.A.R. Hoare's important dictum that inside every
large program there is a small program trying to get out.

Good one! It is also similar to what I think of any films over 90
min long that are not complete rubbish.

 

[Ben C]

Wise indeed. Funny how they are so easily ignored, not only in
programming, but in many other earthly endeavours.

The thing is it's harder than it looks to keep things simple. But people
don't always even realize that that's what they should be trying to do.