Category Archives: Computers & Technology

The (highly biased) case against CSS preprocessors

Everybody who’s anybody is using CSS preprocessors!

Or so it feels. I’m an old-school vanilla CSS curmudgeon, and the more I’ve dipped my toes into working with CSS preprocessors (specifically, SCSS with Compass), the less I like them.

As I see it, there are three main problems with vanilla CSS:

No variables. Honestly this is probably the only problem I really have with CSS. I’d like to be able to set variables for things like colors that I use throughout a site. To a lesser extent, I see the benefit of “mixins” — reusable chunks of CSS.

Redundant code. It really depends on how you conceptualize your CSS structures, but it is very easy to fall into a habit of writing the same CSS code over and over again, resulting in bloated, hard to maintain files. While I am guilty of this just like anyone else, I find that if you format your CSS code properly you can combine properties efficiently to avoid redundancy without needing any external solutions.

Lack of programmatic logic. Here I’m thinking about things like conditional statements, and also math operations. This is probably as much of a strength as a weakness. CSS is a stylesheet, not a program. It’s a set of rules to be applied to formatting a document. There’s nothing programmatic about it. But still, as CSS selectors become more complicated and convoluted, it is clear that in some cases light programming logic would be helpful.

The real question is, do CSS preprocessors actually solve these problems? Or, more specifically, do they solve them without introducing new problems that are at least as bad as the ones they’re trying to fix?

For me the answer has been, and continues to be, no, they don’t. But I’m trying to get a more tangible explanation for why that is, rather than the simple gut feeling that’s been driving me away from using them up to this point.

What are other people saying?

My first stop in trying to answer this question of why I dislike CSS preprocessors was Google. I wanted to see what other people were saying, pro and con. Here are some interesting blog posts I found, going back a few years to the early (or at least earlier) days of CSS preprocessors:

The problem with CSS pre-processors
This article by Miller Medeiros was the first one I came across a few months ago when I initially pondered this question, and at the time it was all I needed to satisfy myself that I was not crazy for wanting to avoid CSS preprocessors.

So, assuming preprocessors do solve the problems with vanilla CSS, what are the problems they introduce? And how bad are they, really?

I need to get specific to my own situation for a minute here. I have a former coworker who is a firm believer in SCSS, and now that he’s gone, I’m left to maintain and extend the code he was writing. This experience casts my aversion to CSS preprocessors into stark relief.

Maintenance can be a challenge

The most obvious issue with using a preprocessor is that the output CSS is not exactly easy to hand edit, and worse, you shouldn’t hand edit it, because your changes don’t end up back in the original SCSS (or whatever format you’re using) files. If someone else goes back in later and edits the original SCSS and generates new CSS, your changes will get lost.

But let’s set that matter aside for a minute. In a broader sense, one of the key challenges for any web developer is to build code that is easy to maintain. Not just for you to maintain, but for whoever comes after you to maintain. Face it, you’re not going to be working on this project forever. At some point, someone else is either going to need to take it over, or throw away what you did and start fresh.

If you’ve ever jumped into an existing project midstream, or been handed the task of maintaining something someone else built — especially if it’s something built by someone who is no longer around to answer your questions — you know that it’s rarely an ideal situation. Even if the previous developer left copious documentation, it can take hours of picking apart their code to really get a firm understanding of how it all works. This is true with plain CSS too, but at least with plain CSS it’s a lot less work to track down a particular piece of troublesome code.

It’s non-standard

What happens when certain features of your favorite preprocessor get rolled into a future version of vanilla CSS? What happens if similar (but incompatible) features of a different preprocessor become the standard? In short, what if everything you’re doing right now becomes obsolete? How long are you going to hang on to doing things your old way with your no-longer-relevant preprocessor, before you have to scrap it and start over, or at least rewrite big chunks of your code to fit the new way everyone is doing things?

Call me a curmudgeon, but having been a professional web developer for over 18 years I’ve seen a lot of technologies and design trends come and go. I’ve always been skeptical of anything non-standard. I never used VBScript or ActiveX, I never embraced Flash, and in general I’ve done everything I could to both champion and adhere to open standards as much as possible throughout my career.

Suffice to say, resisting CSS preprocessors is just in my blood. They just don’t feel right to me. I’d rather do without features I want, if they’re not part of the standard, than resort to a non-standard workaround to make them happen… especially if it looks like there’s a reasonable chance they’ll be added to the standard at some point in the not-too-distant future.

A couple of quick steps to improve the Yosemite UI on non-Retina Macs

I’m guessing most Mac users running a Mac that can handle it have already updated to Yosemite, or will soon. I’m the kind of user who always runs OS updates whenever they’re available.

I’m not a huge fan of Apple’s decision to make Helvetica Neue the new system font in Yosemite. I like Helvetica, but I don’t love it. I prefer something with a little more personality, a little less ubiquity. That said, I do prefer geometric and Grotesque-type fonts over humanist fonts… and I was really sick of Lucida Grande, which I never really liked in the first place.

My first reaction when I tried the Yosemite beta was that it looked half-assed. The final version is a bit more polished, but it still feels poorly thought out. Or, at least, it did until last weekend when I was at an Apple Store and I saw Yosemite on a Retina MacBook Pro for the first time.

Wow.

Retina is clearly what this interface was designed for, and eventually that’s how we’ll all be experiencing it. But for now, and for a while to come, most of us will probably be stuck with non-Retina Macs and the inferior presentation of Yosemite’s refined UI that they deliver.

That said, there are a couple of things you can do to improve the experience. Part of why Yosemite doesn’t look great on a non-Retina Mac is that there’s too much subtle stuff going on that just kind of gets mucked up when you don’t have that precise definition on letters and icons. You can improve this aspect of the UI immensely by reducing its use of transparency. Open up System Preferences and switch to Accessibility. Check the box labeled Reduce transparency.

Screen Shot 2014-11-06 at 12.11.23 PM

Another optional change you may wish to make is to darken the menu bar and Dock. This is more of a matter of taste, but personally I like the darker look. Switching this on essentially inverts the colors, so your menu bar has a nearly black background with white text, and the Dock becomes translucent dark gray, instead of translucent white.

Once again in System Preferences go to General and check Use dark menu bar and Dock.

Screen Shot 2014-11-06 at 12.11.16 PM

Now enjoy your new OS!

Responsive images with srcset in WordPress

As a developer, I am somewhat conservative. I believe strongly in the importance of web standards, and I am reluctant to be an early adopter of any new techniques or, even worse, non-standard workarounds for limitations in existing standards. I’d rather live with the limitations until a proper standard — or at least a de facto standard — takes hold.

One of the latest issues to challenge my approach has been responsive images. I’ve settled into a pattern of going with “1.5x” quality images, trying to strike a balance between quality on large high-res displays and a reasonable file size. But it really doesn’t do either very well.

Today’s issue of A List Apart features an exciting article:

Responsive Images in Practice

Yes! In practice! Let’s do this!

There have been a couple of competing proposals for handling responsive image sets, and I am pleased to see the srcset attribute begin to emerge as the winner. The biggest plus it has for me is that it degrades gracefully for older browsers that don’t support it.

Well, before I had even finished reading the article I started thinking about how I could leverage the build-in image sizing mechanism in WordPress to use srcset. I haven’t looked around — I’m sure someone else has already created a plugin that perfectly nails what I am attempting to do here. And, to be honest, I haven’t extensively tested this code yet, although I did drop it into a site I’m currently working on, just to be sure it doesn’t throw a fatal error and that it actually does render the HTML <img> tag as advertised.

function img_with_srcset($attachment_id, $default_size='medium', $echo=true) {
  $output = null;

  // Get image metadata
  $image = wp_get_attachment_metadata($attachment_id);

  // Set upload directory for image URLs
  $upload_dir = wp_upload_dir();
  $upload_url = $upload_dir['baseurl'] . '/' . dirname($image['file']) . '/';

  // Build array of sizes for srcset attribute
  $sizes = array();
  foreach ($image['sizes'] as $size) {
    $sizes[$size['width']] = $upload_url . $size['file'] . ' ' . $size['width'] . 'w';
  }
  
  // Sort sizes, largest first
  krsort($sizes);

  // Get image alt text
  $image_alt = get_post_meta($attachment_id, '_wp_attachment_image_alt', true);

  // Generate output <img> tag
  if (!empty($sizes)) {
    $output =  '<img srcset="' . implode(', ', $sizes) . '" ' .
               'src="' . $upload_url . $image['sizes'][$default_size]['file'] . '" ' .
               'alt="' . esc_html($image_alt) . '" />';
  }
  
  // Return/echo output
  if ($echo) {
    echo $output;
    return true;
  }
  else {
    return $output;
  }
}

Let’s just examine what’s going on here.

The function takes three input parameters. An attachment ID, a default size (for the old school src attribute), and a boolean for whether to echo the output or just return it.

First, we get the attachment metadata and put it into $image. You can see more about what the wp_get_attachment_metadata() function does here.

Next, we set up the $upload_url variable to be the full base URL to the WordPress uploads directory. That’s because the metadata output only includes the filename of each sized image, not its full URL.

Then we loop through all of the sizes in the metadata output, generating a series of strings containing the image URL and its width, for use in the srcset attribute. We put these into an array because we need to manipulate the list a bit: we need to sort it so the largest images come first, and then later we need to implode() this into a comma-separated string.

Of course we also need the image’s alt text, so we grab that with get_post_meta() which you can read more about here.

Finally, assuming we actually have some size data, we build the <img> tag, complete with srcset attribute! Then we either echo or return it, as determined by the $echo input parameter.

Something else I’d like to try with this is taking it a step further by adding a filter that processes page content, looking for <img> tags, and automatically inserts the appropriate srcset attribute.

There you have it. I welcome anyone who’s reading this to give the function a try in your WordPress site, and let me know how it goes!

Follow-up on my post about getting an iPhone 5c on the eve of the iPhone 6 announcement

So, a few weeks back, just 4 days before the iPhone 6 announcement to be specific, I wrote here that I wanted an iPhone 5c. I had been coveting the funky colors and unashamed plastic of them since they’d been announced, and I’d seen enough leaked photos and specs for the iPhone 6 that I already knew, if it lived up to the rumors, that I didn’t really want one.

The day after I wrote that blog post, I went for it. We went to the Apple Store and bought no fewer than three iPhone 5c’s, in fact — two 32 GB units and one 16 GB unit for the boy, who’s now in middle school and needs a way to communicate with us given his newfound independence — and switched from Verizon to T-Mobile in the process.

The rationale: regardless of what they did keep, I knew (or at least reasonably assumed) Apple would be discontinuing the 32 GB 5c once the 6 was announced, and I also knew that 32 GB was the “sweet spot” for my iPhone storage capacity needs. My faltering iPhone 5 had 64 GB of storage, and I had never used more than about 35 GB of that… and even then only by unnecessarily carrying around a half dozen full-length, HD movies on the device.

So it was that on the weekend before the iPhone 6 announcement, I became the proud owner of a gaudy, banana-yellow iPhone 5c. And it was good.

T-Mobile, so far, has been great. The guys at the T-Mobile store where I had to go the next day to activate my phone were fast and knew what they were doing, and T-Mobile’s service has been outstanding, with voice call clarity and LTE reliability I could never even have imagined possible with Verizon, at a little over half the cost.

But my joy didn’t last long. Not because the iPhone 6 surprised me — it didn’t. At all. But because less than 24 hours after I took my iPhone 5c out of the box, it fell out of my pocket as I got out of the car in our garage, and suffered a permanent ding in the plastic on the lower right corner. Fortunately it was very, very small. But it was big enough to consume a significant portion of my attention for the next two weeks. I touched it constantly. I stared closely at it, willing it to disappear.

It did not disappear.

On the night we bought the iPhones, I rationalized the obviously ludicrous purchase by noting Apple’s 14-day return policy. That gave me until the day after the iPhone 6 would go on sale to change my mind.

As it happens, a coworker had preordered the iPhone 6, and it arrived at the studio on Friday. I took a look at it. I held it. I even put it in my pocket. It was not bad… definitely not as obnoxiously big as I had expected. But I still didn’t want it. I would live with my iPhone 5c, scratch and all, for a year at least, until the next round of updates.

But then, the next morning, 14 days after my purchase, and therefore the last day I could return the 5c to the Apple Store, I was idly browsing Apple’s website.

The first thing I noticed was that the 5c, now the lowest-end iPhone, is now only available in an 8 GB size. I had assumed they’d keep the 16 GB around. 8 GB is just stupid now. But whatever. I had my 32 GB unit. I was happy.

Of course I was aware that the 5s had been bumped down to the mid-range level previously occupied by the 5c. Which meant that if I’d just waited a few days, I could’ve gotten a 5s for the price of a 5c. I didn’t really care. I knew it was faster, had a slightly better camera, and had TouchID, which I didn’t think I wanted. I was fine with my banana-colored 5c.

Until I looked at the price. The 32 GB 5s was now $50 cheaper than what I had paid for the two 32 GB 5c’s we had bought 14 days earlier. That meant we could take them back, upgrade to 5s’s, and get $100 back! Hell yes.

Not only that, I could get rid of the ding in the plastic that had plagued my mind for two weeks.

So later that afternoon, we trekked back to the Apple Store, past all of the people queued up outside to get iPhone 6’s, and straight to a blue-shirted employee who was more than happy to work with us and never once even glanced in the direction of the ding. 15 minutes later, we had exchanged our 5c’s for 5s’s and had gotten a big credit back to our bank account.

I used part of my $50 refund to buy a bright yellow case for my “space gray” iPhone 5s.

Reflections on the frustratingly user-hostile motivations behind Google’s unified user accounts

“If it’s free, you’re not the customer, you’re the product.”

–Everyone on the Internet

As I’ve written about several times on this blog, my 11-year-old son did an informal internship with us at Room 34 this summer. Part of the process of getting him set up as a part of the business was giving him his own email address.

We use Gmail (as part of Google Apps for Business) for our email. As such, creating an account for him on our email domain essentially created a Google user account for him, because Google has, of course, bundled all of their services together under a single login: Gmail, YouTube, Google+ (which no one uses), etc. Sounds convenient, right? Sure, but…

A couple of weeks ago, unbeknownst to me (go ahead and judge my parenting now), my son discovered that with his mail login he was able to log into YouTube as well. We have made it clear to him in the past that (legally) you have to be 13 to get a YouTube account, and that we had no intention of helping him circumvent that. But, kids being kids, he tried to take advantage of this back door he had discovered.

Problem is, YouTube asked for his birthdate. And he gave it. His real birthdate.

Nope! said YouTube, and his account was suspended. But not just his YouTube account. His entire Google account. Suddenly we found he couldn’t log into his email. I went into our Google Apps for Business account to manage the domain, and I discovered, to my supreme annoyance and frustration, that when a user account is “suspended” it really is suspended — it’s in a strange state of semi-existence. It can’t be used, but it also can’t be deleted, even by a domain administrator. So now his email address — his email address on my business domain name, not “gmail.com” — is entirely untouchable.

It’s no surprise that we are Google’s product. A customer is a person or company who pays for products or services rendered. Google’s advertisers are their customers, and our attention is the product they are selling.

As a result, Google collects enormous amounts of data about its users. It tracks as much of our activity across all realms of the Internet as possible. That’s why we are a valuable product to their customers — the advertisers. The more information Google collects about us, the more valuable we become as targets for advertising. And all of that data collection is why Google is required to comply with the federal law regarding collection of information about people under the age of 13 on the Internet. Therefore, my 11-year-old son not only can’t have a YouTube account, but he can’t have an email address that is connected to Gmail, because a Google account is a Google account, period.

On a basic level this is a major inconvenience to me and to my son for our purposes of getting him experience working on the Internet. But on a much deeper level, it is more profoundly disturbing for its privacy implications.

As a web developer, I work often with Google Analytics. I help our clients set it up on their websites. I even use it on my own sites (including this one). It’s great to see where your traffic is coming from, which parts of your site are or aren’t getting traffic, which devices and browsers your visitors are using, etc.

But remember, Google isn’t just collecting that data for your benefit. They’re collecting all of that and much more for their own purposes, far beyond what they even make available to site owners on Google Analytics.

Google has created a scenario through Gmail and YouTube (and, I suppose, Google+) where a large percentage of Internet users are logged into Google at all times, with cookies stored in their browsers. Combine that with Google Analytics being installed on a large percentage of websites around the world, and Google knows that you are visiting all of those sites. You may not be providing the sites you’re visiting with any of your information, and they can’t read Google’s cookies themselves, but they’re pulling in a little piece of Google on every page load, and that piece of Google can read the Google cookies on your computer, identifying not just a computer with your same OS and web browser, connecting from your specific IP address, but you, the logged-in Google user.

What are they doing with that information? And what might someone else do with that information?

I do not like this, not one bit. And yet I still happily use these Google services. And you probably do too.