Mark Janssen

Mark,

If your intention is to use just CSS, you should find that :active instead
of :hover does the trick. However, that requires the user to keep the mouse
down, so they will not be able to click on the links . . .

does this help?

Tarquin - author of http://www.howtocreate.co.uk

hmm. That example does not work in Opera, Safari or Konqueror, because they
only consider something as having focus (and therefore being :active) while
the mouse button is held down. Strangely, OmniWeb 4.5 (which is based on
Safari) _does_ work!

Give me about 1/2 hr, I will see what I can find out that might help . . .

Mark,

Unfortunately, I can only find one thing that would help;
user-focus:
However, this is in CSS3 draft and is not supported by Opera 7.

I can give you a very quick JavaScript that will do what you need though:
<a onclick="this.className='activeEl';" onmouseout="this.className='';">
used with:
div#links a:active span, div#links a.activeEl span {
  display:block;
  color: #AAA; background: #22232F;
  font: 10px Verdana, sans-serif; text-align: center;
  padding: 10px; border: solid 5px #444;
}

in a sense, this is using CSS :/ ... well, kindof ...


sorry.

Tarquin

> > <a onclick="this.className='activeEl';" onmouseout="this.className='';">

The technique I gave should work in all good browsers (IE4+[win/mac],
Mozilla, Konqueror, Opera 7, Safari, OmniWeb 4.5+). What will happen is
that the menu will stay open until they move their mouse out of it. Of
course, the :active will override that in IE4+[win/mac], Mozilla and
OmniWeb 4.5+, so in those browsers, the behaviour should be exactly how it
is now.

> I want to have selectable stylesheets.

I do not know why DevEdge would change to server side, but it may be
because Netscape 4 (and a few minor browsers) cannot do client side
switching, but can do server side (if you care . . .), and of course, they
made Netscape 4. Also, server side does not require JavaScript. Both
techniques require cookies.

Personally, I prefer client side, because it is quicker, so the user can
see the results instantly. Try this comparison:

__Server side:
	Pros:
Supported by _all_ browsers that support CSS
JavaScript is not required
	Cons:
Changing stylesheets requires a server request
If the user does not like their chosen stylesheet, they need to do another
  server request
Cookies are required
Access to server side scripting is required

__Client side:
	Pros:
Switching is instant
Less load is put on the server as no extra requests are made to the server
Access to server side scripting is not required
	Cons:
JavaScript is required
Only supported by good browsers (IE4+, Mozilla, Opera 7, Konqueror, Safari,
  OmniWeb 4.5+)
Cookies are required
All stylesheets are loaded by the browser, even if the user only ever uses one

If you want it, I have written a stylesheet switching library that is
relatively easy to implement. See my libraries page:
http://www.howtocreate.co.uk/jslibs/
or try the demo
http://www.howtocreate.co.uk/tutorials/jsexamples/CSStest/
instructions are given at the start of the script file
http://www.howtocreate.co.uk/jslibs/swapstyle.js


Tarquin

switching images with JavaScript is easy also:

<script type="text/javascript" language="javascript"><!--

//firstly, cache the new image
var myImage = new Image();
myImage.src = 'newImageLocation.gif';

function changeImage() {
    //then when you want to change it
    document.images['theImageToChange'].src = myImage.src;
}

//--></script>

<!-- now do the HTML -->
<img src="initialImage.gif" name="theImageToChange" ... >

<a href="#" onclick="changeImage();return false;">Change image</a>

yes it is possible:

replace the icon image with:
<img class="onlyonone" src="blah.gif" ...>
<img class="onlyontwo" src="blah2.gif" ...>
<img class="onlyonthree" src="blah2.gif" ...>

in stylesheet 1:
img.onlyontwo, img.onlyonthree { display: none; }

in stylesheet 2:
img.onlyonone, img.onlyonthree { display: none; }

in stylesheet 3:
img.onlyonone, img.onlyontwo { display: none; }

now when you switch, it will also switch which image is displayed.

does that make sense?

The problem is that CSS only governs how things should look, not HTML
attributes. They belong to the HTML and the JavaScript DOM. CSS cannot
alter the src directly. My workaround is to say they should look invisible.

ok, if you want another way, instead of using an image, use an empty
element (like a span)

<span class="hasImg">&nbsp;</span>

span.hasImg { height: 20px; width:20px; }
/* if you want to align this, use 'float' */

in stylesheet 1:
span.hasImg { background-image: url(myImage.gif); }

in stylesheet 2:
span.hasImg { background-image: url(myImage2.gif); }

in stylesheet 3:
span.hasImg { background-image: url(myImage3.gif); }


howzat?

It does work, just not in IE. You need to change 'makeMenu' to 'topMenu'
in the IE conditional comments as well

<!--[if gte IE 5]>
<style type="text/css">
ul.topMenu li {
	behavior: url( 'ietopmenu.htc' );
}
ul.topMenu ul {
	display: none; position: absolute; top: 2px; left: 78px;
}
</style>
<![endif]-->

Aaah! I see what you mean!

I was using Opera 7. It works fine in Opera 7, but Mozilla seems to 
dislike the display: inline; style - it considers the area of the li to
end at the boundry of the static content, not any positioned content.
That's very bad! It does not consider that the child ULs use any space at
all, even though they are being displayed (try putting a border on them,
you will see what I mean).

It's a Mozilla 'bug' I have run into before. Nothing much I could do about
it then, and I'm afraid there's not much I can do now either.

http://www.serve.com/apg/workshop/cssMenu.html
this page has a solution that works. Instead of using UL.topMenu, it uses
DIV.topmenu. It also uses DIVs for the first set of child elements, and
instead of making them display inline, it floats them left, and does not
clear any of them. Interesting technique and it seems to work, although
you will need to tweak my code if you want to do it that way.

Sorry I can't be more help.


Tarquin

gotcha. I see what they have done. They recognise it as a bug/annoyance,
so they have added
padding-bottom: 30em;
into
ul.topMenu li

You almost got it, but you put it in 
ul.topMenu li:hover ul
I think you need it in both

problem then is that you cannot do any background colourings or borders on
ULs (devedge is not affected by that because they do not have sub menus).
If you do, the background shows under the sub menu, and if there is a
left/right margin on the UL. Also, your menus will not close if you move
the mouse directly below them, instead of to the left/right (just like on
devedge)

all borders / backgrounds need to go onto the LIs, so you must not have any
LI margins (IE bug)

on second thoughts, make the extra padding under
ul.topMenu li:hover
not
ul.topMenu li
or the menus open when your mouse is over the page below them.

problem is that the same thing as before happens if you move the mouse too
far right. When it moves further right than the right edge of the parent
li, the menu closes. Padding cannot help here. This means that child menus
of a sub menu will be unusable, unless they open directly _under_ their
parent LI, not to the right of it. In fact, on devedge, they have used
JavaScript to stop that happening with the first sub level.

Try it, switch of JavaScript, then try the 'library' menu. Hover your mouse
over the 'manuals' entry, then slowly move it right. The menu will close
when the mouse is under the 'toolbox' menu parent, even though you are
still over the 'manuals' LI.

That is ugly. Try it again with JavaScript enabled, and it works fine!

You have to ask yourself just how much work you want to put into this ...

> Check it in opera and it's even worse ;).

I know. They have hit a bug in Opera 7's positioning algorithms. Maybe
Opera 7 is not inheriting a position style correctly, I don't know. Sorry,
but It would take me too long to decypher their code (I do all this my own
time for free, and I have a family too ...).

> How does your menu work??? Why does this mouseover thing work?

My menu just happens not to have the Opera bug. However, 
brothercake's menu does have the opera problem. Opera has problems 
with virtual z-indexing, which is why parts of the menus disappear until
you hover over them.

> Can you help me with what I want?

I don't really have the time to build you a custom menu right now, but I
will take a look for you in the next couple of days. I may have to do it
using DIV elements at the top most level though . . . Sorry, have got food
poisoning today so I'm finding it hard to look at my computer :)

horizontal will only work reliably if you convert to left floated DIVs for
the topmost LIs only (and remove their surrounding UL). The float means
that you don't need to use display: inline; so you won't get the Moz
problem. You can then adapt my code to make multiple levels work with your
chosen colour scheme.

This is possible. Use JavaScript to change the className property
onmouseover, so different CSS rules will be applied

a.class1:hover { etc: etc; }

<a class="class1" onmouseover="this.className='class2';" href="blah">

I got a mail saying you were on holiday.

What I showed you can still use onclick, it just uses the mouseover to
change the className before the :hover has a chance to be applied:

<a class="class1" onmouseover="this.className='class2';"
        href="blah" onclick="doYourThing();">

or, yes, you can use:

<body onload="
for( var x = 0, y = document.links; y[x]; x++ ) {
	if( y[x].className == 'class1' ) { y[x].className = 'class2'; }
}
">

This should get you started (I have not tested it in a menu situation yet):

<div class="myMenu">
	<div style="float:left;position:relative;">
		Title1
		<ul>
			<li>Item1.1
			<li>Item1.2
			<li>Item1.3
		</ul>
	</div>
	<div style="float:left;position:relative;">
		Title2
		<ul>
			<li>Item2.1
			<li>Item2.2
			<li>Item2.3
		</ul>
	</div>
	<div style="float:left;position:relative;">
		Title3
		<ul>
			<li>Item3.1
			<li>Item3.2
			<li>Item3.3
		</ul>
	</div>
</div>

I will not have much time to do this for a while, I'm just back from
holiday and have a lot of catching up to do. I suggest you start by
following the 'float' technique I sent you previously.

OK, obviously this example (attached) is not complete, but it should be
enough to get you started. I have discovered that Opera ignores
position:relative on a float, so I have enclosed the first level ULs
inside two DIV elements, the first of which is floated, and the second of
which is positioned.

Sorry the menu didn't work in Konq, I was at home, and I only have V2.1.1
here, which doesn't do it anyway. I will check at work with 3.0.0 and
Safari, and see if I can fix it.

As for the stylesheet switcher, ... it does work. Just Konqueror overrides
it with its view menu settings. It works normally, but once Konq has
decided to use the 'view' menu setting and ignore my script, there is
nothing I can do. The script works in Safari and OmniWeb 4.5 though, so I
know Konq should do it, it just doesn't want to. I will take another look
into this, because I'm sure it should be OK, but I cannot make any promises,
I think it has something to do with the Konq chrome, not KHTML

Have done so, and linked to a couple of other bug reports.

By the way, the menu I sent you
(http://www.howtocreate.co.uk/emails/testOut.html) works in Safari/OmniWeb,
but not Konq 3.1. I guess that the functionality to change display on
:hover was not implemented even in version 3.1, but it should be in later
versions since apple gave their safari improvements back to the KDE project
at about 3.1.

Opera 7 needs the child menus to be shifted left 1px, it works atm, but
only if you move quickly.

The thing is that BrotherCake said he got it to work in 3.1, maybe he had
3.1.x and it is fixed in his version.

sounds like konq has not caught up with Safari yet . . . Does my other menu
(vertical) work for you?

> What'd be the best solution?

I've been trying to think of a way to do this. I think your best bet is to
use JavaScript, like you do with IE. Effectively making a CSS/JavaScript
hybrid menu from the last one I sent you. I've just been trying to make a
script that does it without significant changes to the document. It should
be quite easy, and I have attached a prototype.

It requires
onmouseover="msOver(this);" onmouseout="msOut(this);"
to be included in the parent element (div at the top level, and li for
child levels - take a look at the source).

I have not tested if it works in Konq 3+ yet, as I only have 2.1.1 here.

This would also start you towards IE support - note that IE5.0/win cannot
position li/ul elements and IE5.5 positions them incorrectly, so you might
want to use conditional comments for these.

I know this is not as neat as a pure CSS solution, but at least it should
work.

> Does work in opera, not in mozilla or konq

It's browser bugs. Change it to
div.hovertest:hover
and it works, in Moz at least. Can't test Konq here.

I was wondering what would happen if you used visibility instead of
display ....

Let's not get ahead of ourselves here. I have just discovered that although
it can handle the vertical menus, Opera 7.20 refuses to handle the
horizontal one. I'm going to scream!

**screams silently over the internet**

ok, I will fix this Opera problem first.

OK, solved Opera's problem. It is a bug (I have filed a bug report).
Adding
div:hover, li:hover { font-size: 1em; }
suddenly makes it work, for no reason. I have also managed to reproduce the
bug on a smaller scale:
	<style>
	div:hover { background-color: red; }
	div:hover span { background-color: #ff7; }
	span { border: 1px solid navy; }
	</style>
	<div>the span is <span>here</span></div>
the :hover has no effect

Now, time to work on that Konq bug

I have attached a menu that uses visibility instead. It does not work in
Konq 3.0.0. Does it work in 3.1?

I have also fixed the Opera 7.20 bug in it.

The second DIV needs to be inside the first, not after it (unless you use
the + selector instead of the > selector, but support for + is worse than
support for >).

CSS commenting should always be done as /* comment */
// is not valid

IE5 Mac, Op 5-7, Safari/Konq, Mozilla all support it correctly
IE 4-5 Win get it wrong, and 5.5-6 ignore it completely.

The reson for the oversized text is because the font size in the .hovershow
is multiplied by the font size in .hovertest

The text in .hovertest is 10 times normal text size. Because the .hovershow
is inside it (so it inherits size from its parent element), it's 1em size
is also 10 times normal size. So, when you use 2.7em to make it 2.7 times
as big as normal, it makes it 2.7 times 10 times normal, so 27 times normal.
Use
font-size: 0.27em;
(as in 2.7 / 10) in .hovershow, and it will work as you expected.

it can be problematic though, as in IE4-5,
'div + p' === 'p'
ouch!

It does not work in Konq 3.0.0
The first div changes colour, but the second does not appear.

Interesting and well spotted. It is a bug, but the reason is quite simple.
If you do not float the divs and you are using display:inline, the ul must
extend to cover the maximum area of the menu content, so it has problems
working out what colours should overlap what others (virtual z-index). If
you don't specify colours, it doesn't try and largely gets it right,
although the bottoms of all the menu blocks are missing in Opera 7.23 until
you hover over them. You should report this to Opera software as a bug, but
it may take them a while to fix, because it is obviously burried deep in
their code somewhere.

Well ...
As you might imagine, as this is a bug, there is no quick and easy fix, but
you can fix it by adding just one element to each top level 'A'.
I found that if you put a span inside the li elements and colour the span
instead, Opera 7 will do the color highlight. Of course, the span is inline,
not block, so the background will not cover the full width. It will also do
the background-color highlight if you colour the li (although the 'a'
colour will override the li colour - so the span is still needed).

Not a pretty fix, but it works.

off the top of my head ...

remember to put your UL class name instead of YOUR_CHOSEN_CLASS_NAME

<script type="text/javascript"><!--
window.onload = function () {
  var ULs = document.getElementsByTagName('ul');
  for( var n = 0; ULs[n]; n++ ) {
    if(ULs[n].className=='YOUR_CHOSEN_CLASS_NAME') {
      x = ULs[n].getElementsByTagName('li');
      for(var i = 0;x[i];i++){
        x[i].onmouseover = function () {
          var y = this.getElementsByTagName('ul')[0];
          if(y){ y.style.display = 'block'; }
        };
        x[i].onmouseout = function () {
          var y = this.getElementsByTagName('ul')[0];
          if(y){ y.style.display = 'none'; }
        };
      }
    }
  }
}
//--></script>

Sorry, I gotta go now.

sorry - extremely busy -

honestly not sure how to approach this one.
I would suggest using className to set the class of the LI, forcing it to rerender. you can use
li.isHigh { background-color: whatever; }
li.isHigh a { color: whatever; }

...
       x[i].onmouseover = function () {
         this.className = 'isHigh';
         var y = this.getElementsByTagName('ul')[0];
         if(y){ y.style.display = 'block'; }
       };
       x[i].onmouseout = function () {
         this.className = '';
         var y = this.getElementsByTagName('ul')[0];
         if(y){ y.style.display = 'none'; }
       };
...