Skip to content
This repository was archived by the owner on Nov 9, 2022. It is now read-only.

Components

Jump to bottom
loganfranken edited this page Jul 26, 2012 · 48 revisions

This page serves as a place where we will start brainstorming a list of "components" for the framework.

Useful Tools

CSS Tools

Browser Normalization

Each browser has a "user agent stylesheet". To ensure that all users get the same experience, these must be normalized. One example of this is the CSS "reset" and another goes a step further and actually builds a base among compliant browsers. Eric Meyer and YUI both created resets, and YUI also provides a base, as does Normalize.css.

Grid System

While a trend has arisen towards "grid-less" CSS, the reality of today's world is that designers still think in grids. Consequently, it still makes sense to provide a layout grid, even if we also have alternatives that do not use the grid-based approach. A discussion of some of these frameworks already exists in [Research: Models, Frameworks & Tools], and it should continue there - this is just a list of them.

Some frameworks focused solely on grids:

Some other frameworks that include grids:

Although there are a lot of grids, let's not forget the gridless approach as well:

Javascript Libraries

Device Capabilities

Two approaches exist for device telemetry: metadata-based with user agent sniffing and dynamic detection. The former is generally used in cases when the user needs telemetry server-side, whereas the latter provides greater details and at less headache as a metadata file doesn't have to be maintained - however, the latter is much harder to exfiltrate server-side. Because so many components here are client-side, namely using media queries for CSS and otherwise Javascript, the dynamic detection approach works just fine, and Modernizr seems a standout in this arena.

However, there is at least one component that needs server-side knowledge: image compression. While not everyone will use it, optimized images are a critical part of a well-performing responsive site, so we want to make sure we're serving optimally-sized images. This compression is only useful when one can get capability data back to the server reliable. However, that doesn't mean a metadata-based approach is required. Because of issues with such an approach, the UCLA Mobile Web Framework introduced a technique for offloading information determined client-side back server-side reliably, and thus it makes sense to go beyond basic Modernizr and use the MWF Device Telemetry Stack (which uses Modernizr for a lot of the capability sniffing).

Media Queries

Not all browsers (most notably IE < 9) support media queries.

As such, one route is to use a polyfill to "add" media query support to these browsers:

Another option is use Javascript to make the substitution, notably done in Adapt.js:

The question here is strategy - if we don't like the tools themselves, rolling out own version of either isn't that challenging, but the question is whether we use Javascript or standard media query or we leave it up to the user possibly.

HTML 5 and CSS 3 Polyfills

HTML 5 elements defined in all browsers (makes sense for the elements that are ''only'' semantic):

CSS3 selectors for IE 8:

Here's an immense list of polyfills for HTML 5 technologies (some mentioned explicitly above):

Media

Dynamic Image Compression

While max-width prevents the presentation of images from looking bad on small screens, it doesn't solve the resolution issue. Instead, this needs to be accomplished through some form of compression. The Mobile Web Framework includes an image compressor, but it's currently non-optimal (caching and general efficiency) and discussions are underway on how to improve it, either selecting an existing compression tool or writing a new one.

Two options should be given to someone running this framework:

  1. Compress at a certain set of fixed sizes (keeps the cache small and processing low)
  2. Compress to the ideal size based on telemetry (larger cache and more processing)

A few tools exist that tackle this problem:

The interface for end users to implement compression should also be as simple as possible. If they lay in regular images, maybe Javascript transmutes it. However, this has performance issues. Another option would be to provide a class that they assign to images that they want to make responsive - this allows a library to more quickly make the transformations where needed and not waste time where not needed (see the next section on "Image Substitution" as well).

Image Substitution

If this framework is to be used in content management systems where images are inserted without control over their tag style, then we need a solution for seamless substitution of an optimal version of the image.

Several options exist:

  1. Modify each CMS to pass images through the image compressor
  2. Write a Javascript library that substitutes the file with one that passes through the compressor
  3. Modify the CMS to actually fetch images, crop them into particular sizes, and then use a polyfill (see below) to lay in multiple versions with either img[set] or picture

The reality here is that one size does not fit all. Some users may be content to just let their content go off to some other server to be compressed, but in some cases that may be non-viable. Therefore, I'd anticipate that both of the latter options should be implemented. That way we have a Javascript-based solution, but also a method for making static crops directly of the image and then using a tag to select which one to use for a given device.

An example of something that kind of does this (albeit not in quite our use case) is Doubletake.

Polyfills for Responsive Images

In some cases, a user simply wants to size up image themselves into several common sizes and then define these paths and let the browser pick the best one based on device dimensions. To this end, there are two standards bouncing around the image community: img[set] (just entered into the HTML 5 ED) and picture (proposed by RICG). A good article can be found on A List Apart: Responsive Images and Web Standards at the Turning Point. Regardless of which one is eventually picked in the debate, this sort of thing is needed now, and several polyfills exist for picture:

Another example exists that uses data-src- prefix:

I lean away from this one though because it requires explicit CSS definitions as well.

Polyfills for Missing Support

Older versions of Internet Explorer do not support max-width. While we've said we're not explicitly going to support old versions of IE, there are two fixes to this that are trivial:

A similar issue comes from transparent PNGs, and the fix is again trivial:

However, the question with all of these support polyfills is whether they make sense to provide or we just say "eff it" to old, unsupporting browsers.

Responsive Video

While the video tag supports max-width scaling, use of an iframe such as YouTube and Vimeo embeds does not. However, a Javascript-based solution does exist:

Typography

Text Fitting

There is sometimes a desire to have flexible font sizing for fluid layouts. A couple libraries exist to this extent:

Typographical Control

UI Element Frameworks

The biggest issue with all UI element frameworks is: '''do we like the semantics of its elements enough to use it or not?''' This is ultimately quite a challenging issue to address, because one cannot modify the semantics without ending up never being able to update the system again. For example, they don't use HTML 5 elements.

However, if nothing else, we can draw inspiration from some of these...

Twitter Bootstrap

This is kind of the "hot new kid on the block":

And a lot of elements have been created based on it like these:

However, it has a number of problems:

  1. Many classes are "presentational" in meaning
  2. Fluid feels like an afterthought in some places (like how text uses pixels, not ems - and cannot be fixed)
  3. Comes with a grid system that not all appreciate
  4. Uses classes and not HTML 5 elements (kind of like problem 1)
  5. Naming convention is inconsistent (some abbreviations like btn and others full spelled out)

If we decide to use Twitter Bootstrap and extensions built off of it, we accelerate our rollout of quick, modern UI elements, but it comes at the expense of the issues above. It seems unreasonable to simple waive these concerns because of the benefit, and thus the question becomes whether we can tweak the Bootstrap to fit our use case sustainably, as simply changes its definitions makes the upgrade process for new versions cumbersome.

The above concerns are not unique. A good quote on the naming issues:

On looking through the CSS, it's laced with class names like '.row .span2' and '.container-fluid', which isn't semantic. When the big boys like Twitter dish this stuff out for everyone to use, they're condoning poor semantics for convenient styling and that is damaging to the industry [ here ]

Others have had to confront them. A couple articles on the issue:

[Alice] on 6/19

I think semantics and css class names is a controversial topic that has yet to be won out. While everyone can uniformly agree on the need for strict semantic meaning to content/data for html entities, the pragmatic reality is that "semantic meaning" for css is inherently related to design (presentation) and not data. A well supported argument is that the separation of content from style -- is the divide between html elements and css styles -- css is afterall style-sheets (concerned with style). This article sums up this points nicely: http://nicolasgallagher.com/about-html-semantics-front-end-architecture/.

This is at the heart of a raging debate that often is waged on the interwebs between 2 camps: the pure sematic community and those from the Scaleable/Modular CSS world. Both have their points, but my gut is that in reality both approaches/methods come at significant pros for some elements at the cost of cons for others. Here, http://www.stubbornella.org/content/2010/06/12/visual-semantics-in-html-and-css/ Sullivan speaks to this distinction/dilemma between what semantic meaning is for html vs. css. I think it's worth seeing this issue since the "problem with presentational css class names" has been one that still hasn't been well solved when you consider a very real need to reuse css styles and name them in an appropriate way so that those trying to apply those styles, know what they mean.

I think this is an issue we should expound on a little more ... The main question is: do we assume the need/requirement of a pre-processer (a non-trivial overhead for the casual developer) at the gain of cleaner html or do we develop modular and reusable css classes that are "semantic to design" w/o the need of a preprocessor and risk introducing class names (semantic to design but not data) into the fray?

Perhaps this makes most sense back in the namin convention area ... so I'm going to start a new section called On CSS Semantics there.

Through LESS mixins, one cal "load" Bootstrap definitions into semantic entities (such as the HTML elements). An example drawn directly from the article "Please stop embedding Bootstrap classes in your HTML":

<!- our new, semanticized HTML -->
<article>
  <section class="main">...</section>
  <aside></aside>
</article>

<!-- its accompanying Less stylesheet -->
article {
  .makeRow();

  section.main {
    .makeColumn(10);
  }

  aside {
    .makeColumn(2);
  }
}

Unfortunately, the Bootstrap does not provide Mixins for everything, so this isn't a full strategy. As opposed to SASS, LESS does not provide "selector inheritance" (outstanding issue here on it). We may be able to still get the proper definitions included, but it's not the same as you'd get with @extend in SASS. There's a level of "getting around" selector inheritance that we can do, but it's cumbersome. Some of the problems with the strategy in LESS:

  • Duplicates the internal style definitions rather than appends them as SASS does
  • Does not create definitions for children, so you have to redeclare every definition you want
  • Cannot use mixins for pseudoselectors like direct child so cannot do nav ul > li { .navbar .nav > li; }

This could end up being too much work to port (if a motivation is to keep up with Twitter as they come out with new releases). We might end up having to generate more Mixins, build custom functions with more advanced behaviors, insert our own routine into the compilation process, or even (sacrilegiously) modify their base styles.

Another option would be to use the SASS implementation of Bootstrap; the issue here is that it is maintained by a third-party besides Twitter itself so that's got its own problems. Here's a real quick and dirty example using Twitter bootstrap with SASS to accomplish the top bar on the UCLA Gateway...

Before any of the Twitter SASS files except variables and mixins:

$navbarBackground:  #93D3EB;
$navbarBackgroundHighlight:  #B3E9F8;
$navbarLinkColor: #204E91;
$navbarLinkColorHover: #000;
$navbarLinkColorActive: #204E91;

Then, after the Twitter SASS files:

nav.bar {
    @extend .navbar;
    @extend .navbar-inner;
    @include makeRow();
    min-height: 30px;
    vertical-align: middle;
    font-size: .923em;
    padding: auto;
    position: relative;
    
    a {
        color: #204E91;
    }
    
    ul {
        @extend .nav;
        height: 30px;
    }
    
    ul:only-child {
        @include makeColumn(12);
    }
    
    ul > li { 
        line-height: 30px;
    }
    
    ul > li > a {
        padding: 0 10px 0 11px;
        line-height: 30px;
    }
    
    aside {
        line-height: 30px;
    }
    
    aside:first-child {
        @include makeColumn(2);
    }
    
    ul:nth-child(2) {
        @include makeColumn(7);
        float: right;
        margin-right:  (2 * $gridColumnWidth) + (1 * $gridGutterWidth);
    }
    
    ul:nth-child(2):last-child{
        @include makeColumn(9);
    }
    
    aside:last-child {
        @include makeColumn(2);
    }
    
    aside.callout:last-child {
        position: absolute;
        top: 0;
        right: 0;
    }
    
    button {
        @include border-radius(0);
        @include buttonBackground(#FFF100, #EEE000);
        color: #000;
    }
    
    aside.callout {
    
        button {
            margin: 0;
            border-top: 2px solid #F0B400;
            border-right: 1px solid #666;
            border-bottom: 1px solid #666;
            height: 34px;
        }
        
        button:first-child {
            margin: 0;
            border-left: 1px solid #666;
            height: 34px;
        }
    }
    
    .container {
        margin: auto;
        position: relative;
        max-width: $gridRowWidth;
    }
}

nav.bar.top.fixed {
    @extend .navbar-fixed-top;
}

nav.bar.top {
    @include border-radius(0);
}

button {
    @extend .btn;
    margin: 0;
}

Finally, here's the markup:

        <nav class="bar top">
            <div class="container">
                <aside>
                    <img src="overcast.png">64&deg; and Overcast
                </aside>
                <ul>
                    <li><a href="#">Prospective Students</a></li>
                    <li><a href="#">Current Students</a></li>
                    <li><a href="#">Faculty</a></li>
                    <li><a href="#">Staff</a></li>
                    <li><a href="#">Alumni</a></li>
                    <li><a href="#">Parents &amp Family</a></li>
                </ul>
                <aside class="callout">
                    <button>VISIT</button><button>GIVE</button>
                </aside>
            </div>
        </nav>

As is clear, it's "somewhat" clean, and takes styles directly from Twitter bootstrap, but there were a lot of overrides necessary. It's not possible to do this in LESS even this elegantly because no @extends keyword.

Icons

Everyone seems to be taking advantage of these nowadays...

.

.

.

.

.

.

.

Framework Units

Below is the start of some general thinking about possibly units that might make sense to have within the CSS/JS structure. These names and even this list of possible elements should be considered nothing but a brainstorm and we can solidify later.

Foundation

These are things that form a basis across the framework. Some, like foundation/color and foundation/typography, should probably have analogues in each of the other modules so that if, for example, you defined an entity/menu/typography, you could define a special set of typography, say for creating special inset headers or something.

  • foundation/reset (reset library to normalize styles between browsers)
  • foundation/color (base color definitions)
  • foundation/typography (base typographical definitions)
  • foundation/container (the container definition that all content goes within)

Layout

Layout General

  • layout/grid (grid foundation)
  • layout/fluid (fluid sizes, responsive switches layouts of the fluid elements)
  • layout/fixed (fixed sizes, responsive simply switches to a lower increment)

Layout Templates

In addition to a flexible grid, we should probably include sets that allow a user to just "invoke" layouts. They should have default spread sizes, but if the user wants to get more specific, they could use the grid classes to resize. For example, with a two column

  • layout/template/3left (main on left, two right small subs)
  • layout/template/3center (main in center, straddled by subs)
  • layout/template/3right (main on right, two left subs)
  • layout/template/2left (main on left)
  • layout/template/2right (main on right)

Entities

See Entities

Javascript Interactivity

Javascript Trigger-Target Interactivity

These libraries are derived in concept from the MWF 1.3 Interactivity suite. The idea is to have CSS-driven Javascript functionality whereby one can use markup to cause common effects.

  • interactivity/effect (target/trigger effects engine like in MWF)
  • interactivity/effect/fade (on trigger, whatever effect is applied fades)
  • interactivity/effect/expand (trigger causes the target to expand)
  • interactivity/effect/collapse (trigger causes the target to collapse - mixed with expandable, you get a toggle)
  • interactivity/effect/transition (a transitioning effect on elements)
  • interactivity/effect/accordion (accordion effect on a set of elements)
  • interactivity/effect/filter (on-page filtering of elements with a text input)

Fully Encapsulated

Clone this wiki locally