A visit with HTML 5

Now that HTML 5 has been declared victorious over XHTML 2, the last six to eight weeks have yielded a bouquet of tutorials, introductions, cheatsheets, and blog postings about it. I guess we’re so excited about anything new in markup we’ll even cheer a draft proposal. I can’t excuse myself from the mob, having joined it on a recent project for a future-minded client who encouraged me to take up the fashion for <!DOCTYPE html>.

On first and even second glances, the HTML 5 element list seems conservative, not much of a change. There are the intriguing new tags like <canvas>, but with limited cross-browser support. <menu>returns from, what, HTML 3.2?, but this time dressed up as a way to group form inputs (easy to confuse with how we’ve been using <fieldset>). Other elements, such as <header>, <footer>, and <section>, are good substitutions for the over-worked <div>, which lingers in HTML 5 for your block element needs. <article> is interesting–it’s supposed to enclose “standalone” content. <nav> is easy to type and remember.

However, some of these tags seem to presume usage in rather old-fashioned situations. For instance, which of the navigational blocks on your application screen will you exalt with <nav>? No fair using it more than once–it’s supposed to designate your primary navigation. And which of your content blocks are <section>s and which are <aside>s, especially if the user can rearrange them?

Where HTML 5 seems more ambitious, seems to pose more of a learning curve, is on attributes and APIs. Form elements seems especially enriched in this specification. I didn’t use any of these on this project, but I’m eager to try them when the browser support is sufficient. Many of the proposals will remove tedious DHTML chores, if ever supported; for instance, this block will replace all those unordered lists distorted by CSS and JavaScript into popup menus:

<menu type="popup">
    <command  label="Check messages" icon="messages.gif"/>
    <command  label="Logout" icon="logout.gif"/>
</menu>

By now I expect you’re asking, “But what about IE?”

Yeah, what about that? Hmmm.

I was blessed to have a client who’d discarded concern for IE 6. Problem solved, you think?

Not at all. IE 7 ignored even the most basic HTML 5 tags–even <section> proved uncharismatic. To the rescue, JavaScript; more specifically, the “HTML5 Shiv” (love the name, which captures the mood of destructive exasperation IE inspires) script popularized by John Resig and Remy Sharp.

Overall, it was an enjoyable stroll through HTML 5’s more accessible areas. Maybe XHTML 2 would’ve been a more thrilling excursion, but I’m content. Shiv or not, it looks to be sunny ahead.

6 Things to Know About Developers

No surprises here, or none for techs, anyway. A lot of the following sounds like banal repetition of common sense. But the thing about common sense is that it isn’t…common. And so, even after twenty years of Dilbert cartoons, I feel compelled to list a few points I want my non-tech colleagues to remember.

6 Things to Know About Developers

  1. We hate lengthy, freeform meetings.
    I’m really disappointed I have to write this it at all. I thought all the books, blog posts, satire, and research results had convinced everyone with at least functional literacy of the total buzzkill, the utter torment, the massacre of productivity, that the typical business meeting means for programmers and developers. And format doesn’t matter–don’t think that conference call is any less loathed.

    Solution: schedule only short meetings (<1 hour) with strict agendas, if you must schedule any at all.

  2. We really don’t need to see all of the marketing presentation.
    I don’t question that the marketing people worked really, really hard on what is just about the world’s best preso, the one that’s gonna reap all the financing and press attention. But I’d prefer to take your word for it; I’m about as enthusiastic and informed an audience for this material as the marketing people are for, let’s say, a prolonged discussion of JavaScript debugging tools.
  3. We require specifics.
    We can tell you’re excited about your idea, and it sounds to us like a good idea, and sure, let’s build it. But we can’t act on the sparse outline of it that you’ve provided: “It’s like MySpace–only for dogs!!” says nothing to us about where you want to start.
  4. We have specialties.
    Yes, there certainly are many people who can design an application, copywrite its content, write all the HTML/CSS/JavaScript for the interface, and develop all the scripting that communicates to an optimized, secure database. The people who can do all these things well are scarce. In fact, they’re usually not for hire since they’re too busy speaking at conferences or writing books.

    Scrupulous developers often qualify their self-descriptions with terms like “software,” “application,” “Java,” “Flash,” “user interface,” or “front-end” prefixed to the noun “developer.” You’ll save a lot of bother noting this qualifier, since it’ll keep you from asking software devs about JavaScript and front-end devs about Java.

  5. Not all of us are white, 20-something nerdboys.
    I don’t know why this stereotype persists. Many, perhaps even most, developers of my acquaintance fail to embody at least one of the qualities listed above. Maybe I just know a select coterie of middle-aged, female, humanities-educated, and/or non-Caucasian techs. Anyway, few of us seem anticipated by the majority of tech firms, who try to lure us into their employ with promises of foosball and all-you-can-drink Red Bull.

    Snore.

  6. We need fresh air and sunshine too.
    So many tech workplaces seem fashioned by prison architects: no windows, horrible, glaring fluorescent overhead lighting that is about a million times brighter than necessary, and even gray cubicle walls subdividing the room into a bunch of sensory deprivation chambers.


    How come you want to work from home?
    Photo by cackhanded

    Ask yourself if you could spend 8+ hours working where your devs do. Even better, take a high school algebra or trigonometry textbook, and try to work out the solutions to every problem in the textbook while seated in one of these spaces. If you can’t, it might not be entirely due to a failure in your math abilities.


What do you want everyone to know about developers?

Elements of a productive work day

Having spent the past few weeks playing Whac-a-mole on a project, and waking this day with some leftover sanity and a lot of work done, I think I’ve arrived at a framework.

Elements of a productive work day

  1. Turning off clients for IM, IRC, and e-mail. The benefits of working without distractions have been well-publicized.  I’ve long detested trying to work with IM and IRC anyway; this time I decided to enjoy hours of even deeper productivity by turning off e-mail as well except for an hour at 9am, 12pm, and 5:30pm.  Regrettably, many customers/project leads haven’t modernized to this way of working, so expect indignation when you try this.
  2. Queueing up the right tunes in Last.fm.  I prefer instrumental music when I work, since I won’t drift away into parsing lyrics.  Normally, I’m indifferent to classical music, but I like working to it, since it reminds me of being in a classy bookstore, instead of being huddled at a desk sweating over support for :hover in IE7. Strangely, both middlebrow “light” classical and less favored experimental works (try typing in “Delibes” and “Xenakis” into  Last.fm‘s artist search) seemed acceptable background music.
  3. Configuring LeechBlock. I’ve got Firefox hot-rodded with loads of add-ons, and one of the newest to me, and most valuable, is LeechBlock.
    Get back to work
    Get back to work

    It works by blocking your browsing to certain sites after a given time period.  I set mine to a reasonable 25 minutes spent on my favorite time-wasting Web properties.  It’ll probably become a boast or social marker to confess which sites you find so compelling you require LeechBlock to take them away from you.  For the record, mine are Netvibes, Facebook, Twitter, Wikipedia, and the New York Times.

  4. Water. Seems so obvious, but a lot of people forget to drink water.  Granted, I’m lucky to have good tap water piped straight from the California mountains, so it’s not hard to choke down.  It also helps to have a glass you like.  Mine is an imperial pint that I refill four times, and which gets re-purposed for a good IPA at the end of the workday.

Think I skipped over something?  Add your suggestions in the comments.

I Still (Heart) RichInStyle

I’ve been perusing a lot of job postings, which is, I know, inefficient, if my goal is to find a job, but it’s interesting to see what employers are putting in their requirements.

More and more frequently I’m seeing a call for skill with frameworks–not just for Ruby on Rails or Prototype, but also for CSS. There are by now a few of these to choose from: the skins for the Yahoo! User Interface Library, Blueprint, Nicole Sullivan’s “Object Oriented CSS” (excellent work, but oh! for a less trendy name), and so on. All of them: good to use. But it depresses me that employers don’t want to hire someone who can develop CSS by hand.

Hand tailoring
Photo by Bradley Allen

I’ve barely used any of the frameworks; I haven’t needed to. I guess I’m like a Savile Row tailor in preferring to make my own measurements and to follow my own procedures. But I can’t really say “my own,” since I was the benefactor of other CSS developers, those who worked in the earliest days of the technique—Web 0.9?—and discovered its patterns.

One of these pioneers was Matthew Brealey, who contributed to the W3C CSS discussion list. In between posts he maintained RichInStyle, a one-man compendium of frontend development tips and tutorials; I had it bookmarked, if not always open in a separate browser window. Brealey somehow had the time to investigate the browser support for every proposal in the CSS 1 specification; generously, or self-aggrandizingly, he posted his findings.

He also devised a way of writing a stylesheet that, with few adjustments, I still use. Brealey’s “Masterclass” show signs of age (remember uppercase element names?), but outlines one of the most logical ways to write CSS I’ve seen yet.

A couple of his most enduring principles are, simply:

  1. Use the cascade. Start with the most general rules at the top (HTML elements), and only then follow with those for classes and IDs. Put the toughest cases–the most obstreperous browser hacks–at the bottom of the CSS text, processed last.This rule seems obvious, but I can’t believe how many stylesheets I see beginning with class or ID rules.
  2. Ease human usage of the stylesheet with alphabetization. Brealey wrote before we had Firebug, or even View Formatted Source. Yes, we were flying with instruments in those days; you never knew where that pesky text color was coming from, nor why your document’s h3s were in italics. But a stylesheet organized as Brealey proposed gave up its secrets more readily: the rule for h3, for instance, would be reliably beneath that for a and above that for p, and its font-style would be beneath border and above margin. Maybe the importance of this approach has diminished as far as debugging goes, but it still shows thoughtfulness, the developer’s hand.

Developed by hand, old-fashioned; an artifact, not a commodity. Sure, I’m biased in favor of hand-tailored CSS, but then I’ve seen nothing but benefits from its skilled usage. Note “skilled.” It’s thanks to Matthew Brealey and others like him that I know what that means.

5 Things I’m Doing Nowadays Instead of Working

So, you might’ve been spending the last year or so snoozing under a stalactite in Mammoth Cave, and completely missed the near-hourly utterance of the word “recession,” and now you’re a trite confused that so many millions of Americans with good educations, impressive experience, and opposable thumbs are unemployed. In fact, you could’ve surfaced a few months ago and been confronted with the same puzzler, even the same zombie battalion of former job holders. But not all of us are weathering the economic downturn with Red Vines and Snuggies. Some of us are keeping busy; almost too busy to work.

5 Things I’m Doing Nowadays Instead of Working

  1. Getting my command of JavaScript from 30 to 60. I can write state-of-the-art scripts—for 1998. Rather than continuing to embarrass myself with inline onclick handlers and overdependence on alert() for debugging, I’m devoting extra time to reading everything and anything written by Chris Heilmann and Peter-Paul Koch.
  2. Playing with all those advanced techniques customers never request. To date none of my clients have paid me to use any of the goodies from GitHub or Google Code or the multitude of promising APIs; instead, my workdays are devoted to treating float drops in IE 6 and the like. Now, with only myself to please, I can spend time on more challenging tasks at the keyboard.
  3. Thinking of going back to school. I spend much of my time reading about the built environment, and all of my time using it. I’ve been interested in architecture for many years, yet have no training in it; haven’t worked in the field at all. So what better time to seek retraining than the unbillable present?
  4. Avoiding the news. I stopped my hourly visits to the Web sites for the New York Times and the San Francisco papers because I suspected I was getting too distressed by the dismal stories I read there. I was right —my mood brightened once removed from the daily downbeat. I’m still informed of the things really important to me, and free from concern about those which aren’t.
  5. Going outside. One of the biggest stressors for me when I’m fully employed is that I’m not able to go outside very much during the daytime. Now, with no hypertensive project managers or overdemanding clients to rebuke me, I’m spending a lot of mid-days running, bicycling, or hiking. It’s a pity that work (unless you’re a bike messenger or park ranger) is so often structured to be incompatible with these activities, which are probably the easiest way to regain your enthusiasm for life.

What are you doing instead of working?