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 --- Colin Clark http://fluidproject.org On 2013-07-03, at 3:08 PM, Colin Clark <[email protected]> wrote: > Hi Jon and everyone, > > On 2013-07-03, at 10:24 AM, Jonathan Hung <[email protected]> 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 >> strategy. > > 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 sign. > >> 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, somehow? > >> - 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 - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
