[buddypress-trac] [BuddyPress Trac] #6088: Twenty Fifteen pagination styles adds big black square to pagination links of all BP Directory Pages

[buddypress-trac]

#6088: Twenty Fifteen pagination styles adds big black square to pagination links
of all BP Directory Pages
---------------------------+------------------
 Reporter:  mercime        |       Owner:
     Type:  enhancement    |      Status:  new
 Priority:  normal         |   Milestone:  2.2
Component:  Template Pack  |     Version:
 Severity:  normal         |  Resolution:
 Keywords:  has-patch      |
---------------------------+------------------

Comment (by hnla):

 >we could yank the styles currently under consideration out of
 buddypress.css and into twentyfifteen.css, if people liked that idea. hnla
 and mercime - is this plan OK with you?

 I think we need to be very careful here, adding  theme specific styles to
 our generic stylesheet is not a good idea, this sheet's purpose is to deal
 with styling of BP elements not styling of BP elements to look good for a
 given theme.

 Adding styles only to then on subsequent releases attempt to extract them
 again is simply messy. If we're not sure yet about #6124 - and I can
 appreciate the sentiments expressed therein - then only approach we should
 follow ''strictly!'' in this ticket is identifying those properties that
 can and perhaps should have been added or removed.

 As an example, twentyfifteen takes the decision to style anchors with
 'border-bottom' this we could have anticipated and allowed for in our nav
 related rulesets and is a property we know we do not want declared for our
 object-nav, item-list tabs, so adding a property/value of ? `.item-list-
 tabs a {border-bottom: none;}` is something that can safely exist in our
 default styles and need not be re-visited; conversely adding a ruleset to,
 say, cover decreasing a heading size is something we should not and can
 not do in our generic styles.

 If we are adding styles then to our generic sheet we must be very careful
 to only add styles that we are ''not'' going to need to extract at a later
 date, imho.

 Long ago, lost in the mists of time when the browser war battles raged it
 came to pass that people referred to ''Hacking'' their styleseets to
 accommodate  and fix browser variances, this approach later came to be
 frowned on; the term  - used erroneously - ''hacking'' was deemed to be
 in-appropriate and in fact what people were doing was ''Filtering''
 styles, at the same time Best Practises stated that a stylesheet follow a
 number of dictates one of those being maintainability and purity of styles
 thus mixed styles where there were any number of ''hacks'' based on
 browser errors in parsing values correctly e.g the ''Star Hack''. Due to
 the inescapable fact that we had to use these the common practise was to
 include these - where possible - in separate sheets, allowing for easy
 removal when/if no longer required - that in principle then is what we
 propose in adding theme specific ''Fixes'' where we can't address them in
 the main styles as non destructive styles for all themes.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6088#comment:14>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac