#3362 closed defect (bug) (fixed)
Main navigation dropdown problem in IE9 and below
Reported by: | mercime | Owned by: | |
---|---|---|---|
Milestone: | 1.5 | Priority: | normal |
Severity: | major | Version: | 1.5 |
Component: | Templates | Keywords: | dev-feedback ux-feedback |
Cc: |
Description
In IE7, dropdown for Community links does not show up. Dropdown for BP Admin Bar is OK though.@ray mentioned that dropdown does not show up in IE8 as well. http://testbp.org/groups/buddypress-testers-614548248/forum/topic/support-for-ie7
Change History (21)
#3
@
13 years ago
- Keywords reporter-feedback removed
I noticed this initially in testbp.org so to check if this was happening in my test install online, I downloaded BP 1.3 trunk-4728 and same thing happened, download does not show up in dropdown when using IE7.
Edit - Er, I meant dropdown does not show up under Community link when using IE7.
#5
@
13 years ago
- Keywords dev-feedback ux-feedback added
- Severity set to normal
The problem is #header { filter: ... } It appears that when filter or -ms-filter are set, IE overrides your implied or explicit overflow property, setting it to 'hidden'. If you remove the 'filter' declaration for #header, #header goes back to overflow: visible, and it works again.
There are a few possible solutions:
(1) Remove 'filter' and use only the CSS3 gradients. The header will be a solid color. (Or we can provide a gradient bg image, loaded conditionally on IE)
(2) Add some dummy markup. Haven't tested, but from what I've read, the following should work: a #header-outer, wrapped directly around #header, and move the #nav out of #header and into #header-outer. Leave the filter on #header for the effect, and let #nav do what it's supposed to do now that it's no longer a child of #header
(3) Leave it. Second-level menus will be inaccessible in IE
Option 3 is clearly unacceptable. Option 2 sucks, because IMO the majority of users will not be using our default CSS anyway (they'll have a child theme), so we'll be adding crappy markup just for a small subset of installs. Furthermore, from what I've read, IE9 does not have the problem, which means that the lack of gradient in IE <=8 will be increasingly less consequential as time goes on. The downside is that you'll have pretty different appearance for users of IE, but this is pretty unimportant compared to navigation and proper markup.
So that leaves option 1, in the absence of other ideas.
#7
@
13 years ago
What about introducing a stylesheet for <= IE8 which sets filter to null (or none, or whatever), and set a solid colour?
#8
@
13 years ago
Taking the filter declaration out of the main stylesheet should accomplish the same thing, since I think it's an IE-only thing. The only question would be IE9 - does it support CSS3 gradients?
#10
@
13 years ago
So then it's better to have an IE9 only stylesheet where the filter is set, I'd say?
#12
@
13 years ago
I was talking to hnla about this and he reminds to check if this is a hasLayout problem
#13
@
13 years ago
- Summary changed from Main navigation dropdown problem in IE7 and IE8 to Main navigation dropdown problem in IE9 and below
Nice investigating, Boone!
Just tested this issue in IE9 and the problem occurs there as well.
This is not a hasLayout problem, as that is true.
Option 2, while it will work, is unnecessary markup; option 3 is out of the question. So I'm for option 1 as the gradient in the header background isn't an important part of the UX.
Like Boone said, the majority of theme designers will probably create a child theme and change the background anyway. And we also offer the WP admin the option of changing the background via "Appearance > Header".
For these reasons, I would actually like to see the header background revert back to the old navy blue background (option 4). Twenty Ten and Twenty Eleven do not do anything fancy with header gradients, so why should we?
Thoughts?
#14
follow-up:
↓ 17
@
13 years ago
Why shouldn't we? I love the new blue header, and it's a key part of all the colour changes (buttons, tabs, activity stream, comments) that helps tie everything together. It's very unlikely that it will be reverted. Either way, changing the colour of the header is another ticket.
#15
@
13 years ago
I think the gradient is nice, and gives theme authors some good ideas about how to use CSS gradients. So my vote is to keep it. If it doesn't show up in lesser browsers, we can call it "progressive enhancement", which is a good thing. Just make sure it's documented somewhere, if only inline in default.css.
We should consider changing the fallback #header background color so that it's at least closer to the gradient. I think we are doing away with the overly-Facebookish dark blue.
#17
in reply to:
↑ 14
@
13 years ago
Replying to DJPaul:
It's very unlikely that it will be reverted. Either way, changing the colour of the header is another ticket.
Fair enough. New ticket created - #3377.
The problem with "progressive enhancement" is we will get support questions ;)
Let's go with PE for now and remove the "filter" declaration; this will fix this issue.
#18
@
13 years ago
DJPaul, you have an opinion on this? Is progressive enhancement an acceptable defense?
#19
@
13 years ago
I regret us not being able to give IE9 use a gradient here, but I think removing it's the best thing for now.
Was this on testbp or a local install? I know that IE9 doesn't like the menus due to some kind of conflict with bbPress on testbp.