Removing FSS from Infusion

Tue Oct 21 19:56:44 UTC 2014

Hi everyone,

The exciting news is the pull requests to resolve FLUID-5469<http://issues.fluidproject.org/browse/FLUID-5469> that removes FSS from infusion, and FLUID-5482<http://issues.fluidproject.org/browse/FLUID-5482> to use Stylus to generate css for preferences framework, have been merged into the project repo.

That means, to work with the latest infusion preferences framework, you need to run a grunt task to compile stylus files into css. This compilation only needs to run once:

grunt buildStylus

Have fun

Cindy

On Jul 25, 2014, at 9:27 AM, Justin Obara <obara.justin at gmail.com<mailto:obara.justin at gmail.com>> wrote:

It's been a couple of weeks since I sent out my proposals regarding FSS. I haven't heard any negative responses, which I'll take as confirmation to go forward.

In Summary:

http://issues.fluidproject.org/browse/FLUID-5469
We'll remove FSS from the repository. We'll add the latest version of Foundation<http://foundation.zurb.com/>, as the CSS framework of choice for demos and examples. All components will remain framework independent. However, we will use normalize.css<http://necolas.github.io/normalize.css/> to provide a common starting point for styling. Normalize.css can be used in all locations, components, demos, examples, and etc.

http://issues.fluidproject.org/browse/FLUID-5482
For contrast themes, and anywhere else that it makes sense, we will start using the Stylus<http://learnboost.github.io/stylus/> css-preprocessor. This will allow us to generate the themes and other complex css files much easier.

Thanks
Justin

On Jul 14, 2014, at 2:11 PM, Jonathan Hung <jhung at ocadu.ca<mailto:jhung at ocadu.ca>> wrote:

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.justin at gmail.com<mailto:obara.justin at 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.justin at gmail.com<mailto:obara.justin at 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 at fluidproject.org<mailto:fluid-work at 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: jhung at ocadu.ca<mailto:jhung at ocadu.ca>

OCAD UNIVERSITY
Inclusive Design Research Centre
205 Richmond Street W, Toronto, ON, M5V 1V3

www.ocadu.ca<http://www.ocadu.ca/>
www.idrc.ocad.ca<http://www.idrc.ocad.ca/>

_______________________________________________________
fluid-work mailing list - fluid-work at fluidproject.org<mailto:fluid-work at fluidproject.org>
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20141021/e6f3666d/attachment.htm>