Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 80 Next »

Overview

Fluid Project is evaluating CSS Frameworks as a possible tool:

  • for implementing project websites, and component demos
  • to integrate in components themselves to bring additional features

After a research and evaluation period (see: CSS Framework Research Notes), Foundation and Bootstrap have emerged to be the front runners. This attempts to document in detail the requirements of the framework to be used.

Criteria Evaluation


 

Feature / Desired applicationBootstrapFoundation
Responsive 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 FLUID-4698 - Getting issue details... STATUS
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
 
UIO Theme generation using default build  

UIO Theme generation - can it be done using the framework's customization tool? 

  • Yes, it is possible to create a theme using the online tool but it is not a quick process and error prone: http://getbootstrap.com/customize/
  • There are many variables to adjust and most do not use mixin variables.
  • For example: @btn-default-color uses a hardcoded colour hex value, and not @text-color.
  • It is possible for a theme creator to miss setting a value and the theme to appear incorrectly.
  • Customizations are not saved, so if you want to go back an edit a theme, you will have to start from scratch.
UIO Theme generation using preprocessor  
Effects of custom Bootstrap build with default Bootstrap

 

N/A
Effects of custom Bootstrap build with default Foundation  
Effects of custom Foundation build with default FoundationN/A 
Effects of custom Foundation build with default Bootstrap  
Nice to have - tooltips  
Example implementation of Fluidproject.org designhttps://github.com/acheetham/fluidproject.org/tree/FLUID-5261https://github.com/jhung/fluidproject.org/tree/FLUID-5262

 

Use Case Exploration

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:

  1. Integrator is not using any framework but chooses to use our component.
  2. Integrator adopts and uses the framework used by our component.
  3. 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).
  4. 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 was created that is scoped to a unique classname called ".inf-foundation". The idea is to mimic the scenario where our component, contained in an element with the classname "inf-infusion", is being added to an existing application one with Bootstrap, and another with Foundation. 

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

 

  • No labels