×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Since a hover didn't drop the menu or display a tooltip, I didn't pick up
on that element being a clickable image - it looked like a part of the blue
bar background image.
I added a "tool tip" saying "Menu Options" as a hover effect. Of course,
that's only applicable if you have a mouse. A 3-bar image has become
something of a de-facto for cell phone menus.
The following CSS snippet is known as a "media query" which automatically
toggles the "display" attribute of menu "bar" or "button" based on screen
width, which makes the menu "responsive". Declarative code like this is an
improvement (IMHO) over writing JavaScript to toggle visibility.
@media only screen and (max-width: 870px) {
#menu_bar {
display:none;
}
#drop_button {
display:block;
}
}
@media only screen and (min-width: 870px) {
#menu_bar {
display:block;
}
#drop_button {
display:none;
}
}
The severe design limitation I see with a fully responsive solution is
that the site design is severely limited if there is going to be a
one-solution-everywhere requirement. This, to me, is a designer issue, not
a programmer issue.
Well, the alternative is to develop and maintain two code bases, one for
mobile devices and another for desktop screens. Wouldn't two code bases be
both a designer and programmer issue?
Last weekend I discussed responsive design with my brother who is a CIO at
a large Internet retailer, and he says that having to maintain two code
bases, one for mobile and another for desktops is a big concern for them.
As an Amazon Associate we earn from qualifying purchases.