active link problem

My method is simplicity its own self. Give each <li> an id. Make it simply the name of the page, or its filename. I use server side includes, so this is a one-time deal.

My usual thing is to cause that menu item to disappear, but you could give it any rules you like. In the page head, as the last style rule do something like this;

For the home page,

#home {
    display: none;
    }

#home a {
    color: yellow;
    background-color: green;
    border: 5px ridged #fee;
    }

gary

nice one gary

I had done something like this before but thought you should just be able to do it through the active or fcus etc.

Back to this method i guess

cheers

Freddy

Just to explain why active and focus does not work in the way you imagined they would.

When a link is in the focus state this means that on the page you are on this is the element that has focus - ie when you tab to something it has focus. For links focus should be given the same properties as hover in my opinion so what people using keyboards get the same highlighting as mouse users get when they hover.

The active state is when the link is in the process of being clicked and lasts not a great deal of time at all.

Directly from the w3c CSS spec

# The :hover pseudo-class applies while the user designates an element (with some pointing device), but does not activate it. For example, a visual user agent could apply this pseudo-class when the cursor (mouse pointer) hovers over a box generated by the element. User agents not supporting interactive media do not have to support this pseudo-class. Some conforming user agents supporting interactive media may not be able to support this pseudo-class (e.g., a pen device).
# The :active pseudo-class applies while an element is being activated by the user. For example, between the times the user presses the mouse button and releases it.
# The :focus pseudo-class applies while an element has the focus (accepts keyboard events or other forms of text input).

Cheers Briski

That does clear it up (and makes me realise that the 45 mins i spent d&*king around trying to get it to work was a waste) :oops:

Still - always learning eh?

Briski -thank you for a thorough explanation. CSS was intended to deal with appearances and not user generated events. Yet there are compelling reasons to build websites as pure CSS without the use of scripting languages such as JavaScript. Security is the most important one. If only CSS would allow to change appearances of elements on mouse click, it would be possible to use simple, robust methods and achieve desired results. Opera 9+ and Firefox 3+ allow that even it is not strictly the specs. But Safari 3+ does not. I would argue that some form of "onclick" pseudo class that changes style or at least visibility of other elements should be included into CSS standards.

CSS does not "allow" anything. CSS is only a specification. It has to be implemented by the browser programmers, and like javascript or anything else, it may be implemented well or badly.

Right now we can't even get browser creators to implement the current standard the same way from browser to browser. Complicating the specification will likely only lead to poorer implementations and even less security.