Hi Justin, I have used all three pre-processors and all three of these would do what we want in terms of simplifying the building of themes. If for technical reasons Stylus is better for our workflow, then I would +1 that.
I have used Stylus and it was a good experience - even better when you add on Nib (https://visionmedia.github.io/nib/). - Jon. On Fri, Jul 11, 2014 at 2:05 PM, Justin Obara <obara.jus...@gmail.com> wrote: > 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 <http://lesscss.org/> > , Sass <http://sass-lang.com/>, and Stylus > <https://learnboost.github.io/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 > <https://www.npmjs.org/package/grunt-contrib-stylus> 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 <obara.jus...@gmail.com> 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 - fluid-work@fluidproject.org > To unsubscribe, change settings or access archives, > see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work > -- *JONATHAN HUNG* INCLUSIVE DESIGNER, IDRC *T:* 416 977 6000 x3951 *F:* 416 977 9844 *E:* jh...@ocadu.ca *OCAD UNIVERSITY* Inclusive Design Research Centre 205 Richmond Street W, Toronto, ON, M5V 1V3 www.ocadu.ca www.idrc.ocad.ca
_______________________________________________________ fluid-work mailing list - fluid-work@fluidproject.org To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
