Blog post by Evan: Elgg's New CSS Framework

[This is a blog post by Evan Winslow]
Imagine trying to build a house without tools.  If you’re like me, you’d be lucky to finish at all, let alone make it an efficient, enjoyable process.  It’s just not something you’d do unless you’re the kind of person who likes doing that for fun.  Up until now, Elgg theming has felt a bit like that to me.  It’s daunting, and there’s a lot of reinventing the wheel to do before you can even really get started.
Elgg 1.8 is changing all that.

We set out with some ambitious goals for Elgg 1.8’s themeability. In order to accomplish those goals, we knew there was one main thing we needed to do: eliminate the bloat. Bloat means more work for everyone. Bloat means a lack of re-use and reusability. Bloat means higher development cost and lower quality results. That’s something none of us should have to accept. There’s no question there is bloat in Elgg’s current CSS: the community site for example has a CSS file of almost 90k, 80% of which is not used on a given page. Margin alone is declared 400+ times, and 300+ of those declarations start with “margin:0”. 

Object-Oriented CSS

In order to cut this bloat and maximize reusability, we decided to re-code the CSS using an approach called Object-Oriented CSS. Essentially, we analyzed Elgg visually for repeating patterns. Each of these visual patterns becomes a “CSS object,” which is made up of an html structure and some CSS classes. Similar objects have their common styles synthesized into one base class and the differences are stored as extensions to that class (skins).

For example, one pattern that we picked up on immediately was the “image block” pattern.

Figure 1.1 Figure 1.2

The two examples above have two completely different implementations, and neither is reusable in any other context. In my review of Elgg 1.7 I counted at least seven different implementations of this pattern. That’s where the bloat is. In Elgg 1.8, we’ve implemented a single “elgg-image-block” CSS object that handles all of these cases.

A second familiar pattern we discovered is the “module” pattern, which is essentially a box with a heading and some arbitrary content.

Figure 2.1 Figure 2.2

These two boxes look awfully similar, don’t they? As of Elgg 1.7, they have completely different implementations. There were several occurrences of such box-with-heading-and-body structures across Elgg. Some had transparent background, some had a different color inner background or different header style, but they were all essentially the same object (html structure) with different skins. We synthesized this pattern into one base class and four extension classes that provide different skins for the pattern that we’re calling “elgg-module.”

The Bottom Line

By coding Elgg’s CSS in an object-oriented way and maximizing re-use, we’ve been able to cut core CSS down 33% so far. That’s 33% less CSS for themers to learn and worry about. Furthermore, the CSS that is left is better written, structured, and documented; so it’s not just less to learn, it’s easier to learn too.

We’ve had even more dramatic success with plugins: the blog plugin, for example, which used to require three kilobytes of CSS now uses just three lines, a 98% decrease in size. We’re aiming to provide enough reusable CSS objects so that any plugin developer can achieve similarly dramatic results. Plugins that build their markup in an Elggy way will have the added benefit of being themeable: Themes written for 1.8 will automatically get applied to that plugin without any extra work by theme developers.  

Needless to say, we’re very excited about these new changes and can’t wait to see what the community does with them. Look for future blogs highlighting the other features we’re including in Elgg 1.8 to make theming better than ever such as improved documentation, a new incarnation of Cash’s developer tools, and more!  

Elgg 1.8 is providing the tools. All it needs now is your creativity. Let’s make Elgg beautiful together!


Latest comments