[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:  closed
  Priority:  normal       |  Milestone:  1.3
 Component:  Theme        |    Version:
Resolution:  fixed        |   Keywords:  has-patch, needs-testing
--------------------------+--------------------------------------

Comment (by hnla):

 Paul the issue of the off screen items is simply now shifted the other
 way!
 ''I don't like the idea that people couldn't use nested menu options on
 the right-most item''

 My test case is set up with a variety of nested pages to different depths
 on various top level nav links, my about page defaulted to being second
 from left, it has 5 levels nested items these now are lost off the left
 hand edge of the viewport!

 We needed to discuss this really before committing, my reference to being
 damned if we do damned if we don't was in reference to the fact that there
 is no real solution, I further go on to make the point that to a degree
 the site admin/owner must make a few decisions *gasp* on where they
 position links.

 I was intending on adding a second patch to limit the depth on the menus -
 despite my stated reservations to following that course of action - As you
 say 'edge case' and I mention structuring any site to have nested greater
 than 5 deep starts to become bad site design.

 I spent a while ensuring that the menus did actually function - albeit
 with semi reduced frills - in IE6 hence the z-index you probably moved due
 to puzzling why I had moved it in first place, there was also a very
 deliberate avoidance of the use of the child selector other than for
 cosmetic and unimportant decoration; sadly now the dropdowns are simply
 broken badly, I can see absolutely no virtue in that (It's not a valid
 argument that BP doesn't support IE6 - I would agree that it makes no
 effort for a full experience but basic functionality should work) However
 I agree that this is probably a moot point and I won't raise the issue of
 IE6 further.

 There is a reason that one can't actually use right:-9999em; in the way it
 has been. Using this property with this value in this manner requires that
 there is a contrary screen direction. You might find it simpler to simply
 go with the display:none; route and suffer the likes of me that will spit
 fury over it's use and issues it causes :)

 There are some further additions that I curious about, attempting to apply
 various positioning aspects, some of these have issues, the obvious one
 being line wraps - create a link title longer than the width.

 Given that the reasoning behind shifting from right flyout to left is a
 flawed one and that we cannot ever know or predict how users arrange their
 menu items it is probably best to move back to right flyout, also another
 consideration is that left flyout like form element layout could be argued
 to fall under HCI precepts; left flyout is fundamentally awkward for the
 brain to track unless one has reversed screen direction for rtl human
 readers.

 I added styling hooks (for someone to improve on) keeping the alpha
 transparency of the original background graphic that existed but changing
 background on hover and text colour and linking that back up the nodes
 highlighting the antecedent elements, thought that was reasonably
 effective albeit requiring perhaps better colour choices?

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