Bjorkoy.com

Automatic compilation of Sass and HSS files

Tue, 21 Oct 2008 15:34:00 GMT

Sass and HSS are pretty cool tools. They are extensions to CSS that allows you to use variables, arithmetic, nested rules and other goodies in your stylesheets.

To make this work, both tools use a compiler to transform the Sass and HSS file contents into valid CSS which will work in a browser.

The problem

Running the compiler on each file change when developing a site is a tedious task to do manually, so I patched together a simple Ruby script to do it for me. In the interest of karma, here’s that script for you to use as you see fit.

The script can esentially be used in any situation where some files must be observed, and a command run whenever they are changed (saved), be it compiling, compressing, running tests or validation.

How to use the script

Put the script file in your CSS directory. The script will monitor both that directory and any subdirectories when started.
Change the configuration options at the top of the script, depending on which tool you are using: Sass, HSS or something else.
Whenever you are working on your files, have the script running in the background. Start it by running ruby monitor.rb.

Now, whenever you save changes to your Sass or HSS files, the corresponding CSS files will be recompiled from their respective sources. The script will also recompile all observed files at the moment it is started.

That’s it! You can now use the CSS extension tool of your choice, while still retaining the sweet ability to refresh your browser to instantly see any changes, all without any annoying extra steps in the process.

Download the script

Passing the torch

Tue, 02 Sep 2008 10:35:00 GMT

Blueprint has had an amazing run so far. Even from the get go, the popularity surpassed anything I could ever have imagined. Dominating the top spots at Delicious, reaching the front pages of both Digg and Reddit, being featured on sites such as Wired, Ajaxian, Daring Fireball, Subtraction and countless others, the numbers speak for themselves.

Where did all this hype come from? The fact is, it took quite a few months until Blueprint was able to deliver on all its promises, and the initial implementation was far from perfect. But the hype remained nonetheless.

I have my own theories on how the, at times, unjustified hype came to be: The enticing coupling of the words “framework” and “CSS”, the void left by having no viable, light-weight competitor to Yahoo UI, and being based on thorough work by industry leaders such as Jeff Croft. All this certainly helped more than any brilliant CSS solutions ever could have.

Either way, here we are. Blueprint is at sort of a crossroad. Should we be happy with what we have, or has the time come to really ramp up development and aim to deliver on all the expectations the now fading hype has come to expect of us?

The Blueprint community has grown exceptionally fast. Inversely, my available time for developing the framework and nurturing the community has diminished. The community has continued to grow and has come to expect a lot more than what has been delivered. This is the problem that presents itself when a project grows faster and reaches more people than you could ever have imagined: You have no way to keep working at the same pace to keep the project at this level for a long stretch of time.

But this is also the beauty of open source: I have done what I can for Blueprint for the time being, and while I’ll still be a vocal part of the community, the time has come to pass the torch.

It’s time for someone else to maintain the project, so that all the brilliant minds who wish to contribute actually get a chance to have their say. Blueprint could be so much more than it is today, and with a few new guys running the show, I’m certain the framework can reach even the high goals set up by the earlier hype.

So here we go. For the time being, the new maintainers of Blueprint are:

Christian Montoya
Joshua Clayton
Chris Eppstein
Glenn Rempe

They are great guys, who have been working on Blueprint for a long time now. If anyone can take the framework to the next level, they can. The new site, with links to all relevant sources can be found at blueprintcss.org.

As mentioned, I’ll still be around, helping out, and if the time comes, I’ll be back on the front lines developing the framework. But from now on, these are the people to contact and look to for any news and developments on Blueprint. Best of luck to all of them!

Blueprint 0.7 has arrived

Wed, 20 Feb 2008 22:08:00 GMT

Blueprint 0.7 has finally been released. Expect a more thorough article on all the new stuff soon. For now, here’s a quick rundown.

It’s been way too long since our last release, so 0.7 is in many ways a pretty daunting upgrade. Lots of things have changed, making the framework more powerful, customizable and nimble than ever before.

Here’s the most important new features:

A powerful new compressor/generator script for customizing every part of Blueprint.
A new directory structure, way better thought out than what we had in 0.6.
No more need for the .column class (div + .span-x implies column).
Lots of bugs fixed.

The new compressor

So what does it do?

$ ruby compress.rb -h
Usage: compress.rb [options]
Blueprint Compressor

options
  -o, --output_path=OUTPUT_PATH    Define a different path to output 
                                   generated CSS files to.
  -n, --namespace=BP_NAMESPACE     Define a namespace prepended to all Blueprint classes 
                                   (e.g. .your-ns-span-24)
  -p, --project=PROJECT_NAME       If using the settings.yml file, PROJECT_NAME is the 
                                   project name you want to export
  --column_width=COLUMN_WIDTH      Set a new column width (in pixels) for the output grid
  --gutter_width=GUTTER_WIDTH      Set a new gutter width (in pixels) for the output grid
  --column_count=COLUMN_COUNT      Set a new column count for the output grid
  -h, --help                       Show this help message.

If you’re using Blueprint in several projects, you should check out the new settings file for the compressor. Here’s an example of the new settings file, with most available options:

my_project:
  path: /path/to/my/project/stylesheets
  namespace: custom-namespace-1-
  custom_css:
    ie.css:
      - custom-ie.css
    print.css:
      - docs.css
      - my-print-styles.css
    screen.css:
      - subfolder-of-stylesheets/sub_css.css
  custom_layout:
    column_count: 12
    column_width: 70
    gutter_width: 10
  plugins:
    - fancy-type
    - buttons
  semantic_classes:
    "#footer, #header": ".span-24, div.span-24"
    "#content": ".span-17, div.span-17, div.colborder"
    "#extra-content": ".span-6, div.span-6"
    "div#navigation": "div.span_24, .span-24"
    "div.section, div.entry, .feeds": ".span-6 div.span-6"

Yes, you’re reading that correctly. In order, we have:

Optional custom output path.
Namespace for Blueprint classes, which even updates the test files.
Custom CSS appended to Blueprint stylesheets.
Custom layout settings, almost too easy.
Automatic compression of plugins which then gets added to the main Blueprint file.
Semantic class names from BP classes. Just add them to your HTML, remove the old BP classes from the same HTML, and you’re ready to go!

Huge thanks to Josh Clayton, the newest member of the Blueprint team, for creating all this. He’s even written quite an article describing the compressor in detail.

CSS font shorthand syntax

Fri, 11 Jan 2008 21:28:00 GMT

The CSS font shorthand property syntax always seem to slip my mind, so here it is, mostly for my own benefit.

Syntax

The syntax is:

font: style variant weight size/line-height family;

The required parts of this shorthand is size and family. You should always stick with the ordering given above, which is what the W3C recommends.

Examples

Example 1:

font-size: 14px;
font-family: Helvetica, sans-serif;

/* Combined into one shorthand rule */
font: 14px Helvetica, sans-serif;

Example 2:

font-weight: bold;
font-size: 14px;
line-height: 1.5;
font-family: Helvetica, sans-serif;

/* Combined into one shorthand rule */
font: bold 14px/1.5 Helvetica, sans-serif;

Example 3:

font-style: italic;
font-variant: small-caps;
font-weight: bold;
font-size: 1em;
line-height: 140%;
font-family: Helvetica, sans-serif;

/* Combined into one shorthand rule */
font: italic small-caps bold 1em/140% Helvetica, sans-serif;

Source: 456 Berea Street on shorthand properties. (You’ll find many more timesavers in that article.)

How to stop comment spam

Sun, 06 Jan 2008 01:22:00 GMT

Comment spam must be the number one threat against an enjoyable blogging experience. Many people quit blogging entirely because they get tired of fighting the ever evolving spam bots. There are, however, ways to win this arms race.

Below I’ve outlined the techniques I use to keep this blog spam free. I’d be very surprised if I ever get spam from bots again - this stack of techniques should be quite bulletproof. The methods are listed in order of usage.

If a comment passes all these steps without being flagged as spam, it’s allowed into the database.

It should be noted that I have no patience for manually approving comments - I feel like I’m letting the spammers win. For shame! :)

Step 1: “Do” field

(This step was initially about referers, but as pointed out in the comments, all browsers do not send referers, making this a bad idea. Here’s a different method.)

We’ll first check if the HTTP POST actually comes from the blog entry in question. This is easily done with a hidden form field called “do”, which contains a simple value of your choice.

When a comment gets posted, you check if the field “do” is set and equals the chosen value. As spammers often send POSTs directly to your “add comment” URL, this might stop some of the less ambitious culprits. The HTML could look something like this:

<input type="hidden" name="do" value="some_random_rotated_value">

The spam check (in Rails):

if params[:do] != the_random_rotated_value
  spam = true
end

It won’t stop all spam, but the philosophy here is that if it can stop any spam, we’ll do it. Onwards, to level two!

Step 2: Hidden Turing test

A recent trend amongst blogs is to have a simple question as part of the comment posting experience. A simple CAPTCHA, in other words. The user has to answer a question, and the answer is then used to decide if the poster is human. In effect, the Turing test expressed through a single form field.

The problem is that this diminishes the user experience. Any extra field a user has to fill in order to leave a comment is just another reason for that user not to comment at all. And since you want as many comments as you can from as happy users as possible, we should do something about this.

Here’s my take: You use a question field, but with an added twist. Through CSS, hide that field. In your code, check the posted value of this field. If it’s not empty and does not equal the answer to your test question, the comment is spam.

You’ll also want to give the field a name that makes it certain that a spam bot will fill it out. I use “url” to store links, so here I’ve used the name “website”. The HTML looks like this:

<div style="visibility:hidden; display:none;">
  <label>What is 2+3?
  <input type="text" name="website"></label>
</div>

(Jan Pingel and Jeremy Weathers suggests in the comments that visibility:hidden is needed in addition to display:none in this case, as it will help apps like screen readers to hide the test.)

And the POST check might look like this (at least in Rails):

if params[:website] != '' and params[:website] != '5'
  spam = true
end

We hide the field because common sense says that spam bots probably won’t parse CSS, and therefore fill in the field based on the name given. A user without CSS turned on will see the field, and fill inn the answer to your question. The vast majority of users, however, will never even see the question, thus making the probability of them leaving a comment higher.

A truly resilient spam bot might pass this test. It might parse the CSS or understand the question. No matter, on to level three!

Step 3: Akismet

Akismet is a great tool for stopping spam. It’s basically a web server to which you pass the content of and information about each comment, and it in turn gives you a “true” or “false” signifying if it thinks the comment is spam. It has a great hit rate, and has worked for a vast herd of now spam free Wordpress bloggers.

The service is open to everyone, though you’ll need to create a (free) account on wordpress.com. You’ll then get an API key which will give you access to the Akismet servers.

There’s already been written plugins and API wrappers for many systems and languages. Here’s a few:

Wordpress plugin (official)
Akismet API wrapper for Ruby
Ruby on Rails plugin (uses the above wrapper)
Drupal module
Movable Type plugin

(A simple google search for Akismet and your blogging system will likely produce your desired result.)

In many cases, using Akismet will protect your blog from almost all spam. However, since this is supposed to be a bulletproof setup, I would still recommend using all the techniques mentioned above. Since Akismet is starting to get very popular, spammers might work extra hard to find countermeasures for it, and as it’s a centralized service, it’ll probably experience some downtime.

Still not satisfied? I have one more technique you can try out.

Update: Carl Mercier writes in to mention Defensio, which is a service similar to Akismet. I haven’t tried it, but judging from it’s website, Defensio might very well be a worthy competitor. You could of course use both, which would be especially useful in case one of them is experiencing downtime.

Step 4: Click test (Javascript required)

This is a technique used by SimpleLog, and requires that Javascript is turned on by the user posting a comment.

I don’t use this, as I think websites should always work perfectly without JS. However, if you disagree, or run a site where one of the requirements is that JS must be turned on, this might be just what you’re looking for.

First, create a bunch of hidden fields, one for every required field and the submit button, like this:

<input type="hidden" name="check-1" value="no">
<input type="hidden" name="check-2" value="no">
...
<input type="hidden" name="check-n" value="no">

In every required field, create a virtual form value through Javascript, that is only set if the user actually physically (or is that virtually?) entered something in the field, like this:

<input type="text" name="email" 
onkeypress="this.form.elements['check-1'].value = 'yes'">

Do this for every required field, just change the value “check-1” between each new field, so that you get a separate check for each. You should also check if the submit button was really “clicked” by the user, like this:

<input class="submit" 
onclick="this.form.elements['check-2'].value = 'yes'>

You can then check in your “add comment” method if every one of these fields are set to the correct value (“yes”). If they’re not, the comment is spam. (Or the user has JS turned off, which is the problem I mentioned above.)

To really annoy spam bots, obfuscate the custom values, like this.form.elements['ed8mkl32'].value = '9r3w'. You can then randomize these and place them at different intervals and in different fields, all while checking for the current correct setup in your script.. Am I going too far? :)

Step 5: Random field names

Andrew suggest another simple yet effective method:

The technique I am using, and which is working very well, is to randomise the names of the form fields.

When the form is loaded a PHP script generates random names for all the form fields and then adds a hidden element with instructions on which random form name should equal which real form name.

When the form is submitted the comment handler unscrambles the names and assigns the values. Any form fields submitted that were not included in the unscramble instructions are wiped.

Spammers, be gone!

In addition to the techniques mentioned above (except step 4 and 5), I also use a blacklist that comes with SimpleLog as a last measure. I like to think that I’ve caused at least some frustration in the mind of a spammer at this point. :)

I’ve yet to get automated spam after implementing these methods, although I hope no enterprising spammer sees this post as a personal challenge, with its provocative title (in spammer circles) and all.

If anyone has any techniques to add to this list, enlighten me through the hopefully spam free comments section below.

Blueprint's directory structure

Thu, 03 Jan 2008 14:30:46 GMT

The Prototype JS framework has a great directory structure. The project has a source folder, containing different parts of the framework, and a simple script that puts these together to one file (prototype.js) for distribution. This makes both development and deployment enjoyable.

Blueprint’s directory structure has been way too complex until now, with quite a few files that were, well, unnecessary. The goal should be to have as few files as possible, organized in the most intuitive way we can think of.

We can’t go down to a single-file product, such as Prototype, since screen.css, print.css and ie.css all have to be included in the HTML in three different ways. There are ways to make these three files apply to the correct environment through one file, but including them in HTML with correct media types and conditional comments is the easiest and most predictable way of getting this to work. So that’s what we’ll do.

Another thing we must do is to move the inclusion of plugins to the HTML. This used to be done in screen.css, but with this new method, we ensure that upgrading to a new version of Blueprint is as simple as replacing the old Blueprint folder.

So we need three files in the top level directory (screen, print, ie), one source folder for all our different parts (grid, typography..), a script for compressing the source to the three top-level files, a tests folder and a plugins folder. Let’s draw it up:

Blueprint’s new directory structure

blueprint/
    screen.css
    print.css
    ie.css
    src/
        reset.css
        grid.css
        typography.css
        forms.css
        print.css
        ie.css
    plugins/

scripts/
    compress.rb
    validate.rb

tests/
docs/

(The print.css and ie.css files in the src directory are the uncompressed versions of the top-level files with the same names.)

Another great result of this, is that a user not looking to experiment with Blueprint, only needs the top three files. Such distribution would require something like a Blueprint Wiki with better documentation, as these three files have no comments to explain their functionality.

The change has already been made in our SVN repository, so check it out there if anything is hazy. This also means that we have a new compression script, which you can check out in the SVN as well.

It’s a good start, but I’m sure we can do better. Suggestions? :)

Rejoice, the blog is back!

Wed, 02 Jan 2008 22:45:00 GMT

You might have personal problems if the return of my blog is as important to you as it is to me, but let’s assume for the purpose of justifying this entry that it is.

The blog returns after a short hiatus, imposed by MediaTemple’s rails hosting, which I hear is based on a wobbly cluster of jello-cored Elbonian brand servers. It looks different, yes, but this is the good kind of different. Here’s why:

It doesn’t have a design I’ll instantly tire of (or so I hope).
It’s faster to serve, easier to customize and has better spam protection (fear my untested rails skills).
It’s inspired by a recent favorite blog of mine, Dive into Mark. (Naturally, mimicking the design of a good writer means my writing will improve as a result).
The text is Helvetica, big and friendly, as it should be. Why do we ever use 11/12px sized text anyway?
It has better archives, tag support, comment form, et cetera.

However, when I say it’s “better”, I mostly mean “better for me”. You might disagree. Bjorkoy’s law, however, categorically refutes whatever argument you might have:

Bjorkoy’s law: “The quality of written content improves linearly with the level of satisfaction the writer derives from the environment in which the content is written.”

Never mind the fact that I just made this axiom up. I also made up an axiom that says that axioms easily can be made up on the spot. Also, one that circular reasoning is perfectly valid logic.

The point is, when I like my blog, my writing improves, which you of course enjoy as well. Happy new year, have a good one. I predict another year of “too many tables”, <!--[if lt IE 7]> and questionable redesigns. Welcome back! :)

Tools of the trade

Fri, 16 Nov 2007 19:04:00 GMT

The Blueprint ecosystem is growing at what seems like an exponential rate. Even I have trouble staying up to date with all the cool tools people are releasing. Most of the tools here are works in progress, so please treat them as such.

List-o-matic

Christian Montoya is working on a webapp called Semantify. It takes the URL for a page using Blueprint as input, and lets you create semantic class names instead of using the admittedly semantically questionable BP markup. (You didn’t think I was in denial of that fact, did you?) :)
Min Kim has developed an Adobe Air app for generating customized Blueprint grid files. I’ve never used Air, but if that’s your thing, please check it out.
Don Albrecht is working on The Blueprint Layout Tool, which is a WYSIWYG editor for creating your own grid. Impressive work in progress. He also has a cool name. The Don (yes, I had to) has also created a plugin called SilkSprite, which lets you use a vast number of icons out of the box in your HTML.
Alejandro Vasquez has started working on a much requested cheat sheet for Blueprint. You have no idea how many people requested this.
Here’s a simple tool for creating grid backgrounds with Javascript for your desired setup, created by Jonah Fox.
The aforementioned Blueprint Grid Generator is still going strong, complete with support for Blueprint 0.6. This tool has made my life much easier.
This next tool is right down my alley: A Ruby on Rails plugin for using Blueprint. Mad, raving props to Ariejan de Vroom for putting this together.

I’m a busy man. Give me a shorter list!

We’re trying to collect all the tools on This Blueprint Wiki page, but I thought I’d highlight some of them. If you feel something is missing, let me know in the comments. Although that’s not a prerequisite for commenting. Actual constructive comment content rarely is.

Finally, here’s the article which should complement what you’ve just read through.

Now, back to reading frantically on all the courses I’ll fail either way. Damn you Blueprint! Maybe I should intimidate my professors by changing my name to Don.. I’ll get back to you on that.

Blueprint 0.6 Released

Fri, 21 Sep 2007 20:28:00 GMT

Today marks the release of Blueprint, version 0.6.

This release is quite literally miles ahead of what 0.5 ever was, and is a giant leap towards what we’ll eventually call version 1.0.

Some of the highlights include:

A much more sensible directory structure.
A new plugin system.
Lots of functionality extracted into plugins, keeping the core files sweet and nimble.
New test suite for proper browser compatibility testing.
We’re back to using em units for all vertical sizing, although with a much better implementation than what we had in 0.4.
New ruby scripts for compressing and validating the CSS.
Proper styling of forms.
Tons and tons of bugfixes.

Check out the way too extensive changelog for more details.

I’ll write more about each change in future posts, but it’s just way too much ground to cover in one sitting.

For now, just head over to the Blueprint site to grab your copy. :)

(Also: Polar Bear)

Inspiration

Fri, 07 Sep 2007 18:50:00 GMT

Virb

Apple

Swissmiss

A Brief Message

Theocacao

CSS 101: Opposing Floats

Fri, 07 Sep 2007 11:31:00 GMT

One of the CSS techniques most prone to failing in Internet Explorer 6 is floating elements up against each other.

For instance, you might have a main-content div, and a sidebar div. You then float both of these to the left, and give one of them some margin on the left or right hand side.

Bad idea! This often induces one of IE6’s many CSS layout bugs, so here’s a better way:

Float the two divs to different sides. That is, give the first column a float:left, and the second column a float:right.

Apply a width to each column, so that the whitespace in between the columns is as wide as the margin you originally applied.

Now, the columns aren’t even touching, ensuring that IE6 won’t push one column down below the other.

Just like that you’ve accomplished the same exact layout, without the need to float divs up against each other, making for a much more robust layout.

Blueprint 0.6 stress test

Thu, 06 Sep 2007 18:30:00 GMT

Before releasing Blueprint 0.6, I’d like to put it through its paces. If you have the time and ability, please check out the latest revision from our SVN repository, and try your utmost to brake it.

This release will be miles ahead of out current release, and is a giant leap towards version 1.0. If all goes according to plan, the versions between 0.6 and 1.0 will not bring any major changes, only subtle improvements, additions and bug fixes.

This also means that the release of 1.0 should not be too far away. :)

Here’s a quick list of the improvements in BP 0.6:

We’re back to em units for vertical spacing, though with a much better implementation than what we had in 0.4.
This release introduces a new plugin structure, keeping the core files light and nimble.
Three plugins (two extracted from the 0.5 core, one new).
A new IE stylesheet imported with conditional comments.
A much cleaner directory structure.
New compressor script for easy compression of core files.
Compressed version of print.css.
A CSS validation script.
Greatly improved test files.
Lots of improvements to the typography.
.box, .clear, .append- and .prepend- 12 through 23 are back by popular demand. :)
Loads and loads of small improvements and fixes.

This might seem like a lot of files, but while the number of bundled tools have increased, the use of plugins and a much better directory structure actually means that the CSS framework itself is lighter and more robust than ever.

Take a look at the full changelog for more details, though some changes might be missing from that as well. Also, the readme file in the SVN directory is of course the only updated documentation on 0.6.

Submit feedback in our Google Group, or by mail (olav at bjorkoy dot com).

I’ll be posting about who the people in the BP dev team actually are, and about all the new tools to use with BP in the near future.

CSS 101: There's always another way

Thu, 30 Aug 2007 13:18:00 GMT

So your CSS layout breaks in a certain browser (cough IE cough).

Before applying any nasty hack to fix the issue, try to use another CSS technique to achieve your desired look.

For instance, if paddings make the layout break, try margins. If floats makes you pull your hair out, see if you can’t create the same result using absolute positioning. Or just change the way the divs float.

The point is that CSS gives you a lot of options on how to achieve your desired layout. And way too often, people spend a lot of time creating an ugly work-around before trying out every option.

There’s always another way, find it before resorting to hacks.

Blueprint 0.5: The Experiment

Tue, 28 Aug 2007 22:11:00 GMT

Today marks the release of Blueprint, version 0.5. This is a special release, as it is above all an experiment, trying out a few different techniques as we approach version 1.0.

The Grid

The grid in this release is upped from 14 to 24 columns. Now, before you all go haywire, consider the following:

12 is quite certainly the best number of columns for a grid, mathematically speaking. It is dividable by both three and four, giving you lots of options on how you’d like to set up your layout.

However, after trying out the 12 column scheme on a few sites, I believe it is too constricting. That is, the column count is too low. It was already too low when we were using 14, if you ask me, so 12 doesn’t seem completely right.

That’s why I’ve gone for 24. Being 2 * 12, you get all the flexibility, with the added possibility of creating truly complex grid systems. And, if 12 is your preference, all you have to do is to double your desired span counts.

But hey, Blueprint is about flexibility, not constraints. That’s why Matz from kematzy.com is the latest addition to the growing BP development team. He has created a wonderfully flexible BP grid generator, which lets you input your desired number of columns, margin between columns, and even your preferred total width, and outputs a nicely formatted and customized grid.css.

So please, if 24 is not your bag, check out Matz’s generator.

Also, the first class is no longer needed. :)

PX vs EM

Blueprint 0.4 introduced the use of em units for all vertical spacing, including line-heights and font sizes. However, in retrospect, this does not work as well as it should. While giving IE users the ability to resize text properly, the vertical flow and baseline was disrupted in nearly every browser except Firefox.

I do believe the baseline is quite important, giving each page a great look and feel, so we’re going back to pixels in this release. Resizing might not work as well, but the baseline now looks perfect in nearly every browser. I think this is a fair trade.

To accommodate those not happy with this, BP 0.4 will remain as a download on the Google Code site, so that you may easily make your own changes to stick with em’s.

We do hope to return to using em’s one day, but that won’t happen until we can make them work correctly with the baseline. If anyone wants to tackle this issue, please feel free to do so. :)

Fonts for the typographically literate

Version 0.5 also sports a new set of default fonts. We figure that if you’ve gone so far as buy your own great fonts, you should also get to use them when you browse the web. Here’s the fonts that now gets set in typography.css:

h1,h2,h3,
h4,h5,h6  { font-family: Constantia, "Palatino Linotype", Palatino, Georgia, "Times New Roman", Times, serif; }
body      { font-family: Frutiger, Univers, "Helvetica Neue", "Lucida Grande", Calibri, Helvetica, Verdana, sans-serif; } 
pre       { font-family: Corbel, Verdana, "Bitstream Vera Sans", sans-serif; } 
code      { font-family: Consolas, "Bitstream Vera Sans Mono", "Courier New", Monaco, Courier, monospace; }

This is also highly experimental, and the font choices are likely to change in future releases.

Coming in 0.6

A few things didn’t make it into this release. Most noticeably is the forms.css file. Created by Kim Joar Bekkelund, this file aims to give you some great looking default forms, with support for fieldsets, buttons and more. Expect it to ship with BP 0.6.

Another quite important feature that probably will be added to 0.6, is the use of an ie.css stylesheet, loaded with conditional comments, so that IE hacks stays in one place, and doesn’t clutter up our beautiful core files.

Get yer Blueprint, half price!

So that’s that. Another release, another milestone on the way to Blueprint 1.0.

As always, a tutorial, example files, the credits, and the download itself, are all on the Google Code site. So go ahead, and grab your own copy. :)

CSS 101: Group by layout

Sun, 26 Aug 2007 20:19:00 GMT

Many developers group their CSS stylesheet rules by element, with every text element in one segment of the CSS file, then headings, then lists and so forth.

However, since you almost always look for rules that applies to a special part of your page when editing your CSS, grouping your rules by layout is a much better idea.

For instance, at the top of your CSS file, put general rules for body, p, ul and such. Then, group the rest of your rules by layout element, like #header, #sidebar, #footer and so forth.

h1,h2,h3,
h4,h5,h6  { font-family: Helvetica, Arial, sans-serif; } 
a         { font-weight: bold; text-decoration: none; }
body      { margin:18px 0; }

/* -------------------------------------- */

#header         { position: relative; margin-bottom:5px; }
#header #links  { border-bottom:1px solid #ddd; }
#header h1      { font:bold 5em Helvetica, Arial, sans-serif; }
#header ul      { list-style-type:none; margin: 0 0 35px 0; }

/* -------------------------------------- */

#promo            { border-top:2px solid #ddd; }
#promo .column    { border-color:#ccc; }
#promo .column p  { padding:10px; margin:0; }

I think you’ll find that this makes for much more enjoyable CSS development.

Note: Blueprint 0.5 will hopefully be released tomorrow.

Blueprint 0.4 released

Sat, 11 Aug 2007 00:29:00 GMT

(If you don’t know what Blueprint is, read this first.)

Pencils down, let’s ship this thing, and bring print design on the web one step closer, as the first release of Blueprint is quickly closing in on 15 000 downloads.

Please read that back to me. The first point-release of a framework, built on a technology that behaves differently in most browsers, with known, gaping holes, has been downloaded almost 15 000 times. If there ever was a time for a new release, this would be it.

Version 0.3 also produced this statement from Khoi Vinh, online design director for The New York Times, and chief catalyst for bringing grid-based designs to the web:

“Is there a way I can turn Blueprint into traffic for Subtraction.com?

Enter version 0.4

Here’s most of the changes at a glance. Scroll down for explanations and clarifications.

All font sizes and vertical margins are now elastic, through the use of em units. Resizing works great in every tested browser.
Comes with a new, compressed version of BP, which reduces the size of the core files by 60 percent.
Support for incremental leading, contributed by Mark Boulton.
Adds perfected CSS buttons, by Kevin Hale of Particletree fame.
Fixes all known IE bugs.
Loads of minor fixes and additions.

I’d say this qualifies as a good, nay, make that a great release. Remember that BP now has taken on a life of its own, and that many of these changes have been contributed by people all over the globe. Be sure to check out BP’s contributors section.

Also, if you have a great fix or addition, post it to the new Blueprint Google Group.

About the changes

Now for a few, hopefully clarifying notes on some of the changes.

Elastic font sizes also means elastic line-heights, and as you may know, calculation of em’s in browsers are inconsistent at best. Because of this, I’ve taken the idealistic approach.

The line-heights (and by extension, the baseline) are set to values that should make them look quite perfect. In Firefox, for instance, they do. In Safari or Opera however, the baseline is a bit off.

This is a problem, but I am working on it, and I’m not even sure you’ll notice it at the default font size. :)

Contributed by print designer extraordinaire Mark Boulton, Incremental leading is a pretty exciting new feature. As most of the ideas in Blueprint, this one comes from the world of print design.

Say you have a sidebar, with smaller type than your main column. Having the same line-height in this column as in your main column might be a bad idea, as this implies a relationship between the content in each column that might not be there.

Enter incremental leading: This sets the ratio between the lines of the two columns to be 4:5, meaning that for 4 lines of text in the main column, you get 5 lines of text in the sidebar. Follow the link above to learn more about this technique.

The new compressed version is an absolute must for high-volume sites. It strips the core files of the framework down to 40% of their original size, mostly through removing comments and whitespace. Check out screen.css for information on how to use it.

And that’s that

I think this is a release one with great confidence can use on a live site, especially now that the glaring IE bugs are fixed. There might, however, be undiscovered bugs, so be on the lookout for a possible 0.4.5 release.

I’d just like to take this moment to thank all the people who have commented on, written about, contributed to, or mailed me about Blueprint. Your enthusiasm, ideas for features, bug fixes, and willingness to overlook obvious flaws in the first release has been nothing short of amazing. So thanks!

If you’d like to contribute or comment on BP, please send me an e-mail: olav at bjorkoy dot com.

Still here? Head on over to the Blueprint site to read about this new release, or just grab yourself a copy.

Credits

As always, please remember that BP is based on work by the following people:

The new BP logo was created by Ludwig Wendzich.

Blueprint: 54548, 6118, 1558, 1217

Mon, 06 Aug 2007 15:23:00 GMT

I’m tempted to ask you all if you can explain to me what just happened? I had no idea that this inconsequential experiment of a project could generate the following:

Visitors to the Blueprint site: 54 548
Downloads so far: 6 118
Del.icio.us bookmarks: 1 558
Number of diggs: 1 217
Average Digg comment opinion: Furiously offended
Support requests curve: Exponential
Giddiness level: Crimson red

So what does this tell us?

Blueprint is an unknown, untested and unused framework from an unknown guy launched from a highly irregular blog. This should make it quite clear that the craving for a proper designers framework almost couldn’t be greater.

As Blueprint is just a light breeze of a project, this gap in the market is a vacuum waiting to be filled. This sucks, as most vacuums do, so if anyone reading this is considering releasing their own framework or toolbox, please do so.

Just imagine what a project like BP on a greater scale can accomplish, if an experiment like this, with absolutely no merits or pre-launch hype, can gain this kind of traction.

Our new home

As a result of this unexpected surge in traffic, I’ve moved the entire project to Google Code.

This is not just because they’ll host the BP download for free (my available gigabytes from MediaTemple were quickly disappearing though), but also because Google Code is a great place for almost any project.

With a wiki, issue tracking and SVN hosting, this new arrangement should make future development of BP a great experience for all of us.

(It’ll also be interesting to see if I can actually get someone to contribute their ideas and patches to this project. Does anyone want to create a logo? ;)

Feature requests

I’ve jotted down some of the most popular feature requests, which, with time, will hopefully make their way into BP:

Relative font sizing everywhere
Multiple versions with different grid customizations
Liquid layout version
Compressed versions of the files to reduce load times

About the credits

It’s important to me that people remember that this framework was not written from scratch. The whole idea and code structure, for the entire project, including the entire way of setting up the grid, is based on something I consider to be great, nay, amazing work by the following people:

Also, the entire reset.css file was created by Eric Meyer, so make sure your praises are directed at the right people. :)

Please check out the rest of the credits at the new BP site.

Stay tuned

I have close to no control over what this project is spiraling into, so please excuse me if your mail or comments go unheard.

What I can promise you, is that blog posts and updates about BP will be frequent, in an effort to stagger the avalanche of support mails currently consuming my spare time.

(Also, the award for the coolest language to write about BP in goes to Dimox, with this entry)

Launch: Blueprint, a CSS framework

Fri, 03 Aug 2007 22:27:00 GMT

After reading an article by Jeff Croft on frameworks for designers, I started looking at the existing CSS frameworks, trying to find one that was right for me.

Never again was I to repeat the tedious task of creating a grid from scratch, defining default typography, or battling with inconsistent default browser CSS.

The only viable option I found was the Yahoo UI Library, but with its dozens of files, weighing in at a hefty 11mb (archived), YUI is just way too bloated for what I want from a designers framework.

(YUI is still a great framework though, and there’s lots to learn from going through its impressive code.)

Presenting Blueprint

Not happy with what I had found, I began writing my own CSS framework, and, after a while, figured that this was something others might find useful as well. So today, I’m releasing Blueprint: a light-weight, easy to use framework for CSS development.

(And when I say light-weight, I mean it. It’s almost too small to be called a framework.)

Here’s some of the features Blueprint brings to the table (not <table>, mind you):

An easily customizable grid
Some default typography
A typographic baseline
CSS reset for default browser styles
A stylesheet for printing
No bloat of any kind

The framework has only five CSS files, making it a light, refreshing breeze compared to the tornado that is YUI. All you have to do is include two CSS files (screen.css and print.css) in the of each HTML file, and you’re ready to go.

Blueprint is still in early development, so you shouldn’t use it any projects of importance just yet. I, however, am using it in all my new projects, fixing bugs as they appear. In other words, new versions should be released quite often.

Get your, got mine

If you’re still interested, head over to the Blueprint site to see an example, read the quick tutorial, or just grab yourself a copy. Oh, and please make sure to check out the “credits” section.

If anyone would like to contribute suggestions, bug reports, or even better, bug fixes, I’d love to hear from you: olav at bjorkoy dot com.

Battle comment spam with an extra form field

Wed, 01 Aug 2007 13:28:00 GMT

I was introduced to an ingenious solution to the problem that is comment spam.

All you have to do is add an extra input field to your comment form. The field should have a name that you won’t use or save, but at the same time, have a name that it’s certain that a spambot will fill in. Example:

<input type="text" name="lastname" id="lastname" />

I don’t store any users last name with a comment, so that should do just fine. Now comes the really clever part. Add a CSS rule to your stylesheet which hides this field from regular users, while still leaving it in the html for every spambot to see:

input#lastname { display:none; }

Lastly, change the part of your site that adds a comment to your database so that a comment is not added if the field “lastname” is filled in.

And there you go: nearly perfect comment spam protection. No need for bayesian filters, API-keys or (gasp) captchas. I can’t understand why this approach isn’t common, so what have I overlooked? :)

Update: I just got spammed again, but I’m not sure what happened. The spam comments was actually left on an entry where the comments are closed. Alas, I must dig deeper to unravel this mystery.

I still think the technique outlined in this post will work, and there’s been some interesting additions made in the comments.

Notes on the WWDC '07 Keynote

Tue, 12 Jun 2007 08:44:00 GMT

So that’s that. Not the most impressive keynote in recent years, but a good one nonetheless. I think a lot of the people who were overly disappointed hadn’t thought about what El Jobso meant when saying he’d demo a feature complete version of Leopard. That is, that in addition to some new features, the ones we heard about six months ago would also be showcased.

I think Leopard looks great. It seems very polished and refined, and sets straight a lot of the inconsistencies we find in the design of Tiger (brushed metal, Finder and so forth). The new Dock also looks good, and I bet a lot of non-mac users will remark its beauty at first sight. I’m less inclined to how good it will look when configured to one of the sides though. It seems like the icons would have to fall of to remain consistent. :)

Quick Look is something I’ve been waiting for with a passion. I’ve always detested how hard it is to preview files, even images. Why should I have to open Preview? Quick Look seems to do just this - just tap the space bar: instant preview. Lovely!

Time Machine will be interesting to try out. Engadget (which I’ve never liked because of their way too contrived bashing of Apple), calls it “backup for noobs”. I think that’s a way too myopic point of view. The fact that something’s extremely user friendly doesn’t mean it’s only for the less technically inclined. But I guess that’s what’s keeping those guys in Windows - an unbridled enthusiasm for the unnecessarily difficult. ;)

Safari for Windows, I’m not so sure about. Of course, bringing more people into the OS X user experience is a very good thing, but doing it by releasing a less-than-perfect imitation on Windows hardly seems to hit the spot. Many people will try Safari on Windows, and then drop the idea of a Mac all together, because they think this is what OS X feels like. It will be interesting to see how all this pans out. I might be wrong. I hope so.

However, the star of the show for me was not shown until after Jobs had left stage. The new Apple.com looks absolutely amazing. I’m even inclined to say it’s the best website out there, at least for any company trying to sell products. The product pages, and I’m not being sarcastic here, are so perfectly glossy and intuitively laid out that buying an Apple product seems like a better idea than ever before.

Watch the keynote here.

More reactions:

WWDC 2007 Keynote News by Gruber.
WWDC ‘07 Fallout by Heilemann.
Confession: My keynote smelled like ass by Steve himself.