I love the idea of building an “interactive style guide” for a website
design. I really do. However, working in Agencyland, it can be
extremely difficult to budget enough time for this kind of tool when
seemingly higher-priority tasks pile up. Right or wrong, the utopian
vision of a living style guide often becomes a foregone luxury in the
throes of looming deadlines.
Assumes the reader understands the basics of Ruby and CSS.
Since I switched to Vim as my primary editor back in March of this year,
I have discovered a wealth of useful tricks that help me get things
done. Most of these techniques are truly indispensible, and should find
a place in any Vim user’s quiver.
I should also note that at this time, I’m nowhere near expert-level in
my Vim abilities, so this post is intended to share some commands,
patterns, and configurations with other Vim users who are still getting
their feet wet with the editor. Experienced Vimmers will already know
all this stuff, and more power to them. This is for the Vim n00bs out
there.
In my previous post, I
hinted at a growing concern with CSS performance. Among those pioneering
ways to approach the issue of maintainable-yet-efficient CSS is Nicole Sullivan,
who is perhaps best known for her open source Object-Oriented CSS
project.
Object-Oriented? CSS?
I have to admit that when I first checked out out OOCSS, I guffawed.
While it’s true that, at first blush, CSS does not have many of the
traditional features of a genuine OO programming language, Nicole has
been exploring ways in which CSS’ inheritance/cascade can be analogous
to OO concepts.
It’s taken me quite some time to come around. There are things in the
OOCSS code base that seem to fly in the face of commonly-accepted CSS
best practices. It is precisely this kind of resistance in the community
that must have prompted Nicole to deliver her latest talk this year at
Webstock, entitled Our Best Practices Are Killing Us (slides).
To those who tried to visit this site only to get a 404 error in the
last 24 hours, I apologize. I believe DNS propagation was the culprit,
and I jumped the gun by announcing that my post was up. I was able to
view stephentudor.com just fine, but quickly found that several people,
including my lovely wife, could not even get to the site initially.
By this time, it appears that most folks have been able to access it. If
you can see this post, you’re fine. Otherwise, you’re probably in the
camp that is left wondering why this joker posted a 404 URL to Twitter.
In capable hands, Sass can do amazing things for your
CSS. With Sass, you can use functions and variables that later get
compiled into valid CSS. This can greatly reduce code repetition and
the potential for mistakes.
For example, not that you would, but you could write some Sass like this:
// Set a couple of vars$titleColor:#000$titleSize:24px.article.titlecolor:$titleColorfont-size:$titleSize.alt-title@extend.titleborder-bottom:1pxsolidlighten($titleColor,80%)// #ccccolor:transparentize(lighten($titleColor,20%),0.1).sub-title@extend.titlefont-size:round($titleSize*0.85)// 20.4px&:hoverbackground-color:transparentize(change-color($titleColor,$red:255),0.8);
The resulting CSS might look something like this, depending upon how you
set your Sass output style preference:
Pretty cool, right? You can see that the @extend keyword can be a very
powerful tool, bringing a quasi-object-oriented paradigm to our CSS. The
same could be true for the nested selectors; you just have to refer to
.article once, and let the indentation take care of the scope for
you.