CSS dependencies for future components

CSS dependencies for future components


Most of you are likely familiar with the CSS framework generated by
ThemeRoller.
As a recap, ThemeRoller generates a number of generic classes for
interaction states, icons, and various helpers for developing
ThemeRoller-Ready components. As they stand, they serve as a pretty
extensive framework for custom component development, and we hope to
see wide adoption among plugin developers for ease of use within the
jQuery community.
Based on the work being done now by Paul with the menus, as well as
various TR-ready custom components we've made here at Filament, it is
clear that the framework is robust enough to accomplish many interface
tasks beyond UI's current widget offering. We also plan to add classes
to it to make it even more useful in the future.
One thing we aren't currently doing is using the framework within UI
itself. Every component currently has a block of styles that drive its
appearance without any dependencies. This is nice in some ways,
particularly if you are only using one UI component in a particular
application, but we've noticed that it also creates a lot of redundant
styles and code weight when you look at the CSS for all components as
generated by ThemeRoller.
A more forward-looking approach for this may be to consider the
framework classes to be a sort of "ui-core.css" dependency. I'm
confident based on having written most of the styles for the current
set of UI components that all of them can be driven by the framework
classes to cover most of their appearance. Of course, there are
portions of each widget that differ from the Framework's styles, and
that's where we can use component-scoped overrides.
This would mean that after including the core css file, a block of
styles for a particular component would mostly consist of margins,
padding, and positioning, as well as some overrides to turn off a
border here and there, or disable a background image while keeping its
background color, etc etc. Essentially, the "theme" portion would be
kept almost entirely in the framework styles, and widget-specific
classes would mostly be layout-based.
An additional change that could come of this would be more consistency
across component markup, such as using framework classes for default/
hover/active states within our components, rather than reinventing
their names for every new component. In most cases, a parent class
name on the outermost component element can be used for scoping, but
there will be custom elements within each component that retain unique
classes as well, depending on their uniqueness in UI. Just like we do
with the JS, when a number of components share a particular UI class,
we might make the decision to move that class into the core framework.
We would love to hear some discussion around this idea and would
invite everyone to become familiar with the ThemeRoller CSS framework
classes to see the current state.
You can see them at the bottom of any ThemeRoller CSS file, such as
here:
http://ui.jquery.com/applications/themeroller/css/jquery-ui-base.css.php
Also, most of the classes, but not all at this time, are documented in
this article on Filament's site:
http://www.filamentgroup.com/lab/developer_your_own_jquery_themeroller_ready_components/
Thanks!
-Scott