|Feature / Desired application||Bootstrap||Foundation|
- 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.
- 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-4698Getting issue details...
|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|| || |
- 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 many do not use mixin variables.
- For example: @btn-default-color uses a hardcoded colour hex value, and not @text-color. So if you want to change the default text colour, you will have to change the value in multiple spots.
- 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|| || |
- REM sizing may be an issue (see below)
- Namespace collisions make integrating another framework difficult
|Nice to have - tooltips|| || |
|Example implementation of Fluidproject.org design||https://github.com/acheetham/fluidproject.org/tree/FLUID-5261||https://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:
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.
Findings: REM units and Root
Issue: REM sizes may not look proper when adding styles with REM units to a document where the root element has existing font-size specified.
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.
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.
Findings: Mixing Frameworks within the same scope
Issue: Without proper namespacing of framework classnames, it is difficult to mix two frameworks in the same scope.
If the integrator wants to customize an Infusion component (which is already using a custom Foundation) using their own framework, namespace collisions may be unavoidable. Therefore Infusion's use of a CSS framework should be properly name spaced to ensure it doesn't get in the way of an integrator's customizations.