As a follow up, I started looking more into CSS pre-processors. Beth, one of our community members, past this along to me a while back. https://speakerdeck.com/bermonpainter/css-pre-processors-stylus-less-and-sass It provides a fairly concise comparison between Less, Sass, and Stylus.
As mentioned before, we'd probably mostly want to use these for generating the contrast themes used by the preferences framework, and any other styles than require !important injections. https://github.com/fluid-project/infusion/tree/master/src/framework/preferences/css/fss We may also find use cases within our component styling. In particular I could see this being useful for generating the style sheets needed for the icon-fonts. At this point, I'm leaning towards Stylus. It offers most if not all of the same features as Sass while also being JavaScript based. The benefit of running in JavaScript is that we are already familiar and setup to use it. There is also a grunt plugin available that doesn't require any external dependencies. On the downside, the syntax permits omitting punctuation, but this seems optional. Let me know what you think. Thanks Justin On Jul 11, 2014, at 1:05 PM, Justin Obara <[email protected]> wrote: > The Fluid Skinning System was deprecated in Infusion 1.5 and slated for > removal from Infusion 2.0. http://issues.fluidproject.org/browse/FLUID-5469 > > We found that for the most part the components weren't using FSS. The plan is > to use Foundation for demos and the like, but to keep the actual components > free from a dependence on any given framework. However, FSS also provided a > few extra handy features namely a css reset and base file, both adapted from > YUI. Foundation relies on Normalize.css, which seems to be the popular choice > for reducing browser inconsistencies. > > Another issue is the set of themes that we have. These are really only used > for the preferences framework and UI Options for the contrast themes. > However, we already have copies of these in the preference framework. Ideally > we'd replace all of these with a CSS preprocessor to construct the themes and > make it easier for a user to generate their own. > > Proposals: > > 1) I propose that we make use of Normalize.css in our components as well as > demos and etc. > > 2) I propose that we remove the themes from within the fss directory and just > keep the ones that are in the preferences framework. Later we should > re-implement the themes using a CSS preprocessor. > > Thanks > Justin
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
