specificity change to all plugin css files

specificity change to all plugin css files


We have a current limitation where ui.theme.css needs to precede our
plugin CSS files. This is because our plugin CSS files contain certain
styles that override style properties set in the framework classes in
ui.theme.css. Since we've written most of our plugin CSS selectors as
concisely as possible, we end up with a 1-to-1 specificity conflict
between the styles and whatever comes last in the CSS ends up being
applied.
This could be done better.
By prefacing each of our selectors with .ui-pluginname we can fix this
conflict without introducing any new bugs. This will also keep our
widget styles even more tightly scoped to a particular plugin, which
is nice even despite our already-meaningful class names.
If everyone agrees (and so far I think Richard agrees), I can make
this change to all of our plugin CSS files and moving forward this
should become our standard.
This will allow for a multitude of advantages, including being able to
pack all of our static CSS into one file and then attaching a separate
theme stylesheet for the skin. It will also mean applying a new theme
is as easy as appending it to the head, which greatly reduces the
complexity of ThemeRoller, and more importantly the ThemeRoller
switcher and developer bookmarklet.
This will also be more consistent with how people think of themes,
which are typically a layer above the structure of a widget, rather
than a core dependency.
So to repeat, every selector in a widget CSS file will be specific to
the widget's container class.
.ui-accordion-header {
becomes
.ui-accordion .ui-accordion-header {
.ui-dialog-titlebar {
becomes
.ui-dialog .ui-dialog-titlebar {
Despite the filesize addition caused by this change, we think it's a
better approach.
Agreed?