The Laboratory - CSS
Transparent, horizontal navigation bar
The challenge
Create a centered web page with a tiled background and a horizontal navigation bar. The width of the page (i.e., the centered content area) should be 574 pixels wide. The navigation bar should contain 4 menu choices, it should run the full width of the page, and it should be transparent in such a way that when the page window is enlarged or reduced in size, the movement over the background should also be visible through each navigation element. The total area of the element (menu text and transparency) should be active for linking. Running around each transparent element there should be a non-clickable, white area of 10 pixels top, right, bottom, left.
If that sounded cryptic, try running your mouse (if you use one) over each menu choice in the navigation bars below, and change the size of the browser window for a “look and feel”.
Possible solutions
This late in the history of evolution, it should come as no surprise that the most flexible and accessible solution will be one which uses Cascading Style Sheets (CSS) creatively. So, for no other reason than to put different methods into perspective, let us compare recent developments with “traditional” and alternative methods.
Where details are lacking in the article, please consult the HTML document where each CSS rule can be found in the head of the source.
The table method
| Menu 1 | Menu 2 | Menu 3 | Menu 4 |
Trusted and proven, still very much in use, and once the only way to achieve an interesting layout, tables are nevertheless inflexible when time comes for a page make-over, and, most disturbingly, they lack semantic meaning for accessibility via screen reader software. If the user is lucky enough to see web page content, however, he or she is none the wiser and will happily use the navigation bar as is. And if a need to enlarge the menu text arises, the table will play along.
To include the cell transparency in the clickable area, the link tag should be displayed as a block element with CSS.
The image method
Because of its fixed size and the fact that it is an image, the image navigation bar will render the same in whatever browser it is viewed in. Semantically and accessibility-wise, however, it sucks. Spelling mistakes? Different wording? Back to the drawing board.
The most irritating necessity of using an image is that you will often resort to HTML image maps to define clickable areas. Unless, of course, the menu text is added with HTML/CSS. But then the text will reposition relative to the image if the user enlarges or reduces the text size. It should be noted that, while image maps are still valid with HTML, they do not separate presentation from content.
The most irritating necessity of using a transparent image (which must be saved as 24 bit to preserve anti-aliasing of text) is that you have to cater to transparent 24 bit images in Internet Explorer prior to version 7. A proprietary Microsoft filter must be called; a filter which is not applicable in all situations. And as it turns out, not in this case. You are simply not able to add an image map reference to the filter. Neither if the image is served inline nor if you try to display it as a background.
Preserving transparency with PNGs in early Internet Explorer browsers has been a major headache for years and several solutions and workarounds have been suggested. For discussions on the problem, Justin Koivisto’s article Normal display of PNG Alpha Transparency with MSIE and Drew McLellan’s Transparent PNGs in Internet Explorer 6 are good starting points. Based on JavaScript or Flash or server-side PHP, many of the solutions are a bit on the heavy side, however, and compromises are sometimes sought. When Alex Walker in his SitePoint newsletter PNG8 – The Clear Winner tested alpha transparency in Fireworks, he handed owners of that application a one-image-serve-all solution (the screendump below shows the optimization values applied to an image prior to export from Fireworks).
But: It is not very useful for text in small sizes. If you anti-alias in Fireworks to serve all friendly browsers a nice, readable text, you have no control over how the “alpha text” is displayed in Internet Explorer prior to version 7. If you are unlucky (and you can count on it) vertical and horizontal lines in the “bitmap” text may “fall between” screen pixels (if they are rendered by Fireworks at all) and what you see is a jagged sort of text, often unreadable. Granted, if you take a step back and scrutinize the image navigation bar, it may look as if 24 bit transparency is overkill; users of Internet Explorer on Windows XP are certainly not spoiled when it comes to anti-aliasing, anyway. If you choose not to anti-alias, or if you use a bitmap/screen font, you can get around this problem, but then you are throwing in the towel somewhat prematurely.
Because: It is possible to create CSS image maps. Which is exactly what you should try. Forget about traditional image maps and use instead a method which both defines clickable areas and is user-friedly and search engine friendly. And can be used on any image and not just for navigation.
Part of the trick is to use an unordered list for the navigation elements and define absolutely positioned a tags (aka links) atop a relatively positioned parent box. Hats off to Andy Budd and his book “CSS Mastery. Advanced Web Standards Solutions” for this tip (even if modifications are necessary). However, to serve old Internet Explorer browsers the same 24 bit image as modern browsers and at the same time allow for activation of positioned links lying on top of a transparent image, is more or less impossible. Early on I was hoping that Angus Turnbull should come to our rescue. He has spent hundreds of hours on a fix. A server-side script and an empty GIF promised to complete the trick.
Of course, a blank GIF sounds a lot like spacer GIF and table layout but in this case one is willing to look the other way if broken browers can be beaten. But alas, Internet Explorer 6 may still, when certain conditions are met, throw up the following complaint: “Children of positioned element are unclickable.” And when tested in Internet Explorer 7, the links are not activated. Even Andy Budd, in his PDF errata report for “CSS Mastery” has admitted to the same problem.
Come to think of it, server-side scripts are not for everybody, anyway. The heavy load will burden your server and not the user’s machine.
I should have seen it coming! In his article, Drew McLellan throws cold water on all our hopes: “There’s a bug/weirdness with AlphaImageLoader that sometimes prevents interaction with links and forms when a PNG background image is used.” So, magic in this world did die with Merlin, after all. If one does not resort to McLellan’s SuperSleight JavaScript, that is. Something I am not willing to do for those souls still on Internet Explorer 6. Possible side-effects of conflicting scripts keep me awake at night.
What to do? I must admit, I was at a loss as to how to activate those links. Untill an idea struck me: Why not create a buffer between the absolutely positioned link and the transparent PNG (or GIF, same thing) below? I will not tire you with the details of trial and error, only state that a creative use of opacity on a white coloured link background and conditional comments finally nailed the trick. But I had to bite the dust and resort to a substitute image for the navigation text in Internet Explorer 6.
For our case study, a 1 per cent white, opaque “film” above the navigation text cannot be discerned and you will be hard pressed to detect it on any image. Humble as I am, I will not say that this will always work and do inform me if you disagree. View the source (HTML, CSS and conditional comments) and you should be able to reproduce it.
The Flash method
You need to install Flash Player and enable JavaScript to view the content as intended.
A closed environment, a Flash movie should render equal in different browsers. This is hard to beat but it comes at a cost. The proper Flash Player plugin must be installed, and, often necessary, JavaScript must be enabled. As a developer you also need access to the Flash application with its rather steep learning curve. Then there’s accessibilty, of course. The future does, however, hold promise for more accessible Flash movies, both for navigation and for search engines.
A stand alone menu created in Flash can not be justified in all situations, but it is a viable solution especially if alternative navigation is hidden from view with CSS (but still available for screen readers).
And how does one get a transparent Flash movie? In short, by specifying a transparent wmode attribute “somewhere” in the HTML document (several options are available but the SWFObject JavaScript method is now universally adopted as the most flexible and unobtrusive way).
Of course, with Flash SWF, the active (aka clickable) area is defined in a button; one for each navigation item.
The CSS method
A CSS-styled unordered list is most often employed to create a navigation bar. To create a horizontal navigation bar, one method is to display list items inline. One difficulty with this approach is that fixed width menu items are hard to achieve. The inline method has also been reported to yield buggy results in certain situations. Whitespace between list elements in HTML is one pitfall and if you do not have complete control over markup, unwanted results may occur.
To get around this, you might try substituting display: inline with display: inline-block. It renders correctly in, e.g., Safari 3.1.2, Firefox 3.0.3, and Opera 9.60, but breaks in, e.g., Camino 1.6.1/1.6.4 and in Internet Explorer 6 and 7. It looks as if support for inline-block in Mozilla browsers has been on and off and on again as they have evolved (now, finally in Firefox come version 3). Depending on the version and your needs, the proprietary display: -moz-inline-stack may do the trick. Without thorough research, though, it is not a method I can recommend.
Inline display may be the way to go, however, if you want a CSS-styled navigation bar with centered tabs. Again, only if you are not concerned with specific widths.
The preferred method for this case study turns out to be a combination of an unorderd list and floating list elements. If the user enlarges or reduces the font size, the menu scales accordingly, and if the browser should, for any reason, fail to pick up the CSS formatting, the navigation is still available in the list.
With presentation all done with CSS, you can also achieve consistent use of typefaces. When images and Flash movies are used for text – as you have done in this case study – the text reflects whatever font (e.g., Lucida Grande) was used when the image was created. The user may not, however, have that font on his or her system. With a first choice of, say, Lucida Grande for body copy, a Windows user will not have that font avilable, so a second or third or generic choice is used as a substitute. Not immediately evident in this case, but if you observe the number "1" in the image menu or the Flash menu, it will probably look the same in the body copy if you are on a Macintosh computer as Lucida Grande is normally available there. On a Windows machine that font may be substituted with, say, Lucida Sans if so specified with CSS. The number "1" is, however, differently drawn in that typeface. A trifle, you may say, but at some point it is all in the details.
That’s it
All roads lead to Rome, or so the saying goes. But that does not implicate that you necessarily complete the journey once you set out. Prepare for obstacles and take care of those who want to come along. Not every method is a means to an end.
To return to where you came from (no pun intended), please use the browser’s back/previous button, or go to the main page.
Leave a comment