MSIE CSS Pop-outs/pop-downs/flyout menus
In April 2006 we revisited pop-ups for some new developments and again felt that shudder of disgust that we were still using Javascript for simple navigation functions in MSIE 5/6 (we had implemented CSS pop-ups in mid 2003 for Gecko and Opera from 7.54+). With MSIE 7 (beta in April 2006 if you are using XP which we are not) promising clean (read standard) CSS pop-ups now was the time for change - but we were still stuck with MSIE 5/6 Javascript. So we went in search of an MSIE 5/6 CSS solution and found two web articles that showed it may, just may, be possible.
The first was an article on MS Conditional Comments which allow selective inclusion or exclusion of MSIE specific CSS, HTML or even Javascript within the target MSIE browsers in the - highly likely - event that such techniques would be required. In this context it is worth mentioning that we currently use server side browser sniffing to generate browser specific pages but would be very happy to get rid of the technique without using one of those gruesome client side javascript browser sniffers. We like the idea of giving the browser with the problem the job of fixing the problem. It just feels right.
The second article was writen in 2003 by Venimus for the codeproject in which a table is used to enable the a:hover effect to span the pop-up definitions for MSIE. This falls into the category of super-kludge, which we generally don't like, but it appears, based on experimentation, to be very reliable. So armed with this data we tried to implement multi-level CSS menus - and ended up with reliable single level CSS pop-ups (vertical and horizontal) but could not find, in a reasonable timeframe, a solution to multi-level pop-ups/flyouts.
The following documents what we did, and the - perhaps erroneous - conclusions we reached in the hope that someone with more patience, more knowledge, or, even more likely, just a lot brighter that us can provide a sensible explanation of MSIE 5/6 functionality and the kluges necessary to generate reliable multi-level results. After we published this note we found some sites that claim multi-level CSS pop-ups for MSIE 5/6 - we could find no explanation as to why their techniques work - it was therefore possible that by making modest changes to the CSS they may not continue to function. We would be no further forward. We think we know why ours work - think, mind you, being the operative word here.
Notes:
We are not entirely opposed to javascript and indeed AJAX techniques may require us to re-introduce the blasted stuff in a future site iteration - but we are constantly offended that it is required for simple page effects.
We always provide a multiple click method of getting to the same page that any drop-down, pop-out/flyout menu targets so we really don't care how it degrades, or even if it does not work, on older or non-conforming browsers (conforming to what you may well ask). We think that designing sites where pages can only be reached by pop-out menus is simply bad design. Instead we think of pop-out/drop-down/flyout menus as both a user convenience and as an alternate site map - in general the more pop-out levels we can provide the better.
Part of the reason we finally gave up on multi-level menus is that all the experiments relied on external observation of MSIE effects - with the objective of de-constructing the logic behind MSIE functionality so that we could use any such functionality to create our desired effects in a consistent and reliable manner. This is a frustrating and ultimately pointless exercise. In an Open Source world faced with the same problem we would have grabbed the source and figured it out. With MSIE ...mmmm.
De-bugging CSS can also be pretty frustrating. You do what you think is right and it does not work. So now what. You keep trying new combinations and even - heaven forfend - read the specifications. We also used unique effects and borders to try and get an idea of what might be happening. Outside of these crude techniques there seems little else possible.
Contents
Note: All the experiments use <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> (without a URL) which according to this list means we are in pure quirks mode. Note: Out of curiosity we re-ran a number of experiments with <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> with no noticeable behavior changes and indeed a number of the test pages still reflect this DOCTYPE.
All Browsers CSS Pop-out/pop down Menus
The first series of experiments were all based on assuming the table markup referenced in the article above was a significant element in creating the functionality and these experiments were designed to eliminate, on a step-by-step basis, as much HTML and CSS as possible, that is, to try and find the minimal CSS/HTML needed to get pop-ups to work in a MSIE environment - trying to find the limitations in the MSIE CSS model by external observation. This page starts from the experimental layout described in the article above and works for MSIE 5.5/6, MSIE 7, Opera (8.54) and Gecko (but with an annoying box below the menu item) - we added an </a> tag to terminate the enclosing anchor tag sequence (for aesthetic reasons - if you are using a kludge it should at least be a clean kludge!) within the inner table and an absolutely positioned div under the menu to allow us to test any interaction and screen redraw issues. Finally we added unique anchor target addresses to test where the links were going. This turned out to be jolly smart of us - most unusual.
Simply removing the enclosing table structure appears to have no effect on the layout. Adding a paragraph and some modest renaming of class fields again appears to have no effect on the layout. So far so good.
We then rewrote the menu system to use a single level of unordered lists (ul/li) within the dummy table structure and to find a better way of handing vertical and horizontal formatting than the <br> tag suggested by the original article - so after a bit of messing around we got to this vertical layout which works reliably for MSIE 5/6, but Gecko and Opera both have minor layout errors. This page corrects the errors in Opera by using a top:1em to remove the gap in the .first:hover .ul-1 definition and plays around with the margins in the .first:hover .ul-1 .li-1 .a-1 since the Gecko error is caused by calculation of box size differences. This page uses a horizontal layout and works for MSIE 5/6 but not Gecko or Opera because the .first anchor tag is not picking up the width of the containing div block. When the same corrections are applied as described above and .first is given a display:block attribute instead of a width:100% the markup is crudely fixed and works for all the browsers. If you click the various sub-menus however you will see that MSIE and Opera generate the right anchor targets but not Gecko which use the primary menu link targets - a side effect of the wrapped anchor tags. Not so healthy - but fixed below.
Summary points so far are:
The table's function is exclusively used to enclose the pop-up definitions (to con MSIE into invoking the :hover effect) and can be reduced, by CSS definitions, to a non-existent space (you can add a border to the CSS table definition in the example page to see this visually). There are no references to the table in any CSS pop-up event definitions.
You will see that all visible formatting effects are defined exclusively in the pop-up/event driven CSS. We had found by multiple experiments that defining visible characteristics (borders, colors etc.) in the base style definitions can cause residual (or ghost) mouse-over effects.
The MSIE pop-ups are triggered via the :hover events which span the pop-up definitions and these must have more than a color attribute defined (we use background in the examples but there are other attributes that can be used in context) - this is the well known (aren't they all) MSIE pop-up bug (more information on the pop-up bug in this excellent in-depth note by Claire Campbell). This anchor spanning technique has an unfortunate side-effect in that it loses the sub-menu anchor targets for Gecko as noted above.
When we moved to a production system we discovered that placing any CSS font-size definition in any of the CSS pop-up definitions (anchors/ul/li) leaves a tiny gap between the li elements which ruins the mouseover effect. Define all font values in either the enclosing menu div or other definition and let the pop-ups inherit them to avoid this problem. We had disguised the effect of this error during testing by turning on 'ignore font sizes' in MSIE Accessibility options.
So we now added some hidden conditional statements around the table HTML which have the effect of removing them only for Opera/Gecko and MSIE 7+ but maintains them for MSIE 5/6. This is the format of the uplevel (hidden) browser conditional statement which acts like a big comment to all non MSIE browsers:
<!--[if lte IE 6]>
visible HTML statements for MSIE 6 and below
HTML not visible to non MSIE browsers
<![endif]-->
The vertical version works for Gecko but not for Opera and the horizontal version again works for Gecko and not for Opera (and incidentally gives the same results when used within XHTML 1.0 Transitional DOCTYPE - but fails to validate 'cos of the nested ul's within the a/li tags in two places.
Finally we added some non-hidden versions of the MSIE conditional comments to terminate the initial A tags for MSIE 7 (and greater), Gecko and Opera but not for MSIE 5/6. We also had to generate some addition CSS using the form div.menu:hover ... to get the pop-ups working for Gecko and Opera because we had changed the containing block (commented in the CSS) and which co-exist with the MSIE required CSS - so we did not have to use conditional comments to wrap this CSS - which is just as well since they cannot work inside style tags - see Conditional Comments and <style> tags below. This page both provides the correct anchor targets for MSIE/Gecko and Opera - but still fails to validate (using a variety of DOCTYPE definitions) using the MS recommended format of the non-hidden - what MSIE quaintly refer to as downlevel browsers (displayed by any non MSIE browser) - conditional comments. MSIE recommended format:
<![if gte IE 7]>
revealed HTML statements for non MSIE and MSIE 7+
<![endif]>
However - fear not - there is a solution from Lachlan Hunt in which the same effect may be achieved using this format:
<!--[if gte IE 7]>-->
revealed HTML statements for non MSIE and MSIE 7+
<!--<![endif]-->
By using this format this page works for all browsers and validates. Phew!
Conditional Comments and <style> tags
HTML comments are not recognized inside <style></style> tags so MSIE conditional comments cannot be placed inside such a tags. Instead a whole style section needs to be wrapped in conditional comments, for example:
<!-- hidden (downlevel) revealed for non-MSIE and MSIE 7+ -->
<!--[if gte IE 7]>-->
<style>
style definitions for non-MSIE and MSIE 7+
</style>
<!--<![endif]-->
<!-- hidden (downlevel) revealed for non-MSIE and MSIE 7+ -->
<!--[if lte IE 6]>
<style>
style definitions for MSIE 6 and below
not visible to non MSIE browsers
</style>
<![endif]-->
The above could also be used with a linked style sheet and, in passing, it may be noted that the normal escape sequences included in a style sheet are not required since the browsers which recognize the tags (MSIE 5/6/7+) also support CSS style tags.
Toward Multi-level Menus
So we have a reasonable single level CSS menu solution for both horizontal and vertical menus. Now we got really ambitious and added a third level menu and that was the beginning of the end.
We got to this page after a lot of messing around. The second level menu is well behaved and has no residual effects if you exit from within the second level menu, but if you mouse over the third level pop-up and then exit via that menu the page leaves a residual mouseover effect. This page makes various borders visible as a diagnostic. We have no idea at this stage where to go next (goodness knows we tried) - experiment with DOCTYPE's, various CSS attributes, HTML etc., etc. We will revisit the problem from time-to-time but have retired hurt and bleeding in getting multi-level menus to work in MSIE 5/6. If you are smarter than we are - that's not too difficult - and understand what is happening we would love to hear from you so that we can share the information with the rest of the known universe. If you have CSS that simply works and have no idea why we are only vaguely interested - but if you think you know why it works and the specific CSS that makes it work we would be delighted to publish the information with suitable accolades and credits to a true hero of the known universe.
In summary. We think this is stable enough to go into production as a single level menu system. For customer sites that need only a single level menu we will use this technique as a single page solution for all browsers using the MSIE conditional comment technique above, that is, we will remove our server-side browser specific page generation for this style of site. We will also - again using conditional statements - generate multi-level menus for conforming browsers and a single level for MSIE 5/6 for our own site. In fact our front page (only) now uses this technique and we will add to all other pges once this has stablized over the coming months. One of the side benefits of using the conditional comment technique is that when Opera identifies as MSIE it gets multi-level menus.
And for customers who require MSIE 5/6 multi-level menus - we are still stuck with Javascript - sigh!
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.
