Consolidating Fluid Skins and UI Options

[Michelle D'Souza]

Hi everyone,

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.

B. CSS fragments stored in a javascript format that could be compiled  
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  
writing CSS inside javascript. This is likely too much to ask an  
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   
automating the generation of a javascript format of a style sheet.

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  
skinning system.

Thanks everyone for this awesome collaboration!

Michelle

------------------------------------------------------
Michelle D'Souza
Software Developer, Fluid Project
Adaptive Technology Resource Centre
University of Toronto