Posts in the History Category

The Web Behind #1

Published 7 years, 9 months past

Last Thursday was the first episode of The Web Behind, which was also episode #35 of The Web Ahead, and I couldn’t really have been much happier with it.  John Allsopp made it brilliant by being brilliant, as always.  To spend 80 minutes talking with someone with so much experience and insight will always be an act of pure joy. and we were beyond thrilled that he used the occasion to announce his Web History Timeline Project—a web-based timline which anyone can enrich by easily adding milestones.

The episode is up on 5by5, where there are a whole bunch of links to things that came up in the conversation; as well as on iTunes—so pick your favorite channel and listen away!  If you are an iTunes listener, Jen and I would be deeply grateful if you could give the show a quick review and rating, but please don’t feel that you’re somehow obligated to do so in order to listen!  We’ll be more than happy if people simply find all this as interesting as we do, and happier still if you find the shows interesting enough to subscribe via RSS or iTunes.

Guests are lining up for the next few shows, which will come about once every other week.  Jen is preparing a standalone web site where we’ll be able to talk about new and upcoming episodes, have a show archive, provide show information and wiki pages, and much more.  Great stories and perspectives are being uncovered.  Exciting times!


John Allsopp to Inaugurate ‘The Web Behind’

Published 7 years, 9 months past

Jen Simmons and I are very pleased to announce that our first guest on The Web Behind will be none other than John Allsopp.

Hailing from Sydney, Australia, John by himself has seen and done more on the web than most web teams put together.  First encountering the web in the early 1990s, he built one of the very first CSS tools, Style Master, and a number of other web development tools; published a wealth of information like support charts and free courses; wrote the deeply insightful and far-seeing article “A Dao of Web Design”; influenced the course of the Web Standards Project; and founded a successful international conference series that continues to this day.

We’re incredibly excited to have John as our inaugural guest, and hope you’ll join us for the live recording this Thursday, September 20th at 6pm Eastern/3pm Pacific.  That’s also Friday, September 21st at 8am Sydney time, and 2200 UTC if you want to calculate your own local offsets.  The time zone dance is the reason we’re recording the first show at that particular time.  Moving forward, the plan is to record on Wednesdays, usually mid-afternoon (US Eastern) but sometimes in the morning—again, depending on the time zones of our guests.

Be able to say you were there when it all started:  please join us for the live recording, and subscribe to get the finished podcasts as they’re released.  We already have some great guests lined up for subsequent shows—more on that as we firm up dates and times—and some interesting plans for the future.  We really hope you’ll be there with us!


The Web Behind

Published 7 years, 9 months past

Whenever I meet a new person and we get to talking about our personal lives, one of the things that seems to surprise people the most, besides the fact that I live in Cleveland and not in New York City or San Francisco, is that I have a Bachelor’s of Art in History.  The closest I came to Computer Science was a minor concentration in Artifical Intelligence, and in all honesty it was more of a philosophical study.

To me, history is vital.  As a species, we’ve made a plethora of mistakes and done myriad things right, and the record (and outcomes) of those successes and failures can tell us a great deal about how we got to where we are as well as where we might go.  (Also, from a narrative standpoint, history is the greatest and most authentic story we’ve ever told—even the parts that are untrue.)  The combination of that interest and my ongoing passion for the web is what led me to join the W3C’s recently formed Web History Community Group, where efforts to preserve (digital) historical artifacts are slowly coalescing.

But even more importantly, it’s what has led me to establish a new web history podcast in association with Jen Simmons of The Web Ahead.  The goal of this podcast, which is a subset of The Web Ahead, is to interview people who made the web today possible.  The guests will be authors, programmers, designers, vendors, toolmakers, hobbyists, academics: some whose names you’ll instantly recognize, and others who you’ve never heard of even though they helped shape everything we do.  We want to bring you their stories, get their insights and perspectives, and find out what they’ve been doing of late.  The Mac community has folklore.org; I hope that this podcast will help start to build an similar archive for the web.  You can hear us talk about it a bit on The Web Ahead #34, where we announce our first guest as well as the date and time for our first show!  (Semi-spoiler: it’s next week.)

Jen and I have took to calling this project The Web Behind in our emails, and the name stuck.  It really is a subset of The Web Ahead, so if you’re already subscribed to The Web Ahead, then episodes of The Web Behind will come to you automatically!  If not, and you’re interested, then please subscribe!  We already have some great guests lined up, and will announce the first few very soon.

I haven’t been this excited about a new project in quite some time, so I very much hope you’ll join Jen and me (and be patient as I relearn my radio chops) for a look back that will help to illuminate both our present and our future.


Same As It Ever Was

Published 9 years, 3 months past

I recently became re-acquainted with a ghost, and it looked very, very familiar.  In the spring of 1995, just over a year into my first Web gig and still just over a year away from first encountering CSS, I wrote the following:

Writing to the Norm

No, not the fat guy on “Cheers.”  Actually, it’s a fundamental issue every Web author needs to know about and appreciate.

Web browsers are written by different people.  Each person has their own idea about how Web documents should look.  Therefore, any given Web document will be displayed differently by different browsers.  In fact, it will be displayed differently by different copies of the same browser, if the two copies have different preferences set.

Therefore, you need to keep this principle foremost in your mind at all times: you cannot guarantee that your document will appear to other people exactly as it does to you.  In other words, don’t fall into the trap of obsessively re-writing a document just to get it to “fit on one screen,” or so a line of text is exactly “one screen wide.”  This is as pointless as trying to take a picture that will always be one foot wide, no matter how big the projection screen. Changes in font, font size, window size, and so on will all invalidate your attempts.

On the other hand, you want to write documents which look acceptable to most people.  How?  Well, it’s almost an art form in itself, but my recommendation is that you assume that most people will set their browser to display text in a common font such as Times at a point size of somewhere between 10 and 15 points.  While you shouldn’t spend your time trying to precisely engineer page arrangement, you also shouldn’t waste time worrying about how pages will look for someone whose display is set to 27-point Garamond.

That’s from “Chapter 1: Terms and Concepts” of Introduction to HTML, my first publication of note and the first of three tutorials dedicated to teaching HTML in a friendly, interactive manner.  The tutorials were taken down a couple of years ago by their host organization, which made me a bit sad even though I understood why they didn’t want to maintain the pages (and deal with the support e-mail) any longer.

However, thanks to a colleague’s help and generosity I recently came into possession of copies of all three.  I’m still pondering what to do about it.  To put them back on the web would require a bit more work than just tossing them onto a server, and to make the quizzes fully functional would take yet more work, and after all this time some of the material is obsolete or even potentially misleading.  Not to mention the page is laid out using a table (woo 1995!).  On the other hand, they’d make an interesting historical document of sorts, a way to let you young whippersnappers know what it was like in the old days.

Reading through them, now sixteen years later, has been an interesting little trip down memory lane.  What strikes me most, besides the fact that my younger self was a better writer than my current self, is how remarkably stable the Web’s fluidity has been over its lifetime.  Yes, the absence of assuredly-repeatable layout is a core design principle, but it’s also the kind of thing that tends to get engineered away, particularly when designers and the public both get involved.  Its persistence hints that it’s something valuable and even necessary.  If I had to nominate one thing about the Web for the title of “Most Under-appreciated”, I think this would be it.


Almost Target

Published 12 years, 5 months past

I’d like to tell you a little story, if I may, from way, way back in 2002.  (The exact date is lost to the mists of time, but the year is pretty solid.)  Like a lot of stories, it’s little bit long; but unlike some stories, it’s true.

As the engineering staff at Netscape prepared a new release of Mozilla, the browser off which we branched Navigator, those of us in the Technology Evangelism/Developer Support (TEDS) team were testing it against high-ranked and partner sites.  On a few of those sites, we discovered that layouts were breaking apart.  In one case, it did so quite severely.

It didn’t take much to see that the problem was with sliced images in layout tables.  For some reason, on some sites they were getting pushed apart.  After a bit of digging, we realized the reason: the Gecko engine had updated its line-layout model to be more compliant with the CSS specification.  Now images always sat on the baseline (unless otherwise directed) and the descender space was always preserved.

This was pretty new in browserdom, because every other browser did what browsers had always done: shrink-wrapped table cells to an image if there was no other cell content.  The only problem was that behavior was wrong.  Fixing the flaws in the CSS implementation in Gecko had broken these sites’ layouts.  That is, it broke them in standards mode.  In quirks mode, Gecko rolled its behavior back to the old days and did the shrink-wrap thing.

We got in touch with the web team at one of the affected sites, a very prominent social networking site (of a sort) of the day, and explained the situation.  We already knew they couldn’t change their DOCTYPE to trigger quirks mode, because that would break other things they were doing.  We couldn’t offer them a simple CSS fix like td img {vertical-align: bottom;}, because their whole layout was in tables and that would throw off the placement of all their images, not just the sliced ones.  All we could offer was an explanation of the problem and to recommend they class all of their sliced images and use CSS to bottom them out, with assurances that this would cause no change in other browsers.

Their response was, in effect:  “No.  This is your problem.  Every other browser gets this right, and we’re not mucking around in our templates and adding classes all over just because you broke something.”

The truth, of course, was that we were actually fixing something, and every other browser got this wrong.  The truth was not relevant to our problem.  It seemed we had a choice: we could back out the improvement to our handling of the CSS specification; or we could break the site and all the other sites like it, which at the time were many.  Neither was really palatable.  And word was we could not ship without fixing this problem, whether by getting the site updated or the browser changed.  Those were the options.

Let me reiterate the situation we faced.  We:

  1. Had improved standards support in the browser, and then
  2. Found sites whose layouts broke as a result
  3. Whose developers point-blank refused to alter their sites
  4. And we had to fix the problem

We couldn’t back out the improvement; it affected all text displayed in the browser and touched too many other things.  We couldn’t make the site’s web team change anything, no matter how many times we told them this was part of the advance of web standards and better browser behavior.  Two roads diverged in a yellow web, and we could choose neither.

So we found a third way: “almost standards” mode, a companion to the usual modes of quirks and standards.  Yes, this is the reason why “almost standards” mode exists.  If I remember the internal argument properly, its existence is largely my fault; so to everyone who’s had to implement an “almost standards” mode in a non-Gecko browser in order to mirror what we did, I’m sorry.

We made “almost standards” mode apply to the DOCTYPE found on the offending site—an XHTML DOCTYPE, I should point out.  While we were at it, we rolled in IBM’s custom DTD.  They were using it make their site validate while doing all kinds of HTML-invalid stuff, and they were experiencing the same layout problem.  And lo: a third layout mode was born.  All because some sites were badly done and would not update to accommodate our improvements.  We did it so as not to break a small (but popular) portion of the web while we advanced our standards support.

(By the way, it was this very same incident that gave birth to the article “Images, Tables, and Mysterious Gaps“.)

Now take that situation and multiply it by a few orders of magnitude, and you get an idea of what the IE team faces.  It’s right where we were at Netscape: caught between our past mistakes and a site’s refusal to accommodate our desire to improve support for open standards.

Some have said that Microsoft is in a unique position to take leadership and spread the news of improved standards and updating old sites to its customers.  That’s true.  But what happens when a multi-billion dollar partner corporation refuses to update and demands, under the terms of its very large service contract and its very steep penalty clauses, that a new version of IE not break (for whatever value of “break” you like) its corporate intranet, or its public e-commerce site?  It only takes one to create a pretty large roadblock.

For all we did in publishing great content to DevEdge, proactively helping sites to update their markup and CSS and JS to work with Gecko (while not breaking in other browsers), and helping guide the improvement of standards support in Gecko, we could not overcome this obstacle.  We had to work around it.

Looking back on it now, it’s likely this experience subconsciously predisposed me to eventually accept the version targeting proposal, because in a fairly substantial way, it’s what we did to Mozilla under similar conditions.  We just did it in a much more obscure and ultimately fragile manner, tying it to certain DOCTYPEs instead of some more reliable anchor.  If we could have given that site (all those sites) an easy way to say “render like Mozilla 0.9” (or whatever) at the top of every page, or in the server headers, they might have taken it.

But had we offered and they refused, putting us back to the choice of backing out the improvements or changing the browser, would we have set things up to default to the specific, known version of Mozilla instead of the latest and greatest?  The idealist in me likes to think not.  The pragmatist in me nods yes.  What else could we have done in that circumstance?  Shipped a browser that broke a top-ten site on the theory that once it was in the wild, they’d acquiesce?  Even knowing that this would noticeably and, in a few cases, seriously degrade the browsing experience for our users?  No.  We’d have shipped without the CSS improvement, or we’d have put in the targeting with the wrong default.  We didn’t have version targeting, but we still made the same choice, only we hinged it on the DOCTYPE.

A short-term fix for a short-term problem: yes.  Yet had we not done it, how long would Netscape/Mozilla’s standards support have suffered, waiting for the day that we could add that improvement back in without breaking too many sites that too many people would notice?  Years, possibly.  So we put in a badly implemented type of version targeting, which allowed us to improve our standards support more quickly than we otherwise would have, and it has been with us for the more than half a decade since.

So maybe I’m more sympathetic to the IE predicament and their proposed solution because I’ve been there and done it already.  Not to nearly the same degree, but the dilemma seemed no less daunting for all the difference in scale.  It’s something worth keeping in mind while evaluating what I’ve said on this topic, and whatever I will say in the future.


Browser Version Timeline

Published 12 years, 5 months past

Way back in March of 2007, I moderated a SXSW panel called “A Decade of Style”.  As part of the introductory material, I created a browser-history timeline in Keynote, spread across two slides.  I’d always meant to throw it up on the web for general edification and reference purposes.  So I finally have, in a slightly simplified visual format (the original had a parchment-like background and so on).

In the end, the web form of this is pretty simple, even though it wasn’t simple to produce.  It’s just a series of images, one per year.  I have in mind a way to do it without the images, which would be nice, as that way the information would be accessible to the blind.  Right now, all the images just have empty alt values, I’m sorry to say.  Besides which, creating the same timeline out of structured content would be a fun challenge, albeit one I really don’t have the time to tackle right now.

A few notes:

  • Internet Explorer has two lines, one for Windows and the other for Macintosh.  I did this because their release schedules often had little or nothing to do with each other.  The other browsers represented typically release cross-platform on or about the same day, and so each got a single line.

  • The temporal resolution is one month.  In other words: no, I didn’t attempt to place the vertical connector bars so they correspond to the specific day of the month a browser was released.  In many cases, I don’t have that information—just the month and year of release.

  • I was interested to discover that the “quietest” years in the timeline were 1999, 2002, and 2004 1999 and 2002.  (My earlier belief that 2004 was quiet was due to my having the wrong year for the release of Netscape 7.2.  Um, whoops.)

  • Because the timeline was created for a session about CSS, the timeline starts in 1996 and doesn’t include pre-CSS browser versions.  I may extend it backward at some point, although that introduces interesting questions like whether or not to include Mosaic, Viola, Cello, and so forth; and whether to extend it all the way back to 1989.

  • Yes, I’m missing browsers such as Konqueror and iCab, not to mention the whole forest of Gecko spin-offs like Camino and Flock.  Again, there’s the question of which browsers to include and which to omit.  This was dictated partly by perceived market share, but mostly by good old-fashioned laziness.

I’ll do my best to address any suggestions for improvement, though this is kind of a side project and so commands a comparatively small share of my attention.  Still, even if it never changes again, I’m happy that it’s finally out into the world.


Winter Drifts

Published 13 years, 4 months past

By current standards, the winter storm we’ve just weathered was pretty severe: two feet of snow blanketed our local environs in the course of 24 hours, give or take.  I put a few pictures up on Flickr, for those who’d like to see some of the aftereffects.  The broad nature of the storm meant that everyone got about the same snowfalls; lake effect seemed to play a minor or nonexistent role.

I’ve heard some people are comparing this storm to the Blizzard of ’77, and a few with a slightly better sense of proportion have recalled the storm that hit the area in November of 1996.  Both strike me as rather specious comparisons.  The ’77 storm was near to epic in scope and intensity, dropping four or five feet and stranding a whole lot of travelers.  My paternal grandparents had dropped by to visit the day before it started and ended up staying several days longer than they’d planned; the snow on our roofed patio was three or four feet deep, and many drifts throughout our area were a dozen feet or more tall.  For 1996, we had four or five days of constantly falling dense, wet snow, and tornadoes and thunderstorms to boot.  This week’s storm mostly dumped the light fluffy snow you can clear away with a broom, assuming it’s not too deep.

The truth is that this week’s storm wouldn’t have been very remarkable twenty years ago.  It might have been one of the heaviest individual falls of a given season, and certainly would have caused some problems, but it wouldn’t have triggered historical comparisons.  I remember days with ambient air temperatures of -20°F (-29°C) and stiff winds, which drove the effective temperature down to -50°F (-45°C) or lower.  I remember snow feet thick on the ground which stayed on for weeks.  I remember tunneling through roadside snowbanks and building elaborate snowforts with the neighbor kids, snowy bus stops, sledding parties and ice skating.

Yeah, yeah, okay: “when I was your age…”.  That’s not actually my point.  What I’m trying to say is that for last couple of decades, we’ve had some very mild winters, and it made us complacent.  I don’t own boots, because it’s literally been years since I needed them.  I had cause to regret that as I cleared snow from our walks in my regular shoes.  Thankfully, we do have access to a snow blower, so I didn’t have to shovel, but that didn’t stop the snow from getting into my shoes.  Oh, that’s a cold feeling.

I stayed far away from any conventional media yesterday, mostly to spare myself the histrionics of local news forecasters and avoid the depressingly repetitive comment, “I guess so much for global warming, haw haw haw!”.  There’s only so much moronity I can stomach in a day.  Instead, we all stayed home (Carolyn’s preschool and Kat’s office both being closed, along with nearly everything else in the city) and played games, read books, and went outside for short periods to make snow angels, get cold-rosy cheeks, and eat a few mittenfuls of snow.  Then we came back in to sip hot drinks in front of the fireplace.

People sometimes ask me why I stay in Cleveland when I could find work no matter where I moved.  In response, I can only point out my window to the drifts of snow sparkling in today’s clear-sky sun and the bare brown trees that will, in a month or two, begin to bud green shoots and tiny flowers; the same trees that will be silhouetted against a lightning-torn sky and will roar as autumn winds rip through their branches and brilliant leaves.

While that is not the only reason I stay, I need no other.


DevEdge Content Returns

Published 14 years, 4 months past

Once was lost, now is found: “Images, Tables, and Mysterious Gaps” has been resurrected from the Great Bit Bucket Beyond and given new life on Mozilla.org.  In fact, it looks like just about all the technical articles written by me and the other members of TEDS are available.  Look through the full list of CSS articles, for example.  You can dig into any number of topic areas from the main page of the Documentation section.  (Scroll down to the “Mozilla Developer Center Contents” headline.)

Some other popular articles from my Netscape days gone by:

So far as I’ve been able to determine, some of the less technical pieces, like the interviews with Doug Bowman and Mike Davidson, are not available.  Not now, anyway.  Perhaps one day that too will change.


Browse the Archive

Earlier Entries

Later Entries