Code smells in CSS – CSS Wizardry – CSS, OOCSS, front-end architecture, performance and more, by Harry Roberts

Code smells in CSS – CSS Wizardry – CSS, OOCSS, front-end architecture, performance and more, by Harry Roberts.

Reading this, I hang my head in shame as I recognize things I am guilty of.

There are CSS tools like http://csslint.net/ which purport to automate helping you write better CSS. It’s easy to think that CSSLint is just like JSHint, and will make your coding life happier. Don’t be fooled!

The notion of ‘code smells’ seems much more appropriate to good CSS than static analysis. CSSLint can anticipate some of the smells mentioned (overqualified selectors, using IDs in selectors) but there are so many things that CSSLint looks for that simply can’t be determined to be good or bad in a vacuum (see http://2002-2012.mattwilcox.net/archive/entry/id/1054/ for a nice writeup).

Extend the Web Forward « Katz Got Your Tongue?

Browser implementers are often wary of providing extension points that can be performance footguns. The biggest footgun is using libraries that rewrite the entire stack in JavaScript, and whole-stack-rewriting strategies are the tactic du jour today. For performance, we have little to lose and much to gain by making extensions more granular.

via Extend the Web Forward « Katz Got Your Tongue?.

This is a good article. But it also taught me the word “footgun”, which is great.

Ben Alman » Multiple var statements in JavaScript, not superfluous

Ben Alman » Multiple var statements in JavaScript, not superfluous.

I think I’m in denial about the potentials for major issues with combined var statements. I use the style because Crockford does, and I am irrationally likely to take what he says as gospel. This is a great dissection of the practice.

JavaScript Scoping and Hoisting

Adequately Good – JavaScript Scoping and Hoisting – by Ben Cherry.

I was not aware at all of “hoisting” in JavaScript, which causes your variable declarations (but not initializations) to be rearranged to the top of your function scope by the interpreter. Function definitions, however, are hoisted along with the function body.

Implications:

  • potentially unexpected behavior if you expect to conditionally declare a variable at runtime
  • before runtime, all of your variable definitions will be shuffled to the top of the function body anyway. The only reason to declare-at-time-of-use is then readability (vs. any performance gains), with the downside that you can’t easily see your scope.
  • it matters how you declare your functions. var foo = function () { }; will hoist just the variable declaration, but not the function definition. function foo() { }; will hoist both the definition and the function body.

For me, this is another strong reason to predeclare all variables at the top of your function. It’s going to happen anyway.

Terrible Mobile Websites

Chrome for Android’s new feature subverts websites that automatically redirect you to a mobile version by spoofing Chrome for Android’s user agent string, in this case sending the string for the desktop version of Chrome instead of the mobile

via Chrome for Android Doesnt Need No Stinking Mobile Websites | Webmonkey | Wired.com.

Dear developers of terrible mobile experiences: you made this necessary. You know how your mobile redirect script redirects a normal URL back to the useless mobile homepage? Yeah, that. You know how you don’t let me just use your damn website, and instead ask me if I want to install the app, or add a bookmark? That too. Stop making the web terrible.