Consolidating Fluid Skins and UI Options

[Jacob Farber]

I think this is a great dissection of the multiple directions we can
take.Option
D seems like a decent place to begin, especially if we need to
decide whether or not to use !important (as it seems to come up at every
discussion) to be extra aggressive. We already have a few working examples
of how this can play out, which could give us a head start.

This is very helpful, thanks!
Jacob



On Thu, Oct 23, 2008 at 5:00 PM, Michelle D'Souza <
michelle.dsouza at utoronto.ca> wrote:

> 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
>
>
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
>



-- 
Jacob Farber
University of Toronto - ATRC
Tel: (416) 946-3002
www.fluidproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20081023/965c727c/attachment.htm>