[buddypress-trac] [BuddyPress] #4953: BuddyPress specific UI refresh

buddypress-trac noreply at wordpress.org
Sat Apr 27 13:01:22 UTC 2013


#4953: BuddyPress specific UI refresh
-------------------------+------------------
 Reporter:  karmatosed   |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  1.8
Component:  UX/UI        |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+------------------

Comment (by hnla):

 @ubernaut not sure what 'universally recognize' means essentially bp
 legacy or packs must be careful not to impose any styles that aren't
 positional, structural or of a necessary nature for the rendering of the
 element dtheming in this scenario simply means running through the
 rulesets identifying properties such as background/gradients and removing
 but equally looking at BP specific unique ui aspects and updating the
 styles where they would benefit and didn't cause a clash with unknown
 themes styles ( the difficult aspect) There is a pseudo namespace token in
 the form of #buddypress that acts as the primary top level ancestral
 elements token so all bp elements fall under that element.


 > Making sure fonts and font sizes come from theme (px to rem would also
 be good)

 Perhaps the hardest aspect, any set font-size needs to be a relative
 measure unless one dictates that e.g activity timestamps need to be
 'small' and set fixed pixel size (we haven't a clue what a rem value might
 actually end up being) testing how the use of keywords fairs might be
 worthwhile (historically terrible x browser and generally problematic) At
 the end of the day and as much as one wants to manage sizing on aspects we
 know must be smaller/larger it may be safest and most practical to leave
 font properties out altogether.

 There is an issue as I see it but may stand to be corrected; with the
 legacy template files having got out in the wild any changes made to
 template markup and or styles could impact sites based on modifications of
 those, or is there a mechanism proposed that switches  i.e not been aware
 of this 'plugin' aspect for packs or how that work, select plugin pack one
 wants and activate?

 On a sidenote but related I have almost finished re-factoring the
 /members/single/*.* templates to use the newer bp_nav_menu() and removing
 the bp_get_options_nav() altogether from sub templates along with a set of
 styles to provide basic structuring of a true nested menu ul structure to
 mimic what visually rendered in existing screens. It has a enqueue
 function for the styles and was intended as a drop in to themes pro tem,
 but may be worth gutting and introducing so that we make use of
 bp_nav_menu() moving forward.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4953#comment:2>
BuddyPress <http://buddypress.org/>
BuddyPress


More information about the buddypress-trac mailing list