Jeremy Keith: Hello every­one. Thank you for still being here. We’re on the final stretch now. I am here today to talk to you about the Web, and more specif­i­cal­ly about web stan­dards. [Audience mem­ber: Yay!” Some gen­er­al cheer­ing.]

Ehh, here’s the thing. Here’s the thing about web stan­dards. Web stan­dards don’t exist. At least they don’t phys­i­cal­ly exist. They’re…intangible. But they’re in good com­pa­ny. Feelings are intan­gi­ble but real. Hope. Despair. Ideas are intan­gi­ble. Liberty. Justice. Socialism. Capitalism. The econ­o­my. Currency—all intan­gi­ble. I’m sure we’ve all had those col­lege thoughts, right. Money isn’t real, man, it’s just bits of met­al and paper; wake up, sheeple.”

Nations are intan­gi­ble. Geographically, France is a tan­gi­ble, phys­i­cal place. But France the repub­lic is an idea. And geo­graph­i­cal­ly North America’s a real, tan­gi­ble phys­i­cal land­mass but ideas like Canada” and the United States” only exist in our minds. Faith the feel­ing is intan­gi­ble. God the idea is intan­gi­ble. Art the con­cept is intan­gi­ble. A piece of art is instan­ti­a­tion of the intan­gi­ble con­cept of what art is.

Incidentally I real­ly like Brian Eno’s def­i­n­i­tion of what art is. He says art is any­thing we don’t have to do. We don’t have to make paint­ings, or sculp­tures, or films, or music. We have to clothe our­selves for prac­ti­cal rea­sons but we don’t have to make clothes beau­ti­ful. We have to pre­pare food to eat it, but we don’t have to make it a joy­ous event.

Also, by this def­i­n­i­tion, sports are also art. We don’t have to play foot­ball. Sports are also intan­gi­ble. A game of foot­ball is an instan­ti­a­tion of the intan­gi­ble idea of what foot­ball is. Football, chess, rug­by, quid­ditch, and roller­ball are all equal­ly intan­gi­ble. But foot­ball chess and rug­by have a bit more con­sen­sus. Just like Christianity, Islam, Judaism, and the Force are equal­ly intan­gi­ble, but Christianity, Islam, and Judaism have a bit more con­sen­sus than the Force.

HTML is intan­gi­ble. A web page is an instan­ti­a­tion of the intan­gi­ble idea of what HTML is. But, we can doc­u­ment our shared con­sen­sus. A rule book for foot­ball is like a web stan­dard spec­i­fi­ca­tion; a doc­u­men­ta­tion of con­sen­sus.

And by the way, eco­nom­ics, and reli­gions, and sports, and laws…they’re all exam­ples of intan­gi­bles that can’t be proven. Because they all rely on their own inter­nal log­ic. There’s no out­side data that can prove foot­ball, or Hinduism, or cap­i­tal­ism to be true. That’s very dif­fer­ent to ideas like grav­i­ty, evo­lu­tion, rel­a­tiv­i­ty, or germ the­o­ry. They’re all intan­gi­ble, but prov­able. They’re dis­cov­ered rather than cre­ate. They’re part of objec­tive real­i­ty. Consensus real­i­ty is the col­lec­tion of intan­gi­bles that we col­lec­tive­ly agree to be true. Economy, reli­gion, law, web stan­dards.

Now we treat con­sen­sus real­i­ty much the same as we treat objec­tive real­i­ty. In our minds, foot­ball, cap­i­tal­ism, and Christianity are just as real as build­ings, trees, and stars. And some­times con­sen­sus real­i­ty and objec­tive real­i­ty get into fights. Some peo­ple have tried to make a con­sen­sus real­i­ty around the accu­ra­cy of astrol­o­gy, or the effi­ca­cy of home­opa­thy, or ideas like the Earth being flat, 9‍/‍11 being an inside job, the moon land­ings nev­er hav­ing hap­pened. The Holocaust nev­er hav­ing hap­pened. Or vac­cines caus­ing autism. And these peo­ple are unfazed by objec­tive real­i­ty, which dis­proves each one of these ideas.

It used to be that for a long time the con­sen­sus real­i­ty was that the sun revolved around the Earth. And Copernicus and Galileo demon­strat­ed that the objec­tive real­i­ty was that the Earth and all the oth­er plan­ets in our solar sys­tem revolve around the sun. Now after the dust set­tled on that par­tic­u­lar punch-up, we switched up our con­sen­sus real­i­ty. We change the sto­ry. Because that’s anoth­er way of think­ing about con­sen­sus real­i­ty. Our cur­ren­cies, our reli­gions, our sports, and our laws are sto­ries that we col­lec­tive­ly choose to believe.

And web stan­dards are a col­lec­tion of intan­gi­bles that we col­lec­tive­ly agree to be true. They’re our sto­ries. They’re our col­lec­tive, con­sen­sus real­i­ty. They’re what web browsers agree to imple­ment and what we agreed to use. The Web is agree­ment.

Now for human beings to col­lab­o­rate togeth­er, they need a shared pur­pose. They must have a shared con­sen­sus real­i­ty, a shared sto­ry. And once a group of peo­ple share a pur­pose, they can work togeth­er to estab­lish prin­ci­ples. Design prin­ci­ples are points of agree­ment. There are design prin­ci­ples under­ly­ing every human endeav­or. And some­times they’re tac­it and some­times they’re writ­ten down. And pat­terns emerge from the prin­ci­ples.

Here’s an exam­ple of a human endeav­or, the cre­ation of a nation-state like the United States of America. The pur­pose is agreed in the Declaration of Independence. The prin­ci­ples are doc­u­ment­ed in the Constitution. And the pat­terns emerge in the form of laws. HTML ele­ments, CSS fea­tures, Javascript APIs are all pat­terns that we agree upon. And those pat­terns are informed by design prin­ci­ples.

I’ve been col­lect­ing design prin­ci­ples of vary­ing qual­i­ty at prin​ci​ples​.adac​tio​.com. And here’s one of the design prin­ci­ples behind HTML 5. It’s my per­son­al favorite. It’s the pri­or­i­ty of con­stituen­cies. In case of con­flict, con­sid­er users over authors over imple­men­tors over spec­i­fiers over the­o­ret­i­cal puri­ty.”

In case of con­flict. That’s exact­ly what a good design prin­ci­ple does. It estab­lish­es the bound­aries of agree­ment. If you dis­agree with the design prin­ci­ples of a project, there prob­a­bly isn’t much point con­tribut­ing to that project. Also, it’s reversible. You could imag­ine a dif­fer­ent project that favored the­o­ret­i­cal puri­ty above all else. In fact, that’s pret­ty much what XHTML 2 was all about. XHTML 1 was sim­ply HTML refor­mu­lat­ed with the syn­tax of of XML. Lower case tags, low­er case attrib­ut­es, always quot­ing attribute val­ues.

Remember, HTML does­n’t care whether tags are upper case and low­er case or whether you put quotes around your attribute values—you can even leave out some clos­ing tags. So, XHTML 1 was kind of a nice bit of agree­ment. Professional web devel­op­ers agreed on using low­er case tags and attrib­ut­es, and we agreed to always quote our attrib­ut­es. Browsers don’t care one way or the oth­er.

But, XHTML 2 was going to take the error-handling mod­el of XML and apply it to HTML. And this is the error-handling mod­el of XML:

An empty yellow screen.

If the pars­er encoun­ters a sin­gle error, don’t ren­der the doc­u­ment. Of course nobody agreed to this. Browsers did­n’t agree to imple­ment XHTML 2. Developers did­n’t agree to use it. It ceased to exist. Because it turns out that cre­at­ing a for­mat is rel­a­tive­ly straight­for­ward. But how do you turn some­thing into a stan­dard? The real­ly hard part is get­ting agree­ment.

Sturgeon’s Law states that 90% of every­thing is crap. Coincidentally, 90 is also the per­cent­age of the world’s crap that gets trans­port­ed by ocean. Your clothes, your food, your fur­ni­ture, your elec­tron­ics. Chances are that at some point they were trans­port­ed with­in an inter­modal con­tain­er. These ship­ping con­tain­ers are prob­a­bly the most vis­i­ble, and cer­tain­ly of the most impor­tant, stan­dards in the phys­i­cal world. Before the use of inter­modal con­tain­ers, load­ing and unload­ing car­go ships was a long, labo­ri­ous, and dan­ger­ous task.

Along came Malcolm McLean, who real­ized that the whole process could be made an order of mag­ni­tude more effi­cient if the car­go were stored in con­tain­ers that could be moved from ship, to truck, to train. But he was­n’t the only one. The move­ment towards con­tainer­iza­tion was already hap­pen­ing inde­pen­dent­ly around the world. But every­one was using different-sized con­tain­ers, with dif­fer­ent kinds of fit­tings. And if this con­tin­ued, the result would be a Tower of Babel instead of a smoothly-running glob­al logis­tics chain.

Malcolm McLean and his engi­neer Keith Tantlinger designed two crate sizes, twenty-foot and forty-foot, that would work for ships and trucks and trains. Their design also incor­po­rat­ed an inge­nious twist lock mech­a­nism to secure con­tain­ers togeth­er. But the extra step that would ensure that their design would win out was this: Tantlinger con­vinced McLean to give up the patent rights.

Now this was­n’t done out of hippy-dippy ide­ol­o­gy. These were hard-nosed busi­ness­men. But they under­stood that a ris­ing tide rais­es all boats, and they want­ed all boats to be car­ry­ing the same kind of con­tain­ers. And with­out the threat of a patent lurk­ing beneath the sur­face ready to tor­pe­do the poten­tial ben­e­fits, the inter­modal con­tain­er went on to change the world econ­o­my (the world econ­o­my being very large and intan­gi­ble).

The World Wide Web also end­ed up chang­ing the world econ­o­my and much more besides. And like the inter­modal con­tain­er, the World Wide Web is patent-free. Again, this was a prag­mat­ic choice to help fos­ter adop­tion. When Tim Berners-Lee and his col­league Robert Cailliau were try­ing to get peo­ple to use their World Wide Web project, they faced some stiff com­pe­ti­tion. Lots of peo­ple were already using Gopher. Anyone remem­ber Gopher? Wow. And the seem­ing­ly unstop­pable growth of Gopher was some­what hob­bled in the ear­ly 90s when the University of Minnesota announced it was going to start charg­ing fees for using it. And this was a cau­tion­ary les­son for Berners-Lee and Cailliau. They want­ed to make sure that CERN did­n’t make the same mis­takes. So, April 30th, 1993, the code for the World Wide Web project was made freely avail­able. This was for every­one.

If you’re try­ing to get peo­ple to adopt a stan­dard or use a new hyper­text sys­tem, the biggest obsta­cle you’re going to face is iner­tia. As the bril­liant com­put­er sci­en­tist Grace Hopper used to say, The most dan­ger­ous phrase in the English lan­guage is we’ve always done it this way.’ ” Now Rear Admiral Grace Hopper waged war on busi­ness as usu­al. She was well aware how arbi­trary busi­ness as usu­al is. Business as usu­al is sim­ply the cur­rent state of our con­sen­sus real­i­ty. She said, Humans are aller­gic to change. I try to fight that. That’s why I have a clock on my wall that runs counter-clockwise.”

But think about it. Our clocks are a per­fect exam­ple of ubiq­ui­tous but arbi­trary con­ven­tion. Why should clocks run clock­wise and not counter-clockwise? Well one neat expla­na­tion is that clocks are mim­ic­k­ing the move­ment of shad­ow across the face of a sun­di­al. In the Northern Hemisphere. And had clocks been invent­ed in the Southern Hemisphere, they would indeed run counter-clockwise. But on a clock face itself, why do we carve up time into twenty-four hours. Why are there six­ty min­utes in an hour? Why are there six­ty sec­onds in a minute?

Well, it prob­a­bly all goes back to Babylonian accoun­tants. Early cuneiform tablets show that the used a sex­a­ges­i­mal sys­tem for count­ing. It was because base 60…sixty is the low­est num­ber that can even­ly divid­ed by six, five, four, three, two, and one. But we don’t count in base 60. We count in base 10. I mean that in itself is arbi­trary, we just hap­pen to have a total of ten dig­its on our hands.

So, if the sex­a­ges­i­mal sys­tem of telling time is an acci­dent of account­ing, and base 10 is more wide­spread, why don’t we switch to a dec­i­mal time-keeping sys­tem? It has been tried. The French Revolution intro­duced not just a new dec­i­mal cal­en­dar much neater than our base 12 cal­en­dar, but also dec­i­mal time. Each day had ten hours. Each hour had one hun­dred min­utes. And each minute had one hun­dred sec­onds. So much bet­ter. It did­n’t take. Humans are aller­gic to change. And sex­a­ges­i­mal time may be arbi­trary and messy but…we’ve always done it that way.

It’s also why I’m not hold­ing my breath in antic­i­pa­tion of the USA ever switch­ing to the met­ric sys­tem. Instead of try­ing to com­plete­ly change peo­ple’s behav­ior, you’re like­ly to have more suc­cess by incre­men­tal­ly and sub­tly alter­ing what peo­ple are used to. And that was cer­tain­ly the case with the World Wide Web. The hyper­text trans­fer pro­to­col sits on top of the exist­ing TCP/IP stack. The key build­ing block of the web is the URL. But instead of cre­at­ing an entire­ly new address­ing scheme the Web uses the exist­ing Domain Name System.

Various HTML tags

Then there’s the lin­gua fran­ca of the Web. And these ele­ments prob­a­bly look pret­ty famil­iar to you, right? You rec­og­nize this lan­guage, right? Right.

It’s SGML. Standard Generalized Markup Language. Specifically, it’s CERN SGML, a fla­vor of SGML that was already pop­u­lar at CERN when Tim Berners-Lee was work­ing on his World Wide Web project. And he used this vocab­u­lary as a basis for the Hypertext Markup Language. And because this vocab­u­lary was already famil­iar to peo­ple at CERN, con­vinc­ing them to use HTML was­n’t that much of a hard sell. They could take an exist­ing SGML doc­u­ment, change the file exten­sion to “.htm”, and it would work in one of those new-fangled web browsers.

In fact HTML worked bet­ter than expect­ed. The ini­tial idea was that HTML pages would be lit­tle more than indices that point­ed to oth­er files con­tain­ing the real meat and pota­toes of con­tent. You know, spread­sheets and word pro­cess­ing doc­u­ments, what­ev­er. But to every­one’s sur­prise, peo­ple start­ed writ­ing and pub­lish­ing con­tent in HTML. And was HTML the best for­mat? Far from it. But it was just good enough, and easy enough, to get the job done.

And it has since changed. But that change has hap­pened accord­ing to anoth­er design prin­ci­ple: evo­lu­tion not rev­o­lu­tion. From its hum­ble begin­nings with a hand­ful of ele­ments bor­rowed from CERN SGML, HTML has grown to encom­pass an addi­tion­al 100 ele­ments over its lifes­pan. And yet it’s tech­ni­cal­ly the same for­mat. And this is a clas­sic exam­ple of the para­dox called the Ship of Theseus, bet­ter known in this coun­try as Trigger’s Broom.

Side-by-side screenshots of a modern web browser and a text-based browser

You can take an HTML doc­u­ment writ­ten over two decades ago and open it in a brows­er today. Even more aston­ish­ing, you can take an HTML doc­u­ment writ­ten today and open it in a brows­er from two decades ago. And that’s because the error-handling mod­el of HTML has always been to sim­ply ignore any tags it does­n’t rec­og­nize and ren­der the con­tent inside them. And that pat­tern of behav­ior is a direct result of the design prin­ci­ple degrade grace­ful­ly.”

Document con­for­mance require­ments should be designed so that Web con­tent can degrade grace­ful­ly in old­er or less capa­ble user agents, even when mak­ing use of new ele­ments, attrib­ut­es, APIs and con­tent mod­els.
HTML Design Principles

Here’s a pic­ture from 2006. That’s me in the cow­boy hat.

This pic­ture was tak­en in Austin, Texas. It’s an impromp­tu gath­er­ing of peo­ple involved in the micro­for­mats com­mu­ni­ty. And micro­for­mats, like any oth­er stan­dards, are sets of agree­ments. In this case their agree­ments on which class val­ues to use to mark up some of the miss­ing ele­ments from HTML: peo­ple, places, events, that’s pret­ty much it. And yes, they do have design prin­ci­ples, some very good ones. But that’s not why I’m show­ing this pic­ture.

Some of the peo­ple in this pic­ture Tantek Çelik, Ryan King, and Chris Messina were involved in the cre­ation of BarCamp, a series of grass­roots geek gath­er­ings.

A barcamp schedule board, showing time slots and proposed sessions written on notecards taped in place

And bar­camps sound like they should­n’t work but they do. The sched­ule for the event is arrived at col­lec­tive­ly at the begin­ning of the gath­er­ing. It’s kind of amaz­ing how the agree­ment emerges; rough con­sen­sus and run­ning events. And in the run-up to a bar­camp in 2007, Chris Messina post­ed this to the fledg­ling social net­work­ing site twit​ter​.com:

This was when tag­ging was all the rage, right. We were all about folk­sonomies back then. And Chris pro­posed that we would call this a hash­tag.

Now I was­n’t a fan. But it did­n’t mat­ter what I thought. People agreed to this con­ven­tion. And after a while, Twitter began turn­ing the hash­tagged words into links. And in doing so, they were fol­low­ing anoth­er HTML design prin­ci­ple: pave the cow­paths. Which sounds like advice for agrar­i­an archi­tects, but it is fur­ther clar­i­fied:

When a prac­tice is already wide­spread among authors, con­sid­er adopt­ing it rather for­bid­ding it or invent­ing some­thing new.
HTML Design Principles

Now Twitter had pre­vi­ous­ly paved a cow­path when peo­ple start­ed pref­ac­ing user names with the operand sym­bol. That con­ven­tion did­n’t come from Twitter, but they did­n’t try to stop it. They rolled with it and turned any user­name pref­aced with­in an at sym­bol into a link.

And the at sym­bol made sense because peo­ple were used to it from email. And the choice to use that sym­bol in email address­es was made by Roy Tomlinson. He need­ed a sym­bol to sep­a­rate the per­son and the domain. He looked down at his key­board. He saw the at sym­bol. And he thought, That’ll do.” And per­haps Chris fol­lowed a sim­i­lar process when he pro­posed the sym­bol for the hash­tag. It could’ve just as eas­i­ly been called a num­ber tag, or an octothor­pe tag, or a pound tag. And this sym­bol start­ed life as a short­cut for pound. Or more specif­i­cal­ly libra pon­do,” mean­ing a pound in weight.

And libra pon­do was abbre­vi­at­ed to lb” when writ­ten. And that got turned into a lig­a­ture when writ­ten hasti­ly. And that shape was the com­mon ances­tor of two sym­bols we use today: pound, and pound.

And the eight-pointed sym­bol was per­haps jok­ing­ly renamed the octothor­pe in the 60s when it was added to tele­phone key­pads. And it’s still there on the dig­i­tal key­pad of your mobile phone. And if you were to ask some­one born in this mil­len­ni­um what that key is called, they would prob­a­bly tell you it’s the hash­tag key.

And if they’re learn­ing to read sheet music, I’ve heard tell that they refer to the sharp notes as the hash­tag notes. And if this upsets you, you’re prob­a­bly the kind of per­son who rages at the word lit­er­al­ly” being used to mean fig­u­ra­tive­ly. Or super­mar­kets with aisles for ten items or less instead of ten items or few­er.

Well tough luck. Because the English language…is agree­ment. And that’s why English dic­tio­nar­ies exist not to dic­tate usage of the lan­guage but to doc­u­ment usage. And it’s much the same with web stan­dards. They don’t carve the stan­dards into tablets of stone and then come down the moun­tain to dis­trib­ute them amongst the browsers. No, it’s what the browsers imple­ment that gets carved in stone. That’s why it’s so impor­tant that browsers are in agree­ment. In the bad old days of the Browser Wars of late 90s we saw what hap­pened when browsers imple­ment­ed their own pro­pri­etary fea­tures. Standards require inter­op­er­abil­i­ty. Interoperability requires agree­ment.

Alright, so what can we learn from the his­to­ry of stan­dard­iza­tion? Well there are some directs lessons from the HTML Design Principles like the pri­or­i­ty of con­stituen­cies. Listen. I want devel­op­er con­ve­nience as much as the next devel­op­er, but nev­er at the expense of user needs. And I’ve often said that if I had the choice between mak­ing some­thing my prob­lem and mak­ing it the user’s prob­lem, I’ll make it my prob­lem every time. That’s the job. And I wor­ry that these days devel­op­er con­ve­nience is some­times prized more high­ly than user needs. I think we could all use a pri­or­i­ty of con­stituen­cies on every project we work on. And I would hope that we would pri­or­i­tize users over authors.

Degrade grace­ful­ly. I know. I go on and on about pro­gres­sive enhance­ment a lot. Sometimes I make it sound like a sil­ver bul­let. And it kin­da is. I mean, you can’t just buy a bul­let made of sil­ver. You have to make it your­self. And if you’re not used to craft­ing bul­lets from sil­ver it will take some get­ting used to. Again, if devel­op­er con­ve­nience is your pri­or­i­ty sil­ver bul­lets are hard to jus­ti­fy. But, if you’re pri­or­i­tiz­ing users over authors, pro­gres­sive enhance­ment is the log­i­cal method­ol­o­gy to use. And it’s a tes­ta­ment to the pow­er and flex­i­bil­i­ty of the Web that we don’t have to build with pro­gres­sive enhance­ment. We don’t have to build with a sep­a­ra­tion of con­cerns like struc­ture and pre­sen­ta­tion and behav­ior. We don’t have to use what the brows­er gives us: but­tons, drop­downs, hyper­links. If we want, we can make those things from scratch using Javascript, divs, and some ARIA attrib­ut­es.

But why do that? Is it because those native but­tons and drop­downs might be incon­sis­tent from brows­er to brows­er? Consistency is not the pur­pose of the Web. Universality is the key prin­ci­ple under­ly­ing the Web. And our pat­terns should reflect the intent of the medi­um. Use what the brows­er gives you. Build on top of those agree­ments. Because that’s the big­ger les­son to be learned from the his­to­ry of web stan­dards, and clocks, and con­tain­ers, and hash­tags. Our world is made up of incre­men­tal improve­ments to what has come before. And that’s how we will push for­ward to a bet­ter tomor­row. By build­ing on top of what we already have, instead of try­ing to cre­ate some­thing entire­ly from scratch. And, by work­ing togeth­er to get agree­ment instead of going it alone.

The future can be a fright­en­ing prospect. And I often get peo­ple ask­ing me for advice on how they should pre­pare for the Web’s future. And usu­al­ly they’re think­ing about which pro­gram­ming lan­guage or frame­work or library they should be invest­ing in. But those spe­cif­ic pat­terns mat­ter much less than the broad­er prin­ci­ples of work­ing togeth­er, col­lab­o­rat­ing, and com­ing to agree­ment. And it’s kind of insult­ing that we refer to these as soft skills. They could­n’t be more impor­tant.

And work­ing on the Web…you know, it’s easy to get down­heart­ed by the seem­ing­ly ephemer­al nature of what we build. None of it is…real. None of it is…tangible. And yet, look­ing at the his­to­ry of civ­i­liza­tion, it’s the intan­gi­bles that sur­vive. Ideas, philoso­phies, cul­tures, and con­cepts. And the future can be fright­en­ing because it is intan­gi­ble and unknown. But, like all the intan­gi­ble pieces of our con­sen­sus real­i­ty, the future is some­thing we col­lec­tive­ly con­struct through agree­ment. Now let’s agree to go for­ward togeth­er and build the future Web. Thank you.


Help Support Open Transcripts

If you found this useful or interesting, please consider supporting the project monthly at Patreon or once via Square Cash, or even just sharing the link. Thanks.