The Future of FSS

[Johnny Taylor]

Jon,

Let's try this again…

Interesting. I've been meaning to redesign my site with the intent to  explore this issue, specifically. I personally hope to forgo FSS entirely. The overhead is quite substantial -- a problem you can't avoid when developing  a CSS framework. Where is the time going?

But for my other projects using FSS/ UIO, FSSFive ideally, I'm very interested in this topic. I've found in the 3 projects I've built with FSS I spent so much time correcting styles that were declared earlier in the stylesheet. Having to do with FSS, mostly.

That said, it serves a purpose. It's pretty easy to feel comfortable working with. But I'm not sure you have to make a solution from scratch. Or ditch it entirely. It could use an overhaul, granted. 

And I'm not saying looking into Bootstrap is an unwise decision to explore -- I haven't looked into Bootstrap, I don't know anything about it -- but you run the same risk of having the same issues FSS has, no? Being style clashes. 

Or is the idea a widely used framework would have the details smoothed out a bit? Come to think about it the only clashes I had ended up being with the theme styles. This may be a moot point should you ditch FSS.

Like I said, interesting...

Johnny

On 2013-07-03, at 10:24 AM, Jonathan Hung <jhung at ocadu.ca> wrote:

> Hi everyone,
> 
> Recently Justin, Heidi, and I have been talking about FSS and we were wondering if we should continue maintaining FSS or transition to a new strategy.  
> 
> Specifically, it seems that browser standards compliance, third party CSS frameworks (like Twitter's Bootstrap), and CSS languages (like Sass/SCSS, or Less) have advanced sufficiently that it could replace FSS. However, if we make a change to using a CSS framework, this will affect other Infusion components like UI Options.
> 
> Conversely, maintaining FSS is complex due to:
> - the different theme implementations (FSS comes with 10 themes)
> - the FSS CSS itself is like the API (modifications must be done with consideration to the effect on end users)
> - lack of resources to maintain and improve it (some styling methods used in FSS seem a bit antiquated like using .PNG images to create different button borders for themes).
> 
> Also FSS doesn't seem to be used much by our components aside from FSS reset, contrast, and input sizing.
> 
> Therefore, I would like to open a discussion on the future of FSS as an Infusion Framework component given the issues with maintenance, and availability of possible alternatives. 
> 
> Do we:
> 1. maintain status quo (no changes)
> 2. explore re-implementing FSS using another framework like Bootstrap (and keep FSS classnames the same)
> 3. deprecate FSS
> 
> Options 2 and 3 will have an effect on current Infusion components which we will need to explore.
> 
> 
> Coming to some sort of decision soon will help us with current work on converting FSS' image icons into fonts, and creating contrast themes for the Discovery Tool.
> 
> Please chime in and give your thoughts.
> 
> - Jon.
> 
> -- 
> JONATHAN HUNG
> 
> INCLUSIVE DESIGNER, IDRC
>  
> T: 416 977 6000 x3951
> F: 416 977 9844
> E: jhung at 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 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/20130703/bcd8aad1/attachment.htm>