The following account represents one person's unabashed love for an up and coming web font service. 

As many know by now, the dawn of true web type is finally upon us. Dozens of service offerings have sprung up, pricing models have become more reasonable, and @font-face usage is becoming far more ubiquitous than it was just a year ago. I couldn’t be more thrilled. 

We’re so close to the typographic possibilities that web designers have always dreamed of, but there are still some roadblocks in terms of what works best for agencies and clients. I won’t weigh the pros and cons of different services and options. That’s been done elsewhere already. I'd rather explain why I love Fontspring so much for our needs at Viget. For a more technical and pragmatic view on exploring the realities of @font-face usage see Doug's post. 

Thinking back to childhood, there were those who lined up their crayons, organized them by color, and sharpened them in that crayon sharpener in the back of the crayon box before ever touching crayon to paper. And then there were those who had crayons flung everywhere, mixed old and new crayons together, and basically worked in total anarchy.

One of the things that slightly bugs me about Omnigraffle is that it doesn't have built-in objects for basic HTML form elements that behave like real ones. I would love to have these to add a little more realism to my wireframes and possibly extend them to work inside of a more full-on prototype with "real" forms. So, I recently took a shot at creating some clickable form elements for myself using a combination of Applescript and the custom data feature.

Warning: What I hacked together works, but its not foolproof. I've included some notes below that should help you in using this stencil.

Download the Stencil (Viget.FormElements.gstencil, 156 K)

Checkboxes

• These can be clicked on to toggle between checked and unchecked states.
• The label is stored as "value" within the object's data.
• The state (checked or unchecked) is stored in the object's data and can be keyed off of for further prototyping.

Radio Buttons

• These can be clicked to change the selection in a group of radio buttons.
• The label is stored as "value" within the object's data.
The state (selected or unselected) is stored within each object's data and can be keyed off of for further prototyping.
• They are grouped together as a table, so it's easy to add new rows or columns of radio buttons.
• The unselected radio image is a separate object that needs to live behind the table and can't be grouped with the radio buttons (sorry, it'll break the script).
• To create multiple groups of radio button on the same canvas, you'll need to give each group a unique name. The table has a data item "groupName" currently set to "Fruits". Each object in the table has a data item "group" - also currently set to "Fruits". Both of these need to be changed when another radio group is created.

Drop Downs

• The option that will be displayed when the dropdown is collapsed is stored as "defaultOption" within the object's data. When it's expanded, "allOptions" will be displayed.
• A lot of the styling is contained within the script, so if you want to tweak the styling, I would suggest looking at the script to see how styles are being applied.
• The value that is selected is not passed back to the parent object, so this element is not set up for further prototyping. It is good for showing the list of drop down options without using another layer.

I've also included some buttons and text fields in the stencil. I'm sure there are improvements that can be made to these, so everyone should feel free to use and modify this stencil. If anyone creates something better (especially a dropdown that fully "works"), I'd love to hear about it.

Update 01/11/12: new code at the bottom of this post.

Sass has been kicking around for a while, but I hadn’t given it a try until just recently. Sass usually goes hand-in-hand with Rails, Compass makes it so easy to run Sass on standalone projects that I’ve started using it on nearly everything. The result is faster, DRYer, more enjoyable coding. The biggest benefit for me has been Compass’s sprite generation, which — if done right — can cut down your coding time and filesize.

Sprites are an optimization best practice, but they’re no fun to work with. Making them by hand requires a lot of nudgy mechanical math, and most auto-spriting tools create more work than they save. Compass does sprites the smart, Sassy way: by compiling them from your code and filling in the CSS rules for you.

It also does things the Rails way, in that it provides conventions to follow rather than configuration to specify. I’ll walk you through my process for Compass spriting on a simple, standalone project.

This is the first in a series I’m calling, “JS 201.” It’s not introductory material, but is instead that helpful middle ground between the basics and pretty much anything John Resig writes. Short, practical, typically plain-ol’-JavaScript tips is what you’ll get.

I’m in the middle of working out a new feature for a project that requires JavaScript to append some markup, stylesheets, and scripts to a page. The task is fairly straightforward: JavaScript has native capability to do all of that. I’m looking at you, createElement and appendChild.

I did run into a problem, though. A piece of JavaScript required styles be applied to certain elements before it should execute. Unfortunately, the script was executing while the stylesheet was being loaded. Like most reasonable front-end developers, I figured I’d just run a function when the onload event fired on the link element. It works for images, why not for stylesheets, right? Wrong!