CSS Framework recommendations

[Justin Obara]

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 <colinbdclark at gmail.com> 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 <obara.justin at gmail.com> 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 <jhung at ocadu.ca> 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 <michelled33 at gmail.com> 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 <jhung at ocadu.ca> 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.
>