Skip to main content

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

Shop Talk Show #85

1 min read

Chris Coyier and Dave Rupert invited me to join them on Shop Talk Show to -- what else? -- talk shop. We chatted about my trip to CERN, employer size, portfolios, and code-related stuff. Check it out!

Kimberly Blessing

Interview during LMB Hack Days

1 min read

I am so fortunate to have had the opportunity to participate in the Line-Mode Browser Hack Days at CERN. In this interview, I speak about why I think experiencing the line-mode browser is important today.

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 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

'Change' Is Not a Four-Letter Word

1 min read

A repeat performance of my AccessU keynote, delivered at the end of the two-day, online Accessibility Summit. If you're not familiar with the Environments for Humans conferences, check them out! (Powerpoint slides with notes)

Kimberly Blessing

Unspoken expectations don’t work

1 min read

Unspoken expectations don’t work. Then again, some expectations, when communicated, may just go a bit too far.

If you don’t care about the French toast, then perhaps you don’t care about anything is my train of thought on the matter, and if you don’t care about anything, then working for me doesn’t seem feasible, as I have an insatiable desire to be surrounded by people who care as much as I do.

Stanley Kubrick, Some Instructions to the New Guy Concerning the Preparation and Presentation of My French Toast

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

Change Is Not A Four-Letter Word

1 min read

It was my great honor to be invited to give the keynote at the John Slatin Accessibility University (aka AccessU). This year's theme, "From the Margins to the Mainstream," really struck a chord with my inner change agent, and thus my keynote address was born. (Accessible PDF or PowerPoint file with full notes)

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 (What? 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.