Consolidating Fluid Skins and UI Options
michelle.dsouza at utoronto.ca
Thu Oct 23 21:00:41 UTC 2008
Fluid 0.6 beta will be shipping with a skinning system and 0.6 final
will contain a UI Options component. The UI Options component allows
users to customize their display including, but not limited to,
styling options. Clearly there is much overlap in these areas. After
several conversation with several people, I'd like to sum up the
current styling strategy for UI Options.
In looking at strategies, we took the following into consideration:
1. simplicity for integrators
2. minimizing the duplication of effort and maintenance
3. the effect of specificity and precedence when using CSS
4. CSS best practices
5. delivering iteratively
One of the issues we discussed was the structure of our CSS and how it
would be used. The four options we talked about follow.
A. Separate CSS files for each skin plus CSS files for the part of
each skin not covered by the choices in UI Options and separate CSS
files for each possible choice in UI Options. The integrator would use
the CSS classes required for the skinning system to style the page and
the small CSS files would override these styles where required. This
strategy would mean a lot of duplication of CSS and therefore a
maintenance burden for us. Duplication of effort would also be
required by the integrator if they wanted to add their own skin.
into style-sheets as required. This gives us good control over styling
since we could use strategies such as id based styles which have
greater precedence then classes. The draw back is the unnatural way of
integrator to do when writing their own skin.
C. CSS files for each skin and some automated way to build B. This
would again give us great control and it allows for the creation of
CSS in a natural way. The draw back is the time required for
D. Separate CSS files for the part of each skin that is not covered by
the choices in UI Options plus separate files for each UI Options
choice. Each of the CSS files would have its own class namespace. The
integrator would need to specify several class names in their markup.
The strategy for restyling based on preferences would require removing
existing class names and adding a few classes to the body.
It seems that the ideal strategy is 'C' where we have great control as
well as a natural workflow and no duplication of effort. This is could
be where we are headed, however in order to deliver something useful
in the 0.6 timeframe, it is necessary that we take a smaller step
first. I think that 'D' is our best first step. We don't have
duplication of effort here but rather a few more styles that would
need to be specified when creating markup that will be styled by the
Thanks everyone for this awesome collaboration!
Software Developer, Fluid Project
Adaptive Technology Resource Centre
University of Toronto
More information about the fluid-work