Hi Colin, Actually I was suggesting that we may not use the CSS Framework for the Preferences Frameworks contrast themes either. Instead we'd provide a SASS or Less file and some pre-generated versions all based off of custom styles. This will allow it to be focused on Contrast (not general site theming), extensible to different contrast themes that the integrator may want, and also work across a broader range of sites (not just those already using a specific CSS Framework). Although we may want to include extension(s) that work with CSS framework(s) to better cover those cases as well.
You are right though, from my standpoint this is largely theoretical and could use more detailed exploration. Thanks Justin On Mar 26, 2014, at 11:32 PM, Colin Clark <[email protected]> wrote: > Hey guys, > > I generally feel good about the decision to go with Foundation. I’d like to > learn more about how exactly we’ll tackle this point that Justin makes about > the stylesheets we use in the Preferences Framework for high contrast and so > on. Has anyone looked into this in any detail yet? That might be a good last > bit of research to do, just to plan out what it might look like. > > I was worried about the issue of Foundation not allowing us to scope class > names and thus not being suitable for use by the components, but then I > remembered that the FSS was never really broadly used by our components > either. We found, I think, that their styling requirements were already > pretty focused and unique to each one. There was a JIRA filed about making a > common style guide for the components, but interestingly not much discussion > of practical opportunities for the FSS except in the Reorderer: > > http://issues.fluidproject.org/browse/FLUID-4910 > > So I think this, along with our busy to do list for Infusion towards 2.0, > motivates us to no worry too much about how Foundation and the components > will interact at a deeper level than ensuring that they don't bother each > other. It sounds like our decision to use Foundation largely covers two use > cases: > > 1. The Preferences Framework themes (high and low contrast, etc.) > 2. Our own website design/development activities > > Does this seem reasonable, or am I missing other details or crucial points? > > Colin > > > On Mar 26, 2014, at 10:48 AM, Justin Obara <[email protected]> wrote: > >> Currently we primarily use the FSS themes for contrast in the Preferences >> Framework. I'd like to suggest that we move away from these as general >> themes and keep them focused on their use by the Preferences Framework. To >> that end, I think we may not use a framework for them, but instead provide a >> (SASS and/or Less) file and some pre-generated contrast themes for >> integrators to use. >> >> Thanks >> Justin >> >> On Mar 26, 2014, at 9:26 AM, Jonathan Hung <[email protected]> wrote: >> >>> Hi Michelle, >>> >>> It would be possible to use a CSS framework to replace most of FSS (i.e. a >>> CSS framework can replace FSS linearization and layout). One sticking point >>> may be theming since generating themes for a framework is not straight >>> forward. >>> >>> Essentially we will need to identify all the relevant CSS rules in the >>> framework and replace the values with our own. There may be an programmatic >>> way to do this, but from what I've seen this will largely be a manual >>> process since each change needs to be visually verified. >>> >>> Also, when there are updates to the framework, we would have to account for >>> any changes to the themes. This creates a maintenance burden. Currently >>> Zurb updates Foundation roughly once a month (reference: Foundation >>> changelog) and we would monitor the _settings.scss file for changes. We can >>> probably expect this pace going forward since this space changes so rapidly. >>> >>> However this may present an interesting opportunity to contribute to the >>> CSS framework community by providing methods for generating inclusive >>> themes. >>> >>> I've singled out theming as a possible issue, but there may be other issues >>> as well. I think this would require a more detailed investigation. >>> >>> - Jon. >>> >>> >>> >>> On Tue, Mar 25, 2014 at 10:16 AM, Michelle D'Souza <[email protected]> >>> wrote: >>> Thanks for sending this, Jon. I really like the detailed chart that was >>> made prior to the recommendation. >>> >>> Can you please clarify for me what the recommendation is for Infusion in >>> terms of getting rid of FSS? >>> >>> Thanks, >>> >>> Michelle >>> >>> >>> >>> >>> >>> On 2014-03-25, at 9:59 AM, Jonathan Hung <[email protected]> wrote: >>> >>>> Hi everyone, >>>> >>>> After some time doing research into the utility of 3rd party CSS >>>> frameworks to be used for Fluid, the following is the proposed >>>> recommendation: >>>> >>>> - CSS framework is not recommended for Fluid components at this time >>>> primarily due to the lack of custom name spacing. Without proper name >>>> spacing, there is a chance that there will be classname collisions which >>>> will make it difficult to integrate Fluid components. >>>> >>>> - CSS framework is fine to be used for websites, demos, and other >>>> integration / non-component scenarios. >>>> >>>> - Zurb Foundation is the suggested framework to be used. >>>> >>>> - Continue using default styles in Fluid components and leave it to the >>>> integrator to customize with their own CSS framework if they choose to. >>>> >>>> - There may be an opportunity to add new features to Learner Preferences >>>> that can transform CSS framework components (like navigation bars and >>>> button links). Further discussion is encouraged. >>>> >>>> For more details, please refer to this document on the Fluid wiki: >>>> http://wiki.fluidproject.org/display/fluid/Fluid+Project+Support+for+CSS+Frameworks >>>> >>>> >>>> Please feel free to comment and ask questions. >>>> >>>> Thanks! >>>> >>>> - Jon. >>>> >>>> PS. Thanks to Johnny and Anastasia for helping out with the research. > _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
