“The foundation of the web platform” is very confusing

Two days ago Alex Komoroske, Product Manager of Chrome released a series of videos about the Web Platform accompanied by links to some of the demos and the standards and proposals it uses. I was excited about this as in a world of shiny HTML5 demos and lock-in examples (“you need this browser to see this”), I was looking forward to an agnostic view of what the web platform gives developers. After all, Google did a great job with their Web App Field Guide released a few weeks ago.

Now the videos come with an explanation that is needed to understand their approach:

A few weeks ago one of my developer friends was gushing about the capabilities of his favorite native platform. After every point I felt obliged to point out that the web platform either already had or was actively developing precisely the same capabilities—and then some. He was incredulous. “Prove it,” he said.

I get this request a lot as well, and in most cases I am happy to show what the web can do that native clients can’t. Comparing them on the same level doesn’t make much sense to me. It is like comparing a Formula 1 car to a hovercraft. One is built for a specific purpose and to excel there and the other is meant to adapt to change in the environment. Native client development thrives on abstraction, on the web we build very close to the live code. The web is not a fixed environment where you know what browser and configuration users run your code in. Promising developers of thick clients that they have the same control on the web that they have in their world is a course of action that is hard to go through with.

According to this series, it seems that what we have right now is a solid foundation that is complemented by new standards that need agreement and then will form the platform of the future:

The web platform is composed of a large collection of interoperable standards that represent a solid foundation for building powerful apps. New standards are born on the cutting edge, where various organizations experiment with new capabilities. Those capabilities that capture the imagination of the broader community may eventually become a formal part of the web platform.

This all sounds grand – if a bit weird – as we have been building web apps for quite a while and before that web sites for even longer. So there is a foundation to be aware of and also an infrastructure of outdated browsers and setups that needs to get something if we offer our apps there.

So let’s take a look at the first video for now: Meet the web platform – Building on foundations

Sorry, here’s the web

The video starts with an apology. In order to convince someone who sees the web as a not mature platform, that is not too good a start, but at least it is honest. There is an explanation that some examples only work in Chrome, others will be implemented in Chrome and others are still being defined. It then continues to say that we need a bit of magic to make things work – setting flags, extra code and so on. The goal is explained that this is a preview from the cutting edge and it should get people excited about the web as much as Alex is.

Wait, hang on. This is called “building on foundations” and from the very beginning we are told that we will see what Chrome can do and that it needs hackery to even work in there? What about other browsers? Like the one that comes with Windows or the one in OSX? This is not the web platform I would put my trust in.

Hello world!

It continues with a great message – the low barrier to entry of the web as a developer platform. Open an editor, save it as .html and open it in a browser and you go. There is no compile step. This is an important message to give.

The example is “hello world” without any HTML around it – from the very get-go developers are being conditioned to expect the browser to do magic under the hood to make things work. HTML is not explained, not what a DOCTYPE does or why it is important to mark things up in order to make the browser turn them into what you want to have.

The first code example (1:22) shown is introduced as a “little toy”. A functionality to make a label show up after a checkbox showing in green that the checkbox is checked and in red that it isn’t.

Here is the code for one of the checkboxes:

<style>
  .toggle label {
    background-color: green;
  }
  .toggle.disabled label {
    background-color: green;
  }
</style>
<div class="toggle">
  <span>Flux Drive</span> 
  <input type="checkbox" checked 
onclick="this.parentElement.className=(this.checked)?
'toggle':'toggle disabled';
this.parentElement.querySelector('label').textContent=
(this.checked)?'ON':'OFF';">
  <label>ON</label>
</div>
[...]

Alex explains that this works, is only a bit of styling, and a small script. The main issue here according to the video is that when you repeat this, you add a lot of code and you might to forget a label or something and then it breaks.

Building blocks and modules for the web

The video then goes on to explain that every other platform has building blocks to build on top of them but HTML doesn’t. It explains that there are JavaScript libraries to do that but they are immediately dismissed as “not being robust”.

Without missing a beat, the video then explains that Web Components are the solution for that – a “new standard” (actually a “Extremely early draft” only supported in Chrome 19 when you turn on a flag). So the code that might cause trouble gets replaced by a template and an is attribute.

<link rel="component" href="toggle-control.html">
<div is="toggle">
  Flux Drive
</div>

With the component being:

<component>
  <element name="toggle">
    <template>
      <style scoped>
        label { background: green; }
        .disabled label { background: red; }
      </style>
      <div>
        <content></content>
        <input type="checkbox" checked 
onclick="this.parentElement.className=(this.checked)?
'toggle':'disabled';this.parentElement.querySelector('label').textContent=
(this.checked)?'ON':'OFF';">
        <label>ON</label>
      </div>
    </template>
  </element>
</component>

Regardless of this not rendering the SPAN in the first example, let’s stop here and see what this small piece of code does to the notion of an “open web platform agreed by several players”.

I understand that this is aimed at application developers used to other environments and these people want to see a module system with reusable components. We have these working fine in browsers using JavaScript libraries at the moment – YUI, jQuery and others doing a great job. This is a foundation we could be promoting as the source where we learn from and try to shift into native support. So to say showing what works and where it can go – a foundation, if you will.

Small code, lots of problems

Let’s break this down:

1. We write awful, hard to maintain inline code that is fragile as it expects HTML to be available rather than testing for it – violating the separation of concerns principle of HTML design (seriously, whoever writes that much inline code that does DOM traversal and checks twice for the state of the checkbox either generates their code in a loop or copies and pastes without knowing what they are doing.)
2. In order to avoid breaking this, we don’t replace the code with something more sensible, but instead we move it into a template
3. By using the template, we break backwards compatibility – one of the very basic principles of HTML5.
4. In essence, we solve the issue of developers – using bad code – over the needs of our end users, violating the priority of constituencies principle of HTML5 (users > authors > implementors > specifiers > theoretical purity).

All of this only working in Chrome right now – after setting a flag.

From the very beginning this code example is a very contrived way to get into Web Components. The irony is that the code violates basic principles of what we do on the web to build accessible and stable solutions.

Making the example web code

The whole inline code could be replaced by a single event delegation:

document.addEventListener( 'click', function( ev ) {
   var t  = ev.target;
   if ( t.type === 'checkbox' ) {
     var c = ( t.checked ) ? 'toggle' : 'toggle disabled';
     t.parentElement.className = c;
     var tx = ( t.checked ) ? 'ON' : 'OFF';
     t.parentElement.querySelector('output').textContent = tx; 
   }
},false);

Engineers understand events. Inline code is for the lazy and confused.

What is this output thing here? Well, the HTML of the example does not make any sense as it is now. The job of a label is to link a text with a checkbox, to, well, label it. This is supported by assistive technology and browsers. In a browser the main benefit is that you can click the whole text and not only the checkbox. So, if you want to use JavaScript for this functionality, then an output element would be more appropriate:

<div class="toggle">
    <label for="drive">Flux Drive</label> 
    <input type="checkbox" id="drive" checked>
    <output>ON</output>
</div>

Funnily enough, there is actually no need for JavaScript at all. By using the proper CSS and a span element we can do exactly the same effect:

<style>
  input + span::after {
    content: 'off';
    background: #c00;
  }
  input:checked + span::after{
    content: 'on';
    background: #0c0;
  }
</style>
<label for="html">I actually know HTML</label>
<input type="checkbox" id="html">
<span></span>

And if we align the checkboxes in order to not make this a UX nightmare we won’t even need the SPAN.

<style>
input + label::after {
  content: 'off';
  background: #c00;
  margin-left: 1em;
}
input:checked + label::after {
  content: 'on';
  background: #0c0;
}
</style>
<input type="checkbox" id="html">
<label for="html">I actually know HTML</label>

You see, the on and off labels are just visual fluff. They are not needed. The checked checkbox gives the same information. When we do things that only make sense as a visual aid, CSS is the technology to use. Then we can’t even forget a label as it gets generated only when the browser supports it.

I know, this is “just a quick toy demo”, but if we want to promote the web as a serious platform we should play it to its strengths and not start on the notion of “write whatever, the browser will magically sort out what you do”. 90% of a good web solution is thinking it through before you code and use what already works and build on top of that.

Tab controls – a real web components example

The next demo makes more sense as a web component – it is turning a few articles into a tab strip. There is no HTML for that, true (we dropped the ball when we defined the semantics of HTML5, we defined menus but not tabs. In WAI-ARIA on the other hand, there are tabs amongst many other widget controls, which could be re-used in web components).

The solution is scrolled through fast explaining there is a “a bit of CSS” and a “bit of JavaScript” – hey this could be interesting! How about some info on the how?

We’re done with the web – here’s a debugger

Instead, the video goes on immediately to introduce the Chrome web inspector for debugging explaining that as we use web components we will see the component code in the inspector and not the code that is generated “to make this work”. We learn as an aside that there are spans and divs being generated to make the tab control work. That is new. So what happens when the generated code fails? Where can I debug and fix this? Apparently, this is a feature and not an issue as “component authors will know that their stuff works as nobody can muck around with the internals of the components”. So much for view-source as the power of the open web.

CSS can do amazing things Apple showed you some years ago

Next up we see that all these components are HTML and can be styled with CSS. the demos are blurring them with the webkit-only blur filter and rotate them in 3D space. This is impressive, but which app spec has these as deliveries? How about showing that I can colour tabs alternately or define a “you are here” state in CSS?

HTML editing in the browser

We then learn how to replace the web component tab strip we just created with a video to rotate in 3D space. This is there to show the web inspector HTML editing. Right after we got to know that our components are safe as nobody can mess with them.

There really are applications for this

Next is the SXSW 2011 BeerCamp web site as an example how the things we just saw can be used in a real web site to show amazing effects between pages.

Application layout

Next up Alex brings up a very important point – layout of applications and that absolute positioning and floats are hacks. He shows off flexbox layouts and how they can be used to allow for icons to realign themselves. The code again is scrolled really fast and declared “simple as there are no floats or absolute positioning” – presuming you know how to do flexbox already. We learn that there is no script and all is done declaratively in CSS. That’s a very important and good message. Separate them out.

Debugging on phones

Next up is showing the same demo on Chrome for Android beta on a phone (you can try this – if your phone runs ICS). We also learn that developer tools now connect to the phone and we can debug on the desktop what is happening on the phone. Opera Dragonfly had that for quite a while but it is very good to show to developers who are tired of compiling.

More stuff in the developer tools

Next we learn about timeline in the web inspector showing us when what is rendered and what things are loaded. For debugging this is very important, but to show off the capabilities of the web of the future, I am not sure.

Experimental typography

Next is advanced typography and text rendering showing off the CSS Exclusions defined by Adobe and only supported in a webkit build available on their site.

The video concludes with that “all of this shows how the web is improving upon its core strengths”.

Summary

I for one am confused. If all of the demos shown here were done by someone in Mozilla I’d have asked to re-write the script.

This video doesn’t explain much about the web platform for development – it is an ad for Chrome. It even mentions “the chrome suite” which I hadn’t heard before. It is a very confused script that tries to pack in far too many things in seven minutes.

As a foundation, we now know that there is a standard that nobody has agreed on but people are interested in that might give you modularity and reuse of components. There is no depth to these examples.

Instead we get to know how to use the debugger in Chrome and how to blur things and rotate them in 3D. We also learn that we can edit a HTML document in the browser. That has only marginally to do with the web as the platform unless we could allow end users to do that in a CMS fashion (contenteditable anyone?). We then briefly hear about application layout before we go back to the editor to debug things on the phone – just to show that it can be done. We hear more about the developer tools and then learn that in the future we’d also have typography.

There are a lot of great ideas and passion here, but the passion is for a browser and its tools, not for the open web platform. I would really love to hear some feedback from developers who saw that as an introduction to building things on the web. Right now these are a lot of promises and remind me of videos I have seen showcasing .NET development in Visual Studio or Flex development in Flexbuilder.

I would love this to be better – the idea is great. Have small videos explaining the benefits of the web. As it is I am overloaded and confused. This is not me saying this because it is Chrome. I have been asked several times to show off debugging tools in my talks about HTML5 and I refused as they are different issues. You can show off debuggers explaining what code does and how it works, not to randomly add things in the page.

This video would have been much, much better explaining one thing at a time. How about this:

• Basics of the web – no compilers, add code run it in the browser
• Styling things in CSS - create what is only visual. Show the power of CSS (animation, transition, transformation)
• Boundaries of CSS - flexbox is a solution for app needs, more typo control coming
• Boundaries of HTML - there are no building blocks to reuse
• Web components proposal with a demo that does things HTML can’t do
• As debugging is a large part of development, here is a debugger – look it even works on a phone

I’d be happy to work together on this. I will not do a “use Firefox as the web platform of the Future” as this is the same approach that led to all the IE6 only apps we have out there and the need for Chrome Frame. The web platform has various players and it is up to the end user to decide what browser to use. This will in a lot of cases be the one that comes with the OS.