Posts Tagged ‘tools’

Test-driven CSS Development

I’m not the only one to have searched this phrase. Many front-end developers (including, it seems, a statistically significant number of people named Simon) crave the benefits of a TDD-like process when devising stylesheets.

The dream: define styles at the beginning of a project, test them for validity, performance, browser interpretation, then continue development feeling assured that you’ve satisfied all requirements and that you won’t meet any nasty browser surprises upon launch.

The reality: a process, not yet susceptible to automation. You’re still using your own eyes and hands to evaluate whether your CSS meets your project requirements. The good news is that there are a lot of people discussing this, and building tools to help out with it.

TDD for CSS. OMG!!

Start with the stylesheet, not markup. This is becoming common as more of us use CSS frameworks for tasks such as grid layout or responsive design. As you add markup, keep assessing whether you’re really using all the rules in your CSS. Prune the ones you won’t use. Tools to make this assessment include:
* Chrome Developer Tools. Under Audits>Web Page Performance, run Web Page Performance to obtain a report of which CSS rules have gone unused by your page.
* Firebug CSS Usage add-on. Click Scan, and see all your CSS rules evaluated for relevance to the page loaded. The tool will even export a cleaned CSS file that prepends the unmissable string UNUSED to rules found useless.

Validate your CSS as you go along. The solution to that wildly inappropriate heading styling might be as simple as a neglected closing brace, or an invalid rule (go on, claim you haven’t typed font-color:... at least once). Don’t wait until the moments before deployment to discover how many of your style rules are invalid.

Create a style guide page with samples of all element styling. Jade Zahnster promoted this concept for easy CSS refactoring without adding rule bloat. Did you have blue submit buttons on your project’s first iteration, and now you have green ones as well? Keeping an inventory on a single page will remind everyone which rules are already defined and require only extension for the new requirements.

Optimize your CSS. Even if you’re a finicky, careful, solo developer, there will be places in your stylesheet with duplicate, verbose, and unnecessary rules. The best way to discover these is pasting your CSS into the CleanCSS tool, and noting where properties were streamlined.

Check your stylesheet’s performance. What’s keeping those styles from rendering? Why does that puffy-font, rounded-corner, gradient-fill form button not just, like, pop up first thing? Though no less than Steve Souders argues for less concern over CSS selector efficiency, it’s pretty interesting to see which rules in your CSS are creating bottlenecks. Review Paul Irish’s thoughts on performant CSS, the use Andy Edinborough’s CSS Stress Test, which evaluates CSS rules for performance by removing each one from the stylesheet, and noting changes in rendering time.

Keep looking at the browser. The days of having numerous browsers and multiple platforms engaged as you work are, regrettably, not yet past, but there are a couple of tools to help you check for display problems before you open five different user agents.
Simon Kenyon Shepard’s CSSUnit will report how rules are interpreted by a browser, which is useful when you’re trying to understand by how much browser X differs in opinion from browser Y. Mogotest is a commercial service which reports discrepancies between perfection (your favorite browser’s display of your page) and other browsers’ rendering of it.

It’s still all a lot of work; automation and robots can’t do all this yet. Consider it job security.

Sh*t People Say to Front-end Developers

Posted on: by mejarc 3 Comments
  1. We really don’t need a designer.
  2. What’s an information architect?
  3. Nobody will be looking at this page with a mobile device.
  4. This style guide from 2002 is still good.
  5. We really don’t need localization.
  6. This Excel spreadsheet is our issue tracker. Works great!
  7. Using Flash would make this so much easier!
  8. HTML5 is too risky and experimental.
  9. What’s a validator?
  10. Browser support? All of them, of course.
  11. We really don’t need a copywriter.
  12. Of course our users will sit through this thirty-second auto-play splash video.
  13. We really don’t need JavaScript testing.
  14. The database guy already did the HTML and CSS, so you just have to add a few tweaks.
  15. Of course our users will submit this twenty-question form before seeing our content.
  16. This will be a short project.

Why we’ll stop using ID in our stylesheets

Seemed like everybody was talking about CSSLint a couple of weeks ago. I waited for the hype cycle to slow its rotation, then dutifully visited the online linter to pay my respects.

It didn’t repay them.

“Will hurt your feelings” is CSSLint’s tagline. Heh, heh; I’ve written stylesheets for thirteen years now. What faults could CSSLint find with my CSS?

Plenty, it seemed. Chief among the linter’s nagging judgments was my use of the ID selector in so many rules. Now, what’s so wrong with that? How is it that my practice for all these years is suddenly considered wrong?

I found this blog post proposing that the hip, up-to-date stylesheet of today contains no ID selectors. Intrigued, I posted the link on Talentopoly, where it generated a thread of comments from people who seemed indignant with the premise. Why discard a totally valid technique which can make one’s markup and CSS more succinct?

I think one reason we were so uneasy is that we’ve had to work with so much bad markup and styling written by people with poor understanding of the cascade. The result is overdependence on classes for style rules–a classic example would be a navbar with a couple dozen <a class="navLink"> bloating the markup. Expertly written CSS distinguished itself with terse rules attached to ID’d elements. But if you prohibit that, don’t you end up encouraging that stupid “class”-itis?

Perhaps. CSSLint can’t determine if your style rules rely too much on classes. But you can satisfy the linter’s criteria and also target specific elements without resorting to attaching class attributes to every node in your markup. For instance, you could show off your handling of CSS3 selectors instead.

Like JSLint, CSSLint is a tool based on its makers’ opinions of what constitutes good style. It’s not a validator, but an evaluator: it can suggest improvements (as did earlier linters). Using the linter is like getting the opinion of a haberdasher as to how wide your lapels should be: you’re not obligated to act on his advice, but you might look a little strange alongside your more fashionable peers.

But why has the ID selector fallen into disfavor?

Looking at the explanations on the CSSLint About page, I notice a pronounced concern for portable, modular styling. The linter discourages intensely specific selectors such as IDs and “qualified headers” (h* tags within a cascade, or with class attributes). There seems to be less focus on styling an entire, discrete page, and more on styling blocks of content which may be sent or received in an API. This is a reasonable emphasis: think of all the markup you’ve done in the last year. How much of it was for standalone pages? And HTML5 prods us to think of Web content in articles or sections, each with its own h1–our markup and styling are scraps, not whole cloth. It’s efficient to make them fit with others.

Well, so what–it’s just between CSSLint and you, right? No. A less obvious reason for abandoning the ID selector is so that your style rules pass CSSLint when somebody else submits your CSS to it. And this will happen. In a profession with no licensing and very little certification, front-end developers have few means of convincing potential clients that we know what we say we do. If our clients had the skill to inspect our CSS for quality, they’d probably wouldn’t need to hire us to write CSS for them. Tools like CSSLint, despite their basis in subjective opinions of good practice, reassure these clients: they know you’re following certain rules if you pass. They want the work you do for them to be rule-following and interchangeable, not idiosyncratic and difficult to reuse. Yes, a lot of terrible CSS can pass CSSLint–just as it can pass the W3C validator. That’s no reason to avoid using it.

What not driving for 25 years taught me about UX

One drizzly morning in 1988 I arrived at the infamous San Francisco DMV office.

There were two lines for service, one noticeably shorter than the other, and since I was already running late for work, I stepped into that shorter line. At my turn at the counter, I completed the paperwork for a state identification card instead of a driver's license, which didn't seem that important to me at the time, since it'd been already two years since I last drove a car, and now I lived in SF, which had passable public transit. It wasn't this grand activist moment for me, this kind of Damascus Road flash of insight--no, it was just my deciding that driving wasn't very important to me.

And I was right. Not driving proved more important.

Try getting around the United States without a motor vehicle.

Asphalt Nation, by Jane Holtz Kay

Asphalt Nation, by Jane Holtz Kay

Try it for a while. Try it while also attempting to sustain a career, relationships, household, your sanity. You will learn, as I did, very important lessons about how user experience can be structured to assist or thwart your journey.


Here are some of my discoveries:

Places with more than one way to access them have greater vitality.

As Jane Jacobs pointed out, small city blocks encourage walking and transit use. Places which permit access only by motor vehicle are dead-feeling and often moribund, which is why a high WalkScore is becoming so attractive to potential buyers.

In Web terms, how many of us enjoy visits to sites which permit access only through needless Flash intros or mandatory registration? These pages act like those guard kiosks in suburban gated communities. Or how about the sites with no provision for usage by mobile devices?

No, I am not going to watch your pointless branding animation, nor wait for your bloated JavaScript form validation script to load: I'm going to shop at your competitor's site.

You can't "set it and forget it."

All over the United States, roads and transit systems are crumbling into unusability because of deferred maintenance. The jagged potholes in my neighborhood act as the speed bumps the City of Oakland can't commit to installing in this dire period for municipal budgets. A couple blocks away, the once-handy AC Transit bus system runs fewer and fewer buses, thanks to neverending budget cuts. Being stranded for 45 minutes waiting for the next bus after missing one by just seconds is a pretty common experience for us commuters.

Out there on the Web are so many undermaintained, tatty sites that I really don't need to link to them. Outdated copyright date on the footer? "Best viewed in Netscape" graphic? Visual design so old it's on the cusp of being retro-cool? Those are easy to remedy--if you commit time and money to fixing them.

Accessibility is pricey to build in...and exorbitant to bolt on later.

When the Americans with Disabilities Act passed in 1990, there was the usual unappealing backlash of nay-sayers claiming that the Act's provisions were merely nice-to-have and too expensive to require. Despite that, the built environment of the United States changed rapidly to include curb cuts, ramps, and wheelchair-accessible bathrooms. Building owners whimpered about the expense of retrofitting for ADA-compliance; new construction posed the advantage of having these features built in from the start.

The question of Web accessibility arose pretty early in the medium's history, but remains incompletely answered. Too many site owners consider accessibility a "nice-to-have, but...", or something at which you can toss a few inadequate "alt tags" and be done with it, whereas true accessibility requires assessing how your application or site is used in different situations: can this site be used without a keyboard? Without a monitor? Without color contrast?

Making something accessible also makes it relevant to use cases we can't anticipate. When I injured my knee in 1992, I sure appreciated those buildings with elevators and ramps. When I started browsing the Web on my Palm Treo in 2005, I admired those sites with text-heavy, low-graphics means of interacting with them.

You're free to think you don't need to accommodate a diversity of users, of course, just as you're free to require a motor vehicle to access your physical location. And you're free to destroy your own brand with slipshod UX. It's a free world.

HTML5 Boilerplate Rolls Into Town

Posted on: by mejarc 2 Comments

Standing room only, and a waiting list besides–what was the attraction bringing so many to the tech college conference room at Fisherman’s Wharf?

Haloed at one end of the room by the glaring video lamp, a man, a laptop, and the new way you should build the front-end of your Web app. Ladies and gentlemen, presenting Paul Irish, in turn presenting the HTML5 Boilerplate.

There’s much you can gain just downloading it, of course. You could opt to pick through the unzipped goodies and apply them piecemeal to your aging markup, refinishing your early 21st-century XHTML with some latter-day varnish. But there’s a lot more in the Boilerplate than too-hasty reading of the docs will reveal.

Irish, one of the mod squad behind the informative and massively entertaining YayQuery podcast, delivered a quick, focused survey of the Boilerplate’s many benefits to those eager to follow advice like Steve Souders’s 14+ rules. Among these is a customized .htaccess file, for those of us with good intentions of, say, gzip’ping assets but only rudimentary Apache admin skills–that’s worth the attention of a full room all by itself. Another is the built-in provision of QUnit: no more chasing this down to install separately. And coming along in the bright future is the Boilerplate for mobile.

Build an ant!?


But best of all is the build script. No wonder Irish calls it his favorite part of the Boilerplate.

Here’s where mere mortal front-end devs can finally scale the Olympus of best practices. Need to combine your CSS files? Your JavaScript? Optimize, minify, them? Remove test suite leavings? Excise all those dangerous calls to console.log? Boilerplate’s build script does this for you. Hurrah; I didn’t need yet another checklist to consult.

I was gratified to hear someone take HTML seriously. For too long writing markup‘s been dismissed as a simple, easily acquired technique that any drooling idiot can/should perform. Now there are Meetups full of software engineers anxious to learn things like table-less layout. Hah! Isn’t the Web fun?

12+ People I Owe

Posted on: by mejarc 2 Comments

So here’s a pretty satisfying thought experiment/daydream: if uncountable buckets of money suddenly landed in your bank account one morning, who would you invite to share the windfall? Just in case this happens to Yours Truly, I’m writing up a list of people who devised things which made my professional life easier over the years, so that I can compensate them appropriately before I retire to a villa in Tuscany.

This villa is absolutely positioned. Photo by Maney Digital

12+ People I Owe

  1. Jesse Ruderman, for the Web Dev bookmarklets
  2. Felix Ritter, for View Formatted Source. Yes, Firebug has assumed its function, but I’m nostalgic for the day this add-on removed tons of guesswork from my project.
  3. Eric Meyer, for his Reset CSS, which introduced us to a sparkling world clean of browser defaults
  4. Joe Hewitt, Rob Campbell, et al., for Firebug
  5. Mike Buckley and Lorne Markham, for Pixel Perfect
  6. Kevin Freitas, for MeasureIt
  7. Lorenzo Colitti and Philip Chee, for FlashBlock
  8. Alex Sirota, for ColorZilla
  9. James Anderson, for Leechblock
Who will receive your gratitude?