Topic: CSS
-webkit-transform: kill-the-flash
This issue has been popping up all over the place lately. When hovering over elements with certain css3 transform properties set on the hover state, Chrome and Safari sporadically flash. Unless you're into causing seizures, this effect is probably not what you're going for.
To prevent the infamous black flash in Chrome and white flash in Safari, you need to set any element you plan on transforming in the future (like on :hover or with an added class) in 3d space from the start.
For Example:
.item {
-webkit-transform: translateZ(0);
}
.item:hover {
-webkit-transform: scale(1.5);
}
-webkit-transform: translate3d(0, 0, 0) will accomplish the same thing. The flash seems to occur when the browser switches to gpu accelerated rendering for an element. Thus, by giving the element a gpu accellerated property from the get-go, the browser does not have to switch in and out of rendering modes, and the flash is prevented.
There is a downside.
In Chrome, without this fix, if there is text inside of the element you are transforming, the text nicely re-renders when the transformation is done. With the translateZ(0) fix, the text is rasterized and stretched, causing things to get fuzzy. So say you scale some text up to 1.5 percent — you'll get something like this:
-webkit-transform: scale(1.5) WITH the fix.
-webkit-transform: scale(1.5) WITHOUT the fix.
As you can see in the second image, the text properly re-renders when the transform is complete (in Chrome), where as the second image with the translateZ fix does not. Ultimately, translateZ does seem to be the lesser of 2 evils for now. The good news is, that as of Chrome 17.0.963.26 dev, I'm not seeing the flashing issue at all. Hopefully that means it's been addressed, and that the public release and Safari will soon follow suit.
Background-clip, Text-shadow, & Gradients; Oh My!
I’ve had a couple of designs recently where I have been able to play around with background-clip: text in combination with text-shadow and gradients, and I wanted to share my experience.
Before we get too far, background-clip: text is not supported in all browsers. I believe it is still only supported in Webkit browsers, so make sure you have sufficient fallbacks. The demos on this page will also only show up with all the fanciness in webkit, so I’ll wait for you to switch over.
Okay, ready?
Continue reading "Background-clip, Text-shadow, & Gradients; Oh My!"
Some Lesser Known Features of LESS
For the last year or so, LESS has gained a lot of traction in the front-end development community, particularly among designers. LESS extends CSS with dynamic functionality and organizational features, which provide a lot of power and efficiency to designers and developers. However, it's not the only CSS pre-processor player out there. The other major one is Sass, which is very similar, and both are solid options to consider.
Many of the review articles out there do a good job of providing an in-depth look at syntax and general usage, but I'd like to take a different angle—highlight one difference that isn't written about all that much, and present a few features of LESS that have have proved very valuable on recent projects.
CSS Strategy Square-off
It’s an exciting time for CSS. On top of the advances being made both in what to write (CSS3) and what to write with (SASS+Compass, Less), CSS is enjoying a spate of serious discussion over how it should be written.
This might come as a suprise to some (and did to me). After all, CSS seems pretty straightforward — without many of the complexities of programming, CSS has long been seen as something you just write. After all, it’s not particularly hard to write good CSS and markup; so long as your definition of “good” means “looks right, seems consistent, has semantic value”, you’ve generally gotten a pass.
The question recently posed is: is this definition of good, originating from the dark ages of table layouts, good enough to deal with the problems CSS encounters in 2011?
The answer might depend on a few things: first, whether you observe such problems, and second, whether you see them as sufficiently difficult to work with. As I see them:
Stop Making Sprites (Compass, Sass, and PNG Sprite Generation)
Update 01/11/12: new code at the bottom of this post.
Sass has been kicking around for a while, but I hadn’t given it a try until just recently. Sass usually goes hand-in-hand with Rails, Compass makes it so easy to run Sass on standalone projects that I’ve started using it on nearly everything. The result is faster, DRYer, more enjoyable coding. The biggest benefit for me has been Compass’s sprite generation, which — if done right — can cut down your coding time and filesize.
Sprites are an optimization best practice, but they’re no fun to work with. Making them by hand requires a lot of nudgy mechanical math, and most auto-spriting tools create more work than they save. Compass does sprites the smart, Sassy way: by compiling them from your code and filling in the CSS rules for you.
It also does things the Rails way, in that it provides conventions to follow rather than configuration to specify. I’ll walk you through my process for Compass spriting on a simple, standalone project.
Continue reading "Stop Making Sprites (Compass, Sass, and PNG Sprite Generation)"
@font-face, Realistically
I don't need an intro paragraph to tell you it's been a pretty great year for @font-face. Tons of foundries have unveiled webfont versions of their typefaces, and several services are reliably providing on-demand fonts (some even for free). Safari is even on its way to supporting .woff files, which is a big step forward for the modern browser.
@font-face is a boon for designers, who can finally use the type they want the way they want — kind of. As a noted crusher of dreams, it is my duty to lay out some @font-face issues that designers should think about when they’re planning.
Internet Explorer, Transparent PNGs, and jQuery Animation: The Black Background Issue Solved
This is an issue I ran into a few months ago. I couldn't find much documentation around this on the interwebs, so I thought I'd post my findings here. Hope this helps a few people out.
I was working on a project where I was animating the opacity and position of transparent 24-bit PNGs with jQuery. Everything was going great until I fired up IE (big surprise). I hadn't thought it would be a problem, since both IE 7 and IE 8 both support PNGs with alpha, but as it turns out, like most things in IE, it's a little buggy.
Everything displayed properly at first, but the second I animated the opacity, this nasty black background/border/fringe junk showed up.
After much googling, one semi-solution I found was to give the image the same background color as your page with CSS. That's all well and good if your image is on a solid background. If you give the image a background color or image, the PNG displays properly on top of it, BUT that background is still opaque, and that pretty much defeats the purpose.
THEN I remembered a RGBa to IE filter converter I had come across (thanks, Michael Bester). So I wondered what would happen if I gave my problem PNGs a transparent background using an -ms-filter background converted from rgba(255,255,255,0). Fully expecting it not to work, I used the converter and tried this:
.item img {
background: transparent;
-ms-filter: "progid:DXImageTransform.Microsoft.gradient(startColorstr=#00FFFFFF,endColorstr=#00FFFFFF)"; /* IE 8 */
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=#00FFFFFF,endColorstr=#00FFFFFF); /* IE 6 & 7 */
zoom: 1;
}
Kazaam!! Goodbye black, and hello working, animatable transparent PNGs in IE 7 and 8.
You can now use jQuery's fadeIn(), fadeOut(), and animate() on your transparent PNGs in IE 7 and 8 to your heart's content. Hope this saves you some time and frustration down the road.
2012