[sword-devel] CrossWire frontpage
dmsmith555 at yahoo.com
Fri Dec 5 06:27:56 MST 2008
On Dec 5, 2008, at 6:53 AM, Eeli Kaikkonen wrote:
> Quoting David Haslam <d.haslam at ukonline.co.uk>:
>> Hi Peter,
>> Please visit http://www.grc.com/menudemo.htm
>> and read about GRC's Script-Free Pure-CSS Menuing System designed
>> by Steve
> May be good, as long as it supports also those browsers which don't
> have css support. Please check the pages always with lynx, w3m or
> something similar. All information (apart from screenshots etc.)
> should be accessible from text based browsers, too. Then the pages
> probably work everywhere for everyone.
I'm curious as to why support of text based browsers is at all
important? Is it an assistive technology?
GRC's implementation works just fine in all browsers. It is just very
ugly. The menus are a stylized unordered list. So when the CSS is not
used, it is just a bulleted list. You can see this in FireFox by
turning off styles (View -> Page Style -> No Style). Other browsers
might have a similar mechanism.
I've implemented something similar at work, based off of the same
pages that GRC based their work. But mine uses a touch of java script
under IE to add hover capabiliies. I found shortcomings in mine:
1) If there is a dropdown just under the menu, then the menu tunnels
under the drop down. This implementation might not have the problem.
2) You have to be an expert mouser. If you leave the menu by a pixel,
the menu disappears. This is not much of a problem when the menu is
merely a drop down, but when it also cascades to several layers, then
3) It depends on CSS and HTML hacks. Opera and Safari had problems,
but since my target audience only used IE 6+ and Mozilla, it was not
an issue. We had to make changes when IE7 came out.
I've replaced my implementation with Yahoo! User Interface (YUI). It
is a heavy system java script system that fixes these problems. The
"cost" is ameliorated by it's modularity and compression technology.
Our menu system has nearly two hundred entries and we found that the
menu itself accounted for over 25% of our site bandwidth, because it
was delivered with each page (we turn off caching on the user's
browser because our content is static).
We have tempered the cost by using it only once per user visit. When
the user picks a menu choice, it targets an iframe with the content.
Once we did this, using YUI was low cost.
More information about the sword-devel