Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Overview

Fluid Project has adopted the following recommendation for using CSS Frameworks:

ReccomendationApplication: Infusion ComponentsApplication: Integration
Use CSS framework(minus) No(tick) Yes
Use own / default styles(tick) Yes(tick) Yes*
Recommended framework Zurb Foundation
Use CSS framework with contrast themes(minus) No(question) Maybe*

*see notes below

For Fluid Infusion Components: 

  • 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.
  • Continue using default styles in Fluid components

    Summary and Background

    Up to version 1.5, Infusion shipped with a built-in CSS framework called the Fluid Skinning System. When the FSS was first designed, there were few viable production-scale CSS frameworks available to developers. As a community, we felt a need to provide something that had been designed with accessibility and flexibility in mind. Since then, we've experienced a massive shift in the way websites are designed and implemented. Responsive Web Design is now widely practiced, enabling web pages to adapt to different screen sizes and device form factors. CSS preprocessors such as Less and Sass have changed the way style sheets are developed and reused. Mature and widely-used CSS frameworks such as Bootstrap and Foundation are available to help ease the effort of styling responsive layouts, grids, and widgets.

    Unfortunately, the Fluid Skinning System hasn't kept pace. As a result, we chose to deprecate it in version 1.5. We recommend that users of Infusion choose from any of the available third-party frameworks based on their own needs and requirements. As of Infusion 2.0, we will remove FSS entirely.

    Infusion components currently don't rely on any CSS framework, and we will continue to ensure that they are styled in a way that is unlikely to conflict with popular tools like Bootstrap and Foundation. For the foreseeable future, we don't plan to include any third-party CSS framework with Infusion, nor to require that our users select a specific framework.

    Who is this document for?

    This document reflects the decision-making process we have undertaken as a community to select a CSS framework for some of our own websites, documentation, and demos. It may also be useful when selecting your own CSS framework to use alongside Infusion.

    Recommendation Summary

    Fluid Infusion components do not use a CSS framework out of the box. The motivation for this is to ensure Infusion components play nicely in whatever application is used. Integrators may choose to add their own CSS framework to Infusion components if they wish.

    Using a CSS Framework within an Infusion component

    • Components shipped as part of the core Infusion package do not use a CSS framework for their styling.
       
    • Some CSS frameworks don't use namespaced or prefixed class names, which creates the possibility of collisions that can cause styling problems. Infusion component styles are always namespaced, which reduces the potential for Infusion to cause conflicts with non-namespaced frameworks. See Infusion Class Name Conventions for more information.
    • Because Infusion components do not use a CSS framework by default, component creators will need to create good default styles and leave it to the integrator to customize with their own CSS framework if they choose to.We will not create contrast themes for CSS frameworks. Creating a theme is non-trivial (lots of values to adapt) and s high maintenance (each major or minor release will need to be tested - occurs roughly once a month).

    For websites, demos, etc.

    Using a CSS Framework within Fluid-related demos, websites, etc.

    • A CSS framework is fine to be used for websites, demos, and other integration / non-component scenarios.

    Recommended CSS framework:

    • Zurb Foundation is the recommended CSS framework to be used We recommend Foundation because of its use of REM sizing throughout.
    Future possibilities:

    Using a CSS Framework for contrast themes in UI Options and the Preferences Framework

    • At this time it is difficult to create contrast themes for CSS frameworks despite the availability of custom builders. Custom builders may not be an appropriate tool as they do not cover all possible styling rules we want to affect.
    • Creating a theme manually is non-trivial (lots of values to adapt)
    • Themes would have to be tested with each major and minor framework release to ensure compatibility. This adds a maintenance burden.

    Future possibilities

    • 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.
    • Contrast theme generation using a CSS pre-processor to be investigated. Possible pre-processors include: Less, SASS, and Stylus. This will be a separate discussion.

    Findings

    Recommendation

    • (error) Do not use a CSS framework for components. For more details see "CSS framework for components" below.
    • (tick) Recommend the use of CSS framework for websites, demos, and other integration situations
    • (tick) Foundation is the recommended CSS framework primarily because:
      • it uses REMs as units instead of PX.
      • has a more usable grid system - it's fluid width and has a cleaner structure which makes integration and customization easier.
      • it is light weight.

    CSS framework for components

  • It will be difficult to use a framework for styling purposes in an Infusion component because of the lack of name spacing. Without a good way to namespace Infusion's use of a framework, there is a significant chance that Infusion framework styles will collide with integrator's existing styling.
  • Assuming we can name space Infusion's use of a CSS framework in a component:
  • (question) The integrator may wish to override our default styling. In this case, would it be better to not have an Infusion CSS framework and use some default styles instead? This may make it easier for an integrator who desires to customize heavily.
  • (question)The integrator may wish to use our default styling. In this case the integrator is looking for the quickest and easiest way to use an Infusion component.
  • Considering the two questions above - would using a CSS framework bring added value in this case?

    Other interesting notes:

    • Common CSS framework features (such as navigation bars, link buttons, progress bars, breadcrumbs) can lead to some new Learner Preferences transformations. Also see "Possible new Learner Prefs transformations with CSS Framework" in the Criteria Evaluation table in the next section. 
      • It is conceivable that Learner Preferences need not adopt a CSS framework, but instead rely on the integrator to supply an adapter that links Learner Preferences to specific CSS classes. 
      • For example, Learner Prefs has a new feature which transforms navigation bars into vertical lists. The integrator writes an adapter that tells Learner Prefs which classes in their website correspond to navigation bars.

    Criteria Evaluation

     

    Feature / Desired applicationBootstrapFoundationResponsive layouts
    • Bootstrap uses fixed width containers that "snap" across breakpoints
    • Grid layout needs to follow a container-row-column hierarchy. Otherwise 15px paddings / margins don't align properly.
    • Foundation uses fluid width containers that stretch and shrink depending on the size of the client, with relevant breakpoints.
    • Foundation has a row-column hierarchy with paddings on the columns only. Row is only for containment.
    Style reset
    • normalize.css is included in default package, but optional whether or not it is used in your markup.
    Units in EMs

    Current release (v3) uses pixels and not EMs. However, v4 (unreleased) will support EMs. See Mark Otto's January 9th response in this thread on Github.

    • Note: EMs will be supported. Unclear if REMs will be used.
    • UIO works well with Bootstrap's pixel units, although EMs are more desirable.
    Foundation 5 uses REM units throughout. The exception being media queries which use EM units.
    • REMs are desirable and easier to use for CSS styling than EM because REMs always refer to the root EM and not the parent EM as with EM units.
    • REM units currently do not scale properly in UI Options. See
      Jira
      serverFluid Project Issue Tracker
      keyFLUID-4698
    Ease of using default styles in a heavily customized application
    • +/-15px margin and padding on container, rows, and columns dictate a hierarchy and usage pattern. Customizing this or deviating from this pattern causes unintentional and unwanted alignment issues which can be hard to correct (involves overriding).
    • This hierarchy is required to ensure good scalable layouts.
    • Working with Foundation within a heavily customized application seemed very straight forward. Some styles needed to be overridden, but that was expected.
    • Foundation button has !important for font weight
    Use of !important
    • important used for print media styling, visibility of collapsing navbar, and visible and hidden elements.
    • no use of !important on html elements
  • Important primarily used to position starting and ending Foundation classes such as offsets, start and end of navigation containers, hide/show elements (i.e. "hide-for-large"), and custom components (like Joyride widget).
  • Uses of !important on html elements
  • button: font-weight: normal !important;
  • select: webkit - appearance: none !important;
    Namespacing framework classnames
    • Bootstrap uses generic classnames which may cause classname collisions.
    • A work-around is to use LESS or Sass to add a named container. See this as a possible solution: https://coderwall.com/p/uiwcow
  • ZURB intends to add namespace support but not clear when that will be. (see https://github.com/zurb/foundation/issues/546)
  • Sass has / plans to add namespace support (http://thechangelog.com/namespace-support-is-being-added-to-sass/)

    UIO Theme generation

    • Themes can be created using the online tool but it is not a quick process and error prone: http://getbootstrap.com/customize/
    • Themes can also be created by modifying the variables.less file
    • There are a lot of variables to configure, experimentation will be needed to determine the effect of each variable and which variables should be modified for a theme.
    • Background colour can not be changed using the online customization tool: http://foundation.zurb.com/develop/download.html#customizeFoundation
    • Themes can be created by modifying the _settings.scss file
    • There are a lot of variables to configure, experimentation will be needed to determine the effect of each variable and which variables should be modified for a theme.
    Possible new Learner Prefs transformations with CSS FrameworkBootstrap components can be turned into a Learner Preference

    Appropriate Use of a CSS Framework

    Example: Metadata component

    Choosing a CSS Framework: Why Zurb Foundation?

    In deciding which framework to recommend for the Fluid project, many criteria were considered including: documentation, community support, accessibility, and scalability.

    After researching and comparing 6 different CSS frameworks, Zurb Foundation is the recommended framework for the following reasons:

    • Foundation uses REMs as units which ensures scalability across clients and devices.
    • Foundation's grid system is flexible - it's fluid width and has a cleaner structure which makes integration and customization easier.
    • We typically work in highly customized environments and Foundation is light weight and doesn't get in the way (mostly).

    Can I use a different framework?

    Yes, you can use any framework you prefer. For Fluid-related websites and demos, we prefer frameworks that are:

    • Accessible and scalable
    • Mature and widely supported
    • Open source

    Future Considerations

    Better namespacing

    • At this time it is very difficult to namespace CSS framework classes. Most solutions are a manual process, or a manual process that is automated by a script. This is fragile and requires constant testing with each new framework release.
    • If a CSS framework or tool emerges to support custom name spacing easily, and satisfies our needs (i.e. scalable, accessible, widely supported, etc.) - we should revisit the topic of using a framework for Infusion components.

    Add CSS framework support to the Preferences Framework

    • Since CSS frameworks share common features (such as navigation bars, link buttons, progress bars, breadcrumbs), this can lead to some new preferences.
    • For example:
      • Linearize / stack content by changing the grid layout
      • Navigation bar preferences: make tabs look like pills, make navigation pills stack
      • Pager: size, appearance, spacing
      • Alerts: change the way alerts are positioned or styled (i.e. make them bigger, put them in a floating panel etc.)
    Hide / show screenreader-only content (elements with "sr-only" class).
    • Like Bootstrap, Foundation features can be turned into Learner Preferences
    • For example:
      • Linearize / stack content by changing grid layout
      • Reposition side navigation
      • Turn sub-nav (frequently used for filtering lists) from horizontal list into a drop-down menu.
      • Change the way link-buttons (links that look like buttons) appear
      • Make progress bars bigger and appear in different colours.
    Example implementation of Fluidproject.org designhttps://github.com/acheetham/fluidproject.org/tree/FLUID-5261https://github.com/jhung/fluidproject.org/tree/FLUID-5262

     

    Issue: REM sizes may not behave as intended if the root element has existing font-size

    Description:

    It is possible that the document in which an Infusion component is being added to already have a root font-size specified. In which case any REM sizes used in the Infusion component will size itself relative to that existing root font-size. If the font-size is not an expected value, the Infusion component may not look as expected.

    Example:

    Bootstrap specifies font-size: 62.5% on the HTML element, and a font-size: 14px to the Body element. Adding an Infusion component (which is using Foundation) with a font-size: 1rem to this document would have the Infusion component appear smaller since 1rem is relative to the 62.5% font-size value on the HTML element.

    Conclusion:

    This issue would occur if using Foundation in a Infusion component. To avoid this problem, Infusion's use of CSS framework should have a name space.

    Issue: Without proper name spacing, it is difficult to mix two frameworks

    Description:

    If the integrator wants to customize an Infusion component using their own framework, style collisions may be unavoidable due to the use of generic classnames (like "row") or conflicting styles on HTML level elements (like "h1"). Therefore if Infusion's uses a CSS framework, it should be properly name spaced to ensure it doesn't get in the way of an integrator's customizations.

    Discussion:

    Conclusion:

    At this time, name spacing a CSS framework is not feasible. The common approach is to use a post processor (like Python) to add name space information, but this approach is fragile since new versions of the CSS framework may break the script.

     

    Appendix: Use Case Exploration

    Info
    On February 26, 2014, there was a Fluid community workshop which explored the scenario where an integrator tried adding Bootstrap to a page with Foundation, and vice versa. The following outlines the goals. The outcomes from this workshop helped generate knowledge which went into the research contained in this document.

    There are currently some unresolved user questions:

    • What if a Fluid component is using a particular framework in its implementation, what are the consequences for an integrator?
    • An integrator is using an existing framework, what happens if the Fluid component is using the same or different framework?
    • In the case of the same framework, the component may be using a custom build or custom framework styles (over-ridden in css file) - what happens in this framework-framework interaction?

    To explore answers to these questions, the following 4 use cases are possible:

    • Integrator is not using any framework but chooses to use our component.
    • Integrator adopts and uses the framework used by our component.
    • Integrator is using the same framework as our component, but with different customizations (essentially two versions of the same framework exists on the same page).
    • Integrator is using a different framework than the one used by our component.

    To attempt to figure out the consequences of use cases 3 and 4, a custom version of Foundation (linked below) was created that is scoped to a mock Infusion component with the classname ".inf-foundation" on the container. 

    • Customized Foundation: Namespaced to .inf-foundation, headings pink: app-pink.css (customized Foundation with pink header text colour)
    • Customized Foundation: Namespaced to .inf-foundation, headings blue: app-blue.css (customized Foundation with blue header text colour)

     

    Table of Contents

    Table of Contents

    • In order to support multiple CSS frameworks, consider using an adapter model where the Preferences framework supports a generic definition and adapters are created to map CSS framework definitions to the framework. i.e. Framework 1 may use divs for breadcrumbs, and Framework 2 may use a list. The adapter would define this configuration so that the framework can use both.

     

     

    Table of Contents

    Table of Contents
    excludeTable of Contents