Notebook – numerosign | progressive web and iOS design and development

CSS3Machine isn't just a CSS3 Generator

There are already CSS3 Generators on the web. Some of them are fairly usable. But they all lack a few key things; they don't give live previews of what you're generating in a meaningful context, they don't save your work, they're not pretty, and they're not any damned fun.

CSS3Machine checks those boxes, then takes it further.

Webkit's Keyframe animations are powerful and flexible (and hardware-accelerated on iOS devices), and CSS3Machine brings them to life. With live previews of each keyframe and the ability to tweak the animation even as it plays, CSS3 Machine makes it simple to experiment with the cutting edge of web design.

CSS3Machine can store all the stylesheets you're using for your current projects, as well as custom HTML templates.

When you're ready to use the styles created, CSS3Machine makes that a breeze, too. Just hit http://your-ipad's-name.local to connect your browser to CSS3Machine over wifi and you'll see the full set of declarations you're working on in CSS3Machine, ready to do with what you will.

CSS3Machine will be available soon. Sign up to be notified at CSS3Machine.com or follow @CSS3Machine for updates.

It appears that conflicts can occur between animations on your page and animations declared by an extension. I put together a test page which demonstrates the problem. Specifically, animations with identical -webkit-animation-names collide, and weird things happen. My cursory testing indicates that animations declared in extensions will always take precedence as they are loaded last.

I ran into this phenomenon last week as I was putting together the teaser site for a (heretofore) secret iPad project. Most of my animations worked well, but one, in which an iPad drawn exclusively in CSS3 flips around, caused me no end of hell. In the end I discovered that my animation's name, "flip" was conflicting with one in Panic's Coda Notes extension. Their "flip" occurs when the page turns around to reveal a postcard on its back.

This is certainly no fault of Panic's, of course. The trouble is that it's natural to name animations simple verbs; slide, stutter, flip, spin, etc., but that only makes this more likely to bite you. And, frustratingly, when it does you'll still get an animation, and it may even be sorta like what you want, but it'll have parts someone else's swipe or flick or jiggle, like that freaky chimera at the end of "The Fly." Yeesh.

I'll be prefixing my animation names from here on out, and I wholeheartedly recommend that all of y'all do the same.

I blinked. What? My "preferred internet password?" For access to your stinkin' worthless rewards program?

Let’s skip over the implication that I have just one password I use (or try to use) everywhere and concentrate on the fact that Priceline puts my “internet password” in the same bucket of superficially-meaningless-but-difficult-to-guess information as my dog’s name and my favorite movie.

Screw you, Priceline. First, for confusing _personal_ information with confidential information. Personal information is what color my house is. Very few people know (or care), but I do and can recall this information easily, and it can be used to distinguish me from some random jerk or bot. Confidential information is my social security number. Passwords are confidential; don’t ask for them in the same breath you ask my favorite flavor of ice cream.

Second, screw you for teaching my Mom that passwords aren’t confidential. (And here, I’m using "Mom" in the rhetorical sense. My actual mother is much smarter than my rhetorical mother.) The grocery store asks her phone number for their rewards program, and you ask her “preferred internet password?” To her, it makes these things equivalent. Never mind the point that the grocery store shouldn’t even be asking for her phone number. You’re undermining the work of those who care about her (and their own) security. In short, you’re behaving like a crook.

Third, screw you for reinforcing my rhetorical mom's notion that it’s okay to have one password everywhere. For God’s sake, it’s 2010, and it sucks that we don’t have some kind of retina-scan thing figured out, but EVERYONE on the honest web has an obligation be be responsible with users’ data and to reinforce (and sometimes require) good security habits in those users, and you're blowing it.

This is exactly the sort of thing that led us to a place where things like this Facebook-recognition catastrophe happen.

If anyone wants to voice their frustration and disappointment with Priceline, I encourage you to use their feedback form.

I'll be presenting this Thursday, Feburary 18th at Ziba Design in downtown Portland. Doors are at 6:45. My presentation is titled "CMYG: Projecting Authenticity in a Crowd of Greenie McFakersons."

The event is an opportunity to hear 10 creatives, designers, and entreprenuers briefly share their insights and interpretations of the inscrutable subject of sustainable design.

It's a whole five buck for non-members, and oh yeah, there's FREE BEER. That's cerveza gratis. Just bring your own glass.

Update: Video Below

The slides are bit hard to see, so I've uploaded a copy to slideshare.

Thanks to AIGA, Ziba, and everyone who brought the event off as such as success. Be sure to check out the other presentations from the event.

Almost all of them are smart, astute, and ambitious. And they have plans—that's why they hired you.

What they aren't is knowledgeable about web design, which makes them ignorant, not stupid. They probably have a limited design vocabulary. They don’t “get” white space or visual hierarchy. They’ve only ever considered the fonts that ship with MS Office 97. None of that is their fault, again, it’s why they hired you; their ignorance is your paycheck. But that doesn’t give you the right to insult them behind their backs.

A client doesn’t know that Comic Sans is the favorite target of every amateur typographer’s pot shots, so when they ask for it, they don’t think, “heh, this’ll really get that prissy designer’s goat;” they’re simply trying to communicate an idea; they want Comic Sans because they want to look approachable or fun. That’s the real message they mean to convey, but they’re bogged down in details, and by the queerest bit of bad luck, these particular details turn us into condescending assholes. It’s like PeeWee Herman’s playhouse, and the secret word is “Papyrus.”

When the client asks for Papyrus, they’re not making a ridiculous request, it only seems ridiculous to us because we know how ubiquitous Papyrus is, and because we read so much of a site that, let’s be honest, just makes fun of people who don’t know.

Our clients hired us to help them find their way, not freak out when they misstep. The trick, and the mark of a professional, is to hear what the client is trying to say and respond to that. Point out that Papyrus is really overused and suggest an alternative. Maybe Mariposa or ITC Cancione. Your client will thank you for helping them avoid a cliché and you’ll end up with a finished project you can stand to put in your portfolio.

Sure, there are clients who think they know better. Everyone thinks they’re a designer, right? But everyone also thinks they have an idea for a Hollywood Blockbuster, the Great American Novel, and the fix for the nation’s woes-of-the-moment. Every plumber has had to deal with a “handyman” homeowner peering over his shoulder. Every mechanic has had to undo the damage done by her customer’s well-meaning but incompetent brother-in-law. It’s the way of work in a world were everyone can try his hand at everything, and simply being paid to do something doesn’t make you an authority in it.

You’re going to have to earn your clients’ respect and trust, and it may not always be easy. Some of the clients from hell seem to think a custom website can be had for a couple hundred dollars. That’s not their fault either; help them understand why it’s worth more. Just as a Hyundai and a Lexus may look alike to someone who doesn’t know, our clients may not at first understand what makes our work different from a Blogger template. Want to be treated like a professional? Act like it. Want authority? Here’s your chance to pull up your britches and earn it.

Reading “Clients from Hell” inculcates us with a sense of superiority, and not only that but a tendency to overreact to a client’s innocent requests or questions. Knock it off.

Because I do all my RSSin' on one machine, syncing and ubiquitous accessibility don't mean much to me, and I find Safari's inbuilt RSS reader quite adequate for keeping up on the thirty or so feeds I read.

So I wrote a user stylesheet that remakes Safari's RSS interface in Helvetireader's image.

There's styling for the condensed view, too:

Just download the CSS file and point Safari to it Preferences -> Advanced -> Style Sheet.

Note: If there's an update that changes Safari's RSS reader markup, you'll have to check back here for an updated stylesheet (This URL is in the comments at the top of the file) or just follow @numerosign on the twitter.

Amidst a bit of googling, a recent poll posted to CSS Tricks caught my eye. The poll asked which convention users preferred; using-hyphens, using_underscores, or the perhaps non-obvoius camelCase. The results seem inconsistent with the code I've seen in "the wild"; camel case came in well in front, with ~45% of the votes, while hyphens and underscores each garnered about 30%.

Many of the respondents noted the rationale behind their personal convention, and while I have doubts that everyone has a considered reason for their separator of choice (most, I submit, simply do what they've always done), the subject is certainly worthy of a closer look.

Hyphens

The most aesthetically compelling argument is that the specification itself uses hyphens in pseudo selectors such as first-child. Some also feel that terms separated by hyphens are more readable.

Camel Case

The leading argument for camel case is one of compatibility; every language can handle terms in camel case. And because camel case is a popular convention in many languages, the simple fact of muscle memory has to be considered. If a developer just *thinks* in camel case and types in camel case automatically, it may become a personal convention without ever being fully considered.

Underscores

Disclaimer: I prefer underscores, and may shamelessly promote them.

If underscore users have a trump card, it's that of text selection. Most text editors consider a hyphen a word separator, which means that a double-click will select an entire underscore-separated selector, but only a single term of a selector separated by hyphens. While camel case has the same advantage, in my opinion the underscore combines the readability of hyphens and the selectability of camel case.

Us underscore folk do have to overcome the handicap of the fact that our preferred separator requires an additional keystroke. For Dvorak users such as myself, though, the reach to the hyphen/underscore key is shorter, and that may mitigate that drawback.

But what do the experts use?

My supposition is that camel case enjoys such a lead because of the demographics of CSS Tricks. Specifically. my thought is that many visitors there are hired guns, who work on a broad range of platforms. Indeed, many of the comments on the poll bear out this idea, as languages from Java to C# are mentioned.

So, what do the specialists use? I created a list of ~25 top CSS slingers, based partially on Andy Clarke's HTML naming conventions chart from 2004. I updated the list a bit, shamelessly tweaked it to my fancy, and then checked under the skirts of each designer's site with the ol' WebKit Inspector.

Among these experts, hyphens are the clear leader. Next most popular was *none*, which is to say that multiple term selectors were avoided or simply concatenated together (if *none* had been an option on the CSS Tricks poll, I wonder what share of the vote it might have received. ). Camel case and the underscore each came in at less than 10%.

Clearly, there is as difference in conventions between the poll respondents and my list of experts, and it makes me wonder why they're using hyphens, and if it's a considered position.

Internet Explorer has offered the feature since version 5.5, and it's been abused in many, many hideous ways. Though you could recolor the scrollbars, they were still chunky, ugly, XP scrollers. On the plus side, it degraded cleanly, except for the invalid CSS.

The subject came up again recently after Google took the covers off of wave, their inscrutable reinvention of, well, I don't know what. Lukas Mathis turned his reliably-keen eye to their radical custom scrollbar implementation. As Lukas said:

As a general rule, there’s nothing wrong with replacing native widgets with different-looking versions; visual consistency is overrated.

Further, he said that so long as your home-grown widgets are recognizable (i.e., that scrollbars look like scrollbars and checkboxes look like checkboxes), usability won't suffer. But he then said,

However, if you’re going to change how people interact with your widgets, you should have a really good reason.

I fully agree with his point. Don't replace something that's mature, comfortable, and expected with some half-assed, bullshit surprise. It's like calling for Columbo and getting Jimmy Fallon.

Still, I think custom scrollbars are an excellent candidate for progressive enrichment, especially in cases where they appear to be a part of the webpage itself instead of a means of interacting with it (e.g., a scrollbar on a block of sample code vs. the scrollbar that controls the viewport on the entire page.

How not to do it

Don't roll custom scrollbars in Flash, for god's sake. Damn.

My survey of the implementations available in JavaScript indicate that they are better than Flash in that they can degrade cleanly, but good god almighty, look at the source fleXcroll:

On top of that, these scrollbar overrides exhibit many of the same behavioral quirks of which Lukas complained. They do degrade to a regular widget with JavaScript disabled, but that's not the point. It's not a matter of degrading to regular scrollbars for users with JavaScript disabled, because the users with JavaScript enabled are the ones getting stuck with something unusable.

Inching toward a simpler way

Recently WebKit's freshly-spouted capacity for styling scrollbars caught my eye. The gigantic aqua scrollbars on code samples on this site were getting to me. A few CSS styles to override the default appearance and create something nice looking for about 60% of the visitors to this site would just tickle my fancy.

Until I saw the myriad selectors and pseudo-classes involved. Jee-zus:


-webkit-scrollbar
-webkit-scrollbar-button
-webkit-scrollbar-track
-webkit-scrollbar-track-piece
-webkit-scrollbar-thumb
-webkit-scrollbar-corner
-webkit-resizer

Applicable Pseudo Classes:
:horizontal
:vertical
:decrement
:increment
:start
:end
:double-button
:single-button
:no-button
:corner-present
:window-inactive
:enabled
:disabled
:hover
:active

That's more than 100 possible combinations of classes and pseudo-classes! The demo page for the new extensions has nearly 500 lines of CSS that apply to the scrollbars and calls more than 30 images. To hell with that.

To be clear; I'm not afraid of complexity, it just makes my teeth itch. And while I'm sure that these extensions are a boon for the iTunes team (they're used all over the new iTunes Store), I'm not the only one who thinks it's absurdly complex. Implementing something so complex and clunky to accomplish only a bit of stylistic sugar just doesn't make much sense.

Nonetheless, I played with the new extensions, and struck upon a way to skip images required by the Surfin' Safari example in favor of a few rules that take advantage of WebKit's support for CSS Gradients.

A simpler way


pre::-webkit-scrollbar {
	height: 1.5ex;
	 -webkit-border-radius: 1ex;
 	}

pre::-webkit-scrollbar-thumb {
	border-top: 1px solid #fff;
	background: #ccc -webkit-gradient(linear, 0% 0%, 0% 100%, from(rgb(240, 240, 240)), to(rgb(210, 210, 210)));
       -webkit-border-radius: 1ex;
      -webkit-box-shadow: 0 1px 3px rgba(0, 0, 0, .4);
}

The result:

So there it is: a nice, subtle scrollbar redress for WebKit that uses no images, comes in at ≈ a dozen lines of CSS, doesn't murder the markup or b0rk the behavior, and degrades to a regular widget on non-Webkit browsers.

Caveats

This CSS obliterates the arrows, which is fine with me but conflicts with Lukas' maxim. I don't think I'm alone in that I can't recall the last time I clicked the arrow on a scrollbar, and users that are still using their un-bescrollwheeled 1996 Microsoft Mouse are probably not interested in any code I present here, anyway. You can skin the arrows, of course, but it about triples the about of CSS necessary.

Oh, and If you don't want the gradient and dropshadow on the scrollbar, you can accomplish a [tweetie](http://www.atebits.com/tweetie-mac/)-like scrollbar with just a couple lines:


pre::-webkit-scrollbar {
    height: 1ex;
    }

pre::-webkit-scrollbar-thumb:horizontal{
    background: rgba(0, 0, 0, .2);
    }

If you're on WebKit, it's the scrollbar you see on the code samples on this site.

numerosign’s new app is now available.

Phixel lets you quickly and easily convert pixel-based layouts to flexible, typographic ems and use the golden ratio to create beautiful, balanced designs. More information is available on the phixel page or in the iTunes Store.