bjorkoy.com

Page Width and Device Independence

2010-09-03T00:00:00-07:00

Page width has to be one of the most debated aspects of web design. The discussion used to revolve around fixed versus fluid layouts, and in the case of fixed layouts, the maximum width a website could use without invoking the dreaded horizontal scrollbar.

Recently the notion of device-specific layouts and page widths has been all the rage, through the use of media queries, user agent matching and dynamic layouts with Javascript. For instance, by using CSS media queries, a site can serve up different layouts to phones, tablets and computers based on their respective screen sizes.

Altering content based on screen width is a wonderful and powerful feature, but there’s a few caveats to remember. If you’re designing a typical website, but have a specific device in mind, you might be doing something wrong.

There’s an ever increasing spectrum of device screen sizes, and while some devices are more popular than others, using exact matching to customize a layout to a specific device brings back memories of “this site can only be viewed through IE6 or newer”. Common sense dictates that the spectrum will become more homogenous over time. Right now, there seems to be three main screen width steps represented by phones, tablets and computers, but new devices will surely pop up in between these ill-defined plateaus.

In designers terms, this means that a site should work fine with any screen width, just as it should work fine with any screen height. We can expect users to scroll vertically, but expecting users to continuously scroll in two dimensions is no solution. Page width has to be device independent, not device-specific.

The ideal solution then seems to be to use a fluid layout, with tools such as media queries to fluidly add, move or remove elements as the screen width changes, but not to identify the actual device in use. This way, the layout is not dependent on any one device or window size, but usable on any current or future device screen.

Contextual Fluid Grids

2010-05-25T00:00:00-07:00

While reading A List Apart’s latest article on responsive web design, their particular use of fluid grids from a previous article struck me as odd. There seems to be two ways to create such grids – trying to work around context or using it to your advantage to create contextual fluid grids.

There are two things that may seem difficult about creating fluid grids: how to use context and how to employ margins. The technique in the ALA article computes widths and margins through calculations given the current context, i.e. by using the width of the closest container element in relation to the total page width. In contrast, I prefer embracing context which results in a system that is as powerful yet simpler to use.

Take a look at this demo page to see what we’re trying to accomplish. Try resizing the browser window and the text size.

Embrace context

Context can be used by letting every container element define its own sub-grid. For instance, if we have a row element, we can divide this element into a number of columns. Each of the column elements in the container can again define their own grids with the same number of columns as the first container. The basic insight is that context can be used without any special computations. Consider the following HTML:

<div class="row">
  <div class="span12">50%</div>
  <div class="span12">50%</div>
</div>

<div class="row">
  <div class="span12">50%</div>
  <div class="span12">
    <div class="row">
      <div class="span12">25%</div>
      <div class="span12">25%</div>
    </div>
  </div>
</div>

Ignore the lack of semantics, the class names are there for ease of explanation. The first row in this example has two columns spanning 50% of the page width. The second row first has one column spanning half the page width, and then two columns spanning 25% of the page. Pretty simple.

Notice that all spans use the same column numbers. Here, the total number of columns is 24. The second column in the second example spans 50% of the page width, and is divided into 24 new columns. Since the wrapping element is 12 columns wide, 12 columns in the context of this element corresponds to 6 columns, or 25% of the page width. By embracing context, the grid can be as complex as you want without having to calculate precise floats.

Programming the grid

As I mentioned in a previous post, the task of creating grids lends itself well to CSS extensions such as SASS. This is true both for fixed and fluid setups. By specifying the number of columns each primary and sub-grid should have, creating a semantic and flexible implementation is quite simple. Calculations are done with percentages and EMs to ensure proper fluidity and support for text resizing.

$grid_columns: 24;        /* number of columns */
$total_max_width: 950px;  /* max page width */

/* compute width of 1 column */
$grid_col_width: 100% / $grid_columns;

/* create a div spanning n columns */
@mixin col($n: 1) {
  float: left;
  @include span($n);
}

/* make an element span n columns */
@mixin span($n: 1) {
  width: ($n * $grid_col_width);
}

/* prepend n empty columns */
@mixin prepend($n: 1) {
  margin-left: $grid_col_width * $n
}

/* append n empty columns */
@mixin append($n: 1) {
  margin-right: $grid_col_width * $n
}

/* define max width in EMs for proper grid resizing */
body { 
  font-size: 100%; 
  max-width: ($total_max_width / 16px) + em; 
} 

/* a row defines a new grid or subgrid */
.row { float: left; width: 100%; }

/* mixin example usage */
#menu { @include col(5); }
#side { @include col(5); }
#main { 
  @include prepend(1);
  @include col(12); 
  @include append(1);
}

/* For the html example */
@for $i from 1 through $grid_columns {
  .span#{$i}    { @include col($i); }
  .prepend#{$i} { @include prepend($i); }
  .append#{$i}  { @include append($i); }
}

Columns as margins

You may have noticed that this example does not consider margins as a part of the column definition. Fluid margins is often the aspect that makes creating such a grid difficult. Ensuring that margins span the same width across context, and that the widths they span don’t get too small to be rendered, can be a pain.

The proper approach is to see margins between columns as empty columns, not as empty gaps between columns. That is, the columns themselves do not have specified margins. Instead, empty columns are appended or prepended where margins are needed. This makes sense as margins between columns in fluid layouts almost always span greater widths than that of their fixed counterparts. And, if your require fixed margins, they can always be applied to an inner element of a column (as in the demo page).

However, we often need narrow margins, even in fluid layouts. To accomplish this, a high number of columns is needed, as columns now not only specify the width of a column, but also the negative space between them. As always, choosing a number with a high divisor count is essential. The best approach is to use a highly composite number (a positive integer with more divisors than any positive integer smaller than itself) such as 6, 12, 24, 36 or 48. This gives you the most flexibility in creating grids with applicable divisive features.

The result is a simple fluid grid which, because of the use of contextual sub-grids, can be as complex and specific as you need. By using an extension such as SASS, no complex calculations have to be done, or re-done when the design needs a change.

Semantic CSS Grids With SASS

2010-05-22T00:00:00-07:00

You design websites, and since you’re brimming with empathy, you want to use a grid-based layout to ensure a minimum amount of confused users. Great! However, you also design a lot of websites, and find yourself doing the same operations for setting up a basic grid at each ⌘+N. Not good.

The way to fix this is a sort of design framework. The problem with such a framework has often been mixing presentational logic with your sweet HTML hierarchy. Nuts to that, you say, I’d like both my CSS and HTML clean and semantically correct. Well, here’s a way to get the best of both worlds.

Using SASS, or any other equivalent CSS extensions, defining functions and variables lets you set up a grid while you stay away from anything less than semantically correct. Here’s a setup of variables and mixins I’ve been using lately:

/*
  Choose a grid width, the number of columns and the margin between columns.
  The result of the following equation has to be an integer, not a fraction:
  
  (width - (columns - 1) * col_margin) / columns = N
*/

$width: 960px;   /* total with of page */
$columns: 24;    /* number of columns */
$col_margin: 0;  /* margin between columns */

/* math magic */
$col_width: ($width - ($col_margin * ($columns - 1))) / $columns;
$col_total_width: $col_width + $col_margin;  

/* create row div */
@mixin row() {
  float: left;
  clear: both;
  width: $width;
}

/* create a column div */
@mixin col($n: 1) {
  float: left;
  @include span($n);
}

/* make an element span n columns */
@mixin span($n: 1) {
  width: ($n * $col_width) + (($n - 1) * $col_margin);
  @if $n == $columns {
    margin-right: 0;
  } @else {
    margin-right: $col_margin;
  }
}

/* the last column in a row needs this */
@mixin last() {
  margin-right: 0;
}

/* prepend n blank columns  */
@mixin prepend($n: 1) {
  margin-left: $col_total_width * $n
}

/* append n blank columns */
@mixin append($n: 1) {
  margin-right: $col_total_width * $n + $col_margin
}

The attentive reader will note I’m using the new SCSS syntax found in SASS 3. This is great, since the syntax is completely compatible with CSS (at least CSS 3), ensuring sweet validation of your files. Because these are mixins, your CSS classes and ID’s can still retain semantic names, and the presentation logic remains where it should be:

.section { @include row; }
.section .main { @include col(18); }
.section .sidebar { @include col(6); @include last; }
.section .promo { 
  @include col(12); 
  @include prepend(6); 
  @include append(6); 
  @include last;
}

If you’re making an extensive site from scratch, or rarely doing new projects, I would suggest using the manual approach. This technique is more for those of us that sometimes needs a conveyor-belt type of web design output. Either way, the point to remember is that a lot of CSS logic lends itself well to programming, and by using an extension such as SASS, much manual labour can be offset by functions and variables.

Blogging With Jekyll, Git and a VPS

2010-05-15T00:00:00-07:00

Welcome to another installment in the never-ending story of my quest for the perfect blogging setup. This time, we stray far from the conventional use of content management systems, shared hosts and database storage.

Yes, like so many others, I’m jumping on the bandwagon of using a local setup for generating blog posts, and then publishing the final HTML to my server using Git. Here’s the setup:

Every blog post is a new file on my machine, ensuring great portability and an easy transition to future systems (yes, it will happen). Post files can be anything from markdown and textile, to html and plain source code.
To generate the final site, each post and page is processed by Jekyll, which has support for layouts, partials, syntax highlighting, automatic regeneration and so forth.
The finished HTML is pushed to a git repository on my Slicehost VPS, which gives me full control over the final result.

You can probably see the benefits and drawbacks of this system, so instead of listing pros and cons, I’ll show you how to set it up.

Jekyll has a great wiki describing its many features. You’ll also find examples of how others have customized their installations in the “sites” section. The only mildly interesting thing I did was to make a script for quickly creating new blog post files:

# Create new jekyll post and open in textmate
# $ ruby _new.rb This is the title

# The arguments form the title
unless ARGV[0]
  raise "Please provide a post title."
end

# Create a URL slug from the title
def slugify(title)
    str = title.dup
    str.gsub!(/[^a-zA-Z0-9 ]/,"")
    str.gsub!(/[ ]+/," ")
    str.gsub!(/ /,"-")
    str.downcase!
    str
end

# Create parameters
title  = ARGV.join(' ')
slug   = slugify(title)
prefix = Time.new.strftime("%Y-%m-%d")
file   = "#{prefix}-#{slug}.markdown"
path   = File.join(File.dirname(__FILE__), "_posts/#{year}/#{filename}")
text   = <<-eos
---
title: #{title}
layout: post
---

eos

# Create a new file and open it in textmate
File.open(path, 'w') { |f| f.write(text) }
system("mate #{path}")

By the way: Jekyll has built in support for using latent semantic indexing to create lists of related posts. It’s a slow implementation of a computationally demanding technique, but at the same time, very cool.

When jekyll has generated the html in its “_site” folder, it’s time to upload the new post to the web server.

To upload new content to the server, I use the setup described in this guide. Three distinct git repositories are established to provide the perfect workflow, where publishing a post is as easy as committing and pushing the new post to the server.

My local copy is stored in the first repo. On the server, there is a “live” repo, which is the site served by apache, and a “base” repo which facilitates synchronization between the two other repos. My local changes are pushed to the base repo, which tells the live repo to update its content. The point is to avoid pushing content to a repo containing a working copy - using three repos is way easier. The guide has all the details if you wan’t more on this setup.

All that’s left is creating a virtual host in apache, it’s document root pointing to the “_site” folder in the live repo. My server also have PHP and MySQL installed, so that my Mint installation can reside in the same repo as the rest of the jekyll files. Sweet!

There’s something greatly reassuring about having a separate markdown file for each blog post, a point underlined by the annoying xml-parsing I did to migrate my old posts into this new system. My posts are safer than ever and can be written in any environment I see fit. In the end, this is a system only a programmer would love, but also the only system I, as a programmer, do love.

Conway's Game of Life in Ruby

2010-05-14T00:00:00-07:00

#
# Conway's Game of Life in Ruby
# http://en.wikipedia.org/wiki/Conway's_Game_of_Life
# 
# Some code from this excellent article:
# http://rubyquiz.strd6.com/quizzes/193-game-of-life
#

class Cell
  attr_writer :neighbors
  
  def initialize(seed_probability)
    @alive = seed_probability > rand
  end
  
  def next!
    @alive = @alive ? (2..3) === @neighbors : 3 == @neighbors
  end
  
  def to_i
    @alive ? 1 : 0
  end
  
  def to_s
    @alive ? 'o' : ' '
  end
end

class Game
  
  def initialize(width, height, seed_probability, steps)
    @width, @height, @steps = width, height, steps
    @cells = Array.new(height) { 
      Array.new(width) { Cell.new(seed_probability) } }
  end
  
  def play!
    (1..@steps).each do
      next!
      system('clear')
      puts self
    end
  end
  
  def next!
    @cells.each_with_index do |row, y|
      row.each_with_index do |cell, x|
        cell.neighbors = alive_neighbours(y, x)
      end
    end
    @cells.each { |row| row.each { |cell| cell.next! } }
  end
  
  def alive_neighbours(y, x)
    [[-1, 0], [1, 0], # sides
     [-1, 1], [0, 1], [1, 1], # over
     [-1, -1], [0, -1], [1, -1] # under
    ].inject(0) do |sum, pos|
      sum + @cells[(y + pos[0]) % @height][(x + pos[1]) % @width].to_i
    end
  end
  
  def to_s
    @cells.map { |row| row.join }.join("\n")
  end
end

Game.new(100, 50, 0.1, 100).play!

Automatic compilation of Sass and HSS files

2008-10-21T00:00:00-07:00

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

2008-09-02T00:00:00-07:00

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

2008-02-20T00:00:00-08:00

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

2008-01-11T00:00:00-08:00

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

2008-01-06T00:00:00-08:00

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.