Ajax Bestiary: A Javascript Field Guide
 
Ajax Bestiary: A Javascript Field Guide
 
 

Plugins, CSS Frameworks And How I Came to Drink The Koolaid

Posted by Don Albrecht

When I first started using CSS frameworks & standardized resets to streamline my web development, I adopted a process that I’m sure is familiar to many of you.  I would first link to the frameworks CSS files and then link to a project specific stylesheet.  The project specific stylesheet would build on the frameworks foundation to provide color & background data, special classes and all the other bits and bobs unique to the design.

For me, this system worked quite well.  I gained the benefit of the frameworks without excessive overhead and while I was no longer coding my CSS from the ground up, the process was surprisingly smooth.  When I first heard about plugins, I really didn’t see the point of adopting them.  They seemed an arbitrary way to include functionality that really belonged in the project stylesheet.  A recent project, however, completely changed my mind.  I was working with a client on a site that required support for several different templates (holiday sale, investor relations, technical support, etc).  While many of these sections employed radically different looks, they needed to be consistent in terms of typography, form elements, tooltips, etc.  They also needed support for seasonal theming as much of their marketing was holiday & special event oriented.

Suddenly, the plugins systems made sense.  I built a single plugin for all site wide styling and a second plugin to allow for seasonal color schemes (simply upload a different folder to the same location and you can change the colorscheme site wide).  Once I realized the power of plugins for complex projects, the realm of uses has exploded for me.

Where I use CSS plugins:

  • Site specific typography & branding
  • Common form elements (error, required field, etc)
  • turn on and off debugging styles (great for troubleshooting)
  • My personal CSS widget toolkit ( pullquotes, notes, etc.)
  • Custom Grid (Instead of replacing grid.css in blueprint, I may deploy a new grid as a plugin during development)
  • CSS Sprites

Plugins are currently supported by Tripoli & Blueprint.

I’m curious who here has started working with plugins or some other formal, modular system for CSS.

Nagging Thoughts About CSS Frameworks

Posted by Don Albrecht

Let me start by saying that I love CSS frameworks.  From Tripoli to Blueprint, YUI to YAML, I’ve embraced them fully into my design and development process over the past 9 months.  Unfortunately, throughout that time I’ve had to deal with a nagging issue: The Semantic Web.

CSS exists to shed the shackles of inline formatting and truly separate content from display.  While It’s rarely possible to achieve all of a project goals in a semantic way, CSS frameworks really fly in the face of a semantic approach. Don’t get me wrong, I still think CSS is the way to go and that frameworks provide powerful scaffolding, but I think we all need to be aware that using CSS grid & layout frameworks isn’t exactly a true separation of content & styling.

Take for example, blueprint.  Blueprint contains a powerful set of tools for building a layout.  Unfortunately, these tools require that columns be explicitly defined in the page source <div class=”column span-2″>.  This makes it impossible for a change in stylesheet to completely alter a page layout for mobile devices without discarding the column & span classes and relying on an independent set of markup e.g. <div class=”column span-2 mobile-column mobile-span-5″>.  This is a rather cumbersome noose to have to carry for some projects.  Especially when the infrastructure isn’t in place to deliver two distinct versions of the site from the server.

I’m wondering how you have addressed these problems in past projects?