[wp-trac] [WordPress Trac] #15851: Admin Bar Is Not Properly Reset
wp-trac at lists.automattic.com
Sat Dec 18 15:40:51 UTC 2010
#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
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
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
More information about the wp-trac