[buddypress-trac] [BuddyPress] #2691: Default Theme - menu support

[buddypress-trac at lists.automattic.com]

#2691: Default Theme - menu support
--------------------------+--------------------------------------
  Reporter:  DJPaul       |      Owner:  DJPaul
      Type:  enhancement  |     Status:  reopened
  Priority:  normal       |  Milestone:  1.3
 Component:  Theme        |    Version:
Resolution:               |   Keywords:  has-patch, needs-testing
--------------------------+--------------------------------------

Comment (by hnla):

 @DJPaul

 Need to look at various issues arisen from the rewrite of my initial
 patch.

 The most pressing issue is that menus do work to some degree in IE6- to
 that effect these changes need to be made:

 line 217 #nav > li {

 needs to become:

 #nav li {

 new rule directly below:

 #nav li li {margin-left: 0;}

 Now at least we have correctly displayed top level li items

 The z-index I moved for a precise reason, as it is, changed to the li
 items in various places, should not be necessary for these elements,
 however what is necessary for IE6 to be able to display the dropdowns is
 that the z-index  be described for a much higher antecedent element e.g
 #header unless that upsets any other aspects of the layout ( it shouldn't
 in theory and in practice a cursory glance suggests it doesn't) i would
 add that property to  #header.

 This still leaves the issue that the use of the child combinator prevents
 IE6 displaying all but the first level dropdown, there is no particular
 fix for this other than the method I used originally but setting a depth
 of nested levels to an insane number that should never be used for reasons
 of bad site architecture - there are other possible workarounds, namely a
 specific Conditional stylesheet for IE6 but that cannot be properly
 enqueued due to requiring the CC markup wrapping the link tag, I wrote a
 simple function  for a WP install to spit out the CC markup and link tag
 to wp_head but not 100% happy that is a good approach here? The other
 approach could be to include a smallish script to fix this and other
 issues IE6/7 has - it's a classic bit of work that was used quite
 extensively:
 http://code.google.com/p/ie7-js/ Dean Edwards IE7.js

 If that was used  I would suggest perhaps a 'Content Negotiation' (mime
 type) script be used to check for browsers that couldn't accept
 'application/xhtml+xml' and only those browsers would trigger the
 add_action() (all modern browsers have been able to handle the xhtml+xml
 mime type except IE6 and earlier.

-- 
Ticket URL: <http://trac.buddypress.org/ticket/2691#comment:21>
BuddyPress <http://buddypress.org/>
BuddyPress