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
