Skip to main content

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

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

Want to become an expert? Study (web) history

5 min read

Lately I've been spending a lot of time thinking and talking about the past.

I'm at the airport awaiting a flight that will take me to the Line-Mode Browser Hack Days at CERN. CERN, perhaps presently most famous for being the home of the Large Hadron Collider, is also the birthplace of the World Wide Web. More on that in a moment.

Screen shotMy first personal web site, circa 1997

Twenty years ago -- What the hell? Where did the time go? -- I started college. I arrived at Bryn Mawr College a French major, soon to switch to Romance Languages. My Italian professor assigned us reading on a Web page. I was one of the few people in my dorm to have a computer (and modem! and laser printer!). I had email before I got to college, on both AOL and Prodigy. Bryn Mawr had a gopher space, but no web site -- in fact, there were only about 500 web servers up and running at the end of 1993. And yet, that seemingly meaningless introduction changed my life. I took computer science classes. I changed my major to computer science. I started building web sites -- heck, I designed and built the first web page to be hosted at www.brynmawr.edu. For me, that was the start of it all.

And so here we are today. You, reading. Me awaiting my flight to Geneva. To CERN. Holy freaking crap! Understand that, for me, this is akin to visiting Mecca, except I am worshiping ideas, and code, and technology, and the propagation of all those things that has help fuel the evolution of our world into its presently hyper-connected state.

But I must admit that I was surprised, when telling some other web developers about my trip, that they didn't know about CERN's relevance to the web. The popular history of the Internet as an American creation dominates, and it has consumed the WWW creation story for some. So I educate and inform, to set things right, to help those whose careers are based on HTTP and HTML understand their domain's history.

Now, here's where I get preachy, because I run into scenarios like this -- where a web developer will make statements about web-related history that are completely wrong -- frequently. "Oh, IE doesn't support inline-block." Wrong, it has supported inline-block for a long time, but it couldn't just be assigned to any old element. (I've heard this one a lot lately -- perhaps because I'm interviewing and one of the coding problems I give can potentially be solved with inline-block.) "Old browsers don't support the HTML5 doctype," is another popular one. Misunderstanding the origin of CSS3 properties, incorrectly attributing computer accessibility to web accessibility, explaining IE compatibility mode based on one or two simple tests rather than reading the documentation -- even attesting to a lack of JSON support prior to 5 years ago (?!) -- are things I've encountered lately.

I admit that I am quite privileged to have, essentially, grown up with the web. I've been active with it, as a user and a developer, almost as long as it's been around. I do fondly remember using both Lynx and Mosaic to not just surf the web, but also test my own sites. I remember "playing around" with CSS to layer text, and trying to get it to work in both Netscape 4 and IE 3.

But I digress -- this isn't about me. This is about getting other web professionals to better understand our field. To be correct in what they say about the past, when trying to educate others. To not make false statements, based on lack of knowledge or direct experience, which lead to wrong assumptions and misinformed decisions about code and architectures.

I realize I sound like a crotchety old geek, complaining about the young whippersnappers who don't respect their elders. This isn't the case at all. I've had the pleasure of working with many younger people, or just less-experienced people, who have taken the time to learn about the web's history. (Admittedly, some of those people were required to, when they took my course on web app development.) And just knowing facts about history doesn't do much good, without analysis or thought of impact, for today or beyond.

Genuine curiosity and a desire to learn all that one can is ultimately what makes an expert. And, truth be told, any real "expert" will be the first to admit that they're hardly such -- they're still on the quest to become experts, themselves.

So, here I am, about to board my plane, hoping to enrich both my understanding of web history, and yours. Assuming I haven't entirely turned you off, I hope you'll follow my travels on Twitter.

Required Reading

Kimberly Blessing

Optimizing Media Queries

1 min read

I revisited my CSS Dev Conf talk for the Responsive Web Design Summit, with additional data from an analysis of Microsoft.com. (What? Microsoft.com is responsive, you say? It is!) Same story, though: how you compose your media queries affects performance, but not consistently across browsers. Overall front-end optimization is still best! slides, data, and test code is all available.

Kimberly Blessing

Realizing "One Web"

1 min read

Realizing "One Web", a presentation given at Open Web Camp 4 in July 2012 at PayPal, subtitled, "Or, Why I Hate the Mobile Web". I don't hate mobile devices, or mobile web browsers -- but I'm not thrilled by the way software engineers and architects approach building web sites and applications for mobile... especially in enterprise-sized organizations.

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.

Kimberly Blessing

Web Developer Job Search: Interviewing Tips

4 min read

Obi-Wan Kimberly Blessing That's me conducting a speed interview during my Speed Interviews session at WebVisions 2010

I've interviewed a fair number of web developer candidates recently, and many have followed up with me afterwards for feedback. The number one question I get? What else should I have known or said during the interview to land the job?

This is a pretty easy question for me to answer, so let me give all of you some insight into what I'm looking for, as a hiring manager and interviewer:

  • Have an opinion. This doesn't sound too tricky, right? But in order to have an opinion, you have to have some knowledge and/or experience. For example, if I ask someone what their favorite browser is and why, it's going to be easy for the person to come back with a response -- likely based on what they use everyday. So why is it so difficult to tell me what doctype you prefer to code against, or whether you like or dislike reset CSS? To me, not having an answer means that you either don't know what these things are or don't have experience with them. Oh wait, you do have experience, but you don't want to voice an opinion that would be contrary to my own? Your interview is not a time to be timid! State your case and let me at least know that you know what you're talking about. I certainly won't judge you negatively for that.
  • Know some HTML5 and CSS3. There are lots of HTML5 jobs opening up, and even those employers that don't presently advertise the need will want these skills in the future. What, you haven't learned any HTML5 or CSS3? You're a professional, right? The excuse that your current job doesn't support you trying these things doesn't fly. There are plenty of websites and new publications out now to help you get up to speed in your own time. Plenty of shops are currently looking at switching to HTML5 and adding CSS3 features, and they want people who are able to contribute to these efforts from day one. Believe me, you don't need a lot of time to pick up some knowledge -- in just a few hours you can learn quite a lot!
  • Admit that you don't know. Sometimes interviewers will throw you curveball questions designed just to get you to say one thing -- "I don't know." Yes, it can be mean, but it does have a purpose: are you someone who will bullshit your way through an interview, and then possibly a job? Or are you willing to admit that you don't know something -- and in that case, are you the kind of person who shuts down, the kind who asks for help understanding, the kind who says "I'll go learn about that and follow up"? It should come as no surprise that I like the latter kind of person. But there's an even more practical reason for this: you may misunderstand a question, or the interviewer may not ask the question in a clear manner, or you may not be able to give a direct answer to a question but you could speak about something related. Saying you don't know, but that you're going to try to answer the question in the way you understand it, shows patience and diligence -- and may just expose some additional skills or knowledge. Don't hesitate to say it.

Want some more interviewing tips? Back in May, I ran a session at WebVisions called Speed Interviews. In it, I gave some tips to help the audience have a great interview experience, and then I conducted a number of 2-3 minute interviews on stage. It was a fun but challenging experience for me! My slides are online and I welcome your questions about interviewing. Good luck!

Looking to learn more about HTML5?

Kimberly Blessing

Review of HTML & CSS: The Good Parts

3 min read

HTML & CSS: The Good Parts

O'Reilly's HTML & CSS: The Good Parts by Ben Henick is a new book to educate and aid web professionals in building quality web experiences. A quick disclaimer about this review: I worked on this book as a technical reviewer and the author is a colleague and friend.

This book is primarily for those who have some experience with HTML and CSS and want to refine their skills -- but even front-end code ninjas will find some valuable reference material in this book. While the title implies a focus on HTML and CSS, Ben takes the time to touch on a number of related topics, such as the client-server model, creating usable interfaces, image optimization, and web typography -- thus giving the reader greater insight on the wider range of knowledge and skills it takes to build a quality web site.

One of my favorite sections of the book is chapter 4, "Developing a Healthy Relationship with Standards." Ben gives an excellent explanation of the history and benefits of standards adoption and then wraps it up with 10 rules for "standards-friendly" development. If you're still trying to make the case for adopting standards where you work, definitely check out this chapter.

If you've read any of the "Good Parts" books then you know that these books also highlight the "bad parts" and "awful parts" of the subject matter. While Ben gives a good overview of the browser wars as context, he spends a number of pages calling out the various issues with Internet Explorer. (I like to think that I helped tone down some of the harsh criticism he originally wrote by reminding him of how advanced IE6 was at the time of its release.) He goes on to explain the concept of graded browser support (something near and dear to my heart) and hits on a number of seemingly nit-picky but important concepts which standardistas care about.

It's really amazing how much information Ben packed into this 352-page book -- far too much for me to address here. Besides touching on HTML5, there's a helpful glossary and numerous reference tables. As I'm writing this review, in fact, I'm sticky-noting the book so I can easily find reference information that will help me in my day-to-day work. That said, you can also sit down and read the book cover-to-cover. (Ben's an incredible writer.)

If you're looking to enhance your skills, improve the quality of your work, find a better job, or even if you just want to have a backup brain handy, I recommend HTML & CSS: The Good Parts.

HTML & CSS: The Good Parts
  • HTML & CSS: The Good Parts
  • by Ben Henick
  • Published by O'Reilly Media, ISBN-13: 978-0596157609
  • Companion web site
  • Buy it from Amazon

Kimberly Blessing

The Problem Isn't IE6 -- It's You

5 min read

This post is going to upset a lot of people, I'm sure, but what I have to say needs to be said, if only to remind members of our community to behave themselves.

Is Internet Explorer 6 an old, outdated, hanger-on of a browser? Yes, absolutely. Does it require the use code hacks in order to achieve semi-parity with more modern browsers? Yes, it does. Should this be such a problem for web professionals? No, it shouldn't.

IE6 Cartoon Thanks, Tracy Apps!

For a moment, forget about all of IE6's issues, security, how much you dislike Microsoft, or whatever baggage you're carrying around. Instead, think about IE6 as an unknown browser -- perhaps as a random blip in your browser stats, or maybe as an interesting piece of tech you've seen on a blog or at a conference. You don't know much about that browser or how your site is going to work on it, so what do you? You code it using web standards goodness: you create a base with semantic markup (and any server-side tech for forms), add on design via CSS, then layer on client-side interactivity with JavaScript and Ajax-y goodness -- et voilà, you have a lovely, robust web experience.

Now, with some new or unknown browser, you hope for the best. But with IE6, we know what the issues are. If you're using PNGs with alpha-transparency in your design, you'll need an alternate solution. If you're adding horizontal margins to floats, you know you'll run in to a double-margin bug. If you're trying to clear floats within a parent, you know you need to set height. You'll need to plan for handling unsupported CSS selectors. And when it comes to JavaScript, you may not even know what to plan for (unless you spend most of your days working with JS).

But again, you're a web professional. You know your craft. You know this platform and its issues. (If you don't, you need to know your craft better. No, I don't buy "newness" to the field as an excuse -- this is still a present concern, so you need to understand it! Why not start with my CSS tips for IE6.) While some venting may be in order, I find the outright hatred for this browser (and other versions of IE, also bashed on a regular basis) to be downright unprofessional. Here's why:

  1. IE is still #1. While recent reports cite that its market share is shrinking, IE (all versions combined) is still the number one browser in use worldwide. The snide comments I've seen people make about IE (which I won't link to) often extend to remarks about IE users, which is just about the uncoolest thing I've witnessed. Respect the user, regardless of browser!
  2. IE6 use is shrinking. With the growing number of sites proactively messaging that support is being discontinued for IE6, its share should continue to shrink, which will lessen your burden over time. (You do have an actively managed browser support policy, to help you identify when you don't have to support it any longer, right?) Celebrate that people are upgrading instead of harping on the stragglers.
  3. Promote the best experience. Instead of complaining about having to make a fancy widget work perfectly on IE6, engage with the client/product/design team to explain how you can deliver the best possible experience to every user by honoring only what each browser is truly capable of, rather than let one browser hold you back. You now have plenty of real world examples (Google Apps, Digg, Facebook, YouTube, etc.) to back you up on this!
  4. Help prepare for the future. Remind those in decision-making roles that the more time you spend looking backwards at the old, the less time you have to prepare for the new. Since I haven't met a business owner (small, corporate, or otherwise) who doesn't like "new", this should snap them back to their primary focus of strategies that save money and provide for the future.
  5. Don't make yourself look like an ass. If I'm one of those poor souls still stuck supporting (or, perhaps worse, using) IE6 and I'm trying to hire someone, do you think I'm going to hire the person who's been hating on that browser all over the interwebs? Umm, no.

I know folks are going to jump in with all sorts of comments about me not thinking about Ajax-y web apps or super beautiful design-y sites. The thing is, I do work on and continue to lead a team which works on these types of sites and apps, and yes, we're supporting IE6 in all cases. No, it's not to pixel perfection. No, the functionality we build for a new browser isn't 100% replicated. But these sites aren't as far off as you might think* -- and in the cases where I'm using hacks or JS shims to get IE6 into compliance, I also have easy code management techniques for dropping support.

*In fact, very recently, after preparing business and design teams to accept far less functionality in IE6, my team delivered a cool animated design-y thing that worked perfectly in that browser! (It's not live yet, but I'll update this when it is.)

So take the time to inform and to educate about browser differences and support strategies. Enthusiastically suggest alternatives to your team. Track your browser metrics and get happy about those numbers changing. Say a small thank you to those at Microsoft who are working to improve IE. Get inside the IE6 user's head and present their story, not your own tale of woe. If you need help, ask for it.

Seriously, it'll save you from looking like an ass.

Kimberly Blessing

Web Developer Job Interview Questions

1 min read

Every employer has a different recruiting and interviewing process, but at some point you're going to be asked technical questions. (Or, at least, one would hope that you'd be asked technical questions... if not, look out.)

If you've never interviewed for a web development job before, or if it's been a while, you might be wondering what to expect. Rather than list a whole slew of questions here, I'm going to give you access to a real screening questionnaire -- one that I've actually used as a hiring manager to help identify which applicants have a solid understanding of core web development knowledge. (Harder questions get asked over the phone, and the hardest ones in person.)

What are you waiting for? Check out the questions!

Interviewers and hiring managers, what other questions do you ask early-on in the recruiting process?