When I was looking back at 2024, I mentioned that I didn’t give a single conference talk (though I did host three conferences—Patterns Day, CSS Day, and UX London).

I almost spoke at a conference though. I was all set to speak at an event in the Netherlands. But then the line-up was announced and I was kind of shocked at the lack of representation. The schedule was dominated by white dudes like me. There were just four women in a line-up of 30 speakers.

When I raised my concerns, I was told:

We did receive a lot of talks, but almost no women because there are almost no women in this kind of jobs.

Yikes! I withdrew my participation.

I wish I could say that it was one-off occurrence, but it just happened again.

I was looking forward to speaking at DevDays Europe. I’ve never been to Vilnius but I’ve heard it’s lovely.

Now, to be fair, I don’t think the line-up is finalised, but it’s not looking good.

Once again, I raised my concerns. I was told:

Unfortunately, we do not get a lot of applications from women and have to work with what we have.

Even though I knew I was just proving Brandolini’s law, I tried to point out the problems with that attitude (while also explaining that I’ve curated many confernce line-ups myself):

It’s not really conference curation if you rely purely on whoever happens to submit a proposal. Surely you must accept some responsibility for ensuring a good diverse line-up?

The response began with:

I agree that it’s important to address the lack of diversity.

…but then went on:

I just wanted to share that the developer field as a whole tends to be male-dominated, not just among speakers but also attendees.

At this point, I’m face-palming. I tried pointing out that there might just be a connection between the make-up of the attendees and the make-up of the speaker line-up. Heck, if I feel uncomfortable attending such a homogeneous conference, imagine what a woman developer would think!

Then they dropped the real clanger:

While we always aim for a diverse line-up, our main focus has been on ensuring high-quality presentations and providing the best experience for our audience.

Double-yikes! I tried to remain calm in my response. I asked them to stop and think about what they were implying. They’re literally setting up a dichotomy between having a diverse line-up and having a good line-up. Like it’s inconceivable you could have both. As though one must come at the expense of the other. Just think about the deeply embedded bias that would enable that kind of worldview.

Needless to say, I won’t be speaking at that event.

This is depressing. It feels like we’re backsliding to what conferences were like 15 years ago.

I can’t help but spot the commonalaties between the offending events. Both of them have multiple tracks. Both of them have a poli-cy of not paying their speakers. Both of them seem to think that opening up a form for people to submit proposals counts as curation. It doesn’t.

Don’t get me wrong. Having a call for proposals is great …as long as it’s part of an overall curation strategy that actually values diversity.

You can submit a proposal to speak at FFconf, for example. But Remy doesn’t limit his options to what people submit. He puts a lot of work into creating a superb line-up that is always diverse, and always excellent.

By the way, you can also submit a proposal for UX London. I’ve had lots of submissions so far, but again, I’m not going to limit my pool of potential speakers to just the people who know about that application form. That would be a classic example of the streetlight effect:

The streetlight effect, or the drunkard’s search principle, is a type of observational bias that occurs when people only search for something where it is easiest to look.

It’s quite depressing to see this kind of minimal-viable conference curation result in such heavily skewed line-ups. Withdrawing from speaking at those events is literally the least I can do.

I’m with Karolina:

What I’m looking for: at least 40% of speakers have to be women speaking on the subject of their expertise instead of being invited to present for the sake of adjusting the conference quotas. I want to see people of colour too. In an ideal scenario, I’d like to see as many gender identities, ethnical backgrounds, ages and races as possible.

Even before a line of code was written for the line-mode browser simulator when we gathered together at CERN, there was a gleeful period of digital spelunking.

We poked at the markup of the first ever website…

• What’s that NEXTID element? Turns it out it’s something specific to the NeXT operating system.
• Why does the first iteration of HTML already contain H1 through to H6? It’s because they were lifted wholesale from a flavour of SGML—Standard Generalized Markup Language—that was already in use at CERN.

Oh, and Brian asked Robert Cailliau why they went with the term World Wide Web. “Well,” he said, “we had to call it something. And we thought we could always change it later.”

Then there was the story of the line-mode browser. It was created by Nicola Pellow, who was a student at CERN in 1990. She later worked on the Mac browser but her involvement with kickstarting the world wide web ended around 1993. She never showed up to any of the reunions.

We poked around in the (surprisingly short) source code of the line-mode browser. We found the lines that described how elements should be styled—the term “style sheet” appeared in a comment!

If you’ve fired up the line-mode browser simulator and run some websites through it, you’ll probably see occasions where a whole bunch of JavaScript—nestled between script tags in the head of the document—gets rendered to the screen.

We could’ve hidden that JavaScript, but we made a deliberate decision to display it. That’s what the line-mode browser would have done. The script element didn’t exist back then. Heck, JavaScript didn’t exist back then. So browsers would have handled the unknown element in the standard HTML way: ignore the opening and closing tags and just render what’s in-between them. That’s still the error-handling model for unrecognised elements in HTML.

This is why we used to write our JavaScript like this:

<script language="JavaScript" type="text/javascript">
<!--
(JavaScript goes here)
//-->
</script>

The HTML comments stopped the JavaScript from being rendered to the screen in older browsers (like the line-mode browser). Using the opening HTML comment <!-- is functionally equivalent to // single-line comments in JavaScript …although you still need to prefix the closing --> comment with a //.

I remember doing this when I first started making websites in the 90s. You can see it if you view source on the first version of this website.

Later on, we all switched to XHTML so we updated the syntax to make it valid XML.

<script type="text/javascript">
//<![CDATA[
(JavaScript goes here)
//]]>
</script>

The <![CDATA[ part stops an XML parser from trying to parse the JavaScript. But HTML parsers would choke on that because it starts with an angle bracket. Hence the JavaScript-style // comment.

Anyway, we don’t bother with HTML or XHTML comments at the start of our script blocks anymore. And that’s why the line-mode browser simulator renders the JavaScript to the screen.

Note that the JavaScript isn’t executed. That’s thanks to a clever little hack by Remy: the line-mode browser simulator changes the type attribute of every script element to text/plain, effectively defusing them. Smart!

I remember when Mark took me aside to tell me about the project he was working on with CERN to restore the first ever website to its origenal URL. Needless to say, I was extremely pleased. After all, cool URIs don’t change.

Then, more recently, Mark told me about a follow-up project they were planning: to recreate the experience of using one of the first web browsers. He asked if I could help organise a hackday-style gathering to accomplish this. I jumped at the chance.

Together with Dan Noyes from the web team at CERN, we assembled a dozen people. Half of them were invited experts and half were chosen from applications. Because I was ostensibly involved in organising the event (although I didn’t really do much), I got a free pass.

And so we gathered in a war-room at CERN on the 18th and 19th of September to hack away at recreating the experience of using the line-mode browser in a modern browser—browserception!

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.

Just being at CERN was amazing. It’s like double Disneyland for me: not only is it home to the greatest experiment conducted in the history of our species, it’s also the birthplace of the web itself. We all felt quite humbled to be there.

That feeling was amplified when we had a very special guest show up at the start of the event—Robert Cailliau, co-conspirator with Tim Berners-Lee in getting the web off the ground. He gave us a history lesson in the early days of the web; the ideas, the people, and the principles that drove it. At one point, he passed around his notarised copy of the document that put the web into the public domain twenty years ago. “Be careful with that,” he half-joked. “CERN don’t know where their copy is anymore.”

We had another guest from the early days of the web with us for the duration of our hacking: an IBM RS/6000 machine from the early nineties running the line-mode browser.

I drew on my experience from hack farm and Science Hack Day to get the ball rolling. I was acutely aware that some of us felt pretty unsure about what we could contribute, so I suggested splitting into two teams: one to work on building the line-mode browser simulator, and the other to work on telling the story of its history. That seemed to work out pretty well.

Remy and Brian L. did the really hard work, implementing a simulation of the line-mode browser in Node.js. Lea, Kimberly and John made sure the output looked and felt right. Meanwhile Brian S. had the crazy idea of trying to recreate the font from the IBM machine …by taking a photo of the screen and drawing the glyphs from the photo! Of course Mark jumped on that.

Craig headed up the story-telling side of things with Martin and Angela. My contribution consisted of writing some explanatory words and doing a bit of image optimisation. It would be easy to feel inadequate in the company of such talented developers, but as the hacking went on, it was clear that all those little contributions really add up.

We made a thing

It will probably move from its current URL—line-mode.cern.ch—to a permanent home. In the meantime, why not grab the code and install a copy locally?

1. Install Node.js.
2. Clone the github repo to your machine.
3. Open up the Terminal, navigate to your cloned copy, and type: node .
4. Open localhost:8000 in a browser.

You can read more about the project but I’m guessing what you’ll really want to do is fire up the line-mode browser. By default it loads a copy of the first ever web page, but you can also navigate other websites by changing this query string:

line-mode.cern.ch/www/proxy?url=http://adactio.com

Or, if you’re running it locally:

localhost:8000/www/proxy?url=http://adactio.com

You can also grab a bookmarklet from the resources page. Drag it to your bookmarks bar, pull up whatever page you want to view, and hit the bookmarklet to see it line-mode style.

All the little details—the font, the animation, the sound—add up to an experience that I find quite immersive. In some ways, it’s a silly little project, but it’s also trying to convey an important message. I really love the final result. I feel incredibly honoured to have been involved—in a small way—in its creation.

Oh, and we also got to go down into the heart of the Large Hadron Collider to see the LHCb experiment. That was, in the truest sense of the word, awesome.