Web browsers can be pretty self-absorbed. Vendor prefixes (and conditional comments before them) are narcissistic solutions that favor browser detection over feature detection, contrary to our industry’s best practices. As a result, browser makers have gotten themselves in a bit of a pickle.

To be fair, their intentions were (and still are) good. Our designs have benefited from proprietary or burning-edge CSS features, most of which would be difficult or impossible to implement without vendor prefixes.

The problem is, we got here by asking the wrong questions.

We shouldn’t care about whether or not our design is viewed in a “WebKit” browser, Firefox or Internet Explorer. We also shouldn’t care about whether or not a feature is in “alpha” or “beta”, distinctions too broad and subjective to be of much practical use.

Here’s what we really need to know:

1. Does the browser support this feature?
2. Can the browser successfully parse the syntax I’m using?

Media queries already work this way. The browser only renders the styles therein when the query is true. Because CSS is fault-tolerant, browsers that don’t support media queries will ignore the ruleset entirely.

What if we adopted a similar syntax for feature detection? Let’s use our imaginations and dive in to this 100% fictitious, hypothetical example:

@feature (transition) {
    .example {
        transition: background-color .25s ease-in-out;
    }
}

The .example ruleset will only be rendered if the browser supports the @feature query and the transition property.

By implementing the not operator from media queries, we could get hardboiled and only use queries for fallbacks:

.example {
    transition: background-color .25s ease-in-out;
}
@feature not (transition) {
    /* Fallback rules */
}

If these (again, hypothetical) feature queries could be extended to test values as well as properties, we could test for differences in syntax:

/* -moz syntax */
@feature (linear-gradient(left, white, gray)) {
    .example {
        background-image: linear-gradient(left, white, gray);
    }
}
/* -webkit syntax */
@feature (linear-gradient(linear, left center, right center, from(white), to(gray))) {
    .example {
        background-image: linear-gradient(linear, left center, right center, from(white), to(gray));
    }
}

This idea obviously has its flaws. In the latter example, things can get pretty verbose (not to mention repetitive). Also, it feels a little unintuitive to group rules by feature instead of by element or media (even though Modernizr already encourages this, albeit much more succinctly). In spite of these flaws, feature queries would allow us to design for features instead of browsers, which feels like a step in the right direction.

Then again, I may be woefully misguided. Thoughts?

Yesterday, Lifehacker published a neat article on How to Roll Your Own Awesome Drag-and-Drop File Sharing Service. The instructions therein are great, but consider replacing Step 4 (their ZIP file of PHP scripts) with Indexy.

I made Indexy so I could have easily themeable, PHP-based file listings (demo here). Some of its features include:

• Automatic subdirectory scanning (no file duplication or cron jobs necessary).
• A default theme optimized for smartphone and tablet viewing.
• The ability to create new themes using Mustache (a dead-simple templating language) and any combination of HTML, CSS and JavaScript you’d like.
• A built-in Markdown viewer.
• Source that’s open and easy to fork on Github.

Indexy was created for my own personal use, so I’m sure there are a ton of ways to improve it. I encourage folks to give it a whirl, make tweaks and contribute back to the source.

View or download Indexy on Github

Brand loyalty’s a funny thing. I don’t mind switching between Windows and OS X on a daily basis. I request Coke out of habit, but you could hand me a Pepsi (or even an RC) and I wouldn’t care to correct you.

But mechanical pencils? Give me Pentel Twist-Erase 0.9mm or give me death!

I’ve used these pencils since they were recommended to me in an extracurricular figure drawing class I took during high school. I jokingly referred to my first as “Excalibur,” and the nickname stuck.

A few reasons why I love this pencil:

• It’s easy to hold, with the right circumference and an understated but functional rubber grip.
• The 0.9mm lead is closer to the width of a traditional pencil tip than the more common 0.5 and 0.7mm sizes.
• You can twist the far end to extend the length of the eraser. Refills are infrequent, and replacement erasers are much harder to misplace due to their size.
• They last a long time. I’ve only broken one after 5 or 6 years of daily use.
• They’re extremely affordable and easy to find online or at any office supply store.

After Matt Bepler mentioned the pencil in a comment, it seemed like the right time to sing the praises of one of my favorite tools of the trade.

Now I’ll just bide my time until that Pentel endorsement deal comes rolling in…

Allison Wagner wrote a thoughtful post summarizing her experience with LESS on Happy Cog‘s lovely blog, Cognition. Her criticisms echoed my own when I first started using the self-described “dynamic stylesheet language,” so I thought I’d respond to them here so that other designer/developers might avoid similar points of trepidation.

She starts with the difficulty of debugging the compiled CSS:

LESS, by virtue of the compiler, rewrites and reformats CSS, which means the line numbers referenced by Web Inspector or Firebug are guaranteed to be wrong. I found myself having to search for styles a lot more, whereas in the past I would have simply referenced the line number in the debugger. While this may seem like a small annoyance to many, it slowed me down quite a bit.

Yep, totally annoying and, as Allison suggests, never 100% avoidable. While I would argue that fundamental LESS features (such as variable and operator support) more than make up for time lost to this quirk, there are still a couple of ways to minimize its impact:

1. Use @import in your primary style sheet to include your mixins and variables in one or more separate files. Since these will usually contain the majority of your un-compiled styles, the resultant CSS should map a little bit closer to your LESS line numbers.

2. If you’re using less.js for development (as opposed to less.app or a server-side compiler), calling less.watch() will tell the script to asynchronously recompile whenever your style sheet is modified. This can greatly expedite troubleshooting, especially if you have enough screen real estate to develop and preview side-by-side.

Allison’s other concern is the risk of “code bloat”:

Let’s face it, CSS is not exactly a champion of the DRY (Don’t Repeat Yourself) programming principal. Repetitious values in a pure CSS style sheet are the mark of a solid design system. Even the most well-written, pure CSS is typically teeming with identical declarations repeated over and over. I like that LESS advocates a very DRY approach to writing styles with shortcuts like mixins. And while the DRY approach is promoted inside the LESS files themselves, the generated CSS is anything but DRY. In fact, it’s far less DRY than pure CSS.

She provides a brief example of potential code bloat while suggesting that LESS users “are encouraged to embed [declarations] into each selector individually in the form of a mixin”. To be clear, this behavior isn’t encouraged by LESS any more than repetitious selections are encouraged by jQuery. If you use LESS to enhance your existing principles of well-formed and scalable CSS, there’s no reason why your code bloat should become unmanageable.

Example time! Let’s say we have an hCard with a photo, full name and role we’d like to style. Our vanilla CSS might look like this:

.vcard {
    border: 1px solid #ccc;
    margin: 10px;
    padding: 10px;
    -webkit-border-radius: 3px;
    -moz-border-radius: 3px;
    border-radius: 3px;
}
.vcard, .vcard .photo {
    -webkit-box-shadow: 0 1px 3px #eee;
    -moz-box-shadow: 0 1px 3px #eee;
    box-shadow: 0 1px 3px #eee;
}
.vcard .photo {
    float: right;
    margin: 0 0 10px 10px;
}
.vcard .fn {
    font-weight: bold;
    text-transform: uppercase;
}
.vcard .role {
    color: #999;
    font-size: 87.5%; /* 14px / 16px */
}

Not unmanageable. But let’s see how we can make it easier to read, write and expand upon using LESS. We’ll start by looking for things that can be re-used or streamlined. The gutter value seems to be consistent, so we’ll move that to a variable so we can change it easily. Also, those vendor prefixes are a bit lengthy, so we’ll move them into mixins we can re-use anywhere.

@gutter: 10px;
.border-radius (@radius) {
    -webkit-border-radius: @radius;
    -moz-border-radius: @radius;
    border-radius: @radius;
}
.box-shadow (@shadow) {
    -webkit-box-shadow: @shadow;
    -moz-box-shadow: @shadow;
    box-shadow: @shadow;
}

With our variables and mixins established, we can rewrite our LESS like so:

.vcard {
    border: 1px solid #ccc;
    margin: @gutter;
    padding: @gutter;
    .border-radius(3px);
    &, .photo {
        .box-shadow(0 1px 3px #eee);
    }
    .photo {
        float: right;
        margin: 0 0 @gutter @gutter;
    }
    .fn {
        font-weight: bold;
        text-transform: uppercase;
    }
    .role {
        color: #999;
        font-size: 14 / 16 * 100%;
    }
}

Note the use of the ampersand combinator, which will be replaced with the parent selector (.vcard) in the output. Combined with the nested .photo, .fn and .role selectors, we’ve avoided re-typing the parent selector altogether. We’re no longer repeating vendor prefixes or margin/padding sizes, and LESS can do the font-size math for us. Best of all, the output is identical to that of our vanilla CSS. Sayonara, code bloat!

I’m not saying that Allison’s criticism isn’t a possibility in LESS… only that it’s a direct result of how you choose to use the language. In his blog post CSS: Taking control of the cascade, Jason Z. illustrates a LESS technique that he finds valuable in spite of its verbosity. LESS won’t make these decisions for you, it only provides the tools to do the job faster and easier than you could have otherwise.

To quote Stan Lee in Spider-Man’s first appearance, “with great power there must also come — great responsibility!”

I am convinced that there will come a time when the web will take over and no one will be able to tell the difference between a web app and a native one but we’re not there yet. Today and for a few years, native apps will still provide a better experience.

I have a profound respect for designers who start from a purpose instead of a platform.

I was fascinated by Kill Screen’s interview with Tiny Wings creator Andreas Illiger, particularly how rejecting opportunities has allowed him to retain creative autonomy.

The Icon Handbook is clearly the essential resource on the subject, and not merely by default. Jon Hicks has done a wonderful job covering many aspects of icon design from history to theory to execution. Plus, it’s gorgeous! I can’t wait to receive the print edition.

Finally, IGN posted a wonderful “making of” video for Rayman Origins, one of my very favorite games of 2011 and arguably one of the best platforming games of all time.

I usually shy away from political issues here or on my public social media channels. If you’re reading this, you probably want to see posts on web design, games, comics and assorted geekery. Other nonsense would seem, well, nonsensical, so I choose to omit it.

I’m making an exception today because SOPA and PIPA threaten to irreparably damage the foundation of the web (DNS) in a futile and misguided attempt to curb piracy. New and innovative apps, websites and social networks could be crippled without sufficient process just to stop a handful of errant users from uploading copyrighted material.

If you’d like to protect this industry’s ability to innovate, please contact your representative and let them know that you disapprove of this legislation.

Here are some helpful resources:

• EFF: Stop the Internet Blacklist Legislation
• SOPA Strike
• A List Apart: Say No to SOPA
• The Verge: The SOPA Story So Far

Thank you for indulging this bout of activism. We now return to our regularly scheduled drawings of Rayman holding a Portal gun and Sonic the hedgehog running like an idiot.

Portal 2 (PS3/Steam) and Rayman Origins (PS3) continue to amaze me. Both titles, in completely different ways, aren’t just a blast to play… they teach me things about game design and design in general. They are engrossing, masterful works.

Some honorable mentions:

• Super Mario 3D Land (3DS)
• Pushmo (3DS)
• League of Evil (iOS)
• Tiny Wings (iOS)
• Sonic CD (iOS)
• Jetpack Joyride (iOS)

I also thought Sonic Generations (PS3/Steam) was fun, but mostly for the nostalgia. I haven’t had a chance to play Bastion (Steam), Q.U.B.E. (Steam), L.A. Noire (PS3) or Arkham City (PS3) yet, though I’d like to.

I don’t think it’s an accident that most of these titles are portable, with shorter play sessions. When I was in school, I could devote whole weekends to uncovering every unlockable in some sprawling epic. Today, every hour I spend playing games is an hour I’m not making games… or websites, or apps, or whatever.

As an adult, shorter games feel somewhat merciful.

Job titles are weird. Here are a few I’ve had (seniority omitted for brevity’s sake):

• Designer/Developer
• Graphic Designer
• Interaction Designer
• Visual Designer
• Experience Designer

All of these have separate Wikipedia articles. None of them rank in the 2010 ALA survey findings (unless you count “Other,” the third most popular option).

In college I majored in Interactive Media Design, which they used to call Multimedia & Web Design. After I graduated, they changed it to Web Design & Interactive Media before merging it back into Graphic Design.

Some of my favorite web designers are graphic designers. Some of my favorite game makers are also my favorite web and interface designers. It seems like half the designers I’ve ever known are musicians (the other half are, of course, photographers). One of them is an abstract painter and sculptor, and one just built a chicken coop.

Perhaps the web naturally attracts the oddballs and outsiders of adjacent industries. Or maybe it’s too young to accurately define itself.

Another possibility: This could be the first medium where making and publishing something is often quicker than explaining it. Sometimes we don’t even know what we’re doing until our users clue us in.

This time last year, Tim Sears and I released Ramps 1.0 to an unsuspecting public. A couple weeks later, Apple featured us as an iPhone Game of the Week. In May, we doubled the game’s content with the dark world update.

During that time, we received one request more than any other: iPad support. It took a while to do it right, but that request is now a reality.

Ramps 1.2 is universal, a free update for existing users, and available now!

Get Ramps in the iOS App Store

For more info, check out my post on the Backabit blog. Happy holidays!

So how’d it turn out?

The pitch

I’ve been a frequent user of Wacom tablets for years (at one time using a “Penabled” tablet PC as my primary laptop), so my quality bar for styluses is set pretty high… every capacitive stylus I’ve tried has failed to meet my expectations. Because of this, I ignored most of the initial Cosmonaut murmurings on Twitter.

Luckily, Calvin Ross Carl mentioned the campaign to me again, suggesting I at least watch the introductory video.

Despite my initial skepticism, I was impressed by the concept. Instead of attempting to circumnavigate the touchscreen’s limitations to deliver a compromised fine-tip writing tool, Studio Neat embraced the lack of precision, drawing inspiration from dry-erase markers and emphasizing the weight and feel of the object itself. I appreciated that thoughtfulness and forked over a paltry sum for the opportunity to try it firsthand.

The stylus

The Cosmonaut arrived in a stylish-yet-understated cardboard box, the soviet space theme lovingly maintained throughout the presentation. It made me smile.

The stylus itself feels very substantial in the hand. It’s a little heavier than a whiteboard marker, moreso as it comes to a point. I had to look up antonyms for “slippery” to describe its rubberized, outer coating, but “unslippery” is still the best description Thesaurus.com or I could come up with.

The pen tip feels firm and plastic to the touch, but it’s actually squishy and flexible. It’s tough to describe, but a brief tap with the tip of your finger will feel very resistant, whereas a firmer tap and hold will make it flex inward. It’s a surprising combination that makes the stylus feel sturdy and reliable without risking damage to the screen.

In use

I tried the Cosmonaut in my two favorite iPad sketching apps, Adobe Ideas for whiteboard-style doodling and Procreate for painting.

When sketching in Ideas, I found I had to press just a little more firmly than I would have with my finger, but once I learned to do this without trepidation, writing and doodling began to feel natural. While it didn’t feel quite like a dry-erase marker on a whiteboard in terms of effortlessness, I definitely felt my dexterity improve with the stylus.

This improvement was even more noticeable when painting. Procreate’s interface is so well-designed to begin with that, combined with the comfort of the Cosmonaut, I quickly forgot about either tool and just enjoyed the act of making a fun little Mickey Mouse sketch. For me, that’s the mark of a great design… the object disappears, allowing you to focus on the task itself.

The verdict

I feel a strange sense of pride in writing this review. While Studio Neat clearly deserves 99.9% of the credit for the Cosmonaut’s existence, it feels great to have been an early supporter.

This is easily my favorite capacitive stylus. By abandoning the goals of traditional, resistive touchscreen input devices and instead focusing on comfort and contextual appropriateness, they’ve successfully created a useful and charming tool that’s earned a spot on my desk (in the Gorillaz mug, next to my Wacom pen and my favorite mechanical pencil).

Now I just have to count the days until I get to watch Indie Game: The Movie…