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 </LISTING> 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 <hp1> and <hp2> 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 <style> or <script> 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 <P> 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

Optimizing Media Queries

1 min read

Wonder what impact all those media queries have on your fast, responsive web sites? So did I, so I did some research and presented it at the first CSS Dev Conference in Honolulu, Hawaii in December 2012. You can check my code as well as my math. TL;DR - it all comes out in the wash but it's good to know what different browsers seem to prefer.

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

In Control of HTML5

1 min read

At this year's In Control Web Design Conference, I'm conducting the HTML5 workshop. A portion of the workshop is done live with text editors and browsers, but I also have some slides to help set up the various exercises.

Kimberly Blessing

Pausing for a new year reflection

3 min read

Reflection, by Kimberly Blessing

Since my last real post here, over four months ago, I've been asked countless times why I don't blog more. I've received numerous emails from people who've thanked me for the advice I've offered here, and I can tell from the stats that people are still visiting. Don't worry -- I haven't given up on the blog, and I get that you're still interested in what I have to say. To which I can only say, thank you! I will get back to posting soon. But let me update you on some changes in my world.

Last month I transitioned into a new role at CIM: that of senior software architect, focused on web front-end engineering. It's exciting and it's scary, as any change is. I've put a lot of time and effort into developing my management and leadership skills and changing some bad behaviors, but I don't think any of that will go to waste in this new role. One becomes a software architect, in part, because of one's leadership skills, and having experienced managing some of the people I'll continue to work with only gives me greater insight into their talents and strengths, so I can help them accomplish more. From a technical skills perspective, while I've kept up on HTML, CSS, and browsers, there are a whole host of languages and technologies I need to brush up on or get acquainted with. I don't need to be the expert on everything, but I do need to hold my own in conversations with Java programmers, system administrators, and even other front-end developers. Most importantly, though, I need to buckle down and write more, so that my thoughts, research, ideas, and questions are available both to myself and others. As you, dear reader, can probably tell, sitting down and making myself write out my thoughts is not one of my strengths!

I will also be busy these next few months teaching a web application design and development class at Bryn Mawr College. I first had the opportunity to teach this "recent topics" computer science class at the end of 2008, and it was popular enough that the students asked the department chair to bring me back! I'm honored that every space in the class is full, and I hope to challenge both the students and myself by looking more into creating single web experiences which adapt nicely to the mobile environment. I am still thinking about whether I will re-present or make available the course materials to a broader audience, online.

I'm also preparing to present at some conferences this year and I'm working on a few other projects. I joked, on Twitter, that my theme word for 2011 should be "over-committed" and that's definitely true. So the mantra I'm repeating to myself is one I recently got in a fortune cookie:

You cannot be anything if you want to be everything.

A good reminder to all of us. Happy new year!

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

Planning for and Managing Browser Support

1 min read

With a flurry of new browsers hitting users’ computers and mobile devices this year, everyone involved with the Web has had to scramble to ensure that their sites are compatible with the latest and greatest. This has left many Web professionals and business teams wondering, “What browsers should my site support?” Kimberly Blessing helps you answer that question.

At Peachpit.

Kimberly Blessing

Planning for and Managing Browser Support

1 min read

With a flurry of new browsers hitting users’ computers and mobile devices this year, everyone involved with the Web has had to scramble to ensure that their sites are compatible with the latest and greatest. This has left many Web professionals and business teams wondering, “What browsers should my site support?” Kimberly Blessing helps you answer that question.

Read my article at Peachpit and let me know what you think! And stay tuned for my next article on optimization...