Forum OpenACS Q&A: Re: Going great guns now!

Posted by Richard Hamilton on

Yes, thank you. Once I managed to find your examples to import I was away! I saw the -decoration none directive to the includelets in the docs, but nothing specific to the included wiki pages. I eventually concluded that this probably also worked for wiki pages as you have confirmed, {{en:page -decoration - none}}, however by that stage I had decided to bite the bullet and dive into making the menu system I have been forced to produce, work with the categories includelet!

I have done so, but want to suggest an ammendment to the <ul> that the includelet produces that will enhance its utility and interoperability with CSS.

I have been forced by a design to produce a horizontal menu with dropdowns. This requires the CSS selectors to be able to distinguish the top level list and display it 'inline', whilst all subsequent lists are displayed as 'block'.

The issue is that if you render the submenus as blocks, they are displayed as blocks inline to the top level list. This unrecoverably upsets the position of the subsequent inline top level menu items. The ONLY way to avoid this is to take the submenus out of the normal flow by using position: absolute. However if you do this without a containing <div> all the menus sit on top of one another adjacent to the left hand margin of the last absolutely positioned block element.

I therefore propose that every <ul> that is a child of <ul class="mktree"> be wrapped in a <div class="mkbranch"> or other suitable classname. The reason this works is that the <div> when set to position: absolute; width: 100% will sit beneath, and only be as wide as, the top level <li> that is its parent. You can then relatively position the <ul> submenu within the div block, without upsetting the top level menu item display flow.

I have posted below an example of the menu and the CSS. I realise that this is a specific applicaton for me, but this small change to the categories includelet itself would increase its flexibility, which surely can only be a good thing. I think this would add potential without breaking anything (although I confess I haven't studied the oacs-view template for the gory details of the treeview code). At least I would hope any change to that would be trivial.

The code posted below has taken quite a bit of time to get right, so I hope it will prove useful to anyone else who has to consort with the evil forces that demand horizontal drop-down menu bars! :-) A bit of a fantasia on the use of CSS pseudo-classes.