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

Remember my complaint about all the CSS3 syntaxes differing from one browser to another? It’s now addressed with CSS3 Please, a jQuery-based, in-browser editor that replaces multiple attribute values of the more complicated CSS3 syntaxes (from border-radius to rgba to @font-face) all at the same time, so you don’t have to.

In addition to syncing and normalizing changes across the necessary properties, it also sneaks in IE support for a few features via IE filters. Right now it helps you write the rules for: border-radius, box-shadow, linear-gradients, rotation and @font-face. A few more transforms like skew and scale are on their way, stay tuned.

You can preview your code on the box at the right side by toggling it on and off. When you’re done, click on the clipboard icon to copy the code.

This is a smart solution to a growing problem. However, even though I’m thoroughly grateful for this tool, I still want to axe the real problem, which is the inconsistent browser syntax. It’s unreasonable for a programming language to have redundant code, and while CSS isn’t really one, it’s still code. We’re still supposed to pride ourselves with efficiency, conciseness, and standards with any kind of code. We like to kick IE for constantly breaking standards; should we tolerate the same thing for other browsers just because they’re implementing cutting edge features?

Originally posted on March 12, 2010 @ 7:49 pm

It’s a disappointing day when you find a single serving site that generates the comprehensive syntax for the border-radius property, aptly named border-radius.com. Because not all browsers (and browser versions) support the latest and greatest things CSS3 can do, one has to resort to browser targeting yet again. Only this time, one browser’s syntax is different from another browser’s, and becomes a chore to write CSS for each.

There’s a pretty obvious explanation for the existence of browser-specific properties from SitePoint:

Vendors—browser makers—are free to implement extensions to the CSS specifications that, in most cases, are proprietary to their browser. They may do this for a number of reasons, such as adding new features for users, or for experiments and debugging. Most often, though, the extensions are used to release and test browser features that have been developed in the preparation of W3C drafts that have not yet reached Candidate Recommendation status—the extensions allow these new properties to be widely tested before they become available as standard CSS properties.

So for starters, the browser-specific CSS has prefixes like:

• -moz: Gecko-based browsers like Firefox
• -webkit: WebKit-based browsers like Safari and Chrome
• -ms: Internet Explorer
• -o: Opera
• -khtml: Konqueror

(The complete table is listed at the W3C.) That’s fine, but what I don’t get is why the syntax following the prefix isn’t always the same as the standard CSS syntax. The border-radius property is just one example, which is peanuts compared to the gradients syntax. Compare:

-webkit-gradient(
    linear,
    left bottom,
    left top,
    color-stop(0, rgb(0,10,148)),
    color-stop(1, rgb(45,58,246))
)
-moz-linear-gradient(
    center bottom,
    rgb(0,10,148) 0%,
    rgb(45,58,246) 100%
)

Sure, we can turn to generators like WestCiv’s and Damien Galarza’s—and we’ll probably be increasingly dependent on them in the future as CSS capabilities and their corresponding syntaxes grow more complex. But why must browser vendors insist on that when it only multiplies the code and maintenance necessary? Does it have to do with the way their engines parse the code, or something less significant?

Originally posted on March 2, 2010 @ 9:52 pm

Andy Clarke of For A Beautiful Web has presented a stylesheet for the web browser we haven’t been able to push off the provebial cliff: Internet Explorer 6.

When I asked myself why people visit my sites, and the ones that I make for other people, the answer was always “for the content”. Content that is almost always written words and that means type.

That is why I’m now advocating to my clients (and to you), that where feasible, not to waste hours in time and a client’s money on lengthy workarounds in an unnecessary attempt at cross-browser perfection. Instead, you and I should provide simple but effectively designed HTML elements. This means just great typography for headings, paragraphs, quotations, lists, tables and forms and no styling of layout.

But this idea is not new; this Universal IE6 CSS file contains just enough rules for a practically unstyled but easy to navigate website. You’re basically giving websites loaded in a low-fi browser a low-fi experience. Examples here, here, and here.

Despite its waning popularity, we seem to have amassed a whole buffet of solutions to the shortcomings of IE6, ranging from the hostile upgrade messages and campaigns to the subtle conditional stylesheets and scripts.

I can just imagine someone creating one of those personality quizzes out of this whole debacle: which IE6 compatibility fix are you? There’s an idea.

But really, dealing with IE6 and somesuch boils down to principle and circumstance. Can your clients and your conscience accept barely recognizable version of their sites in twentysomething percent of their audience? Is your sanity more precious than squishing mysterious bugs? Or do you feel like throwing some humor in?

Let me know if someone’s actually made a personality quiz about this; I’d love to take it.

Originally posted on May 21, 2009 @ 11:24 pm

Harry Roberts a.k.a. CSS Wizardry tweeted a certain tutorial by CSS Aid (page is dead now), which was enclosed with four little words (“Good lord, wrong much?”) that echoed such alarming levels of horror and shock (considering he tweets about poor examples of HTML/CSS code everyday), that I had to check it out.

First, the tutorial was entitled “Tables Without Tables”. If that doesn’t trigger warning bells in your head, then consider the opening paragraph:

It’s the year 2009, CSS rendering has vastly improved from when it was released, so there is no reason for any website to use tables as layouts. Although you can ditch the table tag when it comes to layouts, you may someday need to use it for what it was made for…or do you? I am going to show you an easy way to make a table with a simple unordered list.

No. Just no. Yes, <table>-based layouts are considered wrong because HTML is supposed to properly represent data. Lists should be lists. Tables should be tables. Layouts that look like tables (grids) can be done in CSS. That’s semantics, the core principle of web standards.

But avoiding the use of <table>s at all costs is no better. Perhaps it’s even worse, since it demonstrates not only ignorance but false expertise, feigning arrogance over an HTML element that has been shuddered at because of its misuse and abuse.

The page has gone down in between the time that I read the tweet and wrote this post. Fortunately the forum thread that seems to be the source of the link is still up, and shows us the author’s reasoning for writing the tutorial. Take post #7:

Because I hate the <table> tag

Is this the extreme dark side of web standards, where we’ve been conditioned to hate <table>s so much that we can’t even think to use them for what they were meant for anymore? A sad, sad turn for us all.

By post #15 he’s already backed down and promises not to use the experiment for real-life cases, but this summarizes things nicely:

It’s a pointless experiment though. It’d be like experimenting making a house out of tampons. Doable but just plain wrong.

It’s bad enough that we have to deal with preaching proper web standards, dropping crusty old browsers from, and adding newfangled technologies to our web design arsenal. Let’s not get sidetracked by punishing HTML elements by twising them into things they weren’t meant to be.

Originally posted on August 20, 2009 @ 4:56 pm