Skip to main content

Kimberly Blessing

Giving Credit Where It's Due on Ada Lovelace Day 2014

3 min read

I haven't written a post for Ada Lovelace Day in a few years (last in 2010) and recent conversations have made one feel necessary. When the contributions and accomplishments of my female contemporaries on the Web are unknown to people just a generation behind, I get extremely concerned. After all, the making of the Web is the making of history in modern times. As I've pointed out before, we have the opportunity to document our times and lives unlike never before -- but data loss can occur. And it is.

Twenty years ago, when I was in college and learning how to create web pages, I pretty much had two sources of information: documentation written by TimBL and USENET newsgroups. But once I started working professionally, I realized that there was a wealth of information being printed on paper. And what I saw was that large numbers of these books on web development and design were being written by women.

Me and Molly HolzschlagMe with Molly Holzschlag

Women such as:

I wish I could tell you exactly how many books these women have collectively written -- I'm sure it's over 100 -- but quick searches of their bios and websites doesn't always make this data clear. Is it modesty? Do multiple editions make the numbers tricky? I don't know.

But when I mention the names of these women -- all of whom are still active online, many of whom are still writing (or speaking) about the web and programming -- to web developers today, I'm often met with blank stares. I'll have to mention that Lynda founded Lynda.com, (still!) one of the top online training sites, or that Jen co-founded the extremely popular ARTIFACT conference. I have to explain that Dori has helped run Wise Women's Web, one of the earliest communities for female developers online, and that we have Molly to thank for convincing Bill Gates and Microsoft to be more open about Internet Explorer development at Microsoft (there are so many articles to link to, but I want to link to Molly's old blog posts, which are gone *sadface*).

While my past ALD posts have been happy remembrances of people who've made positive impacts on my life, this post is written out of frustration -- and even a bit of anger -- that the contributions of these women are being forgotten or overlooked in their own time. Let's give credit where it's due. Comment or blog or tweet about the books written by these women that helped you learn your craft. Send them a thank you email or tweet. (In Molly's case, you can give to her fund.) Share this post or the links to these women's websites with someone who needs to learn about their foremothers. And just be thankful that women helped light the path for others by sharing knowledge about building the World Wide Web.

Kimberly Blessing

BlogHer '14: Preserving Your Online Content

4 min read

BlogHer 10th Anniversary Celebration

Earlier this year, I read (and raved about) Book of Ages: The Life and Opinions of Jane Franklin by Jill Lepore. One of the obvious realizations when reading this book is that today we have little first-source material of the average person's life from this era -- and especially little of it from women. It's only because of Jane's famous brother that her writing has survived -- and through that correspondence, we can learn so much.

That seems to be a theme for me, this year: I've been thinking a lot about how we document and preserve information -- stories, photos, videos, etc. -- online, whether for ourselves (ooh, the cloud), to share with family and friends (social media), or for posterity. I was first drawn to the web, 20 years ago, as cheaper means of communication... but like so many others, have realized the wealth of history we're documenting as well. It's important to me that we preserve that history... because, even though we think the Internet never forgets, it does.

So, when the good folks at BlogHer approached me about participating in this year's 10th anniversary conference, I thought this would be the perfect subject to talk about. Except I'm not talking... I'm running a Geek Bar instead! This means that I'll be helping bloggers who are interested in hands-on learning and help on how to preserve their online content. This post is a short summary of some of the material I expect we'll review and resources we'll need to reference, mostly for WordPress users (non-developers). Whether you're at my session or not, you may find this information useful and you're welcome to contribute your own! (I'll update this post later with anything else we cover.)


Backing up your blog

If you're blogging on a free or paid service, learn about what backups they're creating and whether or not you can get access to them. If you're paying for hosting and running your own blog, add a backup subscription service or set up your own backup solution.

  • For WordPress: VaultPress, Backup Buddy, and loads of other plugins.
  • If you're looking for something that will (likely) outlive you, submit your site to the Internet Archive for archiving (via the "save page now" form). Make sure your web page templates or robots.txt do not include NOARCHIVE.

Better broken links

Nobody likes getting a 404 (page not found)... and they're not good for search engines or archiving tools, if you want them to get your content! Help 'em out:

Moving and taking down content

If services go offline, you choose to switch providers or domains, or you simply choose to take content offline, you're going to want folks (and search engines) to know.

  • Familiarize yourself with the HTTP status codes. Here's a quick review of the most relevant ones:
    • 200 OK - this is what you want folks to get, in addition to your content
    • 301 Moved Permanently - if you're moving between services/URLs, you want this to be the redirect type
    • 302 Found or 307 Temporary Redirect - if you're having momentary issues and want to send readers somewhere else for a short time
    • 404 Page Not Found - the one we don't want people to get
    • 410 Gone - what you want to send when you've taken something down and don't ever intend for it to come back
  • If your site runs on Apache, learn about Redirect and Alias directives which you can set in your .htaccess file.
  • Yes, there are WordPress redirect manager plugins, too.

Solutions for all of your online content

What about your Facebook posts, tweets, Instagram pics, and other content on third-party sites? You can save those, too!

Kimberly Blessing

My Nerd Story

8 min read

Rosie the Riveter reminds you that we can do it!These are cute totems. I have the Tesla doll.

A few days ago, I was directed to Crystal Beasley's Nerd Story post by Kirin Kalia, my Bryn Mawr College classmate. She asked me to share my own "nerd" story.

I hesitated. I hesitated because I saw that Crystal was prompted to write her story in response to one of the current sexism-in-tech spotlights. (I'm not trying to downplay whatever is going on currently -- I'm just not following it and can't speak much about it.) I hesitated because I know that my story is laden with the exact kind of privilege that is often attributed to white men in technology. I know that some women don't so much see me as a potential role model as part of the problem.

Still, I considered it. Then I went back to Crystal's post and read the comments that had been left and thought, "I don't need to deal with this shit." Crystal's post had brought out the trolls, haters, and real misogynists. While I've read my fair share of hate mail, I am past the point where I want to deal with online harassment because it wastes *my* time to have to handle it.

After thinking about it some more, I figure that if my story guides or inspires just one other person, or validates something going on in their brain (or heart), then any grief will be worth it. So, here goes.


I grew up in a middle class family that was extremely focused on education. My grandfather was an engineer in the midst of the CAD revolution; my dad and aunt were pharmacists dealing with the computerization of their field. Math, science, and tech geekiness ran in my family.

I started elementary school in 1980 and, from day one, got used to seeing a variety of TRS-80s in the building. Soon, I got used to using them on a regular basis, first through the gifted program, and later through a before and after school program, which I've written about before. BASIC was my first programming language. I wrote programs to make sounds, change the screen color, print text to screen, draw shapes -- all of which culminated in me programming a TRS-80 CoCo 2 to play the harmony to "Yesterday" by The Beatles, while I played the melody on the flute.

TRS-80 CoCo 1My TRS-80 CoCo 1, salvaged in 2008. I don't like getting rid of old tech.

Meanwhile, at home, we had Pong, then an Atari 2600. Playing games was fun, but I wanted to write programs. I got a Commodore 64; in the summer of 1983, after seeing War Games, I spent weeks trying to program my own "Joshua" artificial intelligence. Thankfully, no one ever discouraged me from working on that fruitless program. I don't think they even knew that building an AI wasn't possible. I sure as hell didn't.

The Commodore 64 eventually became a 128 and was a mainstay for everything from gaming to doing homework to getting online. In 1985 or 1986, my aunt purchased an Epson Equity PC (8088) and thus I was introduced to DOS (version 2.11, and all of the upgrades from there!). She was using it for basic word processing; I quickly figured out how to do mail merges for her, create spreadsheets, and other more "office-y" type things with it.

As I made my way into junior high and high school, my interaction with computers was limited to home and the library. Whereas every classroom in my elementary school had a TRS-80 or an Apple IIe, the only computers in the upper schools were in special computer rooms, which were mostly used by the "business prep" students. Honors/gifted students, apparently, didn't need to use computers. At home, with more and more homework to do, my computer use became much more practical -- checking math and typing papers. There wasn't time for programming.

In reality, I didn't make time for programming anymore. It wasn't in the classroom anymore, so I suppose I didn't see it as important anymore. Although I started seventh grade already knowing some trigonometry, I went back to algebra. Yawn. Science was still fun, at least, but my language and music teachers were much more encouraging of my work and progress. I turned my focus to where I got feedback and positive reinforcement. By the time I graduated high school, I had dropped out of calculus but took AP French. I had skipped the one and only programming class at my high school -- but when I saw the homework assignments, I yawned again. They would've been pretty repetitive for me.

Thanks to my grandfather, I started college with a brand-new Packard Bell 486/33, which came with 4 MB RAM, a 120 MB hard drive, a sound card, a 2400 baud modem, and Windows 3.1 -- better than my boyfriend's! In my single dorm room, I had plenty of time to noodle with my new tech. Word 6 and NCSA Mosaic had just been released. I had accounts on AOL, Prodigy, and Compuserve but also quickly learned how to dial in to my college's UNIX server. That computer lasted me one year; I built a new computer the following year and upgraded it consistently, until I got to grad school and bought a fancy Dell machine with a Pentium processor.

At the same time, I was rocking my liberal arts education experience, with my intended romance languages major, until the reality of completing the quantitative (i.e. math) requirement reared its ugly head. I wanted to love calculus, but I struggled. Where to turn? Intro to computer science, of course. I figured it should be easier than suffering through more calculus. I didn't count on it changing my educational direction.

I wasn't a great student, that first CS class. Instead of really trying to learn something new, I relied on my existing knowledge and prior experience to get me through. But I guess it was clear that I "got" it enough to warrant the encouragement of the professor, my friend Deepak Kumar, to continue studying CS. So I did. It was as simple as someone saying, "Hey, you're good at this. Ever thought of majoring in it?"

Me in college with an X-TerminalIn the X-Term lab. I think Sarah and I were writing a program to play Konani.

Being a major in computer science at a women's liberal arts college with only one CS professor wasn't easy. I had to lobby the school to be a CS major, and I had to take classes at other colleges and universities in order to complete my CS requirements. I remember taking computer organization (my favorite subject) at Carnegie Mellon University, and being one of about four women in the hall of perhaps 200 people. It's only strikingly odd to me now; at the time, I knew I was a rarity, but it didn't really faze me. (Later, in grad school, the ratio was a bit better because the classes were smaller.)

I made friends with Sarah Hacker (yes, her real name) who had already decided on a CS major; she worked for campus IT services and helped me get a job. Because I knew UNIX, I made an extra 25 cents an hour! Sarah introduced me to HTML (and helped me fix my first markup bug) and I started cranking out websites on Deepak's server. Other members of the team taught me everything I know about software and hardware support. It was a perfect storm of interest, opportunity, and encouragement. The rest, as they say, is history.

Today, after 20 years of experience in large internet/tech companies (AOL, PayPal, and Comcast) and other organizations, I head up the web development team and growing technology consulting practice at Think Brownstone. I've architected and built some of the coolest publishing systems and web sites in the history of the internet -- and I still get excited when I'm presented with a challenge that requires strategic thinking, technical know-how, and organizational savvy. I've been able to take my experience and turn it into book contributions, conference presentations, and a for-credit CS class at my alma mater. I'm still a technology junkie, but as a manager and leader, I get the biggest kick out of coaching younger talent and helping them grow their skills.


Disney's Kim Possible

The moral of my story is: discouraging a young mind can stop its progress, but encouragement can help get things moving again. If you're an adult, figure out who you can encourage today. If you're a young adult, avoid the discouragers (as much as you can) and find the encouragers.

Write your own Nerd Story -- don't let it be written for you.

Kimberly Blessing

On the Writing Process

4 min read

I am not a storyteller.

This was the thought I had the other day, after reading Neil Gaiman's tribute to Lou Reed. Those guys are storytellers.

I love listening to stories. Reading stories. I love the way they take me on a journey. I'm able to just sit back, take everything in, have the plot laid out for me, the characters developed, and the whole thing resolved, all for my enjoyment and entertainment.

A good storyteller is a magical thing.

I bring this up because storytelling is an incredibly effective way of communicating. Because I am not a storyteller, communicating is often very difficult for me.

I recently published a blog post that took me over six weeks to write. Now, I wasn't working on it continuously for six weeks of course -- but I did have all of the important information I wanted to communicate identified six weeks ago. Structuring it so that it made sense is what took so darn long. And, by the time I published it yesterday, most people had moved on from thinking about that topic, and so it went over like a dud.

That's okay, I tell myself. I'm only writing for me: to practice writing, to capture my own thoughts. And then I call bullshit on myself, because I'm reloading the stats window and watching to see who retweets the link.

Once upon a time, writing wasn't hard for me. I just sat down and wrote and wrote and wrote. Creative writing, they called it -- and through 6th grade, it was among my top favorite things in school (probably after math and computer time and reading). Come junior high, I had to discipline myself and structure my thoughts to write five paragraph essays.

Ugh, five paragraph essays: an introduction, three supporting points each in their own paragraph, and a conclusion. I really sucked at those, and I have the bad grades to prove it.

Mr. Weaver, my history teacher, and my grandmother both spent a lot of time with me to help improve my structured writing approach. No longer could I just sit down and write, because the editing process made such a mess of my work that I couldn't look at it any longer. And so I began writing out individual sentences or thoughts on index cards, and sorting those into groups and then writing connector or transition statements on new cards and adding them to the mix. And, in the end, all I had to do was copy my index cards to paper and submit. Done. A+. I still have the first paper I ever wrote this way (on Henry Clay) -- and the supporting index cards! -- to show me that this approach works.

And this approach works for a lot of things. It's great for making slide decks, which I do a lot of in my work -- and with all of the practice I have, I do it rather quickly. I also wonder if this approach to writing didn't influence the way in which I code, since I really love the modular approach.

But when it comes to writing -- well, it's hardly writing, is it? I mean, it is, but it seems rote. Perfunctory. Emotionless. And so this is why I struggle to write now -- because I write from an emotional place. But my emotional place doesn't do well with logic and often communicates its point by feeding information between the lines, and so only the most careful of readers will get the point.

Storytelling is all about emotion -- great storytelling makes you feel something. Most of my writing falls flat from lack of emotion. But at least it gets the point across...?

So, what to do? Write and ramble and never quite get my point across? Or structure my thoughts, compose the thesis, defend it, all stocky and blocky and templatized and boring? How does one combine the two approaches?


PS: I wrote this in one sitting, and mostly in one shot straight through. The end is where I got hung up the most -- when I was trying to figure out what my point was. The opening and a few of the statements I wrote in my head, in the shower yesterday.

Kimberly Blessing

Code Archaeology: Dusting Off the Line Mode Browser

6 min read

Photo of an old IBM computer running the line mode browser, with the explanation page displayedThe line mode browser (LMB) info page, running on the line mode browser.

It's been over a month since I returned from my trip to CERN to participate in the line-mode browser hack days and I'm finally getting my photos and my notes in order. If you haven't read much about the event, Jeremy wrote an excellent summary of the whole experience.

I was on the "coding" team and spent a good deal of time reading through and tracing the logic of the line-mode browser (LMB) source code. It felt like every few minutes I was finding something new or interesting, and pointing it out to the rest of the team, so we could be sure to make note of a feature we needed to implement or something that might be a pitfall. I referred to this work as "code archaeology". Here are some of my more interesting findings:

  • The earliest style sheet (compiled into the browser) had six styles: normal, list, glossary, monospace, address, and heading. (Heading had a further seven nested styles for TITLE and H1-H6.) What changed with each of these styles? Left indent (two levels), right margin, alignment, capitalize states (two, one for each left indent), double spacing, number of blank lines before and number of blank lines after.
  • There's code in place to handle H0 as a heading level. It was mapped to the title heading style -- so if both TITLE and H0 were present, H0 would overwrite what was shown in the TITLE location (at the top right of the screen (see picture).
  • If you've been doing web development for long enough, you'll probably recall the ISINDEX element -- and perhaps, like me, wondered it was supposed to do. If it existed in a page, it added a keyword command to the list of options in the prompt (see picture). It doesn't look like this feature was fully implemented in the LMB -- I don't see any code that would return a list of pages matching the query. In addition, the LMB only recognized ISINDEX if the opening tag was in all caps.
  • Here's an HTML element that was new to most of us: LISTING, which is supposed to render plain text. The LMB code we were looking at had a bug, however: only the opening tag was parsed and any closing tag was left to render in the page (see picture).
  • Another element that we'd never heard of before was HP, for highlighted phrase. HP comes from SGML. It had the effect of forcing text into all caps. The LMB that we reviewed parsed and only.
  • Because of the way the LMB parses a document, HTML comments (e.g. ) are ignored -- even though there were no comments in any of the early HTML documents we reviewed. In fact, any unknown tag is thrown away as a "junk tag", yet its contents (what's between the opening and closing tags) are still rendered to the screen. Thus, a modern web page with a or block would end up showing the user a whole lot of code!

My handwritten notes from my time at CERN My handwritten notes tracing the logic of the LMB, with Tim Berners-Lee's original proposal in the background

I'm not sure that we explicitly discussed it, but it soon became clear that we were building a simulator that we expected could render both current web pages as well as the earliest markup found in the first web site. This led to review of some very old markup, written by Tim Berners-Lee himself, and lots of experimentation with the old IBM system we had with us, which was running the LMB. Some more fun discoveries:

  • The HEAD element doesn't yet appear in HTML -- it would have been parsed out as a "junk tag". That said, in some old HTML documents, you'll find HEADER tags surrounding the TITLE and NEXTID. Fortunately modern browsers handle this old markup pretty well, so we didn't have to code anything special for our simulator.
  • These days, we're used to surrounding paragraphs of text with opening and closing tags... and, back in the day, we just putt hem at the start of paragraphs. Originally

    tags were used as paragraph separators, to create space between paragraphs. This made the work of writing the simulator CSS, to render both old and new code correctly, a little tricky.
  • The LMB indicated a hyperlink by placing a number in brackets following the link text, e.g. [1]. If your link text was more than one word, it might be confusing or hard to determine what text was part of the hyperlink. That said, the list command would show all of the hyperlinks in a document... but it was only helpful if your URLs were descriptive (see picture). The LMB could be started with flags to disable the showing of hyperlinks, which may have been useful when also running in non-interactive mode -- perhaps when trying to cat contents to files for storage or printing.

You, too, can get the line-mode browser source code and read through the main file (www.c). See what jumps out at you!

As I've expressed before, I'm concerned that many web professionals don't understand the history of the web and thus are doomed to repeat past mistakes. My biggest hope is that anyone who writes code for the web today will spend just a few minutes using the LMB simulator to browse the first web site as well as to check out their own site -- and notice, at the very least, that well-marked up content was and still must be the foundation of the web, in order to have a decent experience, regardless of browser capabilities. Good markup never goes out of style.


Kimberly Blessing

Empathy is for Every One

3 min read

Title borrowed/tweaked from this Pastry Box post... with thanks to Viviana for the reminder.

I screwed up this week. I didn't mean to, of course. I did something, made a decision, for good and right reasons. I just did an incredibly poor job of communicating that something to others. Normally, that's not a really big deal, but in this case, it was. And so my screw up ended up occupying too many people's minds and time for too much of the week.

The first word in the name of this blog is People. I've realized that, throughout my career, when People didn't come first, things go wrong. And you can't just say that you're putting People first, you have to actually do it. To me, putting People first means having empathy for each individual, and considering their needs. Empathy is a crucial part of respect and trust, in my opinion.

I am best at putting People first when it comes to my team. Wherever I've worked, I have found empathy for those who reported to me, and I think/hope it has made me a good manager and leader. It hasn't always been easy, although it usually is. This week, my empathy for my team was running very high.

When it comes to the other end of the organization -- my peers and those higher in the leadership chain -- I realize that I sometimes forget about having empathy for the individual. Sometimes I get caught up in referring to "the management team" when all I see is bureaucracy. I have to stop and remind myself to see the People instead.

While empathy on my part can go a long way, it's ultimately a two-way street. I think we complain about working for our bosses, The Man, or Corporate America because those roles and organizations don't exhibit much or any empathy towards us. Too often, they demand respect due to their authority -- they intimidate and instill fear rather than communicate to understand and build trust. This, my friends, is debilitating.

Ultimately, I wasn't in a debilitating situation this week. I felt empathy for a member of my team, and I acted in that person's best interests. But I wasn't feeling any empathy for those I needed to inform about my actions, and I botched the communication. I'm shifting perspective and making amends, and writing this blog post to remind myself, because I know it will happen again.

Time to write "Empathy is for Every One" on a sticky note and put it on my monitor. Or, maybe have it tattooed on my hand.

Kimberly Blessing

Why I'm starting a new blog

2 min read

Welcome, and thanks for checking out my new blog!

My old blog, Obi-Wan Kimberly Is Your Only Hope, is still online and won't be going away. The content is all still relevant although the code needs major updating. It's still on my to-do list and it will happen, eventually.

I've been saying for a while that I need to get in the habit of writing more often. I love reading blogs by tech folks that write every day, even when they don't write about technical topics -- Tim Bray writes one of my favorites. If I can make time to read every day, I can make time to write everyday. I know how to form new habits, duh.

I'm starting fresh to free myself of constraints. I'm using a default WordPress theme in order to stop myself from making excuses about design tweaks or code changes. Even though I'm calling the site "People, Process, Technology", I'm going to allow myself to write about whatever's on my mind. (I'll explain why it's called "People, Process, Technology" soon, though!) In short, this site is a blank notebook for me. You're welcome to read through it, at your leisure.

Thanks again for stopping by and I hope to see you again soon.

Kimberly Blessing

Blog, Interrupted

3 min read

I started this blog in January of 2010, with the intention of re-contextualizing myself as an authority on career development for web development professionals. My goal was to post weekly about topics that would be relevant for early and mid-career web developers, or for new managers. The first month went decently, I thought: I had a long list of topics I wanted to address, I had a set time for writing (on my train commute), and I got great traffic and decent responses to what I published.

Then things got busy at work, and weekly posts turned into monthly ones. As issues and frustrations crept up at work, more time went by without posting. Without regular practice, constructing coherent opinions was time consuming and, due to what was going on in my day job, I found myself injecting too much cynicism and negativity in to my posts. Still, many readers and colleagues encouraged me to keep at it, and occasionally a post appeared.

Then, in February of 2011, my life changed when a family member became ill and I took on primary care-taking duties. Most of my time was taken up by phone calls to various state and government agencies, doctor's visits, shopping trips, extra laundry... and what wasn't taken up with care-taking work was spent trying to chill out. Now, almost exactly two years later, with that family member happily situated in the proper care facility, I have time to myself again. With this time, I'm starting to understand how much I've changed, and how much this experience has taught me about myself as a person, but also as a leader, a team member, a technologist, an advocate, an educator, a student -- the list goes on and on. I am still me, but my brain has been rewired. And, I think, it's for the better.

As for the blog, I do intend to continue with it. I still have a long list of topics to write about, and I need the writing practice! But change is constant and time is in limited supply, so I know that the posts won't be produced quickly. I can't promise that I will respond to every question I've received in the past few years, although I'd like to, since they were all wonderful and important questions I hear many people asking. I do hope that whatever I do write here will impart some knowledge that you, dear reader, find useful or interesting. Thanks for sticking it out with me.

Kimberly Blessing

Life Lessons from the Labyrinth

2 min read

I came upon a labyrinth in the woods.

I considered the labyrinth, and its goal at the center.

There are two ways to the goal:
- follow the path, trust it will get you there, or
- skip the intended process and jump to the center

Wondering what I would get out of trusting the process, I followed the path.

I worried that I was traveling in circles, when I observed an obstacle in my path. I had to duck to avoid hitting tree branches. I kept moving.

I saw myself moving towards the goal, and I was pleased. At one point, I was close enough to touch it, but I did not. I was traveling in a circle but felt momentum pulling me in. I knew I would get there.

Then I took a drastic turn and moved to the outside of the labyrinth. I was far from my goal, and I questioned why the path had diverted me. I was so focused on my anger over being as far from the goal as I was at the start that I neglected to see the tree branches ahead. But I had encountered this obstacle before, and I remembered to duck. But this time I had to be more flexible -- there were more branches than before, so I had to bend further and for longer. I could have stopped, abandoned the path. But I kept moving.

Upon exiting the tree branch obstacle, I found myself moving closer to the goal again. I felt a sense of calm -- not excitement. I was glad I had been challenged by another obstacle on my path. My commitment to the goal had been tested, my faith in the path had been tested. I knew I would succeed.

I came closer to the goal. I did not think about jumping the path to the goal. I did not even fixate on the goal getting closer. Instead I found myself thinking back on the path that I had traveled, and what I had learned along the way.

And, before I realized it, I had reached the goal. I looked around at the path that had gotten me here, and thanked it. I thanked myself for not abandoning the path.

And then I exited the labyrinth, ready to face the day.

Written June 26, 2011 at Bryn Mawr College

Kimberly Blessing

I should've bet money (on using paragraphs in forms)

2 min read

For years and years, I have coded HTML forms with paragraphs. I would tell people that an input field and its label, plus any associated data (help text, error messaging, whatever), should be wrapped by a paragraph. To me, the contents are semantically and syntactically related; and much like any other written document, each form label-field pair is a distinct topic requiring separation from others. I think there's also precedence in the print world for this, as well as examples from early HTML work, but let's just leave my argument at that.

I believed in paragraphs in forms so much that I even made this the rule in PayPal's coding standards. And because of this, I have had a very long-standing argument with colleagues and friends, like Steve Ganz. (Mark Trammell, Shimone Samuel, and Jeff Harrell come to mind, too.)

I've been working on a writing assignment with Christopher Schmitt (a chapter on HTML5 forms for the upcoming HTML5 Cookbook) and he suggested that I include an explanation as to why I'm using paragraphs in my form examples, because, as Christopher said, "You know someone's going to be coming out for us on that one."

So, direct from the HTML5 spec, here's my new justification for using paragraphs in forms [Emphasis mine.]:

Any form starts with a form element, inside which are placed the controls. Most controls are represented by the input element, which by default provides a one-line text field. To label a control, the label element is used; the label text and the control itself go inside the label element. Each part of a form is considered a paragraph, and is typically separated from other parts using p elements.

There you go. I was right all along. I should've bet money on it.