In a perfect world, Ethan Marcotte would star opposite of me in a web design-themed, buddy cop action comedy called Beep and the Squirrel.

Actually… I’m writing that one down, just in case.

Until that glorious moment, I’ll enjoy his raw intellect and seasoned wit while envying his creative talent in a suitably stalker-like fashion. (Unless you’re reading this, Ethan, in which case I assure you that I am in no way digging through your refuse bins looking for cast-off brilliant ideas and toothbrushes.)

While we’re in the vein of borderline creepy idol worship, I’m going to agree with Ethan’s succinct tweet on the W3C’s CSS Conditional Rules Module Level 3 Working Draft (which I’ll reduce to the much easier to remember abbreviation “CCR Module”, hereafter nicknamed the “More Cowbell” document). I feel cold.

I’m still perusing the document. Although any judgement leveled while shooting from the hips (hello, ladies) is bound to be rife with bad summaries and skewed views, in my opinion the module doesn’t seem to solve any problems that aren’t already being solved in a better fashion by good CSS practice or other techniques. It’s a lazy man’s shortcut to “supportin’ olla them thar browsers”.

As Dylan Wilbanks said, these aren’t the conditionals I’m looking for.

Just look at @supports, for the love of cheese (or dairy-free cheese alternative for vegans and the lactose intolerant). It lets you test if a browser supports a feature, before (in their examples) you then go and use the feature. What? How bizarre is that? I know in their examples you can get far trickier with not and or and doogie howser, but seriously?

When it comes to the problems that CSS is supposed to solve, although @supports and its ilk would work, they seem to encourage bad or unnecessarily laboriously bloated CSS documents instead of streamlining the process. And when it comes to @document I believe that the authors are trying to make CSS solve problems it wasn’t intended for.

Look, if you’re trying to get your CSS to be flexibly supported across different browsers and devices, I recommend checking out Ethan’s Responsive Web Design, or at least actually using your skullmeat instead of slapping shoddy shortcuts into your CSS. Capiche?

This is a general request for assistance regarding a strange font-related error.

AKA: my brain desperately needs your brain’s help.

I’ve recently added embedded fonts to this site, making use of the lovely @font-face to kick things up a notch. By and large, I’ve been rather pleased with the results. However, I’ve encountered an unusual rendering bug that I’ve never seen before and am having very poor luck locating a solution for on the web.

In short, on some Webkit browsers, some (but not all) of my readers are getting a strange text-overlapping glitch with anchor elements. I can reproduce the problem some (but not all) of the time on Chrome (13.0.782.218) in Windows 7. It seems most of the people experiencing it are using Safari on Lion or iOS, or occasionally Chrome. Which leads me to believe it’s a Webkit-related issue.

Here’s a screenshot of the issue, provided for me by reader (and man of fine taste) Alan Hogan. Additionally, you can just look at this page and if you see any funny text overlaps with anchors, congratulations, you’ve found the bug. I’ve used @font-face with plenty of client websites, and have yet to see a link behave like this before, so I’m a bit surprised at its sudden appearance here. At any rate, I’ve been stumped so far in solving it. (I’m even more stumped at it’s infrequent appearance for me in Chrome).

Stephanie (Sullivan) Rewis suggested in a tweet that it might be related to the difference in size between the text first loading in the default, non-@font-face font and then the @font-face snapping into existence. That seems fairly on-target, but it hasn’t helped me figure out how to correct what Webkit is doing wrong.

If you’ve encountered something like this before and have a solution, I’d love to hear it. Thanks in advance.

As long as you’re not on a legacy browser, to the left you’ll see an image that is rotated 90 degrees.

If you’re using the current version of Firefox (3.6 as I write this), you’ll also notice a rather unpleasant visual effect on the box-shadow, which isn’t properly surrounding the rotated image like it should be.

I came across this by accident while working on some 2d transforms for a series of photos in a client’s project. I didn’t catch it at first because it only happens somewhere between 82 degrees and 108 degrees (and the direct opposite around 262 degrees to 278 degrees). I might be off by a degree or two, but that’s about the range where the shadow sheers off and snaps down to the picture’s height in its original orientation.

I’ve got a test case here. You’ll note Chrome, Safari, Opera and Internet Explorer (yes, even IE) are doing it right in their current versions. Only Firefox isn’t.

Considering how long Firefox has been implementing transforms in comparison to Internet Explorer (infamous inbred step-child of the browser market), this is really disappointing. It’s details like this that are slowly costing me my love for the flaming-tailed fox.

The bug is fixed in the Firefox 4 beta, thankfully. But that begs the question, how much longer do we need to wait for Firefox 4 to release?

There is going to be a comic that gets attached to this rant, I assure you. However, I’m so fired up on the topic at the moment that I’m tossing this post out sans the punchline.

I’ve used border-radius quite a bit. As far as CSS3 goes, it’s one of my go-to styles for making something look snazzy. Just round it and it’s cool, right? Right?

While working on an internal project for Mindfly Studio, I found myself grabbing this particular tool for rounding the thumbnail images that were attached with a list of article briefs. When I went to test the results, I found to my dismay that the images were square still, with the rounded borders cutting behind the square of the image.

Then I remembered that I’d encountered this particular issue before. No problem, I thought to myself. Just wrap that bad-boy in a div (or in this case, an anchor that already existed around the image) and use border-radius on the wrapper. Perfect! Right?

No, sadly.

At this point I felt like my CSS cred was rapidly drying up, and started debating going by JSONSquirrel instead.

“To the cloud!” I pronounced, feeling inclined to abuse buzz words, and fired up Twitter. I was informed this was an issue with Firefox (my browser of choice. I like big butts and I cannot lie) but that it’d be all peachy in Webkit (also known as Apple Browser Jesus in web designer circles).

But as it turns out, Webkit also does it wrong. Less wrong, but wrong.

Here’s my proof: border-radius test page.

What Webkit does correctly is round the corner of the image itself (when the border-radius property is set for the image, but not the wrapper), but it clips the border if one exists. If placed in a wrapper, like Firefox, it fails altogether.

I tested on the following browsers: Safari 5, Chrome, Firefox 3, Firefox 4 Beta, Opera 10.63, Internet Explorer 8 and Internet Explorer 9 Beta. It’s no shock that IE8 didn’t do what I wanted, as it doesn’t support border-radius at all. Although, humorously enough, their outright failure to round the border (while leaving the image square) was still more aesthetically pleasing than the clipping/overlapping that were the results in Firefox, Webkit and Opera. And yes, Firefox 4 Beta also failed to round the corners as I desired.

Unexpectedly, IE9 Beta did exactly what I desired, which was rounding the image with the border intact (and rounded) with it. The only one, in fact, to do so. That was a shock.

Maybe I’m expecting this property to do something other than its actual purpose. That said, wouldn’t an image tag be the most likely case of an element that you’d want a rounded border to work properly with? It certainly is for me.

I’m aware that setting a background-image on an element and rounding it is a workaround that functions perfectly. However, if styles are turned off, you lose the image. What if you want the actual image present regardless of whether CSS was present? Well, at present, go with square corners, it seems.

If someone more clever than me comes up with a way around this that is CSS-based (and not overlapping it with a PNG with a rounded hole in it or some other such workaround) then please let me know. I’d be really curious to see how others tackle this shortcoming.

Over at the Mindfly Studio Blog I’ve added a small tutorial on how to vertically align your text with CSS. Yes, it annoys the hell out of me to use display: table-cell (which was the source of Monday’s comic on this very topic), but for now it’s the best thing we’ve got. If you’re wrestling with just this, pop on over for a simple explanation.

If you’ve got a better method, please tell me in the comments. I’m open to new and strange things, like Texan sushi.