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.

One of the big questions I repeatedly got at events lately is this:

Is HTML5 ready yet?

The answer is no, because HTML5 is not a bowl of spaghetti that you know when they are ready by flinging them against the wall. HTML was never “ready” and will never be “ready”. It can be “the right choice” and it will be “an exciting opportunity”, it might also be “a dirty hack that works right now” or a “semantically valuable resource that can be converted to whatever you want”.

You see, even HTML4.01 or XHTML for that matter was never “ready”. Sure, the standard was agreed on and you could put in your project deliveries that your web site will be compatible with it, but in most cases this was a lie.

Standard compliance on the web is a means to an end. It made it easier to track mistakes and it made your work understandable by other developers but when it comes to delivering web products, it had not much impact. As web developers we were constantly asked to build interfaces and apply designs and interactions that were never defined in the standard. Which is why we had to find ways to do that which in a lot of cases meant abusing the standard.

We used spacer GIFs and   for padding and margins before CSS got support, we used tables for layout, we used image maps, we used image replacement, we used HTML generated from JavaScript for different browsers and whatever it took to get the best out of what we had in order to achieve the goal we set ourselves.

The goal was always the same: deliver the best possible experience in an unknown, always changing environment.

You don’t know what browser in what setting on which operating system with which security settings the end user has. You also don’t know what ability and connectivity the end user has. An HTML5 app is meant to run on a desktop with 1440 resolution, quadcore processor and lots of RAM on a 10mbit line but also on an old smartphone in the middle of nowhere with a flaky connection. And this is where HTML/CSS and JavaScript excel: you can build apps and sites that adapt to the needs of the environment they run in. This always meant a mix of various web standards and approaches.

The big issue we have now is that with a lot of HTML5 marketing this goal has been washed out and people expect more control from HTML5. The incredibly brain-dead message of “HTML5 is the Flash killer” (yes, I said it) clouds all of our judgement and stands in the way of great web applications. In my book, Flash doesn’t need killing at all.

What needs killing is the close-minded limited way we think about web applications. Flash gave people the impression that they can control the web and define what the end user sees. This is limiting the web and does a disservice to your product. When building web applications you should focus on reaching as many people as possible and not force-feed your design or interaction to all and deliver an agreement that leaves everybody unsatisfied. The recently released Web App Field Guide by Google brings it to the point: HTML5 has enabled developers to break free of the limits they were used to when building web applications.

HTML5 is the evolution we needed in web technology to build apps instead of documents. HTML4 was not the right technology for that and XHTML was a bust from the very beginning as it was too rigid for the web. We now have ways to store information on the computer, we have access to multimedia and we can create visuals in the browser. HTML5 is not just markup or “watered down XML”, it includes JavaScript APIs and defines how a browser should behave if it wants to be called an HTML5 compliant browser.

The main difference between HTML4 and HTML5 is the direction of innovation. In the HTML4 world we had a standard that was inadequate to what we needed to build. That’s why browser vendors build their own extensions on top of it and created a total mess for developers. In order to achieve our goal we had to write code for each of the browsers out there, rather than writing HTML. This was awful and caused a lot of people to chose the simple way out and write exclusively for one browser. In the past this was Internet Explorer 6 and this is why we now have a lot of government and enterprise IT environments that don’t upgrade to newer browsers. This holds us back.

HTML is now a living standard. This boggles the mind of a lot of people – how could a standard be living? Well, to me, this makes a lot of sense. The needs of the web are constantly changing. A few years ago nobody predicted – least of all the standards bodies – that we will consume the internet on mobile devices with touch interfaces. What will happen in the nearer future? Who knows? Face and motion recognition?

HTML5 is defined by browser makers tinkering and innovating and feeding back to the standard. Then other browser makers weigh in and we make it an agreed standard. This avoids the issue of developers having to build things for browsers and it means the standard will not fall behind. The main power of the internet is that you don’t need to write the same app several times for different environments and by agreeing amongst browser makers we make sure that there will not be a new IE6 situation.

So no, HTML5 is not ready and will never be – and that is a good thing. We have a standard for the web with all its change and adaptation and not a software standard that expects 5 year turnaround times in innovation.

Discussion on Google+ – Discussion on Facebook

I just spent a week and a few days in environments that are not the web savvy folk I normally hang out with – Mobile World Congress and CEBIT - and it was fascinating.

What fascinated me was not only that the technology approach there is totally different from ours – I was most amazed just how skewed the view of HTML5 in these environments is. Repeatedly I had to answer questions that were not of technical nature but actually simple regurgitations of either marketing BS about HTML5 or marketing BS against HTML5. In any case, it was mostly about blanket statements and in order to keep my sanity I thought I answer a few here.

So here are a few of the questions I repeatedly got and I will go and answer them from my point of view in a series of posts:

• Is HTML5 ready yet, and if not, when can we use it?
• Is HTML5 the Flash killer?
• When will we get HTML5 tools?
• HTML5 means you always have to be online, right?
• How can I protect HTML5 content?
• Will HTML5 ever match native performance?
• Will HTML5 ever have great UX like native solutions have?

All in all I found that most of the questions were about immediate implementation. There seems to be not much tinkering going on in the mobile world. People expect SDKs, IDE integration and defined ways to build and distribute apps. The main goal is to make money, build one thing and have it as a revenue stream. Or to build something, cause a quick hype around it and move on quickly to the next one. There is not much time to wait for technology to evolve and things to change. And that clashes with a few HTML5 ideas. Exciting times.

The other day I was asked to write a foreword for a book on CSS by someone I inspired, so here is what I wrote.

When Cascading Style Sheets got supported by browsers, a lot of things changed. I remember the first article I read about them was saying that using them could increase the speed of your web sites tenfold and your development and maintenance time will be cut in half.

That was totally true, as this was a time when connecting to the internet sounded like Dubstep sounds now and 56k connections were luxury. In order to style things we needed images, background colours, table layouts and font elements. And of course lots and lots of spacer gifs and   to create padding.

Fast forward to now, and you will see that it is almost impossible to think of any web design without CSS. In the last year alone we got so many cool new features to play with that animation and transformations with JavaScript can soon be as forgotten as spacer gifs are now. We can set colours in various formats, we can add our own fonts, create patterns and gradients, we have transformations and transitions and we can define animations. We can generate content in CSS in case we need it only for a visual effect and we have all kind of interaction selectors when the user hovers over something, clicks it or even selects text in the page.

A lot of this comes with a price: we have to repeat a lot of settings to support all the browsers (and those coming in the future) and there are differences in implementation that can make our life harder. This, however, is a temporary problem. Sadly enough it doesn’t stop people from repeating mistakes of the past like favouring one browser without providing fallbacks for others and older ones. We did that already with IE6 which is why now a lot of our products are hard to maintain and upgrade.

In general, the ubiquity of CSS in our development world made it a bit less magical. We actually see it as a given and there is hardly any thought and documentation out there how to write well-structured, clean and simple CSS that does the job. Our high speed connections, caching and a plain disregard of CSS amongst “real developers” made our style sheets a dumping ground rather than getting the same love we give our Python or JavaScript. Want proof? Github, a rather simple looking site loads 400KB of CSS in over 20000 lines of code. Facebook used to have over 2MB of CSS before some friends of mine re-engineered the CSS using an “object oriented approach” and last but not least a new bug in Internet Explorer got discovered: it only loads 32 external style sheets before giving up.

Now, as an old-school, hand-craft developer I shook my head at the mere thought of 32 style sheets, but the fact of the matter is that CMS and other systems create a sheet for each module on a large site and instead of concatenating them just add them to the template as a new link element.

I once wrote a 300 line CSS document for a massive, international web site. When I left the company, I looked at it half a year later and it grew to a whopping 3800 lines with massive selector chains and very specific class names like “headingright3c6bold”. In order to create a visual change the poor maintainers who obviously had no clue how CSS works (or didn’t care) added random HTML elements to the templates to have a handle to increase the specificity and many other crimes against CSS were committed before my very eyes.

That is why I am happy that there is a new movement, a desire to clean up the CSS we write and make it snappy and fast again, going full circle to the original promise of CSS.

This book is part of this movement, and the writer shows insight, foresight and interest in a topic that many consider too confusing to care about. I for one am very happy to see it come out and hope that by reading it you get inspired to put the art and the magic of speed back into your style sheets.

Every since I played around with the sidebar here on the blog giving it a slight tilt in 3D I get a lot of questions how it was done. Well, there is no dark magic at play, just some 3D CSS transformations and a transition.

So I recorded a quick screencast showing you how it is done (also showing some of the Firefox devtools). You can see it on YouTube or in higher quality on vid.ly.

The code is very simple:

<div class="yui-b" id="sb">
  <div id="rot">
    ...
  </div>
</div>

#sb {
  position: relative;
  -webkit-perspective: 800px;
     -moz-perspective: 800px;
      -ms-perspective: 800px;
       -o-perspective: 800px;
          perspective: 800px;
}
#rot {
  -webkit-transform: rotateY(-15deg);
     -moz-transform: rotateY(-15deg);
      -ms-transform: rotateY(-15deg);
       -o-transform: rotateY(-15deg);
          transform: rotateY(-15deg);
  -webkit-transition: -webkit-transform 1s;
     -moz-transition: -moz-transform 1s;
      -ms-transition: -ms-transform 1s;
       -o-transition: -o-transform 1s;
          transition: transform 1s;
}
#rot:hover {
  -webkit-transform: rotateY(0deg);
     -moz-transform: rotateY(0deg);
      -ms-transform: rotateY(0deg);
       -o-transform: rotateY(0deg);
          transform: rotateY(0deg);
}

You can play with 3D transforms using the 3D CSS Tester and don’t forget that this month’s Mozilla Dev Derby is about 3D transforms.