Built on Web Components, and inspired by Model Driven Views, Dart's Web UI library is now ready for testing. This early release of Web UI supports dynamic templates, live one-way and two-way data binding, and custom DOM elements. Web UI also includes a compiler that makes these features available to all modern browsers today.

Web UI helps you build declarative apps that have cleaner semantics and structure. You can build and use custom elements like that encapsulate their style, behavior, and structure to hide implementation details like deeply nested HTML tags. Just like HTML tags, these new tags (aka custom elements) can be nested, extended, and shared with other developers.

Web UI also automatically keeps the HTML page and data models in sync with one-way and two-way data binding. Simply declare, in the DOM itself, the bindings between Dart objects and page elements and let Web UI take care of the details.

Here is a small snippet from a simple TODO app that shows some of these features, including:

(1) linking to a custom element
(2) declarative event handling
(3) templates and iteration
(4) data binding with a custom element

To see Dart Web UI in action, we've ported the ubiquitous TodoMVC sample app:

Getting started and installing Web UI is easy with pub, the Dart package manager. Simply add the web_ui package to your list of dependencies and run pub install. Once installed, you can even configure Dart Editor to watch for changes and automatically recompile your Web UI apps for quick and easy edit and reload development cycles.

Since we launched Chrome, the team has continued to work on ways to make it fast and simple for people to use. To that end, we’re going to begin testing variations of Chrome’s New Tab page (NTP) in which a user’s default search provider will be able to add a search box or otherwise customize the NTP. While you can search straight from the omnibox in Chrome, we’ve found that many people still navigate to their search engine's home page to initiate a search instead. The goal is to save people time by helping them search and navigate the web faster.

We’ll also allow search engines to display the user’s search terms right in the omnibox, which avoids the need for a second search box on the results page. This new capability, along with other ways to improve search suggestions, are exposed in a new Embedded Search API, an extension of the existing SearchBox API. Search engines can implement any part of the specification if they’d like their users to experience a customized variation of the NTP experience.

Starting today, a small set of users on Dev channel on Windows and Chrome OS, who have Google selected as their search provider, will begin seeing variations of the new experience. Mac will be coming soon. We look forward to your feedback and bug reports, which you can file against the InstantExtended feature on crbug.com.

Many popular applications today help users consume, share, manage, and edit media content, as evidenced by the rise of web apps like Google Play Music and YouTube. For Chrome packaged app developers, the new Media Galleries API introduces a simple way for apps to access media stored on a user’s device (with the user’s permission, of course).

To use the API, you first have to determine what kind of permission your app needs to access user’s media:

• read-only: allows media content to be read, but not modified 
• read-write: allows media content to be read and modified 
• add-files: allows media to be added to the galleries but prevents modifying existing media files. 

Currently, only read-only access is supported. Support for read-write and add-files will be introduced in a future release.

To retrieve media content, use getMediaFilesystems(). If this is the first time your app is accessing the user’s media libraries, the system will prompt the user to grant access:

You can also make your app explicitly ask the user to designate specific galleries. This is useful if, for example, your app is only interested in pictures. Once access is granted, your app can then retrieve a list of LocalFileSystem structures. At that point, you can use the W3C FileSystem API to access the media gallery content.

NOTE: The file system APIs will only return files that the Chrome platform natively supports, and only the asynchronous version of the FileSystem API is currently supported.

Sandboxing is a layer of security that Chrome places between attackers and their computer, aiming to isolate an attacker who has successfully exploited a vulnerability. When contained in a sandbox jail, an attacker will typically look for porous or fragile bits in the walls to throw rocks at. That is, he’ll try to gain additional privileges by taking advantage of other vulnerabilities. Our job is to make the virtual walls of the sandbox as strong and impenetrable as possible.

One juicy target for attackers is the operating system’s kernel: a large and complex code base. The latest stable version of Chrome introduces a new layer of sandboxing of Chrome renderers for the 64-bit versions of Chrome OS and Linux, based on a new kernel feature called seccomp-bpf. With seccomp-bpf we’ll install a small filter in the kernel that will quickly reject many of the rocks thrown by an attacker. A simple example: if we know that Chrome renderers don’t need a system call such as vmsplice, or a facility such as “inotify”, we can just deny them completely. We use a broker process model to keep the list of allowed system calls small.

Installing this filter in the kernel improves the security of our users. But it is just the beginning: using this new facility, we’ll continue to make the sandbox safer.

This new sandbox layer is automatically baked into the latest version of Chrome OS. On Linux, you can check by going to chrome://sandbox and look for “Seccomp-BPF sandbox Yes”. If this is not available, ask your Linux distribution to include and enable seccomp-bpf in its kernel, as Ubuntu has done since version 12.04.

As always, you can report bugs and issues here, by clicking on “New issue”.

Whether your web app involves scrolling down a long list of news headlines or a game with flying birds and crumbling structures, you want your web app to look as smooth as native apps. It used to be tricky to chase down the cause of animation jitter and lag in user actions with Chrome Developer Tools. This is why we’ve added the Frame Mode to our Timeline panel to help you pinpoint offending long frames and understand what’s causing them to run slowly.

So, what’s a frame? A frame includes all the tasks that the browser needs to perform in order to update the screen upon a user action or a tick of the animation timer. A complex, but not uncommon, sequence might be:

Even though Chrome extensions and legacy packaged apps are similar at a technical level, users have very different expectations for how extensions and apps should look and behave. Users expect extensions to interact with the whole browser, whereas they expect apps to act solely in their containing tab or window.

Until now, all Chrome legacy packaged apps could request the same permissions and use the same APIs as extensions to interact with Chrome. In order to make the capabilities of legacy packaged apps more closely align with user expectations, we’ve decided to limit the extensions permissions that legacy packaged apps can request.

Beginning this week, you won’t be able to publish legacy packaged apps in the Chrome Web Store that request any of the following permissions:
(a) any host permissions, including "< all urls >" 
(b) the top-level "content_scripts" key 
(c) the "debugger", "devtools", "pageCapture", "plugin", "proxy", "tabs'", "history", "webNavigation" permissions 
(d) the top-level "npapi" key 

Earlier today we launched JAM with Chrome. JAM with Chrome is an interactive web application that enables friends in different locations to play music together in the Chrome browser on their computers.

JAM with Chrome was built with the latest browser technologies:

Today’s Chrome Beta channel release includes a slew of awesome new developer features.

Datalist support in date and time

datalist allows you to specify a list of suggested dates and times for input elements. Of course, users still have the freedom to enter arbitrary dates and times. One use case is helping users choose when their food should be ready for pickup:

MathML

Chrome packaged apps aim to deliver an app experience with the appearance and capabilities of native apps, but built using the growing capabilities of HTML5. These apps can access APIs for better filesystem handling, direct access to hardware devices, raw network communication and many others. One of the new APIs that just landed in an experimental state is TCP Listen, which allows an app to accept incoming TCP connections.

Since the developer preview launch earlier this year, Chrome packaged apps have been able to connect to remote servers using TCP or UDP, and bind to a UDP port. For example, this Media Center application searches for and connects to media servers in the local network. Now, through the new TCP Listen API, a Chrome packaged app can also act as a TCP server itself and accept incoming connections on specified ports.

Chrome Web Store developers can create and distribute apps and extensions that use NPAPI plug-ins. However, platforms such as ChromeOS and Windows 8 don’t support NPAPI. Today, we’re making the installation of apps and extensions that use NPAPI smarter, to help users avoid installing items that they can’t use on their particular platform.

If a user visits the Chrome Web Store on a platform that doesn’t support NPAPI, the store will filter out all items that use it from the home page and the various category pages. These apps and extensions will still show up in search results, and can be visited from direct URL links, but the Details dialog for each item will display a message that the app or the extension in question cannot be installed and the Install button will be disabled.

If you are a developer whose apps or extensions use NPAPI but can still work without it, we’ve provided a way for you to prevent your items from being filtered out. In your manifest.json file under the requirements section, specify the “npapi” flag like this:

"requirements": {

The Chrome Developer Tools team recently launched new features and made several UI changes to improve your development and debugging workflow.

Develop for mobile 

Since we launched Chrome for Android, you’ve been able to use Chrome Developer Tools to debug and profile mobile web pages and web apps.

Today, we take this feature one step further by introducing device emulation support in Chrome Developer Tools. Device emulation includes, among other things, native User Agent and dimension overriding. This allows developers to debug mobile browsers on different devices and operating systems via the Settings Menu. So, now, you can emulate the exact device metrics of devices like the Galaxy Nexus and the iPhone to test your media query-driven design.

Chrome Developer Tools also supports single touch event emulation to make it easier to debug mobile applications on the desktop.

Profile rendering performance 

The Timeline’s Frame Mode feature now allows you to profile Chrome’s rendering performance, remove the jank and deliver the silky smooth performance users expect from your apps. To learn more about this topic, check out the recent "Jank Busters" video from Google I/O.

Preview your log items

The console now prints a user-friendly snapshot of the object properties taken at log time, whereas by expanding the object manually, you can still see its live content. This is especially useful when logging an object in a loop and observing its mutation. With this change, we resolved a longstanding bug many of you prioritized on crbug.com.

Play with experimental features

You can now try new experimental features in Chrome Developer Tools by visiting chrome:flags and enabling them there. Once you do that, a new tab called “Experiments” will be visible in the settings menu, allowing you to enable and use any of the following experiments:

• Snippets (essentially multi-line console on steroids) 
• Source mapping support for SASS 
• Native memory profiling 
• Geolocation / orientation override 
• FileSystem inspection 
• Canvas inspection 
• CPU activity in Timeline 
• CSS Regions support 

Some of these experimental features are almost ready while others have just landed and need some more refining. In either case, we’d love your feedback before we bake these fully in Chrome Developer Tools. You can also read our recently updated contribution guide if you’re interested in helping us make the tools better.

To get more information on all of Chrome Developer Tools features, check out our “Chrome Developer Tools Evolution” talk at the I/O 2012. You can also follow Google Chrome Developers on Google+ or @ChromiumDev on Twitter for more news on changes landing in Chrome Developer Tools.

To publish an app in the Chrome Web Store, developers need to prove they own the domain that hosts their application. Until recently, the only way to do this was through Google’s Webmaster Tools. Today, we are simplifying the process further by allowing you use Google's site verification service to prove your association with a verified site.

Suppose you want to publish an app on the Chrome Web Store and have it associated with your company’s existing site, but you don’t have the ability to use any of the current verification methods e.g. you’re not allowed to upload a verification file to the root directory. The site verification service option in the edit page for each item listed in your Chrome Web Store developer dashboard allows you to request association of your app with your organization’s site:

When you choose an existing site from the drop-down menu or click “Add a new site”, the current registered owner for the site will receive a notification of your request to be associated. The owner can see who is making the request, and then approve or deny the request appropriately. That’s all there is to it! (Note: if this checkbox isn’t available, it may be because there’s no current owner of the site or you already have an outstanding association request).

We hope that this new feature will further streamline the process for publishing new apps on the Chrome Web Store, and allows you to focus more on developing your app and less on process. Have any questions or comments about using Google’s site verification service? You can reach us on our developer forum for store-related questions or head on over to the Webmaster Help forum.

Native Client (NaCl) enables you to write high-performance apps that run your C and C++ code in the browser. With the new Native Client add-in for Microsoft Visual Studio and the new Native Client debugger it just got a lot easier.

The Visual Studio add-in makes it easy to set up, build, run, and debug your app as a Pepper plug-in and as a Native Client module. If you are porting an existing application to Native Client, building as a Pepper plug-in is a convenient intermediate stage for development enabling you to gradually rewrite the app to use the Pepper APIs (video).

The Native Client debugger, affectionately called nacl-gdb, works on Windows, Mac, and Linux and is now available in the SDK. So whatever your development platform, you can now spend more time coding features and less time chasing bugs with printf.

Following the Native Client philosophy of being OS-independent and open source, nacl-gdb is based on... well... gdb! For those of you who are not excited by a text interface, the Visual Studio add-in makes interacting with the debugger easier. If you use a different development environment that can interact with gdb, you can point it to nacl-gdb and use the same commands plus some additional NaCl-specific commands.

Whether you’re an existing Native Client developer or thinking about using Native Client for your next project, now is a great time to grab the SDK, write an amazing app, and quickly squash any bugs you find. We look forward to questions on Stack Overflow and ideas and comments in the discussion forum.

A year ago we released a technology preview of Dart, a project that includes a modern language, libraries and tools for building complex web applications. Today, after plowing through thousands of bug reports and feature requests from the web community, a new, more stable and comprehensive version of Dart is now available and ready to use.

With this version of the Dart SDK, we’ve made several improvements and added many features:

• A faster Dart Virtual Machine that on some Octane tests outperforms even V8. 
• A new Dart to JavaScript translator that generates fast and compact output.
• An HTML library that works transparently on modern browsers.
• A library to interoperate with JavaScript code.
• An easy to use editor.
• Pub, a new package manager
• Dartium, a Chromium build with native Dart support.
• A server-side I/O library.
• A language specification describing the Dart semantics, including new features.

Over the following months, we will continue to work hard to evolve the SDK, improve Dart’s robustness and performance, and fine-tune the language while maintaining backwards compatibility.

You can download the Dart Editor from dartlang.org. It comes with a copy of the open-source SDK and Dartium. Thanks again for all your feedback - keep it coming.

If you are as obsessed with the speed of your web pages as we are, then you may have heard of mod_pagespeed, an Apache module that automatically optimizes your web pages for performance. Since we introduced mod_pagespeed in 2010, we’ve been focused on improving its functionality, to help developers increase the performance of their web pages. Today, after 18 releases, mod_pagespeed is now officially out of beta.

More than 120,000 sites are already using mod_pagespeed to take advantage of the latest performance optimization techniques. To learn more about mod_pagespeed and how to incorporate it in your site, watch our recent Google Developers Live session or visit the mod_pagespeed developer documentation site.

As part of our ongoing effort to reward exceptional vulnerability research in the security community, we hosted the Pwnium 2 competition at Hack in the Box 2012 in Kuala Lumpur yesterday.

We’re happy to confirm that we received a valid exploit from returning pwner, Pinkie Pie. This pwn relies on a WebKit Scalable Vector Graphics (SVG) compromise to exploit the renderer process and a second bug in the IPC layer to escape the Chrome sandbox. Since this exploit depends entirely on bugs within Chrome to achieve code execution, it qualifies for our highest award level as a “full Chrome exploit,” a $60,000 prize and free Chromebook.

Security is one of Chrome’s core principles, and we work closely with the security community to continually make the web safer for users. In that spirit, we're hosting Pwnium 2 at Hack in the Box 2012 in Kuala Lumpur this week.

Participants will be able to demonstrate their pwns against Chrome at 9 a.m. Wednesday local time (1 a.m. GMT for folks keeping track). We’ll be actively analyzing any submissions we receive, and will announce successful exploits and prizes during our talk at 5 p.m, Thursday (9 a.m. GMT) on the evolution of Chrome’s vulnerability rewards program.

Stay tuned!

Posted by Chris Evans, Software Engineer

Calling designers, web developers, and the creatively curious! Next week marks the launch of Google Developers Live Presents, a new series of exclusive programming from GDL.  Presents kicks off this month with Design Ignites the Web, a family of episodes that takes you on a journey from back-end to front-end, showing you how to create compelling projects in the browser. The series will feature exclusive interviews with the developers behind select Chrome Experiments, Chrome WebLab, Movi.Kanti.Revo, and DevArt.

So, what’s coming up? 

Make Web Magic: The Minds Behind the Most Popular Chrome Experiments | Tuesday, October 9 - Part 1, 1:00 PM PDT | 20:00 UTC [Event page] | Part II, 2:00 PM PDT | 21:00 UTC [Event page] | Part III, 3:00 PM PDT | 22:00 UTC [Event page] Using the latest open web technologies, the developers creating some of the most inspired Chrome Experiments showcase their latest web experiments and discuss how they are making the web faster, more fun, and open in this 3-episode hangout.Host: Paul Irish, Developer Advocate, ChromeGuests: Hakim: Google+, Website | Michael Deal: Google+, Website | Mark Danks: Google+, Website 

All the Web’s a Stage: Building a 3D Space in the Browser | Thursday, October 11 - 10:30 AM PDT | 17:30 UTC  [Event page]Meet the designers and creative team behind a new sensory Chrome experiment, Movi.Kanti.Revo, in a live, design-focused Q&A. Learn how Cirque du Soleil and Subatomic Systems worked to translate the wonder of Cirque into an environment built entirely with markup and CSS.Host: Pete LePage, Developer AdvocateGuests: Gillian Ferrabee, Creative Director, Images & Special Projects, Cirque du Soleil | Nicole McDonald, Director/Creative Director, Subatomic Systems 

Van Gogh Meets Alan Turing: The Browser Becomes a Canvas with DevArt | Friday, October 19 - 10:00 AM PDT | 17:00 UTC  [Event page]How can art and daily life be joined together? Host Ido Green chats with creators Uri Shaked and Tom Teman about tackling this question with their “Music Room” – a case study in the power of Android – and with Emmanuel Witzthum on his project “Dissolving Realities,” which aims to connect the virtual environment of the Internet using Google Street View.Host: Ido Green, Developer AdvocateGuests: Uri Shaked, Tom Teman, and Emmanuel Witzthum

Push the Limits: Building Extraordinary Experiences with Chrome | Week of October 29  [Event page] The experiments in Chrome Web Lab are pushing the limits of what developers can build in a browser. Explore the design and technical mastery that went into making extraordinary experiences, directly from the experiments’ home, the London Science Museum.Hosts: Pete LePage, Developer Advocate | Paul Kinlan, Developer AdvocateGuests: Tellart & B-Reel representatives for Universal Orchestra, Sketchbot, Teleporter, LabTag, DataTracer 

Cross-posted on the Google Developers Blog

When you want to build something for the web, it's surprisingly difficult to find out how you can implement your vision across all browsers and operating systems. You often need to search across various websites and blogs to learn how certain technologies can be used. It's kind of like a scavenger hunt, except it's not any fun.

This scavenger hunt is soon coming to an end. Google along with the W3C and several leading internet and technology companies just announced the alpha release of Web Platform Docs. Web Platform Docs is a community-driven site that aims to become the comprehensive and authoritative source for web developer documentation.

The founding members of Web Platforms Docs have all already provided a lot of content for the site to help get this effort off to a strong start. However, collectively, we’ve barely scratched the surface. We decided that it would be better to open up Web Platform Docs to the community as early as possible, so that everyone--including you--can help expand and refine the documentation, and ultimately define the direction of the site.

If you have more questions about Web Platform Docs, you can find us on Twitter.