HTML5 and What's Next

Google I/O 2011: Wednesday, May 11, 1:45-2:45

Speakers
Ian Fette, Senior Product Manager Alex Komoroske, Product Manager Alex Russell, Software Engineer

Summary
Recent improvements made in web standards and Chrome's support of them, as well as where and how Google is experimenting in advancing these standards even further.

Notes
How did we get here
web started as simple documents (HTML), with simple style (CSS), and simple behavior (JS) now people are building real apps on the web like Maps and Gmail the platform is still designed for documents - really cool apps require being a web development ninja

Expand your Vocabulary

It's important to let you be more expressive on the web and the types of apps you're able to build.

Filesystem (?)
Server Side apps are made up of multiple files structured in a logical way. Client side data is no different. HTML5 Filesystem API allows you to structure and store data on the user's computer Notable changes since Chrome8 - renamed a few APIs - initially only worked inside the context of Chrome apps and Chrome extensions - as of Chrome 13, these APIs will be available for all web pages - to date, all Filesystem APIs have had a 5MB default quota - Now introducing a modifiable quota with the StorageInfo interface - two types of quota: temporary and persistent - most applications will use temporary quota, since affords lots of space. However it is managed by the browser, and may be deleted if necessary. Temporary quota does not require explicit consent from the user - persistent quota allows for long-term guaranteed storage and requires user consent

WebSockets
WebSockets is a simple API for bidirectional client/server communication over a persistent connection - WebSockets has matured since last year and is now in "Last Call" - adding support for multiplexing to allow for multiple connections - 3D - WebGL enabled in Chrome 9 - initial 3D CSS support in Chrome 12. this allows for simple visual flair that doesn't require all that WebGL is capable of

Say what you mean

We now have a large expressive vocabulary that is very precise, but makes simple things more difficult than they should be. Why require an encyclopedia when all you want to express is a short story? Moving more functionality from your application to the platform mean... - reduced maintenance burden - smaller payload on the wire - a more succinct message will transfer faster - make execution time faster - native code will always be faster than interpreted code - reduced complexity and cognitive overhead - all the time spent building (or learning) a framework is time NOT spent on your actual application

What needs changing?

CSS Variables
variables in software are not just placeholder, they are descriptive and become the language of the application. syntax proposed to the W3C working group: @var $light #7a7; looking to add support to modify values via Javascript as well.

CSS Mixins
factoring out common sub-expressions. Media queries allow rules to be enabled or disabled for certain environments, but they don't allow an easy way to scope CSS rules to a particular portion of the DOM. analogous to macros or functions in other languages. These are particularly important for supporting vendor prefixed CSS rules such as -webkit-linear-gradient in a scalable way. proposed syntax: @trait backgroundLinearGradient($from, $to) { background: -moz-linear-gradient(top, $from, $to);

background: -webkit-linear-gradient(top, $from, $to); } .themedButton { border: 1px solid $themeLight; @mixin backgrounLinearGradient($veryLight, $light); }

Nesting / Hierarchy
before: .slide.image { /*..*/ } .slide.image .credit { /*..*/ } .slide.image .counter { /*..*/ } ".slide.image" becomes a prefix that we include on all of our rules to mimick our document structure. after: .slide.image { /*...*/ & .credit { /*...*/ } & .counter { /*...*/ } } new "&" character means to repeat the selector from the containing block composed together all of these make CSS a much more expressive language that is more maintainable, smaller on the wire, and easier to understand.

CSS Animations
today's syntax is somewhat unclear - transitions are "edge triggered". they define change in value over a given period of time. they help you interpolate values between states - animations define visual effect to be executed when a given state is reached better syntax for animations, expressing them as a set of state changes in a graph: button { state-interaction: normal; } button:active { state-interaction: pressed; } @transition button { over: state-interaction; from: normal; to: pressed; animation: fancy-press .1s;

interrupt: reverse; } Today CSS animations must be fully specified, for example the exact pixel size at the beginning and end state. A better approach would be to parameterize our CSS transition rules.

Improving Javascript
Recently luanched traceur, a Javascript to Javascript pre-processor.

Model-driven views
HTML mixes models and views. For example an <input> element has both a model and a visual representation, and the two can't be separated. The semantic nature of HTML markup is very good at expressing a data model. templating and data binding are actually the same problem. sample syntax for a new proposed HTML template element: <template iterate="items" id="t"> <li>{{name}} <ul> <template ref="t" iterate="children"></template> </ul> </li> </template> Model driven views allow the manipulation of date models and have them immediately rendered in the DOM without having to make any explicit request.

When can I use this ?

To being, we have a number of projects that allow you to start playing with some of these features: http://code.google.com/p/traceur-compiler http://code.google.com/p/experimental-css http://code.google.com/p/mdv As the ideas mature, we will be iterating and working to add native support in Chrome.

Q&A
How does the AppEngine channel API compare or relate with WebSocks
Ian: browser channel opens two connections, one for downstream and one for upstream. You also have to close the connections in various cases to prevent data from getting cached inappropriately. Reopen those connections adds all the HTTP overhead each time.

WebSockets is designed to address the same use cases but in a much more efficient way.

In a MDV, if you try to edit the DOM, are you editing the template?
AlexR: we're trying to move toward a world where you're actually modifying your data rather than the DOM itself... that is just the visualization of the data. Templates cannot be live edited.

How can the filesystem API and the HTML5 audio or video tags interop with each other?
Ian: It would be possible to construct a data: URI that contains the data. Better would be to use the FileReader class to get a handle to a file and work with it, regardless of where the data came from. We want to support fopen fread fseek style APIs for the web in a safe way

With the templating system you demonstrated and all of the data living in JSON, what are the SEO implications?
AlexR: there's no reason why the data has to be JSON, it could just as easily be HTML. The other question is how smart can the web crawlers be.

How far do you intend to go with conditional logic in templates?

AlexR: the pipe filter syntax similar to django will make a lot of conditional logic possible