In the left corner: Tyler Tate’s 1KB CSS Grid, a lean framework sporting 14 classes and the familiar conventions for enforcing a visual grid via CSS.

In the right corner: Vladimir Carrer’s 1-line CSS Grid, an experimental framework sporting a single class to cut nested column widths in half. The solution is mindblowingly brilliant, but does it work? Design tends to work in thirds, not halves. You decide.

Whether or not it’s a coincidence I chanced upon these two extremely simple CSS grid frameworks just days apart, news of these two solutions makes the CSS framework “scene” a lot more interesting. And accessible. I can imagine many front-end developers shying away from heavyweight frameworks because there are too many features, most of which won’t be utilized, and there are too many conventions, most of which aren’t easy to remember.

I’m not even going to get into how using these frameworks leads to unsemantic, presentational class names and lots of <div> soup reminiscent of <table>-based layouts. Let’s just be glad people are streamlining the application of design principles for the Web, namely grid layouts. When a better way comes out—maybe it’ll be display:table, maybe it won’t—we’ll adjust then.

In the meantime, we need to let our arsenal evolve. Balance out the spectrum with lightweight frameworks like these. Then add diversity as well. Look at the Javascript libraries—the tiny moo.fx, the venerable Prototype and Scriptaculous, and the designer darling jQuery—each one caters to a specific need. What other kind of grid frameworks do we need? Fluid? Do-it-yourself? Highly reputable? Unobtrusive? Oh, what will they think of next?

Originally posted on July 18, 2011 @ 4:11 am

Jon Tangerine, David DeSandro, Trent Walton have all come up with ingenious ways to create image-free logotypes by pushing the limits of CSS (Sean Martell made a mouth-watering CSS-based logo too, but doesn’t contain text) that one has to wonder: is this the next step in online branding and identity?

The simplest argument against this could be that a logo must be constant. In the absence of CSS styling, possibly even helper JavaScript, an image will not suddenly morph into a default browser style and render a brand generic. See the image above for how the CSS-based Opera logo degrades in different browsers.

Now that excludes the scenario where images are turned off, and where text—styled text—can come in. Instead of simple image replacement techniques, we now have @font-face embedding and other advanced effects to bring the text as close as possible to the original design.

Text is great because you can read it, as can search engines. Another thing text based logos have going for them is they’re easier to make bigger; that’ll win over a lot of clients.

But there’s a great deal of extra markup required to achieve the necessary look. Does this make sense for the notion of a logo, which is inherently more portable with an image than with a bunch of divs, spans, classes and IDs? Should logos always be images and nothing but, or can they be both text and images? Which should come first, designing the logo in the browser or in a graphics program? Or should all of this experimentation remain just that: experiments?

Me, I just love we could be on the brink of shattering print conventions, yet again.

Originally posted on May 28, 2010 @ 10:06 am