Skip to:
Content

BuddyPress.org

Opened 13 years ago

Closed 13 years ago

Last modified 8 years ago

#3362 closed defect (bug) (fixed)

Main navigation dropdown problem in IE9 and below

Reported by: mercime's profile 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)

#1 @DJPaul
13 years ago

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.

#2 @DJPaul
13 years ago

  • Keywords reporter-feedback added

#3 @mercime
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.

Last edited 13 years ago by mercime (previous) (diff)

#4 @DJPaul
13 years ago

  • Milestone changed from Awaiting Review to 1.3

#5 @boonebgorges
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.

#6 @boonebgorges
13 years ago

  • Severity changed from normal to major

#7 @DJPaul
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 @boonebgorges
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?

#9 @DJPaul
13 years ago

Nope

#10 @boonebgorges
13 years ago

So then it's better to have an IE9 only stylesheet where the filter is set, I'd say?

#11 @DJPaul
13 years ago

See #WP10618 for some smart conditional includes

#12 @DJPaul
13 years ago

I was talking to hnla about this and he reminds to check if this is a hasLayout problem

#13 @r-a-y
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?

Last edited 13 years ago by r-a-y (previous) (diff)

#14 follow-up: @DJPaul
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 @boonebgorges
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.

#16 @djpaul
13 years ago

(In [4815]) Change fallback colour of #header background to the new light blue. See #3362

#17 in reply to: ↑ 14 @r-a-y
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 @boonebgorges
13 years ago

DJPaul, you have an opinion on this? Is progressive enhancement an acceptable defense?

#19 @DJPaul
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.

#20 @djpaul
13 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [4835]) Remove filter CSS for page header gradient. Fixes issues with the nav menu in IE. Fixes #3362, props boonebgorges

#21 @DJPaul
8 years ago

  • Component changed from Appearance - Template Parts to Templates
Note: See TracTickets for help on using tickets.