The Future of FSS
johnny at abledaccess.com
Wed Jul 3 18:25:27 UTC 2013
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...
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
> 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...
More information about the fluid-work