edit - tried them in IE6/7, they don't degrade that gracefully. They exist and work fine as buttons, but visually it's hard to tell that they are. If you use this I'd recommend adding a :hover on the span's background color as well just so a user knows to click the thing.
The main difference is that these buttons require no images, while the Zurb ones still require an image. The lack of images makes the buttons highly scalable.
On Github there's a version of the Zerb buttons that's pure CSS. I haven't tried it in IE, but it looks good on Safari and Firefox: http://github.com/gr2m/awesome-buttons.
Agreed. That is their main downside but honestly I haven't had any issues with them setup that way. I've been reusing them for both images big and small and it seems to come out alright.
Also, the markup Posterous uses is more verbose than it needs to be. We figured out a way use plain 'ol <button/> or <a/> tags and style them as buttons. Maybe I'll blog about that when we roll this stuff out.
In a live demo of the buttons in Chrome those irregularities are not present. I think it might be a Safari thing? Either that or JPEG compression artifacts.
I love how the author includes a line within the article that pretty much sums up the insanity of using pure CSS to create buttons ... "a small truckload of CSS" A designer could replace that truckload of CSS with 1 image and 1 line of code.
We gotta stop sometimes and think .. what are we trying to achieve exactly? Strikes me almost as an extreme diet that excludes 100% of fat from your intake just for the sake of having no fat irregardless if it's healthy or causes you to lose weight.
But in the "cool project" nerdy line of thinking .. it's pretty neat.
Well for one thing the buttons are scalable, unlike images. Also I imagine that the truckload of CSS still comes in way smaller than the required image(s).
If someone's willing to take the time to figure it out, it is not wasted. If indeed it is more efficient to draw buttons this way than to use an image, it makes sense to do this.
Three images, actually (normal, hover and active). Six if you have buttons in two different colors. Twelve if you need the buttons in two different sizes.
You need a truckload of CSS to define how a button looks but you only need to do it once. Creating arbitrarily colored and sized buttons is as easy as adding one or two lines of CSS. And at some point in the future we will actually be able to drop the prefixes and the CSS will become quite elegant and compact.
Well, you can still do it with one image (CSS sprites and kind of "sliding doors" technique), however an image is one more resource to maintain, and that "truckload" of CSS in reality is smaller than HTTP request headers of an addtional request for said image (even if responese is 304 Not Modified). Sure, you can properly set Expires into far future and save request for repeated visitors, but then you will need to come with a versioning scheme.
All in all, CSS way is simpler and easier to maintain. Add some more bling with CSS transforms, e.g. some nifty color fade/shift on hover and it gets realy tough for an image based solution to stand a chance.
All valid points, I looked at it more from the maintainability point of view, not so much the speed angle. You will have to maintain a Photoshop file, have some mechanism in place to stitch together your sprites and export a truckload of different images. All that can be automated up to a point, but still. Seems like a lot of hassle.
That, and more and more browsing is done using easily zoomable browsers like Mobile Safari. It's becoming less likely that users will experience your site at its "native" resolution, so anything that moves away from poorly-scalable images is a good thing.
False. Webkit extensions, mozilla extensions, and internet explorer extensions are NOT pure CSS3. They are ugly browser hacks. This is hard-coded to only work on the Big 3 and will never work on Opera, thanks for not supporting browser freedom.
These are vendor-prefixed implementations of features which are present in the current drafts of future editions of the relevant standards. As such, they are neither an "ugly browser hack" nor an attack on "freedom"; in fact, this is the way it's supposed to happen. Once the standards go final and the browsers get compliant implementations, the vendor prefixes will go away.
So... how about you get that big chip off your shoulder and let people get on with their work?
>To achieve these effects, I needed a small truckload of CSS
You:
>Once the standards go final and the browsers get compliant implementations, the vendor prefixes will go away.
So the implementation is excessively long, temporary, and to be changed to something more standards compliant at a later date. Seems like the definition of "ugly hack" to me.
And I'm not talking about supporting an outdated browser like IE6 here. I'm talking about a browser whose public releases support more "pure CSS3" than both Gecko and WebKit.
So the implementation is excessively long, temporary, and to be changed to something more standards compliant at a later date. Seems like the definition of "ugly hack" to me.
The idea is that until the standard goes final and the implementation has been checked against it, you can't know that the implementation is correct or even that the syntax for the feature will be the same in the final version. So rather than yank the rug out from under people later on, you use a vendor prefix until the standard is finalized and the implementation's checked out. Then people can drop the vendor prefix.
I'm talking about a browser whose public releases support more "pure CSS3" than both Gecko and WebKit.
And... well, Opera's doing it wrong. CSS3 is not finalized. CSS3 may go final with subtle or even significant differences from the current spec. And then anyone who relied on Opera's implementation and patted themselves on the back for being so ahead of the game will instead be up a creek.
My implication was to do something standards compliant and browser-neutral like 1px wide PNGs and (for the super fancy) JavaScript. Avoid non-standard CSS hacks entirely. It has a higher chance of breaking and not-working because, as you said, CSS3 is not finalized.
I wouldn't care if it was supposed to be some sort of academic tech-demo, but in the comments the author says:
>On Posterous they are going to be used in many places
edit: moral: JavaScript enabled\disabled is 1 axis of degradation. Non-standard CSS3 hacks have 3 axises: Browser type, browser version, state of CSS3 spec. It's a statistically worse bet.
Do you actually develop sites with this kind of thinking? I'm shocked that you'd rather use a 1px png (adding an additional http request) and JavaScript to achieve an effect that CSS can handle all on its own. We use browser extensions because specs like CSS3 aren't suddenly turned on one day like a light switch.
You can make your layout look nicer on cutting-edge browsers and by the time the old browsers are no longer around and the spec is in widespread use you can remove the extensions. It's trivial to remove CSS from a stylesheet. It's usually a pain in the ass to re-implement CSS functionality from 1px pngs and JavaScript hacks once all the browsers have caught up.
CSS can't handle it all on its own is the point. And yes I'd rather incur the extra bandwidth of a 1px wide crushed PNG in order to have simpler code and have my site support all-browsers, including ones whose team made good CSS a priority before other browsers did. Rewarding the large monoliths by coding specifically for them simply because of their popularity while punishing teams that actually prioritized CSS is what got us into this mess in the first place. Would you encourage this behavior pre-CSS4? pre-CSS5?
