Mozilla has sparked a bit of controversy lately by talking about supporting the -webkit prefix, a prefix that has not traditionally been supported by a browser that doesn’t actually use the WebKit rendering engine (Mozilla uses their own rendering engine, Gecko, which is targeted by the -moz prefix).

The reason for this, in a nutshell, is that Mozilla is dissatisfied with the way web designers are targeting—or rather not targeting—their Firefox Mobile. You see, the default rendering engine for the majority of mobile web use is WebKit-based. On the iPhone, it’s Safari (and almost every other browser in the App Store). On Android phones, Google also uses WebKit. On this platform, one could download Firefox for Android, and Mozilla is disappointed that this browser is being ignored by web designers when it has the capacity to display the same high level features that WebKit can.

I’ll leave it at that, for now. If you need more information, there is plenty of literature out there already.

My knee-jerk reaction was that this move was a little bit crazy. A lot of talented designers are survivors of the Internet Explorer 6 nightmare—I mean monoculture—and a significant portion of them agree that we’re at risk of a WebKit monoculture that will lead to incomplete standards support and technological stagnation. A second internet dark age, so to speak. Conversely, Mozilla believes that not supporting the -webkit standard will bring on the same monoculture.

Vendor prefixes allow designers to target experimental features in new browsers—at their own risk—without having to wait years for the official standard to develop. Furthermore, they allowed for standardized overrides to supersede any of the prefixed versions, which kept websites future-friendly, in addition to being cutting-edge.

I thought the main problem might be evangelism. Tutorials abound with information about cross-browser compatibility for new features, and once you drill that into a designer’s head, they have the skills to build truly cross-browser websites.

About this time, a developer from Mozilla sent several tweets to me, basically dismissing my concerns, saying I’m wrong, and that evangelism hasn’t worked. It was a strange exchange that turned into an “I’m right, you’re wrong” pissing match that I have to say shook my allegiance to the Firefox browser. So, that did nothing to convince me that Mozilla might be on to something.

Then I read what Peter-Paul Koch had to say about it and the thing that sunk in for me was that some or many or most web designers don’t want to write the same style three to five different times. Personally, I think that’s lazy and a sign of a bad craftsman, but that doesn’t change the way it is. Designers don’t want to compensate for the flaws in the standardization process, they just want to write it once and have it work.

Koch’s solution was that we let the browsers implement -webkit support, but eventually migrate that into a new -beta prefix that all browsers will share. If one browser screws up one of the properties and ruins it for all the rest, well, “this serves as a powerful reminder to web developers that they’re meddling with forces they can only comprehend after a study of the spec.” I can see where he’s coming from; I feel that’s how current prefixes should be kept in mind.

A List Apart, the authority on web design, also posted a really great interview between CSS master Eric Meier and current Mozilla standardista Tantek Çelik. First, I have to give Meier a lot of credit for digging in and asking the hard questions. Second, Çelik did a much better job showing the thinking that led to their current direction than did the Mozilla dev I chatted with. It seems as though “the WebKit-specific mobile web is growing faster than we can evangelize, especially in contrast to WebKit-specific evangelism, both implicit and explicit.” So, evangelism is a bigger problem than I thought.

To this, designer superstar Andy Clarke said, “I’m sorry [Tantek]. That is tough shit.” I’m going to have to disagree here. In an ideal world Clarke would be right. It’s a bit slimy that a Gecko browser would be paying attention to properties it’s explicitly told to ignore. But this is a user problem more than it is an author or vendor problem. According to Çelik, “[Users] are seeing downlevel or ‘feature-phone’ ultra-minimal and reduced functionality experiences.” As the W3C’s own Priority of Constituencies states, “In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.” Users first. Authors second. Secondarily, Mozilla does have a commercial interest in protecting their users. I can’t begrudge them that.

Later, Koch followed up on his -beta post with a post about adding in an -alpha prefix, as well. This would be for new features that were, um, truly experimental? Moreso than the -beta prefix, anyway. Plus, -alpha could disappear or change at any moment, while -beta would be effectively stable and supported for life.

Kyle Weems, designer and creator of the CSSquirrel comics, tweeted at me: “I think -webkit adoption is a mistake, but I think -alpha and -beta would be serious problems too.” Agreed. -alpha and -beta would carry all the same problems as -webkit minus the part about Mozilla not being a WebKit browser, which is at least a step forward. But we still have legitimate concerns here. It seems unfair that the designers like Weems and Clarke and Meier (and me) who are doing it right should get punished with significantly less flexible and altogether more unpredictable web prefixes. Is there a better way?

Here is my answer:

• Forget -alpha. It’s too ambiguous and unnecessary. Prefixes are, by definition, experimental and subject to change. They’re dangerous, and they should stay dangerous.
• Forget universal -webkit support. -webkit is called -webkit because it’s used by WebKit browsers only.
• -beta is keeper because it solves a problem. Lazy web designers who don’t care about their clients can rely on a single prefix, that all browsers can support, without too much effort. Furthermore, when the experimental implementations become stabilized before they’re officially welcomed into the spec, it would allow the hard workers to condense their verbose system of prefixes to a single one. Hell, I would love to have as few gradient declarations as possible.
• Here’s the first key part, though: continue to support all the vendor prefixes. Essentially, each -beta feature would be mapped to the appropriate vendor prefix. For example, -moz-border-radius would be the same as -beta-border-radius. This way, when a browser does come along and screw up an implementation, designers can work around the bug by targeting the other browsers. If Safari accidentally inverted border-radiuses, we could break it down from -beta to each individual prefix, minus -webkit.
• The second key part is that evangelism for building to standards must not flag. Designers must—absolutely must—include standards-based overrides so that their sites will continue to work into the future. I think the best way to do this is to rapidly pull support for experimental properties once the spec is put in place. It must be in a designer’s second nature that if they don’t play by the rules, their websites are going to degrade over time. Again, prefixes are dangerous! Use them wisely.

It’s definitely a lot to think about, and this is one of those instances where the decisions we make now will be echoing for a long time. I don’t see my proposal as a compromise, because the solution doesn’t hurt anybody. This solves an real problem, while working within the existing system.

With every new technology that appears on the web, clever designers and engineers always find ways to hack it into something that will get attention, change the way we interact with technology, or sell products and services. It’s that last bit that tends to be the most frustrating. After 15 years of popular internet usage one might think we’ve learned this lesson by now, but today we’re still sacrificing good design for the latest shiny object.

The Bad Old Days

In the beginning, marketers jumped on board the web in general. A presence was all that was really needed, and eventually their sites turned into interactive brochures. But they were often hard to use, experimenting with overly metaphorical navigation and frames. And they looked terrible. If anyone needs a good reminder on how this worked, check out the original Space Jam website.

Next came Flash, which offered a deeper control of interactive elements, but also gave birth to horrifying intros like this Polish toy site, Hurtownia Kontakt. Web marketers were thrilled to be able to present a little movie (with sound!) for their clients to watch, which promoted all the amazing features of the product or service we were surely going to buy. Users inevitably just skipped by them (or worse, backed out of the site altogether) and Flash’s performance grew increasingly processor-intensive.

Today, we have JavaScript frameworks like jQuery and more, and the shininess of one particular trick is just too much for a marketer to resist: the content slider. Content sliders are everywhere.

Content Sliders 101

For those of you who don’t know what a content slider is, I’ll describe a typical implementation. (You can also try the four links above to see what I’m talking about.) Imagine a large banner across the top of the content, with text and photos describing a new product. After five seconds, the banner slides off to the left and is replaced by a new banner; this one has information about a deal, like free shipping. After five seconds, that banner slides off to the left and is maybe replaced by a third banner. There might be left and right buttons, or there might be dots or thumbnails that allow the user to bring a banner back to the forefront. There might also be play and pause buttons to give more control.

Here’s why marketers love content sliders:

• They’re able to “fit” more content on the front page, “above the scroll”.

• They’re able to animate the slider automatically, so that a user will see more features, news, or deals.

• A slick animation is flashy and eye-catching and makes the site feel modern and impressive.

Here is the reality:

It’s time to give up on content sliders.

Content sliders are a usability nightmare. There is nothing worse than abruptly hiding content from your users. I do quite a bit of casual reading, but I’ll be the first to admit, I’m not a fast reader. Nearly every content slider I’ve come across has not given me enough time to read the text and absorb the imagery. I’ll be in the middle of a sentence and suddenly that content is just gone.

The problem compounds the longer the slideshow goes. Banner after banner, flashing something before my eyes, then stealing it away before I can fully process what I’ve seen.

Furthermore, once I’ve conquered this obstacle, the rest of the content on the page becomes more challenging to read, because there’s a constantly shifting block moving back and forth at the top of my vision, distracting me at regular intervals. It’s like a faucet dripping into a plastic bucket when you’re trying to get to sleep.

A lot of these sliders have a pause button, and while that helps, it’s just putting a band-aid on a larger problem. Flash intros have skip buttons, music players have mute buttons, and videos have pause buttons, and users click them. By god do they click them. They even write custom scripts and browser add-ons to disable them automatically. Surely y’all still remember MySpace.

People hate losing control over their computers. It’s always better to give the user control over their environment by default. “I am at home. Let’s play this video.” “I am at work and my speakers are turned on. I will choose to play this game discretely and leave the sound effects off.”

Speaking of user control, if JavaScript is disabled, and—best case scenario—the site is designed to degrade gracefully, you’ll have an obnoxious stack of promotional content. Worst case scenario? None of your slider content will show up at all.

Finally, according to this classic Nielsen post, users will actually read very little of your web page. They’re using their nose and following the scent of your links so quickly that any access to information hidden behind initial content quickly drops off so as to be meaningless. For these users, the content may as well not exist. My guess: anything past two slides never sees the light of day.

Conquering The Urge To Slide

Here’s the thing: you don’t even need content sliders. You can do a better job designing without them.

Your job as an interactive designer and usability specialist is to guide users to the content they need. Figure out where they’re most likely to go, or where you most want them to go, and make that your primary focus. Everything else is less important and should have its own appropriate place on the page where it can be seen, read and studied at the user’s own pace. Break it down, spread it out, and guide their eyes.

And as an added bonus, whether JavaScript is on or off, non-sliding content will act predictably on more devices.

As designers, it’s time for us to take the web back from the whims of those who insist on using content sliders. They’re an ineffective cheat and a dead end, and the web will be a more vibrant and usable place without them.

I’ve joined the ranks of Spotify users since its US launch back in July and I think as a service, it’s pretty incredible. It’s sort of like Netflix for music, allowing you to stream tons of media, except that instead of paying a monthly fee, you get it all for free by enduring terrible ads every few songs. I say that with a bit of tongue-in-cheek, because really Spotify is a great deal for users.

There is one thing that bugs me about the program that I wish they’d fix right away. It’s incredibly difficult to close the program. Normally on Windows, if you want to close a program, you just click the big red X in the top right corner, right? Well Spotify doesn’t obey your command. To them, the X means minimize or hide the window.

Even though every program ever written closes (or at the very least minimizes to the system tray—still disagreeable, but slightly less so) when that button is clicked, Spotify breaks the pattern and does something unpredictable.

They take their disregard of the Windows UI even further once Spotify is settled into your task bar. When you hover over Spotify, an Aero preview of the window comes up, and from there you should be able to close the program with the red X, but again, nothing actually happens. If you right click on it to bring up the contextual menu, again you’ll see “Close Spotify” sitting at the bottom, but that actually minimizes, as well.

Now, as a user, I’ve tried to close this program three times using many of the common methods that you’d expect results from, all for naught. This is incredibly frustrating. The correct answer to this riddle is to find the menu item that says “Quit Spotify”, but this works against the ingrained patterns understood by Windows users. Every single time I try to close Spotify, I go through this process, because it’s the only program that decided that close doesn’t mean close.

I’ve sent a couple messages asking for this to be fixed, but have never gotten a reply. I won’t hold my breath, but maybe they’ll someday soon they’ll see how wrong they are.

Michael, my boss, when talking about building an all-star web design team, told me that I would be the resident CSS expert, which shocked me the first time he said it, because it’s very weird when someone gives you that level of praise. The first time I remember being called an expert was when I was a very young web designer, around the birth of web standards, though it would be many years before I would know how to use them. It was a freelance job where I had somehow convinced the client that I was their guy (probably my “competitive” $8 hourly rate had something to do with that). When I asked them what they wanted, they just shrugged and said, “I don’t know. You’re the expert.” I felt like these people were looking at me like some kind of child prodigy, who could understand these technical computery internety things that were just over their heads. It kind of terrified me, because I wasn’t a prodigy and I didn’t have the answer.

When Michael brought up my alleged expertise again, those wide-eyed moments came flooding back to me, and I started asking others what they thought of expertise. It turns out that none of my friends will admit to being experts in anything, including those who are clearly much smarter or more focused than I am.

I even took to Twitter for a mini-survey asking if anybody out there would consider themselves an expert on using Twitter, a bare-bones simple service. I didn’t care about whether they could use it to effectively leverage social marketing or any of that nonsense, just enough knowledge to answer the majority of questions someone might have about Twitter: What can you use it for? How do I answer a question? How do I link to a tweet? Twitter doesn’t really get much more complex than that.

The few responses I got all said no, they are not experts, again some from people who I know have considerable experience and could answer all of those questions and go into more depth, too.

I had chats with Aaron and Emily, who both mentioned that there’s always someone who knows more than you, which is true, but I don’t feel like that works against expertise. Emily admitted that she probably conflates expertise and genius.

As for me, I will now fully admit that I am a CSS expert, and yes I claim expertise on Twitter, as well. Part of expertise is comprehensive knowledge, but the other part is authority. I say it’s time to own up to your knowledge and take pride. If you can live and breathe any specific subject, congratulations, you’re an expert. Tell it to the world.

I’ve linked directly to the tweets so you can go fav them yourself, if you want.

Industry Nonsense

Michael Karlsson—“‘So this SEO copywriter walks into a bar, grill, pub, public house, Irish bar, bartender, drinks, beer, wine, liquor’ #nördhumor #seose”

Ethan Marcotte—“Come on, Internet Explorer! You can totally do it! I believe in yoh god how did you manage to get poop in your hair?”

Karin Dalziel—“I have the song ‘Final Countdown’ by Europe in my head now, except with ‘IE Countdown’.”

Vulgarity & Naughtiness

Lee—“4 gallons of lube just showed up in my office and I thought, ‘Why don't I tweet more?’”

Jenny—I don’t care what you’re talking about, never refer to something as “the perfect moistness.”

Jenny—“My toilet is broken. It sounds like it's whispering secrets—secrets nobody wants to know.”

Elliot Jay Stocks—“‘Grow to the size you've always imagined!’ Hooray—finally an email with news on how to replicate the scene at the end of Akira!”

Amanda Thorpe—“Menstruation is nature’s worst ‘everything’s ok’ alarm.”

Lindsay Dofelmier—“I just learned the term ‘fuck trophy’. Of course it’s a term @SSutton & @minervajayne invented for what the rest of us know as ‘kids’.”

Philosophy & Deep Thinking

Micah Mertes—Everybody always thinks a baby’s going to grow up to be a good person.”

The Guy—“I know that they exist, but I've never met anyone named Ernie.”

Eric L M Shuman—“Experimenting with Pandora, I put in ‘Friday’. 1st track, Kesha: wife mistook for the same song. Skip ahead: Ace of Base. Experiment OVER.

Jamie McKelvie—“When I see a tall person with a small head in an overcoat, I imagine it's really 3 kids on each other's shoulders pretending to be an adult.”

Jason McDowell—“Tried, and failed, to come up with a good lead up to this punchline: Overeaters Anomnomnom. Good luck.”

Lifestyle & Culture

Ethan Marcotte—“Six Things I Wish I Wasn’t: 1. Awake since 4.15am 2. Bad at lists.”

Bryan Lee O’Malley—“OUT: ‘your mom’ jokes. IN: jokes to your mom, about you.”

Kathy SteinauerSmith—“Apparently if you are a black dog on the #LNK trails, you must wear a red collar. #fashionableattire”

Ali Peterson—“I’ve only got enough money to make it sprinkle.”

Jamie McKelvie—“People retweet the strangest things. (Please RT)”

On a related note, you can follow me on Twitter at revoltpuppy.