X-Web: Days of Future Past

If you're not a comic book nerd, or a comic movie nerd, I suppose an explanation is necessary: In the Marvel Universe, there is a genetic mutation in some humans called "the X-gene". This gene leads to development of an exotic protein which can radically affect other genes in unpredictable ways. The result is mutants with all sorts of different "super" abilities. This is the basis for the story lines in the X-Men comics. Some humans, without the X-gene, see mutants as freaks, there is prejudice against them. Others would like to recruit them as weapons. Still others are friends. The mutant community is divided too. One group of mutants believe that they are a new homo superior destined to become the dominant species and they're willing to earn this by fear and force. Another group of mutants, the X-Men, led by Professor Xavier, believe that mutants and non-mutants should live in harmony. Mutants powers can even aid humanity. They work very hard for the advancement of peace and tolerance. And then, there are quite a lot of people - both mutants and everydays humans who are torn back and forth somewhere in the middle on a lot of the subtleties that arise. One of the most amazing parts of the narrative is that the leaders of the two groups are actually best friends. They actually agree on much. Most of their followers are not similarly friendly. It's kind of a hot mess, and it reminds me a little of the Web community.

I don't think it should be controversial to say "we aren't really where we'd like to be" on the Web. For some reason there seems to be more division that we'd like. Some would like to paint the future, or even the present, as being dark and desolate...

The future: a dark, desolate world. A world of war, suffering, loss on both sides. Mutants, and the humans who dared to help them, fighting an enemy we cannot defeat. - Professor Xavier

However, I don't think that this is the case. It strikes me that our debates are as much about the past as they are about the future. Given this, it's worth stopping for a moment and assessing where we are, considering how we got to this place, and whether (and how) we will adapt.

Are we destined down this path, destined to destroy ourselves like so many species before us? Or can we evolve fast enough to change ourselves... change our fate? Is the future truly set?- Professor Xavier

For a little over 20 years, we have attempted to develop the vocabulary and features of HTML via a standards body. HTML was designed to give you the structure and function with a default look and feel. Author provided CSS prettied up the presentation. Because of this, with CSS disabled a user should, in theory, get a perfectly usable (if not very pretty) interface. Both HTML and CSS had forward-compatible parsers which effectively just ignore the stuff they don't understand. All of this is designed to make HTML work on the greatest number of browsers.

Our lexicon has indeed increased, though, admittedly slowly. Unfortunately, even after reaching 'standard' even some of the authors don't agree on the proper use and meaning of some elements main is an example of this. In other cases, things that made it through to the "standard" (recommendation) are implemented by no one (the document outline is an example of this), so writing markup assuming that is actually wrong. In still other cases, even when elements pass standards and are widely implemented and experts agree on how they should be used, actual developers misunderstand and use them differently on an all too common basis - address andarticle are examples of this. Some very common UI metaphors still have no native definition to use (tabs are an example of this). Most native elements have some styling limitations, sometimes these are trivial but other times not: select, for example, is unstylable in non-trivial ways - it is incapable of doing multi-line options or including any text formatting inside them. Some, like table-oriented elements, lack the semantics on their own (without ARIA attributes) to be meaningful enough for a screen reader to make sense of in a lot of cases, yet this is infrequently taught.

But there's more... let's go to the video...

In still other cases, combinations of these factors conspire against us, like the universe itself trying to keep us from success. For example: The vast majority of browsers have supported the video element for some time. Someone following lots of conventional advice would think that markup like this would be a pretty safe bet.

<video crossorigin="anonymous" poster="http://cdn.example.com/link/to/poster.jpg">
  <a href="http://cdn.example.com/link/to/video.blah">
    Download my video of a cat playing with a grape.
  </a>
  ...
  <track kind="captions"
    label="English captions"
    src="https://cdn.example.com/link/to/video-en.vtt">
  </track>
</video>

In theory at least, unsupporting browsers would show a link. A user clicking it would be prompted to download it, and then they could play it with their favorite media player (an even relatively recent OS would even help them find one if they didn't have one). Browsers that did support video would just go ahead and use it. With no JavaScript and no author provided CSS at all, a simple, declarative HTML document can give you a pretty valid experience on just about every browser ever made and accessibility would be free.

But actually, that's wrong. In fact, regardless of whether you had a new browser or an old one in early 2016, your native video element would be inaccessible! It didn't really "work" to some extent or other. That is, if the user of a screen reader had an old browser, they could download the video, but not connect it to the captions files.

Ouch, that is suck.

But even if the user of a screen reader had a "modern" browser it was still potentially problematic: IE11 would fail to download the captions, regardless of whether you included the right CORS headers.

Sigh, IE. Double Suck.

Even outside of that, however, the player in all browsers but Chrome was not keyboard accessible.

Triple suck.

Oh yeah, did I mention that you can't style the controls of the player when it is embedded?

Quadruple suck.

But...

We left out an important detail. If this was really the only option, HTML 5 might still be lingering as something we 'hoped' to achieve. The truth is that there are still commonly used HTML 5 bits that are not universally implemented even in modern browsers. The implementation space is, was, and always will be ragged. The aspect that launched a thousand ships with HTML uptake was the polyfill. Key to the polyfill, of course, is JavaScript.

If the Web had an "X-Gene" it would be JavaScript.

Yes, the X-Gene can give you powers that are seriously abused. Yes, people might use their powers in not super ways. They might even do something like try to drop a stadium on the White House...

Please, don't try to drop a stadium on the White House)

But it can also give us powers to do good things, like, you know... Save the world. You might have noticed that there are a number of sites using the video element that are perfectly accessible when used with a modern browser, and styled when embedded as well. That's possible because of JavaScript. JavaScript made a solution that was more accessible possible. It's a nice thing to say "It should work in really old browsers, even without JavaScript enabled" but the truth is, that doesn't match where we are in a lot of cases. Saying "you don't have to use a modern browser or have JavaScript enabled... unless you are disabled" seems like... I don't know, kind of a dick move.

This is the reality of where we actually are as I see it.

Enter: Xavier's School for Gifted Youngsters

X-Web: First class.

In the comics, Professor Xavier runs a "School for Gifted Youngsters". A place whose purpose Marvel's wiki describes as "train young mutants in controlling their powers and help foster a friendly human-mutant relationship." What if we could learn to harness our powers for good? What would it look like? If, as in Days of Future Past, we could go back in time and apply those same lessons, what kind of difference could that make - and is it worth applying them now?

The past: a new and uncertain world. A world of endless possibilities and infinite outcomes. Countless choices define our fate: each choice, each moment, a moment in the ripple of time. Enough ripple, and you change the tide... for the future is never truly set. - Professor Xavier

The Extensible Web Manifesto stresses the duality of ideas that we want developers to write more declarative code, not less and we want browsers to focus on low-level-features. Those things can seem at odds, unless you understand the intent. JavaScript is already a superpower. Very much Web as we know it could not rightly exist without it, no matter how much we'd like to pretend otherwise. Without JavaScript, there are no polyfills. Without JavaScript, there are unresolvable accessibility issues. We might wish it weren't so, but it is.

What good is spending years debating whether we should have a high level element, followed by years of ragged implementation that we couldn't patch, followed by years of unhappiness that it still doesn't give us what we want.

Imagine then, that we could go back in time - low level features exposed and the ability to mint custom elements. Imagine, if you can, that this was part of the Web from Day One. It's a big ask of the imagination, I realize, but it requires no more suspension of belief than time travel or a genetic mutation that somehow grants its possessor control over the weather, and we find that entertaining, so try to follow along...

Would we have the vocabulary that we have today? Doubtful. We'd have addressed these issues with experience by now. This is the ultimate goal of prioritizing the low-level-features -- so that we can actually figure out the high level in a sane way. We want low-level features exposed because we want developers to help us define new vocabulary. Would we have debates about whether you should count on JavaScript? I don't think so. It can fail to download - but so can your page midway through and that's no good either. There are ways we can reduce that likelihood and improve performance too, and we're working on it. It can have an error, but in truth, so can a Web browser's native code. The trouble is that we have no common, good way to currently find and evaluate high quality custom elements. However, if this became common practice - if it had been a thing since Day One - we'd have solved that by now, 25 years in.

Given a better vocabulary, things that currently require authors to write complex HTML, CSS and JavaScript can be simplified. We can say more with less.

That's good for authors.

That's good for accessibility.

That's good for performance.

That's good for slow connections.

JavaScript is not the enemy, it's the the killer asset. I'd also like authors to have to write less of it by harnessing common high level, preferably declarative code.

This is the present I wish that we had. Unfortunately, changing the past is only an option in fantasy. What we can do, however, is learn the lessons and make today the new Day 0, and begin a new timeline. Not disconnected from the past, but with a different path forward.

We have the powers, now let's learn to use them really well. What we really need is a Professor Xavier's Home for Gifted Youngsters where we can go to find the quality X-Web. This problem is the one I'm most interested in. wicg.io is a step in the right direction. More soon, I hope.