A Brief(ish) History of the Web Universe: Part III The Early Web

Part I and Part II of this series attempt to set the creation of the Web, the first Web browser and early attempts to publicly share Sir Tim Berners-Lee’s idea of “the Web” into some historical context.  They attempt to illustrate that there were ideas and forks of ideas along the way, each  considering different aspects of different problems; and that each had varying degrees of success. Some were popular and increasingly mature desktop products, others created standards upon which many products would be built.  Some were technically interesting but completely failed to take off and some which were academically fascinating but were largely vapor.   All of these were still “in motion” at the time that the Web was being conceived and it’s important to realize that they didn’t stop just because Tim said “wait, I’ve got it.”.  Those posts also attempt to explain how Tim really wanted the Web to be read/write, wanted to tap into existing mature products and which bits he imagined were most and least important.  I described the landscape of deployed hardware and technology at the time – the world was close, but not yet “ready” to be wired in richer form/  We weren’t connected by and large – In fact, the entire amount of information sent across the Internet monthly at that time would easily fit on a single sub $100 (US) external USB hard-drive in 2016.    All of this led helped shape the Web.

It would be an understatement to say that early on, the vast majority of folks in the mature bits of the industry didn’t really take the Web seriously yet.  As explained in previous posts, the authors of mature hypertext products turned down early opportunities to integrate the Web outright.  In 1992 Tim’s talk proposal for the Hypertext Conference was actually rejected.  Even in terms of new “Internet ideas” the Web didn’t seem like the popular winner. SGML enthusiasts by and large shunned it as a crude interpretation of a much better idea with little hope of success.  Gopher, which was created at almost exactly the same time, was gaining users far faster than this “World Wide Web”. What did happen for the Web, however, is that a huge percentage of the small number of early enthusiasts involved started building browsers… Meanwhile, existing ideas kept evolving independently, and new ideas started emerging too and these would continue to help shape and inspire.

1992-1993:  WWWWI

1992 saw the birth of a lot of browsers and little actual hypertext.  For perspective, by the end of 1992 there were seven web browsers which allowed users to surf the vast ocean of what was at the time only 22 known Websites.  As each browser came online they built on Tim’s original idea that the parser could just ignore tags it didn’t understand and each attempted to “adjust” what we might call the political map of the Web’s features.  Each brought with it it’s own ideas, innovations, bugs and so on.  Effectively, this was the first “Browser War” or what I’ll call “World Wide Web War I”.

There is one in particular, worth calling out:  ViolaWWW. It was created by a student named Pei Wei and it included innovations like stylesheets, tables, inline images, a scripting language and even the ability to embed small applications.  Remember that nearly all the popular non-Web, desktop hypertext and hypermedia products of the time had many these features.  What made ViolaWWW different was that it was so much more than text.  Viola (not ViolaWWW) was an Object Oriented programming language and a bytecode VM.   The ViolaWWW browser was a just VM application (though, it was the killer one that made most people care about it) – this made it possible to do all sorts of incredibly interesting things.

Screen Shot 2015-12-07 at 9.22.28 PM

Screenshots of the Viola Web Browser courtesy of viola.org

Some people reading this in 2016 are likely simultaneously impressed and a perhaps just a little horrified by the idea that attempts to “move away from” nice clean declarative, semantic markup with scripts and programs came so early on.  Tim must have been absolutely horrified, right?

Well, no that doesn’t seem to be quite accurate – at least from what I read from the record.  History is a lot more nuanced than we frequently tend to present it.  Ideas are complex.  Understanding nuances can be hard, but I’d like to try.

As I described in Part II, Tim didn’t imagine HTML would be “the solution” for content but rather

I expected HTML to be the basic waft and weft of the Web but documents of all types: video, computer aided design, sound, animation and executable programs to be the colored threads that would contain much of the content. – Tim Berners-Lee in Weaving the Web

In fact, regarding Pei and Viola, he spoke in generally glowing terms in Weaving the Web, and numerous interviews.  In his address at CERN in 1998, upon accepting a fellowship, he said

It’s worth saying that I feel a little embarrassed accepting a fellowship when there are people like Pei Wei …[who] read about the World Wide Web on a newsgroup somewhere and had some interesting software of his own; an interpreted language which could be moved across the NET and could talk to a screen.. in fact what he did was really ahead of his time.

As questions came in related to similar ideas on the www-talk mailing list Tim answered and explained a number of related concepts.  Here’s one that might capture his feelings at the time from May 1992 (Tim’s is the reply):

> I would like to know, whether anybody has extended WWW such, that it is possible to start arbitrary programs by hitting a button in a WWW browser.

Very good question. The problem is that of programming language. You need something really powerful, but at the same time ubiquitous. Remember a facet of the web is universal readership. There is no universal interptreted [sic] programming language. But there are some close tries. (lisp, sh). You also need something which can run in a very safe mode, to prevent virus attacks…. [It should be] public domain. A pre-compiled standard binary form would be cool too.  It isn’t here yet.

While I don’t know precisely what Tim was thinking in the early 1990’s I do think it is worth noting the description, his the use of the words “cool”  and “yet” as well as the absence of any sort of all caps/head exploding response.  In fact, if you wade through the archives, it turns out that a lot of early talk and efforts in 1991-1992 were already specifically surrounding this weird line between documents and applications or HyperText and HyperMedia.  Traditional desktop system makers had recognized the gap and early Web enthusiasts did too.

The point of this observation is simple:  “We” didn’t really fully know what we were doing then, and in many ways we’re still figuring it out today... and that’s ok.

Even the inclusion of inline images brought new questions – MIME wasn’t a given, content-negotiation was still kind of a rough dream and requests were very expensive.

Others were starting to add things like <input> and annotation and comment systems and variable ‘slots’ into the markup for some rough idea of ‘templating’ to help flesh out the problem that a whole lot of a sites, even then, would have to be concerned with repeating things.

Some people wanted to make servers really smart.  They saw the investment in a server as a thing which could query databases, convert document types on the fly, run business logic, etc.  These folks thought that modifying HTML would give them something akin to the IBM 3270 model which allowed the pushing of values and the pulling of page-based responses.  Others, like Pei, wanted to make clients smarter, or at least the cooperation between the two.  At some level, these are conversations nearly as old as computing itself and we’re still having them today.

Tim continues in that same post above to say that:

In reality, what we would be able to offer you real soon now with document format negotiation is the ability to return a document in some language for execution.

He mentions that, for example, the server might send either a shell script or a Viola script by way of negotiation – which he explains would “cover most Unix systems”. For Tim it seems (from my reading) that the first problem was that there wasn’t a standard language, the second was that it might not be safe, the third was that if there was one it should be in the public domain.  If you were on a Unix machine you’d be covered.  If you had Viola, you’d be covered.  If you had neither… well… it’s complicated.  But Viola had already begun tackling the safety issue too.

But even this early on – it didn’t seem to be a question of whether applications should be part of the Web, but more like how they should be.  Should be one way or maybe a few?

There was so much innovation and variance in browsers themselves that in December 1992 Tim sent an email entitled “Let’s keep the web together” simultaneously praising the wealth of ideas and innovations and stressing that they should work to begin the process of future standardization/alignment lest the Web fragment too far.

1993-1994: The Perfect Storm

When Marc Andreessen, was shown Viola it helped inspire him to start an effort at NSCA – at least that’s one story.

For all its value Viola had what turned out to be a critical flaw:  It was hard to get it working.  Despite all of its advantages, you had to install the runtime itself (the VM) and then run the browser in the runtime. Getting it setup and running proved problematic, even for a number of pretty technically savvy people. There were issues with permissions and bugs and Pei was kind of alone in building and maintaining it.

But this wasn’t unique.  Browsing the Web in 1993 was still a kind of painful endeavor to get going. The line mode browser was placed into the public domain in May 1993. There wasn’t a terribly lot there to browse either – even by the end of that year there were only 130 known websites. Setup was difficult and things were generally very slow.  Even finding something on that small number of sites was hard – forget searching Google, even Yahoo wasn’t a thing yet. Even if you could get something working with one browser, chances were pretty decent that you might come across something where it wasn’t the right browser for you to get the whole experience.

Marc Andreessen was the first one to start treating the browser like a modern product – really taking in feedback and smoothing out the bumps.  The team at NCSA quickly ported his UNIX work to Mac and PC, there was even one for the Commodore Amiga.  Mosaic was a good browser, but feature-wise, it probably wasn’t even the best.  Aside from ViolaWWW’s notable work, some browsers already had pioneered forms, for example, and Mosaic initially didn’t support forms.  But there was at least one thing they nailed:   They created an easy to install and setup browser on many platforms and drove the barrier to entry way down.

Moore’s Law had finally created faster and cheaper machines with modems entering a more mainstream market; some notable regulation changes happened; when the makers of Gopher announced that maybe just possibly in some circumstances you might be charged a very small fee Tim convinced CERN to make a statement that the Web wouldn’t do that.

In other words: When Mosaic was released publicly in late 1993 “free for non-commercial use” it was in the midst of the perfect storm.  Timing matters.

Suddenly the Web really started to hit and growth began to really explode.  By 1994, there were an estimated 2800 sites.  Regular PeopleTM were being introduced to the Web for the first time and they were using Mosaic.   After only roughly a year since being placed in the public domain, it is  estimated that less than 2% of Web users (still a comparatively small total by today’s measures) were getting around using the line mode browser. In April of that year, James Clark and Marc Andreessen established what would become Netscape.

Previous efforts to standardize didn’t get there – It wasn’t until November 28, 1994 that RFC-1886 was finally sent to the IETF to begin to create an HTML “standard” which we’ll talk about in Part IV, but wouldn’t ultimately arrive for another year and then in debatable form.

The VM

Pei wasn’t the only one thinking about a runtime VM, Sun Microsystems was too.  As described in Part II, Project Green spawned Oak thinking they’d found the next big market in consumer devices with embedded systems.  By 1992 they had a working demo for set-top boxes which created a read/write interactive internet-like experience for television – MovieWood which they had hoped to sell to cable companies.  But the cable companies didn’t bite.

This confluence of timing and ideas left the Green Team at Sun wondering what to do with the rest of their lives and their ideas.  Over the course of 3 days they discussed the success of Mosaic and decided their future.  As James Gosling would later describe:

Mosaic… revolutionized people’s perceptions. The Internet was being transformed into exactly the network that we had been trying to convince the cable companies they ought to be building. All the stuff we had wanted to do, in generalities, fit perfectly with the way applications were written, delivered, and used on the Internet. It was just an incredible accident. And it was patently obvious that the Internet and Java were a match made in heaven.

So the Sun team went back to the drawing board to build a browser like Mosaic – but in Java (which was a lot like Pei’s approach) and in 1994 they had a demo called “WebRunner”, which would later be renamed “HotJavaTM. Within just a few months everyone, not just techies, were going crazy imagining the possibilities.

Nearly everyone seemed to think that this would change the world. As we’ll see in Part IV, they might have been right, but not how they thought….

A Brief(ish) History of The Web Universe: Part II Time

Part II of “A Brief(ish) History of the Web Universe” aka “The Boring Posts”.  No themes, no punch, just history that I hope I can use to help explain where my own perspectives on a whole bunch of things draw from…

Tim Berners-Lee was working at CERN which was, by most measures, pretty large. Budgets and official policies were, as they are in many large organizations, pretty rigid and a little bureaucratic.  CERN was about particle physics, not funding Tim’s idea.  More than that, many didn’t recognize the value of lots of things which were actually necessary in some way.

The paradox of the Web was that this very very hard problem to connect heterogenous information from heterogeneous computers on heterogenous networks all over the word — a very very hard problem, was solved by a small, non-official, open approach by a team with no resources, or, practically none. – Ben Segal from CERN who brought in TCP/IP ‘under the radar’

In 1989, despite being actually necessary at this point for CERN to function, a memo went out reminding that it was “unsupported”.  A lot of the best things in history turn out to effectively have been people of good will working together outside the system to get things done that needed getting done.

So, in September 1990 Mike Sendall, Tim Berners-Lee’s boss at CERN found a way to give Tim the approval to to develop his idea in a way that many good bosses through history tend to: While no one wanted to fund development of “Tim’s idea,” there was some interest in Steve Jobs’ new NeXT computer (which it appears was also brought in initially despite, rather than as part of CERN policy and plans).  And so, under the guise of testing the capabilities/suitability of the NeXT computer for development at CERN in 1990 Tim would be able to create a prototype browser and server.

The NeXT had great tools for developing GUI applications and Tim was able to build a pretty nice prototype GUI with read-write facilities pretty quickly.  It let him figure out precisely what he was proposing.

A screenshot of the NeXT browser from 1993, courtesy of CERNit looked very similar in 1991.

A screenshot of the NeXT browser from 1993, courtesy of CERN – it looked very similar in 1991.

As explained in Part I of this history, there was already a lot going on, standardized or in place by then – for example SGML.  Because of this, CERN somewhat unsurprisingly, already had a bunch of SGML documents in the form of a thing called “SGMLGuid” (sometimes just GUID).  Unfortunately, the earliest capture of this I can find is from 1992 but here’s what SGMLGuid looked like.

SGML itself had gotten quite complex as it tackled ever more problems, and Tim didn’t really know SGML.  But he saw the clear value in having a language that was at least familiar looking for SGML authors, and of having some existing corpus of information.  As he said later

Who would bother to install a client if there wasn’t already exciting information on the Web? Getting out of this chicken and egg situation was the task before us….

Thus, he initially started with a kind of a subset of ~15 GUID tags (plus the critical <a> tag for expressing hyperlinks which is Tim’s own creation and at the very core of the idea – an exact number is hard to say because the earliest document on this isn’t until 1992).  As explained on w3.org’s origins page:

The initial HTML parser ignored tags which it did not understand, and ignored attributes which it did not understand from the CERN-SGML tags. As a result, existing SGML documents could be made HTML documents by changing the filename fromxxx.sgml to xxx.html. The earliest known HTML document is dated 3 December 1990:

<h1>Standardisation</h1>
There was not a lot of discussion of this at <a href=Introduction.html>ECHT90</a>, but there seem to be two leads:
<ol>
<li><a href=People.html#newcombe>Steve newcombe’s</a> and Goldfarber’s “Hytime” committee
looking into SGML, and
<li>An ISO working group known as MHEG, “Multimedia/HyperText Expert Group”.
led by one Francis Kretz (Thompsa SA? Rennes?).
</lo>

There’s a lot of history hiding out in this first surviving HTML actually.

First, note that this and many others weren’t “correct” documents by many counts we’d think of today: There was no doctype, no <html> element, no <head>, <title> or <body> etc.  There actually wasn’t an HTML standard yet at that point so at some level it’s kind of amazing how recognizable it remains today – not just to humans, but to browsers.  Your browser will display that page just fine.  HTML, as it was being defined however, also wasn’t valid SGML necessarily.  The W3C site points out that the final closing tag is an error (it transposes the letters).

More interestingly still for purposes here, I’d like to note that the very first surviving HTML document was about quite literally about HyperMedia. It’s part of notes from what they called the hypertext conference and, unsurprisingly, that is what everyone was talking about.  To understand why I think this matters, let’s rewind just a little and tie in some things from Part I with some things that weren’t….

The Timing of the Web

Is that title about Tim or Time?  Both.

Remember VideoWorks/Director from Part I?  It illustrated that perhaps the concept of Time was really important to hypermedia.  However, they weren’t the only ones to see this. In fact, even as early as 1984 people were already seeing a gap between documents and hypermedia/multimedia and talking about how to solve it. It turns out SGML, the reigning standard approach of the time for documents as markup actually wasn’t quite suited to the task. It needed revision.

So, Goldfarb (original GML creator, presumably mistyped above) went back to the drawing board with some more people to figure out how to apply it to a musical score. What they came up with was called SMDL (Standard Music Description Language), an effort that was ANSI approved in late 1985.  However, no practical demonstration of SMDL was completed until 1990 and as part of a Master’s thesis rather than a product (this dissonance over what makes a “standard” appears and reappears over and over in standards history).

It’s key though because you could definitely say that by the mid-late 80’s, it was becoming obvious to many that the problem of time and linking objects in time was a more generalized problem.  Video, for example, might have been a neat thing on the desktop but don’t forget that in the 1980’s, cable television was spreading along with computers and multimedia — and much faster. By this time, a number of folks were beginning to imagine something like “interactive TV” as the potentially Next Really Big Thing (even before the Web).  Sun Microsystems established a group, “Green” to figure out the next big thing, who thought it would be interactive consumer electronics (like interactive TVs).

And so in 1989, just about the time Tim was putting together his ideas on the Web, the grander problem of Time/SGML was moved out of SMDL into a new ANSI project known as “HyTime” (Hypermedia/Time-based Structuring Language” which had a lot of key players and support from major businesses.

It really looked like maybe it was going somewhere.  Remember Ted Nelson from Part I?  In 1988, AutoDesk had decided to fund him directly and commercialize his ideas which had become known as Project Xanadu. An AutoDesk press release said:

In 1964, Xanadu was a dream in a single mind. In 1980, it was the shared goal of a small group of brilliant technologists. By 1989, it will be a product. And by 1995 it will begin to change the world.

Nelson/Autodesk were some of the big names on that HyTime committee.  Ironically, I think they got the years pretty close, but the technology wrong.

At approximately the same time the MPEG (Moving Pictures Experts Group) and MHEG (Multimedia and Hypertext Experts Group – also mentioned in that initial post above) were established.  MHEG’s focus, like a lot of other things included hypermedia documents, but unlike SGML required an MHEG engine – basically, a VM.  The files they’d trade would be compiled binary rather than text-based. While they were authorable as documents, they were documents about interactive objects.

And so this is what people were talking about at the conference which Tim was summarizing in that early surviving HTML document.  Both HyTime and MHEG were already thinking about how to standardize this quality in part because there is a lot of media.   An interesting thing about media is that people were building multimedia applications.

Shipping

So the world around him was moving forward and there were lots of interesting ideas on all fronts. Tim had a prototype in hand.  HTML as understood by the NeXT had no forms, no tables, you couldn’t even nest things – it was flat.  Not only did it have no CSS but no colors (his screen was black and white).  But, for the most part many of his tags were simple formatting.  You can debate that an H1 is semantic, but in Tim’s interface it was under styling.  That is, as you could “style” things as an H1, more or less WYSIWYG style, and the editor would flattened it all out in serializing markup.

Tim imagined (and has repeated since) that the most important thing was the URI, then HTTP then stuff like HTML and later CSS.  URIs, in theory, can work for anything as long as you have a concept of a file that is addressable.  HTTP was built with a feature called ‘content type negotiation’ which allows the sender to say what it’s prepared to handle and the server to give him back something appropriate.   As Tim explains this feature in Weaving the Web:

In general … the client and server have to agree on the format of data they both will understand.  If they both knew WordPerfect for example, they would swap WordPerfect documents directly.  If not, they could try to translate to HTML as a default.

So the weird intricacies of HTML or things above weren’t drastically important at the time because Tim didn’t imagine HTML would be for everything. In fact, help address his chicken and egg problem described above, Tim just made his browser give URIs and auto-translate some popular existing protocols like NNTP, Gopher and WAIS to the HTML.  But perhaps even this is over-simplifying just a bit – as he also explained:

I expected HTML to be the basic waft and weft of the Web but documents of all types: video, computer aided design, sound, animation and executable programs to be the colored threads that would contain much of the content.  It would turn out that HTML would become amazingly popular for the content as well…

It would turn out…

One of the most interesting things about invention is the stuff that the inventor didn’t expect people would do with it.  It would turn out that HTML would become really popular for content for a number of reasons.  One reason, undoubtedly, is that the simplest thing to do is simply to provide HTML in the first place with no alternatives.  More importantly, perhaps,  to re-iterate the point from part I: The line between documents and ‘more than documents’ was clearly fuzzy.

To illustrate: Even with the NeXT browser “in hand”, it was very hard to show people value. Very few people had a NeXT, even at CERN – after all, it was a pilot for establishing whether the new-fangled machines would be useful.  Lugging it around only went to far .   There was a new project at CERN to provide a directory and Tim and early partners like Robert Cailliau convinced CERN to publish the directory via the Web.

251-2

Mac HyperCard address book application thanks to http://www.atarimagazines.com

This is interesting because address book applications were something that a lot of the modern computers of the time had, but a phonebook was a bunch of printed pages.  Who wouldn’t have liked that application?   It might have been potentially “easy” to create a nice HyperCard stack and auto-transform to HTML based on content type negotiation – but which part was document and which part was application?  It was actually much easier to just deliver HTML which could be generated any number of ways – and with the current digital expectations of the day, on the machines they were using, that was just fine.  Thus, the simple line mode browser that made the fewest assumptions possible was born as something that could be distributed to all the CERN machines (and all the world’s machines – more on this below).

The line mode browser was, frankly, boring.  It was wildly inferior to the NeXT interface which was itself wildly inferior to something like OWL’s Guide.    But it worked, and as usual, that matters.  Let me repeat that:  Shipping something useful matters.  

If you’ve never heard of Maslow’s Hammer, you’re probably at least familiar with the software version of it:  We like to say “If the only tool you have is a hammer, everything looks like a nail”.  Usually when we say it we’re trying to say “use the right tool for the job”.  However, there’s a corollary there that is just as true and often goes unnoticed:  If someone only has a butter knife it would turn out that they can suddenly screw in some kinds of screws.

It would also turn out that that’s not entirely a bad thing:  If you need to unclog something, a butter knife works.  If you need a lever to lift something small in a tight spot, a butter knife works in a pinch.  If you need a paperweight on a windy day, guess what turns out to work pretty well? Perhaps that wasn’t the butter knife’s original intent, but it is universally true. And guess what else turns out to be true?  A butter knife and some other things were probably an “almost” approximation for some tool that didn’t yet exist.  What’s more, having a few of those “almost” tools frequently helps inspire something better.  Steven Johnson calls this “the adjacent possible” in his Ted Talk “Where good ideas come from” and I think it’s as true of the Web as it is of anything.

Adjacent Possibles

However it came about, it turns out as well that the line mode browser was kind of perfect in time for a number of reasons.  To keep things in perspective, this was 1990.  While computers were starting to catch on, in 1990 they were still very expensive.  As such, as deployed, many of them didn’t even have OS’ with something remotely like what we would call graphical UIs as a norm yet.  Of those that did, few even had modems.  And of those with modems, many still connected at 1200 or 2400 baud.  We weren’t connected nor even completely GUI yet.  Those who were connecting most frequently were often doing so through large, expensive and frequently outdated systems which had been a really big investment years before.

Because of this, what the line mode browser definitely did was to allow Tim and others to show the people who would start writing the modern browsers with GUIs and increasingly recognizable features in short order and keep a small but steady stream of new potential enthusiasts checking it out.  Sadly perhaps, another thing it did was to omit the authoring piece that was present on the NeXT machine and set in motion a trend where people perceived the Web as a way to consume rather than publish and contribute and likely spurned a greater focus on authoring HTML.  “Sadly Perhaps,” but then again, perhaps that’s precisely what was necessary in order for it to mature anyway.  It’s hard to say in retrospect.

With a few new enthusiasts, in 1991 he created a mailing list: www-talk.  For a while a very, very small but steadily growing group of people discussed the early “Web” they were trying to build.  As more people came into the group they wanted more and different things – it should be more like HyTime, links should really work differently, it should actually be SGML rather than just “inspired by” or “look like” it and so on.

What happened next just keeps getting more interesting.  Continue to Part III: The Early Web.

 

 

 

A Brief(ish) History of the Web Universe – Part I: The Pre-Web

There are a couple of posts that I’ve been wanting to write, but in each of them I keep finding myself wanting to talk about historical context.  Explaining it in place turns out to be too hard and I’ve been unable to find a resource that unifies that bits I want to talk about.  I’ve decided, then, that it might be easier then to write this history separately, mostly so that I can refer back to it.  So here it is, “A Brief(ish) History of the Web Universe” aka “The Boring Posts” in a few parts.  No themes, no punch, just history that I hope I can use to help explain where my own perspectives on a whole bunch of things draw from…

Background

Businesses, knowledge, government and correspondence  were, for literally hundreds of years, built on paper documents.   How did we get from that world to this?  And how has that world, and our path, helped shape this one?  I’m particularly interested in the question of whether some of those implications are good or bad – what we can learn from the past in order to improve on our future or understand our present.  So how did we get here from there?

Arguably the first important step was industrialization.  This changed the game in transforming the size of challenges and created new needs for efficiency.  This gave rise to the need for increasing agreement beginning with standards around physical manufacture – first locally, and then nationally around 1916.  World War II placed intense pressures and funded huge research budgets and international cooperation.  A whole lot of important things shook out in the 1940s and each developed kind of independently. I won’t go into them much here except to note a few key points to help set the mental stage of what the world was like going into the story.

The word “computer” in anything resembling really modern terms wasn’t even a thing until 1946.

The First Digital Computer – ENIAC “For a decade, until a 1955 lightning strike, ENIAC may have run more calculations than all mankind had done up to that point.” from computerhistory.org

In 1947 ISO, the International Standards Organization, was founded.  That same year, the transistor was invented at Bell Labs.  In the late 1940’s the Berlin Airlift transported over 2.3 million tons of food, fuel and supplies by developing a “standard form” document could be transmitted over just about any medium – including, for example, by telegraph.  Later this basic technique would become “EDI” (Electronic Data Interchange) and become the standard for commercial shipping and trade at scale, but It required very tight agreement and coordination on standard business documents and processes.

Transistors revolutionized things, but the silicone chips which really began the revolution weren’t yet a thing.  Intel, who pioneered and popularized it wouldn’t even be founded until 1968.

During this interim few decades, the number of people exposed to the idea of computers began, very slowly to to expand – and that gets pretty interesting because we start to see some interesting forks in the road…

1960’s Interchange, SGML and HyperStuff

In the mid 1960’s Ted Nelson noted the flaw with the historical paper model:

Systems of paper have grave limitations for either organizing or presenting ideas. A book is never perfectly suited to the reader; one reader is bored, another confused by the same pages. No system of paper– book or programmed text– can adapt very far to the interests or needs of a particular reader or student.

He imagined a very new possibility with computers, first in scholarly papers and then in books. He imagined this as an aid to authors as well which he explained evolve a work from random notes to outlines to advanced works.  He had a big vision.  In his description, he coined three important terms: Hypertext, Hypermedia (originally Hyperfilm) and Hyperlink.  For years, the terms Hypertext and Hypermedia would cause some problems. Some (including it seems to me Nelson) considered media as part of the text because it was serialized and others considered text as a subset of media) — But this was all way ahead of its time. While it was going down, the price-point and capabilities just weren’t really there. As he described in the same paper.

The costs are now down considerably. A small computer with mass memory and video-type display now costs $37,000;

Another big aspect of his idea was unifying some underlying systems about files.  Early computers just didn’t agree on anything.  There weren’t standard chipsets much less standard file types, programs, protocols, etc.

Markup

In 1969, in this early world of incompatibility, three men at IBM (Goldfarb, Mosher and Lorie) worked on the idea of using markup documents to allow machines to trade and deal with a simple understanding of “documents” upon which they could specialize understanding, storage, retrieval or processing.  It was called GML after their initials, but later “Generalized Markup Language”.  It wasn’t especially efficient.  It had nothing to do with HyperAnything nor even EDI in a technical sense.  But it was comparatively easy to get enough rough agreement in order and flexible enough to make things actually work in order to achieve real things.  For example, you could send a GML document to a printer and define separately how precisely it would print.  Here’s what it looked like:

:h1.Chapter 1:  Introduction
   :p.GML supported hierarchical containers, such as
   :ol
   :li.Ordered lists (like this one),
   :li.Unordered lists, and
   :li.Definition lists
   :eol.
   as well as simple structures.
   :p.Markup minimization (later generalized and formalized in SGML),
   allowed the end-tags to be omitted for the "h1" and "p" elements.

But GML was actually a script – the tags indicated macros which could be implemented differently.  Over time, GML would inspire a lot, get pretty complicated, philosophical about declarative nature and eventually become SGML (Standard Generalized Markup Language).  This would continue growing in popularity – especially in the print industry.

The changing landscape

For the next decade, computers got faster, cheaper, and smaller and more popular in business, science and academia and these all matured and evolved on their own.

Networks were arising too and the need for standardization there seemed obvious.  For about 10 years there was an attempt to create a standard network stack in international committees, but it was cumbersome, complex and not really getting there.  Then, late in this process, Vint Cerf left the committee.  He led work focused on rough consensus and running code for the protocol and, in very short order, the basic Internet was born.

Around this same time, a hypertext system based on Nelson’s ideas, called “Guide” was created at Carnegie Mellon University for Unix workstations.

Rise of the Computers

In the 1980’s Macs and PCs, while still expensive, were finally becoming affordable enough that some regular people could hope to purchase them.

Return of the HyperStuff

Guide was commercially sold by, ported by to the Mac and PC by, and later very much improved on by a company called OWL (Office Workstations Limited) led by a man named Ian Ritchie.  It introduced one of the first real hypertext systems to desktops in 1985.  In 1986 Guide won a British Computer Society award. Remember “Guide” and “Ian Ritchie” because they’re going to come back up.

hcard1-1Another two years later people were really starting to take notice of “HyperText” (and beginning to get a little over-generalized with the term – frequently this was really becoming “HyperMedia”).  In 1987, an application called “HyperCard” was introduced and the authors convinced Apple to give it away free for all Mac users.  It was kind of a game changer.

HyperCard was a lot like Guide in many ways but with a few important details we’ll come back to.  The world of HyperCards was built of “decks” – each deck a stack of “cards” full of GUI: forms, animations, information and interactions which could be linked together and scripted to do all sorts of useful things.  Cards had an innate “order” and could link to and play other media which would – the state of things in a card/deck was achieved through scripting.  They were bitmap based in presentation and cleverly scalable.

Screenshot of VideoWorks and the “score”

That same year, in 1987, a product called VideoWorks by a company named Macromind was released.  In fact, if you got a Mac, you saw it because it was used to create the interactive guided tour that shipped with it.   You could purchase it for your own authorship.

One interesting aspect of VideoWorks was its emphasis on time.  Time is kind of an important quality of non-static media, so if you’re interested in the superset of hypermedia, you need the concept of time.  Thus, the makers of VideoWorks included a timeline upon which things were ‘scored’.  With this HyperMedia, authors could allow a user to move back and forth in the score at will.  This was kind of slick, it made sense to a lot of people and it caught on.  Their product later became “Director” and it became a staple for producing high-end, wow’ing multimedia content on the desktop, CD-ROMs for kiosks and so on.

By the late 1980’s, OWL’s Guide had really come to focus on the PC version.  Hypercard was Free on the Mac and as it’s creator Ian Ritchie would say later…

You can compete on a lot of things, but it’s hard to compete with free…

The emergence of an increasingly fuzzy line…

Note that most of these existing systems of this time actually dealt, in a way, with hypermedia in the sense that they didn’t draw so closely to this fundamental primitive idea based on paper.  All of these could be scripted and and you might imagine: Applications were a natural outcropping.   The smash game Myst was actually just a really nice and super advanced HyperCard stack!

The Stage is Set…

The Internet was there.  It was available – in use even, but it was pretty basic and kind of cumbersome.  Many people who used the internet perhaps didn’t even realize what the internet really was – they were doing so through an online service like Compuserve or Prodigy.

But once again, as new doors were opened, some saw new promise.

The Early 1990s

I’ve already mentioned that SGML had really nothing at first to do with HyperMedia, but here’s where it comes back in.  The mindset around HyperCard was stacks and cards.  The mindset around VideoWorks/Director was Video.  The mindset of OWL was documents.  SGML was a mature thing and having something to do with SGML was kind of a business advantage.

Guide had SGML-based documents.  More than that, it called these “Hypertext Documents” and their SGML definition was called “HyperText Markup Language” (which they abbreviated HML) and it could deliver them over networks.  Wow.  Just WOW, right?  Have you even heard the term “Web” yet?  No.

But wait – there’s more!  Looking at what else was going on, OWL had much advanced Guide on the PC and by now it had integrated sound and video and advanced scripting ability too.  While it was “based” on documents, it was so much more.  What’s more, while all of this was possible, it was hidden from the average author – it had a really nice GUI that allowed both creation and use. That it was SGML underneath was, to many, a minor point or even a mystery.

Web Conception

This is the world into which HTML was conceived.  I say conceived rather than “born” or “built” because Tim had been working out his idea for a few years and refining it.  He talked about it to anyone who would listen about a global, decentralized, read-write system that would really change the Internet.  He had worked out the idea of an identifier, a markup language and a protocol but that was about it.

And here’s the really interesting bit:  He didn’t really want to develop it, he wanted someone else to.  As Tim has explained it several times…

There were several commercial hypertext editors and I thought we could just add some internet code, so that the hypertext documents could then be sent over the internet. I thought the companies engaged in the then fringe field of hypertext would immediately grasp the possibilities of the web.

Screenshot of OWL’s Guide in 1990

Remember OWL and Guide? Tim thought they would be the perfect vehicle, they were his first choice.  So, in November 1990, when Ian Ritchie took to a trade show in Versaille to show off Guide’s HyperMedia, Tim approached him and tried hard to convince him to make OWL the browser of the Web.  However, as Tim notes “Unfortunately, their reaction was quite the opposite…”  
Note that nearly all of the applications discussed thus far, including OWL, were commercial endeavors.  In 1986, authors who wanted to use OWL to publish bought a license for about $500 and then viewers licensed readers for about $100.  To keep this in perspective, in adjusted dollars this is roughly $1,063 for writers and $204 for readers.  This is just how software was done, but it’s kind of different from the open source ethos of the Internet.  A lot of people initially assumed that making browsers would be a profitable endeavor.  In fact, later Mark Andreeson would make a fortune on the name Netscape in part because there was an assumption that people would buy it.  It was, after all, a killer app.

It’s pretty interesting to imagine where we would be now if Ritchie had been able to see it.  What would it have been like with OWL’s capabilities as a starting point, and what impact the commercial nature of the product might have had on the Web’s history and ability to catch on.   Hard to say.

However, with this rejection (and other’s like it) , Tim realized

…it seemed that explaining the vision of the web was exceedingly difficult without a web browser in hand, people had to be able to grasp the web in full, which meant imagining a whole world populated with websites and browsers. It was a lot to ask.

 

He was going to have to build something in order to convince people.  Indeed, Ian Ritchie would later give a Ted Talk about this in which he admits that two years later when he saw Mosaic he realized “yep, that’s it” – he’d missed it.

A Final Sidebar…

PenPoint Tablet in 1991

At very nearly the same time something that was neither HyperStuff nor SGML nor Internet related entered the picture.   It was called “PenPoint”.  Chances are pretty good that you’ve never heard of it and it’s probably going to be hard to see how, but it will play importantly into the story later.  PenPoint was, in 1991, a tablet computer with a stylus and gesture support and vector graphics.
Think about what you just read for a a moment and let it sink in.

If you’ve never seen PenPoint, you should check out this video from 1991 because it’s kind of amazing.   And here’s what it has to do with our story: It failed.  It was awesomely ahead of its time and it just… failed.  But not before an application was developed for it called “SmartSketch FutureSplash” (remember the name) – a vector based drawing tool which would have been kind of sweet for that device in 1991.

I’ll explain in Part II how this plays very importantly into the story.

Many thanks to folks who slogged through and proofread this dry post for me: @mattur @simonstl and @sundress.

 

Pandora’s Box

This post is part of my personal notes in a larger effort in thinking about benefits now that are currently specified in Shadow DOM, but contentious and held up in committee.  We’ll work it out in standards, I’m sure – but given the number of things Shadow DOM was addressing, it may still be several years until we have solutions widely implemented and deployed that solve all of them.  This has me doing a lot of thought exercises about what can be done in the meantime.  This post reflects one such exercise:  Specifically, what would it mean to solve just the styling end of this on its own. Warning, it may be mildly crazy so the title is perhaps doubly relevant. It was originally posted on radar.oreilly.com.

B3t0l4FIAAAPxkUThe Pandora Box

CSS works really well if you can follow good patterns and have nice rich markup. It lets you define broad rules and inherit and override selectively, and if used well it cleanly decouples a separation of concerns — it’s pretty elegant actually.

On the other hand, in the real world, things are often not that simple: Until pretty recently, HTML wasn’t especially expressive natively, so we worked around it. – many times on our own by adding classes like “article”.  But, there wasn’t a standard.  Likewise, our ideas about the patterns we should follow or best practices continues to change as we gain new powers or spend more time with the technology. Of course, there are a vast number of cases where you’ll just go and upgrade your philosophy and be the better for it, but there are a number of times when this just isn’t an option. I recently described this in a recent post as the “friendly fire” problem – when you have numerous teams operating on different time schedules and budgets across many code bases that attempt to mash together into various forms. This is sometimes referred to in standards circles, less colorfully, as “the composition problem”.

When it comes to these sorts of cases, quality and philosophy are inevitably mixed and not entirely in the control of any one team. In these sorts of cases, CSS selectors are kind of like live hand-grenades, it’s just way too easy to do damage you didn’t intend to do because it requires a level of coordination of approach which is, for business reasons, highly impractical. And so you try really hard to analyze the problem, get the right select/cascade/descend/inherit/specificity, pull the pin, lob it into the pages and… hope. Frequently, all hell breaks loose. The more you mix it up, the harder it gets to reason about and the more our stylesheets explode in complexity. You’ve opened the proverbial Pandora’s Box.

You can see this in play in some simple examples. If the page begins with assumptions and a philosophy of it’s own and then injects markup created by another team with a differing philosophy without adopting their CSS as well, the results are frequently bad. Here’s one such (overly simplified) example in which you’ll notice that the taxonomy of classes overlap and the result is that the inner context has bits that not only themselves become unreadable but obscure the page’s (already pretty bad) content. If the page does include the other team’s CSS it can easily get worse, as seen in this example in which you’ll notice both ends have harmed each other to the point of complete uselessness.

At a minimum, one proposal that seems to keep coming up in various forms (most recently Shadow DOM) is to provide a way, in cases like these, for authors to isolate the styling of various pieces so that the default thing is to do no harm in either direction, thereby just simplifying the problem.  But, for now, the platform doesn’t provide you an easy way to do that…. but it does provide a way to fake it, and that might be useful.  In the very least it can help us to figure out exactly what it is we need: Without data, standardization is hard and often a bad idea.  So much discussion is about what we think developers will find intuitive or confusing.  A better way is to know what developers understand or don’t.  So let’s see if we can try to tamp down a cow path.

Thinking about how CSS works

initial-values: All elements have all of the CSS properties from the get-go, all CSS properties have a default, or initial value which is specified in the specification.

A screenshot of the CSS2.1 spec showing the initial value for the display property was 'inline' at the time (it's grown more complicated but the net effect is the same)

The initial value for each property is provided in the spec.

For simplicity, you can sort of imagine that without anything more, all elements begin their life with properties that would look to most of us like a <span>. I’m guessing this is news to a lot of long time users of CSS because we pretty much never experience this world because browsers (“user-agents” in standards speak) come with a stylesheet of their own…

user-agent stylesheets: All browsers come with a default, or “user-agent” stylesheet. This is the thing that tells them how to display an element in the first place, and it does so with the same kinds of CSS rules that you and I write every day. Without it, you’d be able to see the contents of those <style> and <script> tags, your <h1> would look just like any other piece of text, and so on.  You can see one such example in Firefox’s stylesheet. So: initial values + user-agent sheet yields what you’d get if you started editing an HTML document, before you started adding your own CSS (“author CSS” is what we generally call that stuff).

specificity: The CSS runtime is a rules engine – all of the rules are loaded in order and maintain a stable sort based-on a concept called “specificity”. That is, each rule gets a weighted “score” according to the selector it is based on. A “*” in the selector is worth 0 “points”, a tag is worth 1, a class is worth an order of magnitude more (it’s not specifically 10 based, but for illustration you can assume 10 points), an id is worth 100. So the reason author CSS trumps the user-agent stylesheets is simply the user-agent stylesheet is very low specificity and it came first – authors will always be either more specific or have come later.

And this is where things get sticky…

In situations like the ones described above, if you’ve got a independently developed components working on differing models or timeline, no side can really know what they’re likely to inherit, what to override or how to do it (because specificity). Reasoning about this is really hard – many big companies or products have stylesheets that are many thousands of rules, and frequently not just one that must work with a vast array of content of varying age, quality and philosophy.

Keep a lid on it…

At some level, we can imagine that we’d like to identify a container as a special thing, let’s call it a “pandora-box” – the kind of integration point we’re talking about- and have it do just what the browser does with a fresh page by default for that container.  In this model, we’d like to say “Give me a clean slate (reset the defaults and provide a user-agent-like sheet for this sort of container).  Let my rules automatically trump the page within this container, by default, just like you trump the user agent… Likewise, keep my rules inside this Pandora’s Box by default”.  Essentially, we’d like a new specificity context.

If you're thinking this seems a little like a Rube Goldberg machine, it's  not quite so out there - but, welcome to the Web and why we need the sorts of primitives explained in the Extensible Web Manifesto

If you’re thinking this seems a little like a Rube Goldberg machine, it’s not quite so out there – but, welcome to the Web and why we need the sorts of primitives explained in the Extensible Web Manifesto

Well, to some extent, we can kind of do this with a not too hard specificity strategy that removes the most of the hard-core coordination concerns: We can use CSS’s own specificity rules to create an incredibly specific set of default rules, and use that as our box’s equivalent of a ‘default stylesheet’  – basically resetting things.  And that should work pretty much everywhere today.

The :not() pseudo-class counts the simple selector inside for its specificity. So, if we created an attribute called, for example, pandora-box and then picked an id which would be incredibly unlikely to exist in the wild (say #-_- because it’s not just unique but short and shows my ‘no comment’ face), then, it would – using CSS’s own theory, provide a clean slate within the box. And, importantly, this would work everywhere today (because we would wind up with a single “pandora-box stylesheet” with rules like [pandora-box] h1:not(#-_-):not(#-_-):not(#-_-) { ... } which has a specificity of 3 ids, 1 attribute and 1 tag (311 in base-10 – again CSS isn’t base-10 but it’s helpful for visualization to assign a meaningful number), enough to trump virtually any sane stylesheet’s most ambitious selector).

Given this, all you need is a way to shove the component’s rules into the box and shut the lid and you have a pretty easy coordination strategy.  You’ve basically created a new “context”.

Essentially, this is the same pattern and model as the page has with user-agent sheets, at least mentally (initial values are still initial values and they could have been modified, so we’ll have to reset those in our pandora sheet as well).

In simple terms, A pandora box has two sets of rules – the default and the author provided that parallel the user-agent (default) and author.  The automatic ordering of specificity in naturally such that the automatic pattern for resolution is: User-agent default stylesheet, then normal author stylesheets, then pandora-box default stylesheet then pandora-box author stylesheets.

If you can follow this model, you should be able to work cooperatively without the risks and figure out how well that approach works.  Of course, no one wants to write a ton of :nots but we have preprocessors which can help and, maybe we can write something helpful for basic use that doesn’t even require that.

So, here’s a quick test pandora-box.js which does just that. Including it will inject a “pandora-box stylesheet” (just once) and give you a method CSS._specifyContainer(containerElement) which will shove any <style> tags within it to a more specific ruleset (adding the pandora/specificity boosts). The file has a couple of other methods too but they all are just alternate forms of this for a trying out a few ways I’m slicing up the problem – one that allows me to hoist a string of arbitrary cssText, another that I’m playing with in a larger custom element pattern.  You can see this in use in this example, it is identical to the previous one in terms of HTML and CSS.

Interestingly, CSS has an all property for unwinding the cascaded values simply.  Unfortunately, it doesn’t have an equivalent to ‘default’ things back to the fresh page state (the one that includes the user-agent sheet), only to nuke all styles back to their initial values, which, in my mind, leaves you in a pretty bad spot.  However, if it did, our pandora sheet would be essentially a single declaration: [pandora-box]:not(-_-):not(-_-):not(-_-) * { all: user-agent; }. Luckily, that’s under discussion by the CSSWG as you read this.

One question that is semi-unresolved is just what should that pandora sheet actually contain. How much is really necessary and, should it perhaps include common reset rules. I’ve taken what I think is a pretty sane stab at it, but all of this is easily tweaked for experimentation, so feel free to fork or make suggestions. The real goal of this exercise is to allow for experimentation and feedback from real authors, expand the conversation and highlight just how badly we need to solve some of these problems.

What about performance?!

The injection of rules happens just once, I don’t think that is likely a big perf problem. Besides the pandora-box stylesheet, you have exactly the same number of rules (your components rules are replaced, not duplicated) and because it’s easier to reason about you should be able to have generally less crazy sheets. At least, that’s what I hope. Only time and use will really tell. If you’re worried about the complexity of the selectors slowing things down dramatically, I doubt that’s much of a problem either – browsers use a bloom filter and such cleverness that evaluating the pandora sheet should have not much effect and the triple :not’s are placed on the subject element of the selector, so there shouldn’t be much computational difference between something no one would have trouble writing like [pandora-box] .foo and the rule it rewrites to [pandora-box] .foo:not(-_-):not(-_-):not(-_-), it never walks anywhere.

What about theming?!

Pandora shut the box vowing never to open it again. But when a tiny voice begged to be let out, she opened it one las time. As well she did, for the creature left was the one we call Hope

Pandora’s box art from http://wallpapershd3d.com/fantasy-art-wallpaper/ by Marta Dahlig

This seems to be one of the great debates – clearly there *are* certain kinds of advice you want an outer page to provide to the stuff in these various pandora boxes – things like “the background of this calendar component should be blue”.

In case it’s not obvious, the basic principle at play here is that just like selectors are managed with orders of magnitude, this technique employs those to create order of magnitude ‘contexts’. So, if you created a new context with specificity, you can simply trump it, just like anything else.  That is to say that if you really really wanted to pierce through from the outside, you’d just have to make those rules _really_ specific (or just place them after with the same specificity).  The key is that it has the right default behaviors – the calendar defines what it is to be a calendar and the page has to specifically say “except in these ways”.  If you look back at pandora-box.js, you can use the same API to allow the page to add rules, or there is a simple pattern which was also demonstrated in the last codepen example: If the thing you contain has an ID, it will see if there is a matching style tag in your page with a special type <style type="text/theme-{id}">, where {id} is the id of the container. If it finds one, all of those rules will be placed after the component’s rules and will therefore theme in the same way an author customizes native elements.

So, be part of the conversation. Let’s figure out what works and doesn’t in solving the friendly fire problem in CSS. Would the ability to put a lid back on Pandora’s Box be helpful?

Friendly Fire: The Fog of DOM

Any military is comprised of individuals, grouped into successively larger units.  While all of these units are striving for a single overarching goal, they don’t share consciousness and so, regardless of how well trained they are or how much intelligence they have, there is an inevitable amount of uncertainty which is impossible to remove.  This concept is sometimes termed “The Fog of War” and one very unfortunate result is that sometimes same-side damage is caused by an ally.  This is often referred to as “Friendly Fire” or “Blue on Blue”.  In this post, I’ll explain how these same concepts apply in the DOM and talk about how we can avoid danger..

Any large company tends to organize things a bit like a military – individuals in units of units cooperating toward a common goal. If they’re using something like a CMS, one team might define some general layouts for reuse.  Another team creating content and still other teams creating reusable/shared ‘widgets’ which are all assembled together (often dynamically) to create a whole page.

One instance of this might look like the figure below:

A common layout containing a company-wide standard header, main content with social sharing cuttons, an aside/secondary content with shared 'widgets' and footer.

A common layout containing a company-wide standard header, main content with social sharing buttons, an aside/secondary content with shared ‘widgets’ and footer.

What’s interesting about this is that, at an observable level, only the third-party social sharing buttons are not created and maintained by the company itself and need to be treated as a potentially hostile actor.  All of the other pieces are allies in the task of presenting and managing the DOM and any distinction in how they are created, organized and maintained is, at some level, artificial and purely organizational.  Anyone who has worked in this sort of model will have experienced “The Fog of DOM“.  That is, preventing accidental violence against your allies is really hard – it’s simply too easy to accidentally select and operate on elements that aren’t “yours“.  Specifically, it’s not a security concern, it’s a cooperation/coordination concern: The fact that all operate on the same DOM and make use of selectors means that unless there is perfect coordination, even careful use of a selector in a page can easily harm components and vice versa: Friendly fire.

What’s perhaps most surprising is that you don’t actually need a large organization to experience this problem yourself, you just have to want to reuse code that you aren’t developing all at once.

Why is it so damned hard?

Primarily, I think that the answer has a lot to do with how the Web has evolved.  First, there was just markup and so this wouldn’t have been much of a problem even if these approaches/large teams existed way back then.  Then came JavaScript which had its own default global issues, but at least you could scope your code. Then came real DOM and we could start doing some interesting things.  CSS’s aim was to allow you to write rules that allowed you to make broad, sweeping statements like “All paragraphs should have a 1em margin” and then override with more specific statements like “All paragraphs inside a section with the class `suggestions` should have a 2em left margin.”  Within the context of what we were doing, this was clearly useful and over time we’ve used selectors to identify elements in JavaScript as well and our projects continued to get bigger, more complex and more ambitious.

Now, while there are some actions I can take to prevent my component from affecting the page that hosts it, it’s incredibly hard to prevent the outer page from accidentally selecting/impacting elements inside components.  One mistake on either end could spell problems and since they are maintained separately, by different teams, keeping them constantly in check involves an incredible degree of coordination and in the end any shortcomings in coordination usually mean investigation, hackery and guesswork to resolve.

Note again:  This isn’t about security.  I’m not concerned that my co-workers could steal my data, it’s their data too.  My users are their users, my company is their company.  We are allies.  It just needs to be plausible for us to easily collaborate and work together toward a common goal without a high chance of hurting our collaborators.  It still needs to be possible from the hosting page to say “Yes, I mean all buttons should be blue”, it’s just that it shouldn’t be the only (nor necessarily the default) position because it means it’s impossibly easy to harm your allies.

In short:  What the current design means for us, in many cases, is that it’s incredibly hard to “say what you mean” in such a way that it’s likely to avoid the most basic kinds of friendly fire. We have gobs and gobs of selectors stated as document-wide rules which become implausibly hard to reason about.  This makes them hard to write and debug.  Most sites today have hundreds of selectors, many have thousands – any of which could, theoretically apply in many many permutations.  So even if you manage to “get it right” for the time being, when you do have something that suddenly causes unexpected pain (and you will), it’s even more difficult to find out what’s causing it and why because it requires resolving all of those conflicts by resolving the rules in your head without creating others.

Is it “fixable”?

So, is it plausible to imagine a better future?  Is it possible to “fix” this problem, or at least make it very markedly better without completely re-inventing things?  There have been numerous proposals to do so over the years, all of them failed to gain enough traction to cross the finish line.  There were efforts in XBL in the early 2000’s, proposals to allow externally linked CSS mounted/scoped to an element in 2005,  and what would become known as “scoped CSS” is discussed and in drafts in 2006.  This proposal was actually eventually implemented in Chrome behind a flag and then removed.  Removed in part it doesn’t answer all of the questions that another proposal, Shadow DOM did.

We seem to tend to shift back and forth between answers too ambitious or too minimal, and once again, there’s a struggle with agreement.  And so, there’s an effort to step back and see if there is something less ambitious but that we actually can get agreement on. Currently there’s a debate about it going on pulling in two possible directions:  On one side is a group which posits that this is something that should be handled by CSS, on the other is a group which argues that it shouldn’t.  I am in the latter camp, and I’d like to explain why.

Key to both proposals is “isolation” – some kind of boundary at which authors can safely talk and reason about things ‘within a part of a tree’ without implying things outside that part unless they explicitly intend to do so.

Option A: “Handle it with CSS”

This approach suggests that something, perhaps a new @rule could be used to identify ‘isolation points’ via selectors and that subsequent rules could identify an isolation point for which they were relevant.  In fact, however, I believe this creates more questions and problems than it does answers and actually increases the authors’ cognitive load.  This raises some interesting follow up questions for me:

  • Since selectors operate off the whole document, what if I specify that both .foo and .bar should be isolated (and my rules are in that order), and a .bar occurs inside a .foo? Is it isolated as part of the .bar isolation, or only the .foo isolation?
  • Imagining I successfully identified an element as being isolated – would rules loaded or specified inside that element (by <link> or <style> or script) be scoped to that element automatically?
  • Combine the above to questions and it seems that any answers inevitably create a radically new concept in CSS that affects how selector matching is done. While @rules are indeed ‘different’ by nature, at least historically they don’t seem to raise these kinds of issues.  If the new @rule ignores all boundaries to create a new isolation, it does so without any kind of combinator explaining that and it means that the default thing is still sort of an act of violence and you just have to manage avoiding harm through coordination.  If it doesn’t then within your ‘component’ (whether it is a true Web Component or not) you have something conceptually very new and it’s possible to ‘lose’ isolation by something as simple as a class change which seems to largely describe the situation we’re in today.
  • What about the non-CSS end of things?  JavaScript uses selectors too, and has the same kinds of friendly fire issues.  With CSS at least I have dev tools to analyze what rules are in play. When I use a selector via querySelectorAll or something will it be context dependent?  If it uses the same selector matching as CSS, this is a new kind of problem.  It’s never been possible for CSS to affect what kinds of selectors match in DOM, and since it is not reflected in the DOM tree, understanding why this matches or doesn’t requires explanation.  If matching works differently in JavaScript, well, that is kind of confusing and leaves an important part of the problem unchanged.
  • Would this be readable or writable or deletable through JavaScript?  In other words, could JavaScript create an isolation boundary – are we explaining and exposing magic or creating new magic? If they aren’t creatable through JavaScript, it feels like we are going in the wrong direction and even if they aren’t, they’re based on selectors.  In other words, there is a backdoor into it because they are very easily mutable.  This is either new vector for friendly fire or just a continuation of the one we have depending on how you look at it – either way it seems bad.
  • It’s abstract rules.  As I said, at a certain point, it becomes incredibly hard to reason about rules and their permutations – especially when they are super mutable as anything defined by selectors would inherently be.  The bigger the variance and the more you attempt to break up the work, the harder it is to manage them, and when a problem does happen – how will you debug and understand it?

Option B: A New DOM Concept

The DOM is built of nodes with parent and child pointers.  Pretty much everything about selector matching is already built on this concept. If you can imagine a new kind of Node which simply connected a subtree with links that aren’t parent/child, this is a kind of a game-changer. For purposes here, let’s just call it a “MountNode” to avoid conflation with all the bits of Shadow DOM which is essentially this plus more.  Imagine that you’d connect this new MountNode to a hostElement and it would contain a mounted subtree.  Instead of the MountNode being just another child of the hostElement then, it is linked through the hostElement’s .mountPoint property instead.  And instead of the MountNode having a .parentElement, it has a link back through the .hostElement property.  Just something simple like this gets you some interesting effects and offers advantages that none of the other historic approaches (except Shadow DOM) provided:

  • Everything that authors understand about trees more or less remains intact, with the slight caveat that there is a new kind of Node (not Element).
  • DOM inspectors can show this (see Chrome’s representation of “Shadow Root”) and you can easily explain what’s going on.  All of the selector APIs (JavaScript and CSS) work the same way.
  • A mount isn’t linked with parent/child nodes so all existing matching schemes work pretty much “as is” without change because they use parent/child traversal.
  • Its intuitive then to create a combinator in CSS which allows you to select the mount explicitly because that’s just what combinators do today, tell you what to consider during the tree-walking.
  • It’s minimal “new magic”.  We don’t create new things where CSS affects DOM, we don’t raise questions about matching or mutability of boundaries – it’s just a new, foundational piece of DOM that in all other respects works just the way it always has and allows us to experiment with and build higher-level answers.

This last point is especially important to me.  Is it possible to involve CSS and answer all of the questions in a sane way?  To be entirely honest, I don’t know.  What I do know, however, is that today this would involve a lot of speculation, decisions and bikeshedding.  I think this is better vetted in the community – and that any standards org is just as likely (maybe more) to get it wrong as they are to get it right.  Small improvements can have outsized impacts and provide a grounds upon which we can continue to “build” an explainable and layered platform, so I lean toward one that starts low and imperative, with DOM and provides a tool that can be used to solve both the stylistic and imperative ends of it.

What do you think?  Share your thoughts at www-style@w3.org.

Many thanks to all my friends who proofread this at some phase of evolution over the past several weeks and helped me (hopefully) give it fair and thoughtful treatment: Chris Wilson, Sylvain Galineau, Brendan Eich, François Remy, Léonie Watson and Coralie Mercier.  

What Would Bruce Lee Do? The Tao of the Extensible Web.

Recently I participated in a panel on The Standards Process and the Extensible Web Manifesto at Edge Conf.  While ours was the very last session of the day (you can watch the video here), nearly every topic that day called out some mention of the Extensible Web Manifesto.  Privately, there were still plenty of people I met between sessions who privately said “So, what exactly is this Manifesto thing I keep hearing about, tell me more…”.  and my day was filled with discussions at all levels about how exactly we should apply its words in practice or what exactly we meant by x – or specifically what we want to change about standards. 

Given this, I thought it worth a post to share my own personal thoughts, and say some of the things I didn’t have an opportunity to say on the panel.   I’ll begin in the obvious place:  Bruce Lee.


What Would Bruce Lee Do?

What Would Bruce Lee Do? T-shirt from partyonshirts.com who totally agrees with me (I think, they didn’t actually say it, but I suspect it).

Let’s talk about Bruce Lee.  Chances are pretty good that you’ve heard of him from his film work and pop-culture status, but it’s (slightly at least) less commonly known that he was more than just an exceptional martial artist:  He was a trained philosopher and deep thinker – and he did something really new:  He questioned the status quo of traditional martial arts.  He published a book entitled “The Tao of Jeet Kune Do” and laid out an entirely new approach to fighting.  He taught, trained and fought in a way unlike anyone before him. 

He kicked ass in precisely the same way that standards don’t.…  It started by being both intelligent and gutsy enough to make some observations…

There are values in principles, but nothing is too holy to be questioned…

You know, all I keep hearing is “the fight took too long,” “too much tradition, too much classical mess, too many fixed positions and Wing Chun”. You know everything that’s wrong, so fix it. – Linda Lee’s character to Bruce in “Dragon: The Bruce Lee Story” (a fictional, but inspiring scene)

Ok, so we all agree that standards are painful to develop and have sometimes gone very wrong.  From the outside they look, at times, almost comically inefficient, illogical or even self-defeating.  Many comments in our panel were about this in some form:  Too much classical mess – too much Wing Chun.

Bruce Lee saw through the strict rules of forms to what they were trying to accomplish, and he said “yeah, but that could be better- what about this instead”… and opponents fell.

Likewise, standards bodies and processes are not a religion.  Sometimes process is just process – it can be in the way, unproductive – even harmful if it isn’t serving its true purpose.  There are no holy texts (including the Manifesto itself) and there should be no blind faith in them:  We are thinking, rational people.  The Manifesto lays out guiding principles, with what we hope is a well rationed incentive, not absolutes.  Ideological absolutes suck, if you ask me, and Bruce’s approach makes me think he’d agree.

The Manifesto is pretty short though, it begs follow-on and one recurrent theme was that many people at the conference seemed interested in discussing what they perceived to be contradiction in that we have not redirected absolutely everything toward the absolute lowest primitives possible (and for others, a fear that we would).  I’d like to explain my own perspective:

It is often more important to ask the question than it is to answer it perfectly.

Again, the Manifesto lays out principles to strive for, not laws: Avoid large, deep sinks of high-level decisions which involve many new abstractions and eliminate the possibility of competition and innovation – we have finite resources and this is not a good use of them. Favor lower level APIs that allow these things to occur instead – they will, and try to help explain existing features.  Where to draw the line between pragmatism and perfection is debatable, and that’s ok – we don’t have to have all of the perfect answers right now, and that’s good, because we don’t.

Screen Shot 2014-09-28 at 9.54.04 PM

Paralysis is bad.  Perfect, as they say, can be the enemy of good:  Progress matters and ‘perfect’ is actually a non-option because it’s an optimization problem that involves many things, including an ever changing environment.  Realize that there are many kinds of advantage that have historically trumped theoretical purity every time – the technically best answer has never, to the best of my knowledge ‘won’ – and shipping something is definitely way up there in terms of things you need to succeed. More importantly, do what we can to avoid bad. At some very basic level, all the Manifesto is really saying is:  “Hey standards bodies — Let’s find ways to manage risk and complexity, to work efficiently and use data for the really big choices”.

In my mind, the W3C TAG has done a great job of attempting to redirect spec authors, without paralyzing progress, toward asking the right questions: “Is this at an appropriately low level?”, “If it isn’t quite at the bottom, does it look like we can get there from here – or is it what’s here too high-level and overly complicated with magic to be explained?”, “Can we explain existing magic with this?” and, “Is it consistent in the platform so that authors can re-apply common lessons and reasoning”?

I’m sure the there are some who would disagree, but in the end, I think that Web Audio API is a nice example of this kind of pragmatism at play.  There are things that we know already:  We’ve have an <audio> tag, for example, for a while. We have a collected cases which should be plausible, but currently aren’t.  The Web Audio API tries to address this at a considerably lower level, but definitely not the lowest one possible.  However… It has been purposely planned and reviewed to make sure that it gives good answers to the above questions.  While it’s possible that this could lead to something unexpected beneath, we’ve done a lot to mitigate that risk and admitted that we don’t have all of the information we need to make good choices there yet.  It was built with the idea that it will have further low-level fleshing out and that we think we know enough about it to say that we can use it to explain the mechanics of the audio tag with it.  We got the initial spec and now, nearly immediately, they’ve begun work on the next steps.  This has the advantage of steady progress, drawing a boundary around the problem and gives a lot of developers new tools with which they’ll help ask the right questions and through use, imagine new use cases which feed into a better process.  It gives us tools that we need so that efforts like HTML as Custom Elements can begin to contribute in helping to explain the higher level feature.  The real danger is only in stopping the progressive work.

Similarly, it was asked by someone whether Beacon “flies in the face of the Extensible Web Manifesto” because it could be described by still further low level primitives (it might be possible to implement with Service Workers, for example).  Again, I’d like to argue that in fact, it doesn’t.  It’s always been plausible, but prohibitively cumbersome to achieve roughly the same effect – this is why HTML added a declarative ping attribute to links:  Simple use cases should be simple and declarative – the problem isn’t that high-level, declarative things exist, we want those – the Manifesto is explicit about this — the problem is in how we go about identifying them.  Because this is a really common case that’s been around for a long time – we already have a lot of good data on that.  As it happens, ping wasn’t implemented by some browsers, but they were interested in sendBeacon, which – hooray – can actually be used to describe what ping does, and maybe polyfill it too!  It’s simple, constrained, concise – and it’s getting implemented.  It’s enough for new experimentation and it’s also different enough from what you typically do with other network level APIs that maybe it’s fine that it have no further explanation.  If you read my posts, you know that I like to make the analogy of evolution, and so I’ll point to something similar in the natural world:  This may simply be a case of convergent evolution – differently adapted DNA that has a similar-looking effect, but share none of the primitives you might think, and that too can actually be ok.

The important part isn’t that we achieve perfection as much as that we ask the questions, avoid bad mistakes and make good progress that we can iterate on: Everyone actually shipping something that serves real needs and isn’t actively bad is actually a killer feature.  

4921The Non-Option

Bruce had a lot excellent quotes about the pitfalls of aiming too low or defeating yourself.

It’s easy to look at the very hard challenges ahead of us to distill the cumbersome sky-castles we’ve built into sensible layers and fundamentals and just say “too hard” or “we can’t because explaining it locks out our ability to improve performance”.

Simultaneously, one of the most urgent needs is that we fill the gaps – if the Web lacks features that exist in native, we’re losing. Developers don’t want to make that choice, but we force them to.
We’re doing best when we are balancing both ends of this to move ever forward.

Don’t give up.  It’s going to be hard but we can easily defeat ourselves before we ever get started if we’re not careful.  We can’t accept that – we need to convince ourselves that it’s a non-option, because it is.  If we don’t do the hard work, we won’t adapt – and eventually this inability will be the downfall of the Web as a competitive platform.

Jump in the Fire

Good things happen when we ship early and ship often while focusing this way.  As we provide lower-level features we’ll see co-evolution with what’s happening in the developer community, this data can help us make intelligent choices – lots of hard choices have been made, we can see what’s accepted, we can see new use cases.

Some have made the case – to me at least – that we shouldn’t try applying any of this to standards until we have everything laid out with very precise rules about what to apply when and where.  I disagree.  Sometimes, the only way to figure some of it out is to jump in, have the discussions and do some work.

Standards processes and even bodies themselves have evolved over time, and we should continue to adapt where we see things that aren’t working.  It won’t be perfect – reality never is — it’s messy, and that’s ok..

Very special thanks to Brendan Eich and Bruce Lawson for kindly reviewing and providing useful thoughts, commentary and corrections ❤..

Chapters Web Standards Pilot Launched

About a week ago, I blogged about our need to involve the community in new ways on Medium, proposing “Chapters” – local meetups with the idea toward 

  1. Bring people together in local forums to discuss developing standards 
  2. Create a ‘safer’ and ‘easier’ place for lesser skilled developers to learn with mentoring 
  3. Get help reviewing both standards and human documentation around them
  4. To enlist help in looking at/reviewing and developing prollyfills and tests with an eye toward the standard
  5. To ask introduce people to new technology and get them to try to use it 
  6. Most importantly perhaps, to help figure out a way to coalesce this feedback and information and feed it back into standards bodies to manage noise and channels productively.

In this time, we put together a pilot on short notice in Burlington, Vermont (US) and last night, we had our first meeting at the University of Vermont (UVM) – 20 people turned out, including: A W3C Team Member, Darrel Miller who drove all the way from Montreal, UVM 5 students and numerous professionals with varying interests and skills.  UVM’s CS Department graciously sponsored food as well.  I just wanted to take a few minutes and record my own thoughts about what happened, as this is a pilot we hope to emulate in other parts of the world – it’s worth capturing to make those better.

First, I’m fairly introverted and not especially social in real life – I hadn’t expected to be ‘speaking’ as much as just facilitating getting people organized into some groups and helping discussions get rolling.  In retrospect, it’s fairly obvious that I should have expected to do a lot more organization on the first night.  Some people really didn’t know a lot about standards, the interests and skill levels were very diverse (that’s a great thing), it wasn’t clear to some what the goals were (not such a great thing), etc.   Such a diverse audience turned out to be a little rougher than I imagined –  I think if I were going to do it again, I’d plan to have a half hour to 45 minutes just to introduce things and then hope that’s all you need, but be prepared for another 30-45 minutes worth of questions.  In our case, despite a few attempts, I didn’t leave the front of the room for the entire 2.5 hours, which seemed to me like it must have been painful to the audience.  In other words, don’t expect a lot of concrete discussions as much as organization, goal and process agreement, information trading the first night.  Also, tell people to bring laptops and make sure there is wifi in the room that they can access… whoops.  

Despite the hiccups – I’m hopeful that people weren’t too bored and return, maybe even bring a friend.  The good news, even afterward, it seemed that there was genuine interest… Pleasantly, I got a few communications and a hand full of people who stuck around afterward to tell me that they are excited to be involved – so the group will go on, it remains to be seen how the next few will go, but I expect good things once we start digging into it.

If you were in attendance last night and have any thoughts you’d like to share for posterity or have thoughts/advice to others setting up a similar group, feel free to share in the comments.

W3C Special Election

The W3C Technical Architecture Group (TAG) is in the midst of a special election. If you’re reading this then you probably know that this is something of a pet topic for me, and that I think that reforming the TAG and AB is critical to real change in web standards. Generally, I explain who I think the candidates we need are and ask for developers to help make some noise, reach out to anyone they know and help get them elected. If you’re only interested in who I think is the best choice, I suppose you can cut to the chase, but I have some more to say in this election too, so as long as you’re here….

Why an election

First, why are we having an election at all? What makes it “special”? A special election is held when a seat opens up for some unexpected reason, off the normal cycle. In this case, it’s made necessary by the change of employment by one of it’s elected members. According to the rules, no member organization may have more than one representative in each of the elected bodies (TAG and AB). I’m pointing this out because on several occasions throughout the history of these groups, this same thing has happened: Elected folk change employers. Why? It’s simple really… Because the biggest employers with focus on standards belong to W3C and because we tend to try to elect smart folks who are well-respected in the community, it’s plain to see why this occasionally happens. This time, at least it’s led to some good discussion about whether the rule is actually what’s best for the Web, or whether we should make changes. I think we should. In the very least, a simple ‘confirmation’ vote should precede a special election: the rules are there for the people, and when they have implications that make virtually nobody happy, that’s a bad rule.

But that’s where we are: An election to fill a single seat. We have 4 nominees to fill the seat of Alex Russell, who, ironically, isn’t the one who switched employers but rather the one who had the shortest duration of term remaining with that member org (Google).


The Election


The nature of TAG is, at least theoretically, such that all nominees are technically qualified, and that the task is rather to choose who you think is the best choice for TAG at this time. There is a reason I’m bringing this up as well: How votes are cast and counted has been a topic of discussion for some time, and this election provides a perfect illustration of why it matters….

image

Travis Leithead

image

Mark Nottingham

I believe that two candidates are much better choices at this juncture in time than the other two, namely, both Travis Leithead and Mark Nottingham seem like excellent choices to me. They are well known to developers, have good cross-interests with important groups that we need in discussions and seem like they bring the best set of necessary assets as we work to flesh out an extensible platform with a long term vision of standards development that helps them compete and evolve with changing pressures.

But wait, there’s more!

The benefits that any nominee brings to the table can be subtle, but very real. Each AC gets only one vote, and that doesn’t have a lot of expressive power. I think that Travis Leithead has a slight edge in terms of what he brings, but I think that Mark Nottingham stands a slightly better chance of election by merit of his past service and visible social presence. So if I encourage ACs to vote for Travis, because, for example, bringing an inspired Microsoft player to the table is a great thing at this juncture and has virtuous ripple effects, each AC who does is potentially a vote Mark doesn’t get which he otherwise would. The number of ACs who cast votes in the first place is incredibly small, so losing just a couple can easily mean that neither of my preferred candidates get elected, a result that makes me notably less happy than if my “just barely second choice” candidate won. This is the case for preferential voting, it allows me to say ”I prefer this guy most” and “then this guy above others” and so on. The net result is that generally, more people are more happy with the results and spend less time agonizing over the choice.

In a funny way, while the system itself doesn’t work this way, it’s possible to achieve a similar result by way of a compact amongst ACs. If 5 or 6 like-minded ACs discussed who to vote for, and voted together you could avoid most of the incidental effects where neither our collective first, nor second (nor maybe even third) choice is elected.

So, please, encourage any AC you might know to vote responsibly and not only support the candidates I mentioned, but the reforms discussed above as well.

The Extensible Web Summit II: The Web Needs You

On September 11, 2014, Berlin will host the second ever Extensible Web Summit. You can get a (free) ticket from Lanyard and it’s scheduled to coincide with JS Conf EU 2014, so if you are going to be in the area I’d highly encourage you to attend if possible for something very different and important.

A little over a year ago, we sat down and authored The Extensible Web Manifesto which observes failings in how we historically create Web standards and proposes an alternative vision to correct these and make/keep the Web a compelling, competitive and adaptable platform for decades to come. Key among these ideas is the need to involve developers and harness the power of the community itself. 9 months later we held the very first Extensible Web Summit in San Francisco, California.  Unlike many conferences, the summit sets out with a different goal: To bring together developers, library authors, browser implementors and standards writers to discuss and solve problems, hear perspectives, help set priorities, etc. While there were a few quick lightning talks at the opening, the agenda, groups, etc were entirely decided by participants and run bar-camp style.

If you’re curious about how the first one went, here are a few links to posts which themselves have some additional links you can follow.

If you write or use libraries, if you have ever had thoughts, ideas or complaints about Web APIs, if are interested in standards, or you’d like to meet the folks who write the specs or implement in the browsers, if you develop for the Web in any significant way – you should come. Not only that, but I’d encourage you to really participate. At the first summit, several people seemed a little intimidated at first because of the presence of “giants” like Sir Tim Berners-Lee. Don’t be.  These people are all pleasantly human, just like you.  Several good things came out of the first one and with some practice and increased attendance and participation, we gain even more. So, go if you can – and tell someone else about it either way.

Desparately Seeking Jimi: The Web Standards Mountain

Over the past year or so, a number of very smart people have asked me privately or made comments about how I expend my energies with regard to standards: I’ve dedicated a lot of time toward elections to two advisory groups within the W3C (currently AB). Most of the comments can be distilled down to “why bother?” While there are varying arguments, the most prevalent can be summed up as “The groups in question have no real power…” Others argue that W3C is increasingly irrelevant, and that such efforts are a lost cause. More generally, that my time and talents would be better spent in other ways that didn’t deal with seemingly mundane details or bureaucracy. I thought it worth a short post to explain why I do what I do, and why I want you to care too…

Creating standards historically has a way of making one feel a little like Sisyphus in Greek mythology – forever compelled to push an immense boulder up a mountain, only to watch it roll back down again and repeat.  Time and again, we’ve seen struggles: Small groups of very bright people with nothing but the best intent work hard – of that there can be no doubt. They discuss and debate a LOT – progress and consensus takes a long time to arrive, implementations don’t aways arrive at all – and frequently what we get isn’t really usable as we’d like.  A change of venue alone doesn’t solve the problem either: The WHATWG has struggles and conflicts of its own – and has created failures as well. Maybe it’s a smaller mountain, I’ll give you that – but it’s still a big task.  And with the smaller mountain comes a lacks the Titan-sized support of W3C membership.  While I think the WHATWG makes a good argument about the importance of this, it takes a planet to really make it a good standard and having the support of W3C’s membership is still a good thing.  It’s not the fault of the people (ok, sometimes it is), it’s mainly the fault of the process we’ve created based on an outlook of where standards come from. The W3C organization and its processes are geared toward serving this model and that outlook is in need of revision.

A few years ago, several of us converged upon similar ideas which, almost exactly 1 year ago, were written down and agreed to in The Extensible Web Manifesto. It presents an alternative vision –  one that recognizes the importance of developer feedback, contribution and ultimate adoption as well as the evolutionary nature of successful and valuable standards that can both compete in an ever changing market and stand the test of time. Getting a bunch of smart people to sign a document about core principles is an excellent start, but, effectively convincing the larger standards world that it needs to change and embrace important elements of this vision is, to stick with my earlier Greek mythology theme, a Herculean task.

It takes movement on many, many fronts – but interestingly, they all involve people. All of these member orgs, all of the reps, all of the developers out there – it’s just people… People like me and you. The fist step is getting all of those members to pay attention, and then getting everyone to agree that there is a problem that they actually want to solve. It involves realizing that sometimes change requires some brave souls to stand up and make a statement. Sometimes just the act of hearing someone else you respect say it can lead to others standing up too, or at least to opening a dialog.

There are lots of ways to accomplish this I suppose, but it seems efficient if there were some ways to capitalize on the fact that we’re all really connected and, ultimately, wanting the same basic goals. If only there were a way to create a network effect – a call for change and a perception of value that picks up steam rather than simmers out after hitting the brick wall. One way to accomplish this might be give the right people some microphones and stick them in front of the right folks. As the W3C has two major “positions” (Director and CEO) and two advisory bodies (TAG and AB) that have their ear, and, in a more direct way, the ears/role of communicating with technical folks on matters related to the long term architecture (TAG) and on direction /process with AC members (the AB) – those seem like excellent intersections. Getting people elected to these positions involves us reaching out to get enough ACs to vote for them in the first place, electing many gives them perceived volume. It makes people sit up and take notice. It stimulates the debate. It means we have to work together to find agreement about which pieces we are willing to pursue together. It means making sure someone is looking out for developers and finding people who are willing to put in incredible efforts to help make that change happen. – And these are all Really Good Things™.

We’re technically minded people.  We don’t generally like this sort of thing.

So yes, it’s true that I might see more immediately tangible results on a particular API or set of APIs if I very actively focused efforts in that direction, but it doesn’t deal with the bigger problem – the mountain.  What I’d really like to to is help to change the whole world’s mind, it seems like a bigger win for us all in the long run. What I really want to do convince us all to channel Jimi and say….

Well, I stand up next to a mountain And I chop it down with the edge of my hand…

If any of this makes any sense to you – or if you’re just willing to humor me…

If you are an AC in the W3C – lend your voice and vote for a reform candidate (below).  If you’re not an AC, but know one – reach out.  If you don’t know one – tweet or share your support – we’re all connected, chances are pretty good that someone in your social network does.  While I believe that all of the nominees below are excellent, I think there is something critical about sticking one or more developers directly into one of these slots for reasons explained above. If I’m wrong and these groups don’t matter, you’ve lost nothing.


Lea is an actual developer and active in the community — you can find her at talks and conferences all the time. It should be obvious why think some real practitioner voice is important, but she also is an invited expert in the CSS WG and worked for W3C for a while in developer relations — so she has a very unique perspective having seen it from all sides and brings a direct connection to represent developers in the dialog.

Boaz is also a developer and the flâneur at http://bocoup.com/ — a passionate advocate of the open web who has done quite a bit of outreach, hosting (recorded/live) TC-39 and TAG events and whose employees are especially active in the community. He brings a drive and understanding of what it’s like for developers and non-megalithic companies to be involved and has a serious interest and skills with process. (Update: Boaz has since posted about why he is running).

Art is from Nokia — he has been working with standards for a long time, he’s been effective and involved and is outspoken and thoughtful on issues of process, involvement, licensing, etc. and has led efforts to streamline the ability to keep track of what is going on or how to get involved and open things up to developers.

Virginie is from Gemalto and active in a number of groups (she chairs the security group) and I think she can sum up why she is running and why you should vote for her much better than I can. Suffice it to say for purposes here: She sees the problems discussed here (as well as others), brings a unique perspective and has been increasingly involved in efforts to figure out how to help give developers a voice.

David is from Apple and he’s also been working on standards for a long time. He knows the process, the challenges and the history. I’ve not always agreed with him, but he has expressed a number of good things in relation to things mentioned above in his candidate statement which make me especially hopeful that he would be an excellent choice and a good voice to round things out.

While I left him out of my original post, it was an oversight – Soohong Daniel Park from Samsung also wrote an excellent AB statement which is full of great things and I believe would be a great choice as well.  I’ll leave you to read it.