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 consensus. 

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 standards. 

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 agreement. 

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 principles. 

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 principles. 

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 purity.” 

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 values. 

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 other. 

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: 

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 agreement. 

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 intangible). 

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 30^th, 1993, the code for the World Wide Web project was made freely avail­able. This was for everyone. 

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. 

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. 

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 gracefully.” 

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 models.
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 picture. 

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 gatherings. 

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:

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

— Chris Messina (@chrismessina) August 23, 2007

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 hashtag. 

Thinking that hash­tags dis­rupt the read­ing flow of nat­ur­al lan­guage. Sorry @factoryjoe.

— Jeremy Keith (@adactio) November 6, 2007

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 clarified: 

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 fewer. 

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 agreement. 

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 attributes. 

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 important. 

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.