Thank goodness so much web design and dev help is available with a well-formed search.

I was doing multiple animations on an element using jQuery’s handy .animate() function. However, from the second animation onward I was getting rendering artifacts in the form of little lines that were clearly the div’s border, getting stuck all over the place as the element re-rendered.


Upgrade Hover Dropdown for Mobile

You’re like me and you’ve been using hover-based dropdown menus for a long time. There are arguments against the ubiquitous drop-down (and fly-out for third level!) menus, and I believe many of them are great arguments. But if you don’t have time to rethink your approach to menus and you just need to provide a reasonable experience for mobile users, you might be having a hard time.

I’ve done my share of digging, trying to find a pure CSS-based solution, and so far I have come up short of finding anything that works in enough expected target browsers. In the end, I decided that compulsory JavaScript isn’t such a big thing (who on mobile bothers to disable JavaScript, which is enabled by default?), so here’s what I came up with.

Another disclaimer: the sites I have used this for have jQuery already. By mere virtue of including jQuery (a relatively large library) this isn’t for a “mobile-optimized” site. Rather, it’s for a site that’s targeted to desktops, which will be browsed even on a mobile device in the same way, and which just needs to provide the minimum necessary assistance for mobile users.


Convert Single-level CSS Dropdown to Mobile-Friendly

I know people out there are doing this, because I click around on their websites all the time. But could I find a tutorial or code snippet? Not a chance! Here’s a first attempt. If anyone spots anything just awful, I’m eager to hear from you.

What is “this”?

Taking a typical CSS-based dropdown navigation (usually built around li:hover rules) and making it friendly for mobile.

While some mobile browsers (iOS implementation in particular) will try to allow you to “hover” with a quick tap, it’s kind of a fiddly experience. And Android doesn’t seem to have this at all. So what’s a guy to do? I’m confident there is better CSS out there, perhaps using focus or some other sort of state-driven styling, but I couldn’t find it. So I resorted to JavaScript. Since jQuery’s already on the site and is right in my wheelhouse, I went where the comfort was. Not saying this is where the performance is, but for such a trivial bit of code, I’m not bothered.


DRY Font-Family Declarations

How many times have you worked on somebody else’s CSS file and had to do a search and replace for font-families to produce consistency? Or worse, how often have you made a quick change that you thought updated a particular typeface (no global search and replace) only to discover that the wrong font is inherited higher up in the chain? I’m thinking mainly of some pretty well-selling WordPress themes, but even Roots was guilty as I recall. It’s everywhere!

For any site, you should be declaring font family (whether with “font” shorthand or “font-family” explicitly) exactly ONCE for any given typeface. Just as anywhere else in the development cycle, the principle of DRY (don’t repeat yourself) applies.


Ternary Operators – Why bother?

A ternary operator is basically a short form for a conditional (if..else) statement. The syntax is “condition ? result1 : result2″. If the condition is met, then go with result1; otherwise go with result2. Here is what one looks like in JavaScript:

var annoying = true;
(annoying === true) ? alert("Yup, annoying") : alert("Not annoying");

The above will alert “Yup, annoying” because annoying resolves as true. This simplified example is annoying to read already. But with more logic and slightly more abstract variables (or god forbid, functions!) and you get a mess to read.