The Future of FSS
jhung at ocadu.ca
Wed Sep 18 13:11:28 UTC 2013
Thanks so much for bringing this back to the top. Glad to hear that FSS is
going to get some attention going forward.
I'd be willing to initiate / facilitate the research into 3rd party tools
if no one else steps forward. I imagine others will have input on this as
On Tue, Sep 17, 2013 at 10:57 AM, Colin Clark <colinbdclark at gmail.com>wrote:
> Hi all,
> There hasn't been any activity on this thread in two months, so I guess we
> don't have a huge wave of creative ideas for the future direction of FSS.
> We're planning to significantly refresh and simplify Infusion for version
> 2.0, which we will likely release within a year. Now seems like the time to
> start deprecating aspects of Infusion that we aren't planning to bring
> forward with us.
> Here's my proposal:
> 1. Deprecate the FSS in Infusion 1.5. We'll continue to support it fully
> until we have a viable replacement.
> 2. Start a research effort to look at third-party CSS tools, selecting one
> that we will use in UI Options as well as for our demos
> 3. Ship this new third-party tool and any additional supports needed by
> Infusion users in version 2.0
> Thoughts and comments? Is there anyone who is willing take a lead on #2?
> Colin Clark
> On 2013-07-03, at 3:08 PM, Colin Clark <colinbdclark at gmail.com> wrote:
> > Hi Jon and everyone,
> > On 2013-07-03, at 10:24 AM, Jonathan Hung <jhung at ocadu.ca> wrote:
> >> 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
> > Have you considered what the alternative strategies might look like? If
> so, could you describe them for us?
> >> 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.
> > Can you elaborate on how these different technologies might serve as a
> replacement for FSS? What roles would they play, specifically? We've got
> some very diverse tools listed here--Sass is quite different from, say,
> Bootstrap, and works at a lower infrastructural level. Can you guys
> describe how you imagine we might use these technologies?
> > Johnny Taylor seems incredibly enthusiastic about Sass, which is a good
> >> Conversely, maintaining FSS is complex due to:
> >> - the different theme implementations (FSS comes with 10 themes)
> > My impression is that most of the "demo" themes--rust, mist, etc.--are
> long overdue for being deprecated and removed. The themes used by UI
> Options, however, are foundational for doing transformation of web
> applications. Are you thinking that we'd replace these with something else,
> >> - the FSS CSS itself is like the API (modifications must be done with
> consideration to the effect on end users)
> > I'm not sure I understand what this means. Can you explain?
> >> - 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).
> > Yes, I agree. I've tried to encourage efforts to address these legacy
> weaknesses in FSS, but so far no one has been willing to take on the job.
> Given that, I'm not averse to simply choosing an existing framework
> (Bootstrap, Foundation, or one of the many, many others out there) and
> offering it up both for our own development and for our users.
> >> Do we:
> >> 1. maintain status quo (no changes)
> > I don't think this is a good idea to maintain the status quo for FSS,
> but we do need someone who wants to take on and lead a renewal effort.
> >> 2. explore re-implementing FSS using another framework like Bootstrap
> (and keep FSS classnames the same)
> > I think we will have to consider how to preserve backwards
> compatibility, especially for UI Options users who have sprinkled FSS class
> names throughout their apps. We could certainly consider streamlining the
> class naming conventions we use (they're pretty long), but I think we do
> also want to support the use case where people are mixing up framework
> classes with their own. Most CSS frameworks that I've encountered tend to
> use unprefixed names that will cause conflicts with many existing
> stylesheets, which is a shame.
> >> 3. deprecate FSS
> > Presumably we still need something to power UI Options, so I'm not sure
> if this a viable option. Or am I missing something?
> > I hope this helps,
> > Colin
> > ---
> > Colin Clark
> > http://fluidproject.org
> 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
INCLUSIVE DESIGNER, IDRC****
*T:* 416 977 6000 x3951****
*F:* 416 977 9844****
*E:* jhung at ocadu.ca****
Inclusive Design Research Centre****
205 Richmond Street W, Toronto, ON, M5V 1V3****
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work