Tags: worldwide

27

sparkline

Friday, March 29th, 2019

CERN Hack days – Chiteri’s Blog

Martin gives a personal history of his time at the two CERN hack projects …and also provides a short history of the universe.

Monday, March 25th, 2019

WWW:BTB — History (Overview)

This history of the World Wide Web from 1996 is interesting for the way it culminates with …Java. At that time, the language seemed like it would become the programmatic lingua franca for the web. Brendan Eich sure upset that apple cart.

Wednesday, March 13th, 2019

What a day that was

I woke up in Geneva. The celebrations to mark the 30th anniversary of the World Wide Web were set to begin early in the morning.

It must be said, March 12th 1989 is kind of an arbitrary date. Maybe the date that the first web page went online should mark the birth of the web (though the exact date might be hard to pin down). Or maybe it should be August 6th, 1991—the date that Tim Berners-Lee announced the web to the world (well, to the alt.hypertext mailing list at least). Or you could argue that it should be April 30th, 1993, the date when the technology of the web was officially put into the public domain.

In the end, March 12, 1989 is as good a date as any to mark the birth of the web. The date that Tim Berners-Lee shared his proposal. That’s when the work began.

Exactly thirty years later, myself, Martin, and Remy are registered and ready to attend the anniversay event in the very same room where the existence of the Higgs boson was announced. There’s coffee, and there are croissants, but despite the presence of Lou Montulli, there are no cookies.

Happy birthday, World Wide Web! Love, One third of the https://worldwideweb.cern.ch team at CERN.

The doors to the auditorium open and we find some seats together. The morning’s celebrations includes great panel discussions, and an interview with Tim Berners-Lee himself. In the middle of it all, they show a short film about our hack week recreating the very first web browser.

It was surreal. There we were, at CERN, in the same room as the people who made the web happen, and everyone’s watching a video of us talking about our fun project. It was very weird and very cool.

Afterwards, there was cake. And a NeXT machine—the same one we had in the room during our hack week. I feel a real attachment to that computer.

A NeXT machine from 1989 running the WorldWideWeb browser and my laptop in 2019 running https://worldwideweb.cern.ch

We chatted with lots of lovely people. I had the great pleasure of meeting Peggie Rimmer. It was her late husband, Mike Sendall, who gave Tim Berners-Lee the time (and budget) to pursue his networked hypertext project. Peggie found Mike’s copy of Tim’s proposal in a cupboard years later. This was the copy that Mike had annotated with his now-famous verdict, “vague but exciting”. Angela has those words tattooed on her arm—Peggie got a kick out of that.

Eventually, Remy and I had to say our goodbyes. We had to get to the airport to catch our flight back to London. Taxi, airport, plane, tube; we arrived at the Science Museum in time for the evening celebrations. We couldn’t have been far behind Tim Berners-Lee. He was making a 30 hour journey from Geneva to London to Lagos. We figured seeing him at two out of those three locations was plenty.

This guy again! I think I’m being followed.

By the end of the day we were knackered but happy. The day wasn’t all sunshine and roses. There was a lot of discussion about the negative sides of the web, and what could be improved. A lot of that was from Sir Tim itself. But mostly it was a time to think about just how transformative the web has been in our lives. And a time to think about the next thirty years …and the web we want.

First Web browser revived during hackathon - YouTube

This is the lovely little film about our WorldWideWeb hack project. It was shown yesterday at CERN during the Web@30 celebrations. That was quite a special moment.

Monday, March 11th, 2019

T minus one

I’m back at CERN.

I’m back at CERN because tomorrow, March 12th, 2019, is exactly thirty years on from when Tim Berners-Lee submitted his original “vague but exciting” Information Management: A Proposal. Tomorrow morning, bright and early, there’s an event at CERN called Web@30.

Thanks to my neglibable contribution to the recreation of the WorldWideWeb browser, I’ve wrangled an invitation to attend. Remy and Martin are here too, and I know that the rest of the team are with us in spirit.

I’m so excited about this! I’m such a nerd for web history, it’s going to be like Christmas for me.

If you’re up early enough, you can watch the event on a livestream. The whole thing will be over by mid-morning. Then, Remy and I will take an afternoon flight back to England …just in time for the evening event at London’s Science Museum.

Thursday, February 28th, 2019

WorldWideWeb coverage

Remy’s keeping a list of hyperlinks to stories covering our recent hack week at CERN.

Friday, February 22nd, 2019

nexus-project / nexus-browser · GitLab

Here’s the source code for the WorldWideWeb project we did at CERN.

Thursday, February 21st, 2019

WWW: Where’s the Writable Web?

Prompted by our time at CERN, Remy ponders why web browsers (quite quickly) diverged from the original vision of being read/write software.

Wednesday, February 20th, 2019

WorldWideWeb, 30 years on – Dan Q

This is a lovely write-up of the WorldWideWeb hack week at CERN:

The Web is a success story in open standards, natural and by-design progressive enhancement, and the future-proof archivability of human-readable code.

Sunday, February 17th, 2019

Timelines of the web

Recreating the original WorldWideWeb browser was an exercise in digital archeology. With a working NeXT machine in the room, Kimberly was able to examine the source code for the first every browser and discover a treasure trove within. Like this gem in HTUtils.h:

#define TCP_PORT 80 /* Allocated to http by Jon Postel/ISI 24-Jan-92 */

Sure enough, by June of 1992 port 80 was documented as being officially assigned to the World Wide Web (Gopher got port 70). Jean-François Groff—who worked on the World Wide Web project with Tim Berners-Lee—told us that this was a moment they were very pleased about. It felt like this project of theirs was going places.

Jean-François also told us that the WorldWideWeb browser/editor was kind of like an advanced prototype. The idea was to get something up and running as quickly as possible. Well, the NeXT operating system had a very robust Text Object, so the path of least resistance for Tim Berners-Lee was to take the existing word-processing software and build a hypertext component on top of it. Likewise, instead of creating a brand new format, he used the existing SGML format and added one new piece: linking with A tags.

So the WorldWideWeb application was kind of like a word processor and document viewer mashed up with hypertext. Ted Nelson complains to this day that the original sin of the web was that it borrowed this page-based metaphor. But Nelson’s Project Xanadu, originally proposed in 1974 wouldn’t become a working reality until 2014—a gap of forty years. Whereas Tim Berners-Lee proposed his system in March 1989 and had working code within a year. There’s something to be said for being pragmatic and working with what you’ve got.

The web was also a mashup of ideas. Hypertext existed long before the web—Ted Nelson coined the term in 1963. There were conferences and academic discussions devoted to hypertext and hypermedia. But almost all the existing hypertext systems—including Tim Berners-Lee’s own ENQUIRE system from the early 80s—were confined to a local machine. Meanwhile networked computers were changing everything. First there was the ARPANET, then the internet. Tim Berners-Lee’s ambitious plan was to mash up hypertext with networks.

Going into our recreation of WorldWideWeb at CERN, I knew I wanted to convey this historical context somehow.

The World Wide Web officially celebrates its 30th birthday in March of this year. It’s kind of an arbitrary date: it’s the anniversary of the publication of Information Management: A Proposal. Perhaps a more accurate date would be the day the first website—and first web server—went online. But still. Let’s roll with this date of March 12, 1989. I thought it would be interesting not only to look at what’s happened between 1989 and 2019, but also to look at what happened between 1959 and 1989.

So now I’ve got two time cones that converge in the middle: 1959 – 1989 and 1989 – 2019. For the first time period, I made categories of influences: formats, hypertext, networks, and computing. For the second time period, I catalogued notable results: browsers, servers, and the evolution of HTML.

I did a little bit of sketching and quickly realised that these converging timelines could be represented somewhat like particle collisions. Once I had that idea in my head, I knew how I would be spending my time during the hack week.

Rather than jumping straight into the collider visualisation, I took some time to make a solid foundation to build on. I wanted to be sure that the timeline itself would be understable even if it were, say, viewed in the first ever web browser.

Progressive enhancement. Marking up (and styling) an interactive timeline that looks good in a modern browser and still works in the first ever web browser.

I marked up each timeline as an ordered list of h-events:

<li class="h-event y1968">
  <a href="https://en.wikipedia.org/wiki/NLS_%28computer_system%29" class="u-url">
    <time class="dt-start" datetime="1968-12-09">1968</time>
    <abbr class="p-name" title="oN-Line System">NLS</abbr>
  </a>
</li>

With the markup in place, I could concentrate on making it look halfway decent. For small screens, the layout is very basic—just a series of lists. When the screen gets wide enough, I lay those lists out horzontally one on top of the other. In this view, you can more easily see when events coincide. For example, ENQUIRE, Usenet, and Smalltalk all happen in 1980. But the real beauty comes when the screen is wide enough to display everthing at once. You can see how an explosion of activity in the early 90s. In 1994 alone, we get the release of Netscape Navigator, the creation of HTTPS, and the launch of Amazon.com.

The whole thing is powered by CSS transforms and positioning. Each year on a timeline has its own class that gets moved to the correct chronological point using calc(). I wanted to use translateX() but I couldn’t get the maths to work for that, so I had use plain ol’ left and right:

.y1968 {
  left: calc((1968 - 1959) * (100%/30) - 5em);
}

For events before 1989, it’s the distance of the event from 1959. For events after 1989, it’s the distance of the event from 2019:

.y2014 {
  right: calc((2019 - 2014) * (100%/30) - 5em);
}

(Each h-event has a width of 5em so that’s where the extra bit at the end comes from.)

I had to do some tweaking for legibility: bunches of events happening around the same time period needed to be separated out so that they didn’t overlap too much.

As a finishing touch, I added a few little transitions when the page loaded so that the timeline fans out from its centre point.

Et voilà!

Progressive enhancement. Marking up (and styling) an interactive timeline that looks good in a modern browser and still works in the first ever web browser.

I fiddled with the content a bit after peppering Robert Cailliau with questions over lunch. And I got some very valuable feedback from Jean-François. Some examples he provided:

1971: Unix man pages, one of the first instances of writing documents with a markup language that is interpreted live by a parser before being presented to the user.

1980: Usenet News, because it was THE everyday discussion medium by the time we created the web technology, and the Web first embraced news as a built-in information resource, then various platforms built on the web rendered it obsolete.

1982: Literary Machines, Ted Nelson’s book which was on our desk at all times

I really, really enjoyed building this “collider” timeline. It was a chance for me to smash together my excitement for web history with my enjoyment of using the raw materials of the web; HTML and CSS in this case.

The timeline pales in comparison to the achievement of the rest of the team in recreating the WorldWideWeb application but I was just glad to be able to contribute a little something to the project.

Hello WorldWideWeb.

Saturday, February 16th, 2019

FOREVERYONE.NET

I linked to this a while back but now this great half hour documentary by Jessica Yu is ready and you can watch the whole thing online: Tim Berners-Lee, the birth of the web, and where the web has gone since.

In the scenes describing the early web, there’s footage of the recreated Line Mode Browser—how cool is that‽

Recreating the First Web Browser at CERN | U.S. Mission to International Organizations in Geneva

The US Mission to the UN in Geneva came by to visit us during our hackweek at CERN.

“Our hope is that over the next few days we are going to recreate the experience of what it would be like using that browser, but doing it in a way that anyone using a modern web browser can experience,” explains team member Jeremy Keith. The aim is to “give people the feeling of what it would have been like, in terms of how it looked, how it felt, the fonts, the rendering, the windows, how you navigated from link to link.”

WorldWideWeb

Nine people came together at CERN for five days and made something amazing. I still can’t quite believe it.

Coming into this, I thought it was hugely ambitious to try to not only recreate the experience of using the first ever web browser (called WorldWideWeb, later Nexus), but to also try to document the historical context of the time. Now that it’s all done, I’m somewhat astounded that we managed to achieve both.

Want to see the final result? Here you go:

worldwideweb.cern.ch

That’s the website we built. The call to action is hard to miss:

Launch WorldWideWeb

Behold! A simulation of using the first ever web browser, recreated inside your web browser.

Now you could try clicking around on the links on the opening doucment—remembering that you need to double-click on links to activate them—but you’ll quickly find that most of them don’t work. They’re long gone. So it’s probably going to be more fun to open a new page to use as your starting point. Here’s how you do that:

  1. Select Document from the menu options on the left.
  2. A new menu will pop open. Select Open from full document reference.
  3. Type a URL, like, say https://adactio.com
  4. Press that lovely chunky Open button.

You are now surfing the web through a decades-old interface. Double click on a link to open it. You’ll notice that it opens in a new window. You’ll also notice that there’s no way of seeing the current URL. Back then, the idea was that you would navigate primarily by clicking on links, creating your own “associative trails”, as first envisioned by Vannevar Bush.

But the WorldWideWeb application wasn’t just a browser. It was a Hypermedia Browser/Editor.

  1. From that Document menu you opened, select New file…
  2. Type the name of your file; something like test.html
  3. Start editing the heading and the text.
  4. In the main WorldWideWeb menu, select Links.
  5. Now focus the window with the document you opened earlier (adactio.com).
  6. With that window’s title bar in focus, choose Mark all from the Links menu.
  7. Go back to your test.html document, and highlight a piece of text.
  8. With that text highlighted, click on Link to marked from the Links menu.

If you want, you can even save the hypertext document you created. Under the Document menu there’s an option to Save a copy offline (this is the one place where the wording of the menu item isn’t exactly what was in the original WorldWideWeb application). Save the file so you can open it up in a text editor and see what the markup would’ve looked it.

I don’t know about you, but I find this utterly immersive and fascinating. Imagine what it must’ve been like to browse, create, and edit like this. Hypertext existed before the web, but it was confined to your local hard drive. Here, for the first time, you could create links across networks!

After five days time-travelling back thirty years, I have a new-found appreciation for what Tim Berners-Lee created. But equally, I’m in awe of what my friends created thirty years later.

Remy did all the JavaScript for the recreated browser …in just five days!

Kimberly was absolutely amazing, diving deep into the original source code of the application on the NeXT machine we borrowed. She uncovered some real gems.

Of course Mark wanted to make sure the font was as accurate as possible. He and Brian went down quite a rabbit hole, and with remote help from David Jonathan Ross, they ended up recreating entire families of fonts.

John exhaustively documented UI patterns that Angela turned into marvelous HTML and CSS.

Through it all, Craig and Martin put together the accomanying website. Personally, I think the website is freaking awesome—it’s packed with fascinating information! Check out the family tree of browsers that Craig made.

What a team!

Friday, February 15th, 2019

Recreating the first web browser at CERN | Flickr

Photos from earlier this week:

In a small room in CERN’s Data Center, an international group of nine developers is taking a plunge back in time to the beginnings of the World Wide Web. Their aim is to enable the whole world to experience what the web looked like viewed within the very first browser developed by Tim Berners-Lee.

Recreating the First Web Browser at CERN

Thursday, February 14th, 2019

Public Affairs Office on Instagram

A little teaser from U.S. MIssion at the U.N. in Geneva:

This year marks the 30th Anniversary of the birth of the #WorldWideWeb. A team of #webdevelopers are working to make it possible for the public to experience the #FirstWebBrowser as it looked on #TimBernersLees’s computer @CERN…

Tuesday, February 12th, 2019

Back at CERN

We got the band back together.

In September of 2013, I had the great pleasure and privilege of going to CERN with a bunch of very smart people. I’m not sure how I managed to slip by. We were there to recreate the experience of using the line-mode browser. As I wrote at the time:

Just to be clear, the line-mode browser wasn’t the world’s first web browser. That honour goes to Tim Berners-Lee’s WorldWideWeb programme. But whereas WorldWideWeb only ran on NeXT machines, the line-mode browser worked cross-platform and was, therefore, instrumental in demonstrating the power of the web as a universally-accessible medium.

In the run-up to the 30th anniversary of the original (vague but exciting) proposal for what would become the World Wide Web, we’ve been invited back to try to recreate the experience of using that first web browser, the one that one ever ran on NeXT machines.

I missed the first day due to travel madness—flying back from Interaction 19 in Seattle during snowmageddon to Heathrow and then to Geneva—but by the time I arrived, my hackmates had already made a great start in identifying the objectives:

  1. Give people an understanding of the user experience of the WorldWideWeb browser.
  2. Demonstrate that a read/write philosophy was there from the beginning.
  3. Give context—what was going on at the time?

That second point is crucial. WorldWideWeb wasn’t just a web browser; it was a browser/editor. That’s by far the biggest change in terms of the original vision of the web and what we ended up getting from Mosaic onwards.

Remy is working hard on the first point. He documented the first day and now on the second day, he’s made enormous progress already.

I’m focusing on point number three. I want to show the historical context for the World Wide Web. Here’s my plan…

Seeing as we’re coming up on the thirtieth anniversary, I thought it would be interesting to take the year of the proposal (1989) and look back in a time cone of thirty years previous to that at the influences on Tim Berners-Lee. I also want to look at what has happened with the web in the thirty years since the proposal. So the date of the proposal will be a centre point, with the timespan of 1959-1989 converging on it from the past, and the timespan of 1989-2019 diverging from it into the future. I hope it could make for a nice visualisation. Maybe I could try to get it look like data from a particle collision.

We’re here till the weekend and everyone else has already made tremendous progress. Kimberly has been hacking the Gibson …well, that’s what it looked like when she was deep in the code of the NeXT machine we’ve borrowed from Musée Bolo (merci beaucoup!).

We took a little time out for a tour of the data centre. Oh, and at lunch time, we sat with Robert Cailliau and grilled him with questions about the birth of the web. Quite a day!

Now it’s time for me to hit the hay and prepare for another day of hacking in this extraordinary place.

Sunday, September 9th, 2018

The Web Is Agreement

This presentation on web standards was delivered at the State Of The Browser conference in London in September 2018.

Web standards don’t exist.

At least, they don’t physically exist. They are intangible.

They’re in good company.

Feelings are intangible, but real. Hope. Despair.

Ideas are intangible: liberty, justice, socialism, capitalism.

The economy. Currency. All intangible. I’m sure we’ve all had those “college thoughts”:

Money isn’t real, man! They’re just bits of metal and pieces of paper ! Wake up, sheeple!

Nations are intangible. Geographically, France is a tangible, physical place. But France, the Republic, is an idea. Geographically, North America is a real, tangible, physical land mass. But ideas like “Canada” and “The United States” only exist in our minds.

Faith—the feeling—is intangible.

God—the idea—is intangible.

Art—the concept—is intangible.

A piece of art is an insantiation of the intangible concept of what art is.

Incidentally, I quite like Brian Eno’s working definition of what art is. Art is anything we don’t have to do. We don’t have to make paintings, or sculptures, or films, or music. We have to clothe ourselves for practical reasons, but we don’t have to make clothes beautiful. We have to prepare food to eat it, but don’t have to make it a joyous event.

By this definition, sports are also art. We don’t have to play football. Sports are also intangible.

A game of football is an instantiation of the intangible idea of what football is.

Football, chess, rugby, quiditch and rollerball are equally (in)tangible. But football, chess and rugby have more consensus.

(Christianity, Islam, Judaism, and The Force are equally intangible, but Christianity, Islam, and Judaism have a bit more consensus than The Force).

HTML is intangible.

Markup.

A web page is an instantiation of the intangible idea of what HTML is.

But we can document our shared consensus.

A rule book for football is like a web standard specification. A documentation of consensus.

By the way, economics, religions, sports and laws are all examples of intangibles that can’t be proven, because they all rely on their own internal logic—there is no outside data that can prove football or Hinduism or capitalism to be “true”. That’s very different to ideas like gravity, evolution, relativity, or germ theory—they are all intangible but provable. They are discovered, rather than created. They are part of objective reality.

Consensus reality is the collection of intangibles that we collectively agree to be true: economy, religion, law, web standards.

We treat consensus reality much the same as we treat objective reality: in our minds, football, capitalism, and Christianity are just as real as buildings, trees, and stars.

Sometimes consensus reality and objective reality get into fights.

Some people have tried to make a consensus reality around the accuracy of astrology or the efficacy of homeopathy, or ideas like the Earth being flat, 9-11 being an inside job, the moon landings being faked, the holocaust never having happened, or vaccines causing autism. These people are unfazed by objective reality, which disproves each one of these ideas.

For a long time, the consensus reality was that the sun revolved around the Earth. Copernicus and Galileo demonstrated that the objective reality was that the Earth (and all the other planets in our solar system) revolve around the sun. After the dust settled on that particular punch-up, we switched up our consensus reality. We changed the story.

Stories.

That’s another way of thinking about consensus reality: our currencies, our religions, our sports and our laws are stories that we collectively choose to believe.

Web standards are a collection of intangibles that we collectively agree to be true. They’re our stories. They’re our collective consensus reality. They are what web browsers agree to implement, and what we agree to use.

The web is agreement.

The Web Is Agreement by Paul Downey.

For human beings to collaborate together, they need a shared purpose. They must have a shared consensus reality—a shared story.

Once a group of people share a purpose, they can work together to establish principles.

Design principles are points of agreement. There are design principles underlying every human endeavour. Sometimes they are tacit. Sometimes they are written down.

Patterns emerge from principles.

Patterns upon Principles upon Purpose.

Here’s an example of a human endeavour: the creation of a nation state, like the United States of America.

  1. The purpose is agreed in the declaration of independence.
  2. The principles are documented in the constitution.
  3. The patterns emerge in the form of laws.

HTML elements, CSS features, and JavaScript APIs are all patterns (that we agree upon). Those patterns are informed by design principles.

HTML, CSS, and JavaScript.

I’ve been collecting design principles of varying quality at principles.adactio.com.

Here’s one of the design principles behind HTML5. It’s my personal favourite—the priority of constituencies:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

“In case of conflict”—that’s exactly what a good design principle does! It establishes the boundaries of agreement. If you disagree with the design principles of a project, there probably isn’t much point contributing to that project.

Also, it’s reversible. You could imagine a different project that favoured theoretical purity above all else. In fact, that’s pretty much what XHTML 2 was all about.

XHTML 1 was simply HTML reformulated with the syntax of XML: lowercase tags, lowercase attributes, always quoting attribute values.

Remember HTML doesn’t care whether tags and attributes are uppercase or lowercase, or whether you put quotes around your attribute values. You can even leave out some closing tags.

So XHTML 1 was actually kind of a nice bit of agreement: professional web developers agreed on using lowercase tags and attributes, and we agreed to quote our attributes. Browsers didn’t care one way or the other.

But XHTML 2 was going to take the error-handling model of XML and apply it to HTML. This is the error handling model of XML: if the parser encounters a single error, don’t render the document.

Of course nobody agreed to this. Browsers didn’t agree to implement XHTML 2. Developers didn’t agree to use it. It ceased to exist.

It turns out that creating a format is relatively straightforward. But how do you turn something into a standard? The really hard part is getting agreement.

Sturgeon’s Law states:

90% of everything is crap.

Coincidentally, 90% is also the percentage of the world’s crap that gets transported by ocean. Your clothes, your food, your furniture, your electronics …chances are that at some point they were transported within an intermodal container.

These shipping containers are probably the most visible—and certainly one of the most important—standards in the physical world. Before the use of intermodal containers, loading and unloading cargo from ships was a long, laborious, and dangerous task.

Along came Malcom McLean who realised that the whole process could be made an order of magnitude more efficient if the cargo were stored in containers that could be moved from ship to truck to train.

But he wasn’t the only one. The movement towards containerisation was already happening independently around the world. But everyone was using different sized containers with different kinds of fittings. If this continued, the result would be a tower of Babel instead of smoothly running global logistics.

Malcolm McLean and his engineer Keith Tantlinger designed two crate sizes—20ft and 40ft—that would work for ships, trucks, and trains. Their design also incorporated an ingenious twistlock mechanism to secure containers together. But the extra step that would ensure that their design would win out was this: Tantlinger convinced McLean to give up the patent rights.

This wasn’t done out of any hippy-dippy ideology. These were hard-nosed businessmen. But they understood that a rising tide raises all boats, and they wanted all boats to be carrying the same kind of containers.

Without the threat of a patent lurking beneath the surface, ready to torpedo the potential benefits, the intermodal container went on to change the world economy. (The world economy is very large and intangible.)

The World Wide Web also ended up changing the world economy, and much more besides. And like the intermodal container, the World Wide Web is patent-free.

The first ever web server—Tim Berners-Lee’s NeXT machine.

Again, this was a pragmatic choice to help foster adoption. When Tim Berners-Lee and his colleague Robert Cailleau were trying to get people to use their World Wide Web project they faced some stiff competition. Lots of people were already using Gopher. Anyone remember Gopher?

The seemingly unstoppable growth of the Gopher protocol was somewhat hobbled in the early ’90s when the University of Minnesota announced that it was going to start charging fees for using it. This was a cautionary lesson for Berners-Lee and Cailleau. They wanted to make sure that CERN didn’t make the same mistake.

On April 30th, 1993, the code for the World Wide Project was made freely available.

This is for everyone.

Robert Cailleau’s copy of the document that put the World Wide Web into the public domain.

If you’re trying to get people to adopt a standard or use a new hypertext system, the biggest obstacle you’re going to face is inertia. As the brilliant computer scientist Grace Hopper used to say:

The most dangerous phrase in the English language is “We’ve always done it this way.”

Grace Hopper.

Rear Admiral Grace Hopper waged war on business as usual. She was well aware how abritrary business as usual is. Business as usual is simply the current state of our consensus reality. She said:

Humans are allergic to change.

I try to fight that.

That’s why I have a clock on my wall that runs counter‐clockwise.

Our clocks are a perfect example of a ubiquitous but arbitrary convention. Why should clocks run clockwise rather than counter-clockwise?

One neat explanation is that clocks are mimicing the movement of a shadow across the face of a sundial …in the Northern hemisphere. Had clocks been invented in the Southern hemisphere, they would indeed run counter-clockwise.

A sundial in the Southern hemisphere.

But on the clock face itself, why do we carve up time into 24 hours? Why are there 60 minutes in an hour? Why are there are 60 seconds in a minute?

24 by 60 by 60.

It probably all goes back to Babylonian accountants. Early cuneiform tablets show that they used a sexagecimal system for counting—that’s because 60 is the lowest number that can be divided evenly by 6, 5, 4, 3, 2, and 1.

But we don’t count in base 60; we count in base 10. That in itself is arbitrary—we just happen to have a total of ten digits on our hands.

So if the sexagesimal system of telling time is an accident of accounting, and base ten is more widespread, why don’t we switch to a decimal timekeeping system?

It has been tried. The French revolution introduced not just a new decimal calendar—much neater than our base 12 calendar—but also decimal time. Each day had ten hours. Each hour had 100 minutes. Each minute had 100 seconds. So much better!

10 by 100 by 100.

It didn’t take. Humans are allergic to change. Sexagesimal time may be arbitrary and messy but …we’ve always done it this way.

Incidentally, this is also why I’m not holding my breath in anticipation of the USA ever switching to the metric system.

Instead of trying to completely change people’s behaviour, you’re likely to have more success by incrementally and subtly altering what people are used to.

That was certainly the case with the World Wide Web.

The Hypertext Transfer Protocol sits on top of the existing TCP/IP stack.

The key building block of the web is the URL. But instead of creating an entirely new addressing scheme, the web uses the existing Domain Name System.

HTTP upon TCP/IP; URLs upon DNS.

Then there’s the lingua franca of the World Wide Web. These elements probably look familiar to you:

<body> <title> <p> <h1> <h2> <h3> <ol> <ul> <li> <dl> <dt> <dd>

You recognise this language, right? That’s right—it’s SGML. Standard Generalised Markup Language.

Specifically, it’s CERN SGML—a flavour of SGML that was already popular at CERN when Tim Berners-Lee was working on the World Wide Project. He used this vocabulary as the basis for the HyperText Markup Language.

Because this vocabulary was already familiar to people at CERN, convincing them to use HTML wasn’t too much of a hard sell. They could take an existing SGML document, change the file extension to .htm and it would work in one of those new fangled web browsers.

HTML upon SGML.

In fact, HTML worked better than expected. The initial idea was that HTML pages would be little more than indices that pointed to other files containing the real meat and potatoes of content—spreadsheets, word processing documents, whatever. But to everyone’s surprise, people started writing and publishing content in HTML.

Was HTML the best format? Far from it. But it was just good enough and easy enough to get the job done.

It has since changed, but that change has happened according to another design principle:

Evolution, not revolution

From its humble beginnings with the handful of elements borrowed from CERN SGML, HTML has grown to encompass an additional 100 elements over its lifespan. And yet, it’s still technically the same format!

This is a classic example of the paradox called the Ship Of Theseus, also known as Trigger’s Broom.

You can take an HTML document written over two decades ago, and open it in a browser today.

Even more astonishing, you can take an HTML document written today and open it in a browser from two decades ago. That’s because the error-handling model of HTML has always been to simply ignore any tags it doesn’t recognise and render the content inside them.

That pattern of behaviour is a direct result of the design principle:

Degrade Gracefully

…document conformance requirements should be designed so that Web content can degrade gracefully in older or less capable user agents, even when making use of new elements, attributes, APIs and content models.

Here’s a picture from 2006.

Tantek Çelik, Brian Suda, Ryan King, Chris Messina, Mark Norman Francis, and Jeremy Keith.

That’s me in the cowboy hat—the picture was taken in Austin, Texas. This is an impromptu gathering of people involved in the microformats community.

Microformats, like any other standards, are sets of agreements. In this case, they’re agreements on which class values to use to mark up some of the missing elements from HTML—people, places, and events. That’s pretty much it.

And yes, they do have design principles—some very good ones—but that’s not why I’m showing this picture.

Some of the people in this picture—Tantek Çelik, Ryan King, and Chris Messina—were involved in the creation of BarCamp, a series of grassroots geek gatherings.

BarCamps sound like they shouldn’t work, but they do. The schedule for the event is arrived at collectively at the beginning of the gathering. It’s kind of amazing how the agreement emerges—rough consensus and running events.

In the run-up to a BarCamp in 2007, Chris Messina posted this message to the fledgeling social networking site, twitter.com:

how do you feel about using # (pound) for groups. As in #barcamp [msg]?

This was when tagging was all the rage. We were all about folksonomies back then. Chris proposed that we would call this a “hashtag”.

I wasn’t a fan:

Thinking that hashtags disrupt the reading flow of natural language. Sorry @factoryjoe

But it didn’t matter what I thought. People agreed to this convention, and after a while Twitter began turning the hashtagged words into links.

In doing so, they were following another HTML design principle:

Pave the cowpaths

It sounds like advice for agrarian architects, but its meaning is clarified:

When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new.

Twitter had previously paved a cowpath when people started prefacing usernames with the @ symbol. That convention didn’t come from Twitter, but they didn’t try to stop it. They rolled with it, and turned any username prefaced with an @ symbol into a link.

The aperand symbol.

The @ symbol made sense because people were used to using it from email. The choice to use that symbol in email addresses was made by Ray Tomlinson. He needed a symbol to separate the person and the domain, looked down at his keyboard, saw the @ symbol, and thought “that’ll do.”

Perhaps Chris followed a similar process when he proposed the symbol for the hashtag.

The octothorpe symbol.

It could have just as easily been called a “number tag” or “octothorpe tag” or “pound tag”.

This symbol started life as a shortcut for “pound”, or more specifically “libra pondo”, meaning a pound in weight. Libra pondo was abbreviated to lb when written. That got turned into a ligature ℔ when written hastily. That shape was the common ancestor of two symbols we use today: £ and #.

The eight-pointed symbol was (perhaps jokingly) renamed the octothorpe in the 1960s when it was added to telephone keypads. It’s still there on the digital keypad of your mobile phone. If you were to ask someone born in this millenium what that key is called, they would probably tell you it’s the hashtag key. And if they’re learning to read sheet music, I’ve heard tell that they refer to the sharp notes as hashtag notes.

If this upsets you, you might be the kind of person who rages at the word “literally” being used to mean “figuratively” or supermarkets with aisles for “10 items or less” instead of “10 items or fewer”.

Tough luck. The English language is agreement. That’s why English dictionaries exist not to dictate usage of the language, but to document usage.

It’s much the same with web standards bodies. They don’t carve the standards into tablets of stone and then come down the mountain to distribute them amongst the browsers. No, it’s what the browsers implement that gets carved in stone. That’s why it’s so important that browsers are in agreement. In the bad old days of the browser wars of the late 90s, we saw what happened when browsers implemented their own proprietary features.

Standards require interoperability.

Interoperability requires agreement.

Standards atop Interoperability atop Agreement.

So what we can learn from the history of standardisation?

Well, there are some direct lessons from the HTML design principles.

The priority of constituencies

Consider users over authors…

Listen, I want developer convenience as much as the next developer. But never at the expense of user needs.

I’ve often said that if I have the choice between making something my problem, and making it the user’s problem, I’ll make it my problem every time. That’s the job.

I worry that these days developer convenience is sometimes prized more highly than user needs. I think we could all use a priority of constituencies on every project we work on, and I would hope that we would prioritise users over authors.

Degrade gracefully

Web content can degrade gracefully in older or less capable user agents…

I know that I go on about progressive enhancement a lot. Sometimes I make it sound like a silver bullet. Well, it kinda is.

I mean, you can’t just buy a bullet made of silver—you have to make it yourself. If you’re not used to crafting bullets from silver, it will take some getting used to.

Again, if developer convenience is your priority, silver bullets are hard to justify. But if you’re prioritising users over authors, progressive enhancement is the logical methodology to use.

Evolution, not revolution

It’s a testament to the power and flexibility of the web that we don’t have to build with progressive enhancement. We don’t have to build with a separation of concerns like structure, presentation, and behaviour.

We don’t have to use what the browser gives us: buttons, dropdowns, hyperlinks. If we want to, we can make these things from scratch using JavaScript, divs and ARIA attributes.

But why do that? Is it because those native buttons and dropdowns might be inconsistent from browser to browser.

Consistency is not the purpose of the world wide web.

Universality is the key principle underlying the web.

Our patterns should reflect the intent of the medium.

Use what the browser gives you—build on top of those agreements. Because that’s the bigger lesson to be learned from the history of web standards, clocks, containers, and hashtags.

Future atop Present atop Past.

Our world is made up of incremental improvements to what has come before. And that’s how we will push forward to a better tomorrow: By building on top of what we already have instead of trying to create something entirely from scratch. And by working together to get agreement instead of going it alone.

The future can be a frightening prospect, and I often get people asking me for advice on how they should prepare for the web’s future. Usually they’re thinking about which programming language or framework or library they should be investing their time in. But these specific patterns matter much less than the broader principles of working together, collaborating and coming to agreement. It’s kind of insulting that we refer to these as “soft skills”—they couldn’t be more important.

Working on the web, it’s easy to get downhearted by the seemingly ephemeral nature of what we build. None of it is “real”; none of it is tangible. And yet, looking at the history of civilisation, it’s the intangibles that survive: ideas, philosophies, culture and concepts.

The future can be frightening because it is intangible and unknown. But like all the intangible pieces of our consensus reality, the future is something we construct …through agreement.

Now let’s agree to go forward together to build the future web!

Friday, June 1st, 2018

Document

A little while back, I showed Paul what I was working on with The Gęsiówka Story. I value his opinion and I really like the Bradshaw’s Guide project that he’s been working on. We’re both in complete agreement with Russell Davies’ call for an internet of unmonetisable enthusiasms. Call them side projects if you like, but for me, these are the things that the World Wide Web excels at.

These unomentisable enthusiasms/side projects are what got me hooked on the web in the first place. Fray.com—back when it was a website for personal stories—was what really made the web click for me. I had seen brochure sites, I had seen e-commerce sites, but it was seeing something built purely for the love of it that caused that lightbulb moment for me.

I told Paul about another site I remembered from that time (we’re talking about the mid-to-late nineties here). It was called Private Art. It was the work of one family, the children of Private Art Pranger who served in World War Two and wrote letters from the front. Without any expectations, I did a quick search, and amazingly, the site is still up!

Yes, it’s got tiled background images, and the framesetted content is in a pop-up window, but it works. The site hasn’t been updated for fifteen years but it works perfectly in a web browser today. That’s kind of amazing. We really shouldn’t take the longevity of our materials for granted. Could you imagine trying to open a word processing document from the late nineties on your computer today? You’d have a bad time.

Working on The Gęsiówka Story helped to remind me of some of the things that made me fall in love with the web in the first place. What I wrote about it is equally true of Private Art:

When we talk about documents on the web, we usually use the word “document” as a noun. But working on The Gęsiówka Story, I came to think of the word “document” as a verb.

The World Wide Web is a medium that’s works for quick, short-term lightweight bits of fun and also for long-term, deeper, slower, thoughtful archives of our collective culture.

The web is a many-splendoured thing.

Friday, December 22nd, 2017

The web we may have lost | Christian Heilmann

The world-wide-web always scared the hell out of those who want to control what people consume and what their career is. The web was the equaliser.

A heartfelt missive by Christian on the eve of the US potentially losing net neutrality. I agree with every single word he’s written.

I hope that people still care that the web flows, no matter for whom or what the stream carries. The web did me a lot of good, and it can do so for many others. But it can’t do that if it turns into Cable TV. I’ve always seen the web as my media to control. To pick what I want to consume and question it by comparing it. A channel for me to publish and be scrutinised by others. A read-write medium. The only one we have. Let’s do more of the write part.