Forum OpenACS Q&A: Re: Is this it?

Collapse
30: Re: Is this it? (response to 29)
Posted by Richard Hamilton on
I fully understand the thrust of that comment, I spent hours working through it with that assumption in mind. However, I have explained in the comments that because the top level menu is to be rendered horizontally, it has to be:

display: inline;

This is fine until you add the vertically rendered submenus, i.e. setting the <ul> to display: block. What happens then is that the vertical menu is positioned inline to the top level menu, thereby displacing the subsequent horizontal menu items from their expected positions. This cannot (to the limit of my knowledge) be rectified by adjusting the <ul> class because its position cannot change the inline positions of its parent element.

If you remove the submenu <ul> from the inline display sequence by making it position absolute, your containing block for position reference is the grandparent <ul> rather than the parent <li> element! As the menu is dynamically generated, you cannot risk making absolute position adjustments because you don't know how many elements or subsubmenus there will be.

The containing <div> that I have proposed provides you with a new position reference for the <ul> block where 100% of the <div>'s width is equal to the width of its parent <li> element. This allows you to absolutely position the submenus and subsubmenus with reference to the left hand edge of the <li> that gives rise to it. Page 208, para 2 of the Lie & Bos CSS book refers. I don't think that there is a more minimal solution.

I agree that my style sheet could perhaps have been written to work with the -decoration none version, but actually some of the added classes and wrapping div blocks are useful for precision in the selectors.

I have had to alter a few details and will post back. However one thing I have found is that wherever a series of subcategories are rendered by xowiki inside a parent <li>, the rendered does not close the tag with a </li>. Now I know that under the HTML spec this omission is legitimate, however there are circumstances where this can cause ambiguity. I would therefore recommend a change to close the tags.

(Example; I have been asked to make the dropdowns about 80% opaque. If you reduce an element's opacity in CSS or javascript, all descendents are affected and the effect cannot be reversed by subsequent more specific rules. Therefore to add a partially transparent background without reducing the opacity of the text, I have to add another <div class="opaque"><div>which is sized and positioned to provide the transparent backdrop to the menu. Without the explicit closing </li> the browser assumes this <div> to be another top level <li> rather than a block element still in the previous one).

Sorry, this is all rather arcane detail, but it takes hours to thrash through and I may as well record it.

Regards
Richard