[wp-trac] [WordPress Trac] #15851: Admin Bar Is Not Properly Reset

[WordPress Trac]

#15851: Admin Bar Is Not Properly Reset
-------------------------------------+-----------------------
 Reporter:  JohnONolan               |       Owner:  ocean90
     Type:  defect (bug)             |      Status:  assigned
 Priority:  high                     |   Milestone:  3.1
Component:  UI                       |     Version:  3.1
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |
-------------------------------------+-----------------------

Comment (by filosofo):

 Replying to [comment:17 JohnONolan]:
 > Filosofo: I completely disagree. Theme authors didn't ask for an admin
 bar to get in their way, and they aren't writing CSS for the admin bar.
 They're writing CSS for their own layout, so the CSS should only affect
 their own layout. The only time a theme or plugin's CSS should affect the
 admin bar is if it's prepended with .admin-bar.

 John, I'm not sure what you're disagreeing with.  Do you really think we
 should account for every possible rule that could be applied to the admin
 bar?

 Theme developers in general are ''not'' just writing CSS for their own
 layout.  They're writing it for an unknown WordPress site, which could
 have any number of unknown possibilities added by plugins and such.  It's
 their responsibility to write themes in a manner that plays nicely with
 the multitude of ''unknown'' possibilities, and that means for CSS that it
 should be as specific as possible.

 The theme developers who are designing for a particular site (and not a
 general audience) are not as much of a concern, because they can just
 globally disable the admin bar, if that's what they want.

 > A "ridiculously bloated" CSS file is a complete overstatement - it's
 12kb vs 8kb, and is only ever going to be loaded by logged in users - size
 is not an issue.

 I'm not sure where the 12kb comes from.  No proposed patch yet resets all
 of the dozens of commonly-used CSS properties, much less every
 possibility. You've heard about `:before` today; it will be something else
 tomorrow, until we account for ''every possibility''.  I'm saying that
 such a war of attrition is pointless.  Rather, try to account for a
 reasonable number, not every possible scenario.  Surely you don't
 disagree.

 And bandwidth increase is not something to sniffed at.  It's much easier
 for a site admin to adjust her theme to fix a poor selector than try to
 redo the admin bar CSS to reduce bandwidth. Multiply a few kb by thousands
 of users on a social site (so they're usually logged in), and you're
 talking about real money, money being spent in the fear that someone might
 have a poorly-constructed CSS rule.

 > Is it neat? No. Is it necessary? In my opinion, absolutely.

 In what sense is it necessary?  By fixing the scenarios with popular
 themes, most people won't have to change anything.  And the others--well,
 they're used to making changes.  Every significant WP release has involved
 changes to theme authors' best practices.  They'll account for it easily
 enough as they always have.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/15851#comment:18>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software