Who ate my Hamburger?

[SamA74]

Continuing the discussion from Tab navigation on Drop-down menu:

This may be tricky, as I think it may be device specific, but someone may have a clue.
You can skip this waffle and go to The Problem.
The back story is in the previous thread. I was working on an experimental new menu system that would possibly replace my current, poorly accessible, old-school drop-down menu.
Actually, in the beginning it was just an experiment to see if I could make a responsive menu on a responsive page, with no media queries, in pure css with no scripting, just to see if I could do it, and it worked.
Later I was shocked to discover how inaccessible my current, live on-line, drop-down menu system was, hence the other thread. I then discover that this experimental menu is way more accessible and see it a possible solution to the problem.
Since first posing it and getting some feedback, I have made some more enhancements, notably, adding a couple of media queries. Back in the real world, I was never going to make an entire responsive site without any.
The first one was for big screens (desktops). I thought I would give those with plenty of screen space to spare a full-fat version of the menu with words and everything, rather than just the icons (with words on hover/focus).
Then the second query, was for small screens (phones) where I folded the icons into a hamburger until use, to give a bit more reading space where it is at a premium.

The Problem

All appears to work well, testing in Firefox and Chrome all the way down to tiny wee iWatch size views. Then I actually try it on an actual phone. Unfortunately all I have to test it on is an oldish Windows Phone, OS version 7.8, not sure which IE that is though, it does not tell me. On that the hamburger is missing, meaning no menu at all. Actually there is a shadow of it, like it’s 1 or 0px high and still casting a box-shadow, but not clickable, see photo.

Reviewing the css, I can’t figure out why it’s displaying like that. It could be something peculiar to that IE version, whichever it is, one that does not support position:fixed as a side note, but less of an issue.
So, any idea why this should be?
This is a version of it with the hamburger.
This alternative version does not go to hamburger, but keeps the icons on small screen, which does actually work I think.
I also welcome any feedback on usability and accessibility of the menu on a variety of devices and ATs.

[PaulOB]

Hi,

I’m only on a laptop at the moment and away for a few days so can’t test but the first thing I would look at would be the 90% height you gave to the image. It may be 90% of nothing and thus invisible.

Try a px height just to check first.

[SamA74]

Try a px height just to check first.

That didn’t make any difference. I have tried a few other things too, and it is turning out to be a real puzzle. Some changes have altered the behaviour, but none a complete fix. One version did display the hamburger icon, but the actual button background was not there, still with the thin shadow. I did get it to display the menu, but only by breaking the display for ordinary browsers, and the sub menus did not display.
I’m thinking it has to do with how the browser handles position and how that in turn affect height. I already mentioned that the browser does not seem to support fixed positions. That’s why I have been preceding position:fixed with position:absolute as the nearest fallback. But I guess these have different behaviours with regard to height, as fixed sees the viewport as its space, and other position settings see their parent as their space, which is not the same height.
Also, can anyone out there check if it works OK on Android or iOS or even a newer Windows Phone?

[PaulOB]

It was working on my iphone when I tested it.

Older devices don’t support fixed positioning and I doubt an absolute fallback will be much use.

I can’ test until I get back home which will be early next week.

Maybe Ron or Ryan can have a look?

[SamA74]

OK, I think I found the culprit. It was Max Height who ate the hamburger.

#mmen li, #ham, #close   {
       height: 3.13em;
       margin-top: 4px;
       max-height: 15%; /* That's the one */
}

That line is for the benefit of short screens, Eg, a phone in landscape, and forces the icons to snug up as height decreases.
Commenting it out makes the hamburger appear on the Win Phone, but then I lose the shrink-fit effect on short screens.
I also mentioned that when I did get the hamburger to show, and opened the menu, the sub-menu would not show. The reason for that was:-

.smen    {
     overflow: scroll;
}

I don’t know why, but that stops the sub-menu appearing on the Win Phone. This was also added for the benefit of small screens. Because the menu has a fixed position, you can’t scroll down it if it does not fit on the screen, which may happen if you had a small screen and zoomed the fonts up.
I discovered all this working on a further version of the menu which has some additional buttons to the hamburger. In this version, the side-bar becomes a top-bar on the mobile. I also used a height media query (a first for me) to show/hide the hamburger, which makes more sense with the menu being on a fixed vertical side bar.
Just ignore the aesthetic side of the design for now, icons, colours, etc, I’m just getting the mechanics of it sorted first.

[PaulOB]

That line is for the benefit of short screens, Eg, a phone in landscape, and forces the icons to snug up as height decreases.Commenting it out makes the hamburger appear on the Win Phone, but then I lose the shrink-fit effect on short screens.

That is likely because as I suggested the percent is calculated as zero in some browsers and you end up with max-height;0 will over-ride a fixed height. When you changed the overflow from visible to scroll then the element would be hidden.

[SamA74]

That is likely because as I suggested the percent is calculated as zero in some browsers and you end up with max-height;0 will over-ride a fixed height.

That has to be it, but seems odd, as the parent has a height defined, so I would expect % to work.

#mmen li      {
       max-height: 12.5% ;
       max-height: 12.5vh ;
}

I thought I would give this a try. They are effectively the same in this situation. Hopefully a browser will support one or the other.

When you changed the overflow from visible to scroll then the element would be hidden.

I’m still not clear on how some browsers would do this. Or is it another possible 0 height?

.smen    {
       position: absolute;
       position: fixed;
       top: 0;
       left: 0;
       right: 0;
       bottom: 0;
       margin: 0 0 0 3.13em;
       overflow: scroll;
       z-index: 70;
}

Should I try height:100% rather than setting top and bottom 0?

[PaulOB]

That has to be it, but seems odd, as the parent has a height defined, so I would expect % to work.

It does work in modern browsers but seems to be a problem with your specific version. Max-height has had a chequered history and there are some bugs in older browsers. (Note that max-height cannot serve as a basis for nested elements height either as only ‘height’ can be the basis.)

Or is it another possible 0 height?

Yes I’m guessing that as the max-height is zero then overflow:scroll will hide the element as there would be nothing to offer scrollbars for.

Its one of those problems where you need the real device to test so I think that now you’ve found the trigger you will be able to work out the solution.

[SamA74]

#mmen li      {
       max-height: 12.5% ;
       max-height: 12.5vh ;
}

I thought I would give this a try. They are effectively the same in this situation. Hopefully a browser will support one or the other.

That did the trick.

Should I try height:100% rather than setting top and bottom 0?

That didn’t work. But I suppose I could live without it. The longest menu “About Us” will fit on a screen 300px high. So it’s only an issue if someone has a <300px screen or zooms the fonts on a very small screen.

[SamA74]

Back to this one again. This is the latest incarnation of the menu. It’s all working pretty much as I want it to, even on the Windows phone. Fully responsive and tabable.
There is just one more thing I want to fix before it can be released into the wild and put on the actual site.
It’s good old IE8.
Now I don’t want to bust a gut fully supporting prehistoric browsers, but there are still a few die-hard IE7 and 8 users hanging on according to my Analytics.
I’m quite happy for them to just have a basic “no thrills” view of the site; if they want css transitions, round corners and shadows that badly, then they can get a new browser.
But I do want to give them basic functionality, as in, the site is both readable and navigable.
This new menu, for all its improved accessibility, is completely inaccessible in IE8 due to its reliance on the target pseudo class to show the menus.
So I guess I need some form of “polyfill” for this, but I’m not sure how. I did try adding a little js for this. But js is not my strong point and I got nowhere. Any ideas?

[PaulOB]

Hi,

IE8 doesn’t support svg so your menu images would need to be hidden.and perhaps just use the text (or swap the images out for pngs etc).

As IE8 doesn’t support :target then you could change the menu for IE8 to a hover menu instead using CCs to add an IE8 class to the html element.

e.g.

<!DOCTYPE HTML>
<!--[if lte IE 8]><html class="ie"> <![endif]-->
<!--[if gt IE 8]><!--><html><!--<![endif]-->

Then just use the .ie class to construct the hover menu (as per normal). There would be no need to make it collapsible for IE8 so you could just play around with a best fit.

You could instead add some JS to make the menus appear and something like this would work but this is pretty rough.

<!--[if lt IE 9]>
<script src="http://code.jquery.com/jquery-latest.min.js"></script>
<script>
jQuery(document).ready(function() {
  $(".smen").hide(); //Hide all content

  $(".sec").click(function() {
      $(".smen").hide(); //Hide all menus
      $(".sec").removeClass("active"); //Remove any "active" class
      $(this).addClass("active"); //Add "active" class to selected tab
      var activeTab = $(this).attr("href"); //Find the href attribute value to identify the active menu
      $(activeTab).show(); //Fade in the active content

      return false;
  });
	 $('.close,a[title="Close Menu"]').click(function() {
      $(".smen").hide(); //Hide all menus
			$(".sec").removeClass("active"); //Remove any "active" class
      return false;
  });
});

</script>
<![endif]-->

Then some CSS:

<!--[if lt IE 9]>
<style>
.sec img{display:none}
.close{background:transparent;}
</style>
<![endif]-->

You’d still need to sort out the collapsible state in a similar manner but its a rough start.

[SamA74]

You could instead add some JS to make the menus appear and something like this would work but this is pretty rough.

Thanks Paul. That seems to do the trick.
I also added some css in the conditional, so old IE users get a menu like the full fat wide-screen version, only a little narrower because the icons are hidden. The icons are not needed if the text is visible, that saves me from doing png fallbacks.
Strangely, even though I added the media query polyfill, the queries don’t seem to be working in IE8. But does it matter? I think I’m OK with them always having the “words only” menu, since I expect IE8 users to be on desktops or laptops, and the layout is still fluid enough to change size if needed. So I could remove that polyfill, since it isn’t working anyway.

[PaulOB]

Strangely, even though I added the media query polyfill, the queries don’t seem to be working in IE8

The media query scripts only work when you view the page online. They don’t work on local files (unless you are running on wamp or similar).

[SamA74]

The media query scripts only work when you view the page online.

That explains it, I didn’t know that. I may remove it anyway, for the reasons above.
While I’m on the old XP machine with access to IE8, I had a look at another site on it and there is odd stuff happening, but that may be another topic.

[PaulOB]

While I’m on the old XP machine with access to IE8, I had a look at another site on it and there is odd stuff happening, but that may be another topic.

Just start a new thread.

Most of the IE8 problems are straight forward and either lack of support or various bugs.