Great! This is work for Infusion 2.0, which we don't have a formal date for yet. The plan is to release 1.5 (the last of the 1.x line) in the next couple of months. From there, we'll likely release a couple of 2.0 beta releases before cutting 2.0 final sometime in the next year.
So we've got lots of time. :) Colin --- Colin Clark http://fluidproject.org On 2013-09-18, at 10:06 AM, Johnny Taylor <[email protected]> wrote: > 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
