Hey, I'd like to get in on this, too. But I haven't a lot of time to dedicate to much extra-cirriculuar activities at the moment. What kind of timeline were you looking at?
Johnny On 2013-09-18, at 9:54 AM, Colin Clark <[email protected]> wrote: > Hi Jon, > > Thanks! That's awesome. It'll be a fun project. > > Colin > > --- > Colin Clark > http://fluidproject.org > > On 2013-09-18, at 9:11 AM, Jonathan Hung <[email protected]> wrote: > >> Hi Colin, >> >> 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 well. >> >> - Jon. >> >> >> >> On Tue, Sep 17, 2013 at 10:57 AM, Colin Clark <[email protected]> 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 >> >> --- >> 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 >> >> >> >> -- >> JONATHAN HUNG >> >> INCLUSIVE DESIGNER, IDRC >> >> T: 416 977 6000 x3951 >> F: 416 977 9844 >> E: [email protected] >> >> 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 - [email protected] > To unsubscribe, change settings or access archives, > see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
