The CSS Ninja details how Gmail's drag and drop from the desktop works; when you drag a file from the desktop into Gmail the file will automatically start uploading.

The CSS Ninja recreated the code in a demo (source code [zip]).

The code works in Firefox and Chrome. On Firefox the File API is used (detailed in another blog post) while on Chrome a different API is used.

How does Chrome work?

Using a bit of CSS trickery we can create the illusion of having File API support and still allow users to drag and drop files from the desktop into Gmail. I accomplish this by having the drop zone, which becomes visible on a dragenter event, contain an invisible file input with a 100% width and height of the drop zone area. The file input also has the attribute multiple on it allowing a user to drop multiple files.

The drop zone is hidden by default until a dragenter event happens on the BODY tag:

When the drop input is activated a change event is fired and the files can be enumerated:

Big news: Chrome Frame is now stable and out of beta!

Today, we’re very happy to take the Beta tag off of Google Chrome Frame and promote it to the Stable channel. This stable channel release provides our most polished version of Google Chrome Frame to date, allowing users to access modern web technologies like HTML5 on legacy browsers. You now can download the stable version of Google Chrome Frame and users of the Beta will be automatically updated to it in the days ahead. If you’re an IT administrator, we’ve also posted an MSI installer for deploying Google Chrome Frame in your network.

Chrome Frame is now much faster and stable. It's extremely simple to have a site use Chrome Frame:

For the next step the Chrome Frame team is focusing on making start-up speed even faster and removing the need for administrator rights when installing the plug-in.

Congrats to the Chrome Frame team!

[Disclosure: Alex Russell, the chipper-looking fellow in the video, and I have worked together at Google and on Dojo before.]

TechCrunch reports on a Googler, Paul Truong, who created an HTML5-based game for Gmail called Galactic Inbox using his 20% time:

When you start it up, a little Gmail logo envelope guy pops out of a “20% Projects Lab” and starts flying. Essentially, he’s a spaceship and can shoot objects coming his way. It’s simple, but fun.

Read more on the Gmail Blog.

Play the game yourself (note that you must be using a modern browser)!

[via Bryan Neuberg]

Note that the feature only currently works in Chrome.

Ryan begins with the following code:

Describing the code Ryan says:

From the code above you attach an ondragstart event listener to something you want to “drag out” and save to your file system. On the dragstart event you set the data using the new “DownloadURL” type and pass file information to it.

Note though that in order to pass the correct data to the dragstart event you need to provide a download URL that can be passed to the setData("DownloadURL" call. Ryan uses the HTML5 data-* attribute to pass this custom data in:

The custom attribute uses three different fields of data separated by colons:

The files mime type, the name you wish it to be saved as (this can be anything) and the url to where the file can be downloaded from.

Nice find Ryan!

Version 2 of HTML5Rocks is hot off the presses!

We think HTML5 will make your work more engaging and create a faster, more responsive experience for your users, so we're happy to add today a slew of new content to html5rocks.com.

If you want to not only get up to speed, but understand the browser differences and techniques for a robust implementation, please take a look through the new guides for implementing HTML5 video,understanding "offline," auditing your webapp with the Chrome developer tools, and using web workersand @font-face. You can now comment about your experiences with these features and stay up to date on new content via our new RSS feed.

We're also sharing the new HTML5 Studio, a collection of samples of these features in use, with code you can learn from and hack on.

*thump*. That is the sound of Google Chrome Frame getting a beta tag on it with a new version that comes up to Chrome 5 levels:

Instead of adding new bells and whistles, we've fixed more than 200 bugs to make integration with Internet Explorer seamless while improving security, stability, and performance. For example, we’ve improved our handling of Internet Explorer’s InPrivate browsing, cache clearing, and cookie blocking. All of the enhancements and features of Google Chrome 5.0 are available in Google Chrome Frame too, including HTML5 audio and video, canvas, geolocation, workers, and databases.

As we've worked on these improvements, we’ve been excited to see sites adopting Google Chrome Frame, including Meebo and all the blogs hosted by WordPress. In addition to our launch partner Google Wave, some other Google properties, including Orkut and YouTube are also relying on Google Chrome Frame to deliver HTML5 experiences to millions of users.

For those of you who want to develop HTML5 applications and deploy them broadly, we encourage you to give Google Chrome Frame a try. Existing users will be auto-updated to the beta, so if you downloaded Google Chrome Frame before, you’ll automatically get the new version. We’re also creating a new dev channel release, where you can try out the cutting-edge features we’re developing. For information on getting started with Google Chrome Frame, our project documentation is the place to start.

Alex gave a talk on how you can sprinkle in the Chrome Frame love, and start using the HTML5 goodness of video, svg, canvas, etc today!

We hear cries of the end is near!, and now you have a new push. Take a breath and spend the IE6 cycles on building amazing Web applications. So, CFInstall.check({..}) away! :)

Alex has a post on the beta itself:

In some ways it’s a strange product; it’s working best when you notice it least. As a developer, you shouldn’t have to think much harder about it than either to include the header or meta tag or to include a couple of lines of script to prompt users to install the plugin — a process which notably doesn’t require a restart and doesn’t even take users off of your site. There’s no new tool to learn, no new language you have to wrap your head around…in fact, the hardest part might just be putting down all the habits we’ve collected for catering to legacy browsers.

As I’ve begun to build exclusively to modern browsers, the experience of concerted un-learning of hacks and the ability to write directly to the platform again, sans toolkit, has been eye opening. Yes, there’s still a lot that can be improved in DOM, CSS, and HTML, but things are moving, and the tools we need now aren’t the tools we have today. Better yet, there’s every indication that things are progressing fast enough that instead of building tools to bring up the rear, we’ll be building them to shield ourselves from the ferocious pace of improvement should we need them at all.

If you’re starting a new project today, I encourage you to prototype to HTML5 and modern features and then think hard about what you’re building and for whom. Do these apps really need to run on legacy browsers? Why not just use GCF to make that pain and expense go away. Once you’ve experienced how good modern web development can be — how rich and fast the apps you can deliver are — I’m convinced that you’ll find it hard to go back. The rich, open, interoperable web is the platform of the future, and I couldn’t be happier that GCF is going to help deliver that future.

The bulk of the real content from Google engineers was very solid indeed, and there are gems for Web developers out there.

I wanted to highlight a slew of these:

GWT + HTML5 can do what?!

Remember the GWT Quake goodness from April 1st? The crew behind it are back giving a talk about the tech behind it. There are many gems in here, such as the image library by Ray Cromwell that has software and hardware back ends (WebGL). Watching the photoshop-esque filters running via WebGL makes you drool.

There were other GWT sessions:

• GWT Team fireside chat
• Speed Tracer tooling
• Optimizing apps with the GWT compiler
• Architecting for performance with GWT
• GWT Linkers target HTML5 Web Workers, Chrome Extensions, and more
• GWT's UI overhaul: UiBinder, ClientBundle, and Layout Panels
• GWT testing best practices
• Architecting GWT applications for production at Google

HTML5 and Chrome

Google used the "HTML5" word a loooot that week. Here is a blending of talks, part open Web, part Chrome itself.

Ian Fette kicks off a session on HTML5 support:

• WebM Open Video Playback in HTML5
• Developing with HTML5
• USing Google Chrome Frame
• Developing web apps for the Chrome Web Store
• Chrome Extensions
• Native Client
• Chrome fireside chat
• Google Chrome Developer Tools

Oh, and have some fun with Ignite:

We have been thinking about the app store models for awhile, and how they port to the Web. With the Chrome Web Store we can take a look at a concrete example and think about how it could potentially grow?

Mozilla just came out with a post that aims to start a discussion about what an Open Web Store would mean?:

• exclusively host web applications based upon HTML5, CSS, Javascript and other widely-implemented open standards in modern web browsers — to avoid interoperability, portability and lock-in issues
• ensure that discovery, distribution and fulfillment works across all modern browsers, wherever they run (including on mobile devices)
• set forth editorial, security and quality review guidelines and processes that are transparent and provide for a level playing field
  respect individual privacy by not profiling and tracking individual user behavior beyond what’s strictly necessary for distribution and fulfillment
• be open and accessible to all app producers and app consumers

I personally have been taking apart some of the pieces that make the holistic "app store" experience, and think there is room to do more with the various pieces. I would love your thoughts on what I wrote (pasted contents below):

App Stores. Catalogs. Markets. Gardens. They have been an incredibly hot topic ever since the success of the iPhone App Store. Everyone has wanted to own and control an app store ever since, for many different reasons. Not all of them are good. Not all of them can extract from the App Store experience.

With that, today Google unveiled a Chrome Web Store. Many folks have talked about how the Web, and the Open Web, could benefit from an app store. At a high level, the Web should give developers great options to distribute and monetize (if they so wish) their products, projects, and abilities.

There was a phase where people assumed that Internet meant "everything would be driven to be 'free'", and the model to make money is ads. Ads can potentially be a great avenue depending on your product, but people have always been willing to part with money to get value (or perceived value) back... and it shouldn't be too shocking to have see that play out again via app stores. Deliver great experiences and they may come. There is a lot to be said about "expectations" though, and I feel for some of the business models that are in trouble (media etc).

So, it would be nice if a developer could build something useful, stick a price tag on it, and sell it... using great distribution channels. One model for this is to package the application in a way that works in the distribution channels (e.g. PhoneGap, Titanium, or for us on webOS.... natively) but surely we can do better?

When you look at what an app store is, it consists of many pieces indeed.

For example,

Application Platform

This is the set of APIs and technology that you can use to build your applications. We feel strongly that having many fragmented devices with their own set of APIs, and thus their own platform, is a path to madness. To fix that, we need a unifying platform. We could unify on a proprietary platform (e.g. Flash, Cocoa, Silverlight/.NET, or what have you) or we could learn from history and honour the very lucky place that are in as an industry, and choose Open standards... and in concrete, the Web.

The Chrome Web Store very much honours this. Their apps are just Web apps. This is fantastic and a big step forward. The fact that you could take the same codebase and ship it in a store that runs in Chrome and other browsers (and web OS's :) is great news.

But this is only one level of the stack.

Application Packaging

How do you package up your application to place in a store? Chrome has a prelim crack at this with their crx format that we have seen via Chrome Extensions. There are also others:

W3C widgets, Android, webOS, Nokia WRT, and more. Libraries like PhoneGap already have to deal with this world. We need scripts and tools to navigate this world. In the short term lets create and use those tools, but how about all getting together and making a format that we can all live with and extend in the right ways?

Distribution

How do you distribute your apps? Right now you either: a) put up a website and folks find you (via search {and thus SEO}, the social web, and links), b) put an application into a store itself.

The Web won on distribution. AOL couldn't hold back the tide. Everything was Out There. Do we really want one or two companies in charge of what gets Out There? There is certainly value to curation, and finding applications via places you trust, but I personally want to see us solve the problem is a distributed open way. No entity should own the pipe. There should be no "right way" to censor or review applications. Different systems can choose values. Ideally they are transparent, and consumers can then choose where they want to look for the app content.

Discoverability

If we had a standard format for "installable web apps" a lot of good can happen. If we had a standard format, we could annotate the Web with it. Browsers could consume it (e.g. App Discover and the talk on just this.) and search engines could index it.

If I am on a Web site that has an application available, the browser should let me know. If I do a Google search, a one box should tell me about the matching apps for the platforms that I care about.

Anyone could create a merchandising experience and have access to apps to search for. We can go beyond that too of course. We can have web hooks that ping services with information about applications that have been created. A meta service would crop up that looks for the data and then pings the various Web app stores, just like we saw with trackbacks and the like.

There is still a ton of room to innovate in discoverability. Smarter searching that ties deeper than matching on the content will kick in.

Merchandising

Having access to the application data is important. The Palm ecosystem shares full feeds of the data from the catalog and this allows anyone to merchandize the content. They can be creative and present the right content to the user. There is a lot of innovation to be done here. Ideally, someone could create a great new social algorithm and have it run against all of the web apps out there. Right now, the stack is monolithic and we only have basic merchandising needs in most of the ecosystems. What about affiliate systems and the like which could enable innovation here?

Fulfillment

How do you pay for a good. How does the developer get paid for the good. This is an obviously crucial layer. Apple has done very well because people already had iTunes accounts coming into the world of the iPhone. In a distributed model, users could choose to fulfill via Amazon, or Paypal, or Checkout, or SimpleBank (one day right al3x? :)

And more....

We haven't even gotten into identity, single sign-on, reputation systems, and how reviews can be shared on the same applications in different stores. There is so much to be done here.

Looking forward, where does this next step take us? Is there a path where web applications themselves are back to just being websites that can live in various stores, and a pay gate can be setup in an easy way?

I can't wait to see how this plays out. We could all go off and build ivory towered app stores, or we could come together and work out a better way. Are you in?

This is in no small part to the work both Typekit and Google have been doing. Today they both announced some very cool things in this area.

First up, Google announced that they are releasing high quality open source fonts in the Google Font Directory. Since these are open source you can even download the original font files yourself at the font code.google.com project.

Next, Google has made it very easy to include these fonts into your page using the new Google Font API. To use a font you simply drop some HTML into your page similar to the following, specifying the font you want to use:

Doesn't get simpler than that. The new API does alot of things for you behind the scenes:

Google’s serving infrastructure takes care of converting the font into a format compatible with any modern browser (including Internet Explorer 6 and up), sends just the styles and weights you select, and the font files and CSS are tuned and optimized for web serving. For example, cache headers are set to maximize the likelihood that the fonts will be served from the browser’s cache with no need for a network roundtrip, even when the same font is linked from different websites.

These fonts also work well with CSS3 and HTML5 styling, including drop shadows, rotation, etc. In addition, selecting these fonts in your CSS works just the same as for locally installed fonts, facilitating clean separation of content and presentation.

On a related front, Typekit and Google announced a new Web Font Loader that smooths over many of the differences around loading web fonts on a page:

The WebFont Loader puts the developer in control of how web fonts are handled by various browsers. The API fires JavaScript events at certain points, for example when the web font completes downloading. With these events, developers can control how web fonts behave on a site so that they download consistently across all browsers. In addition, developers can set the fallback font's size to more closely match the web font, so content doesn't reflow after loading.

Furthermore, the WebFont Loader is designed to make it easy to switch between different providers of web fonts, including Google, Typekit, and others. The code is modular, and we expect to add modules for other major web font providers in coming weeks.

It's great to see Typekit involved in this; they are a real pioneer in this area and have helped make fonts on the web a reality.

To see all these pieces together navigate over to Smashing Magazine which relaunched their site using these technologies.

Congrats to the Google Web Fonts and Themes team, including Raph Levien, Jeremie Lenfant-Engelmann, Marc Tobias Kunisch, Meslissa Louie, and David Kuettel.

[Disclosure: I work for Google and know the Web Fonts team. However, even if I didn't, I would still be excited about this since I've been waiting for web fonts to happen since the 90s!] ]]> http://ajaxian.com/archives/2010-web-fonts-are-here-and-ready-to-use/feed 21 http://ajaxian.com/archives/chrome-web-store-i-want-an-open-web-store http://ajaxian.com/archives/chrome-web-store-i-want-an-open-web-store#comments Wed, 19 May 2010 17:04:02 +0000 Dion Almaer http://ajaxian.com/?p=9334 Read the rest...]]>

The Chrome Web Store was shown off at the Google I/O keynote (streaming live) today along with the other great news of open codecs, great new tools, and more.

I found myself torn about this one. For one, it seems tied into Chrome itself. The problem that Sundar stated (developers needing a good channel; users having a hard time finding things) is valid for the entire Web. We don't need a Firefox Web Store, IE Web Store, etc etc etc. We have an opportunity to do better here.

That being said, it was great to see the early stages here and how they give developers the ability to place your Web application in to an experience where you can put a price tag on top.

I would love to get details here. How do you package the application? Do you have to upload the package to the store?

I wonder if there is room for a distributed system that allows me to put a price tag on my web application, but keep it at my URL.

What do you think? There is a session on the store... so I look forward to the deets!

The WebM project is dedicated to developing a high-quality, open video format for the web that is freely available to everyone.

The WebM launch is supported by Mozilla, Opera, Google and more than forty other publishers, software and hardware vendors.

WebM is an open, royalty-free, media file format designed for the web.

WebM defines the file container structure, video and audio formats. WebM files consist of video streams compressed with the VP8 video codec and audio streams compressed with the Vorbis audio codec. The WebM file structure is based on the Matroska container.

It happened. Today, Google is up on stage at I/O unveiling a new WebM project alongside a slew of partners (notably: Mozilla and Opera on the browser side) that gets the On2 codec out into the open. This is huge news for the fight for Open Video, and everyone will now have eyes on Safari.

YouTube will be a huge push here, and you can go to their html5 version: http://www.youtube.com/html5 and check it out. Today it is available in trunk builds on Chromium and Firefox. Soon, an Opera beta, Chrome dev release, and more.

The project is going after:

• Openness and innovation. A key factor in the web’s success is
  that its core technologies such as HTML, HTTP, and TCP/IP are open
  for anyone to implement and improve. With video being core to the
  web experience, a high-quality, open video format choice is needed.
  WebM is 100% free, and open-sourced under a
  BSD-style license.

• Optimized for the web. Serving video on the web is different
  from traditional broadcast and offline mediums. Existing video
  formats were designed to serve the needs of these mediums and do
  it very well. WebM is focused on addressing the unique needs of
  serving video on the web.

  • Low computational footprint to enable playback on any device,
    including low-power netbooks, handhelds, tablets, etc.*

  • Simple container format

  • Highest quality real-time video delivery

  • Click and encode. Minimal codec profiles, sub-options; when
    possible, let the encoder make the tough choices.

* Note: The initial developer preview releases of browsers supporting WebM are not yet fully optimized and therefore have a higher computational footprint for screen rendering than we expect for the general releases. The computational efficiencies of WebM are more accurately measured today using the development tools in the VP8 SDKs. Optimizations of the browser implementations are forthcoming.

Congrats Open Web.

Update: Flash will ship VP8, as will IE9. Now everyone looks at the Safari team :)

(One thing though about IE9 support: "In its HTML5 support, IE9 will support playback of H.264 video as well as VP8 video when the user has installed a VP8 codec on Windows."). That is a bummer.

A year after the initial Native Client release we have a more polished Native Client SDK for developers.

The Native Client SDK preview, in contrast, includes just the basics you need to get started writing an app in minutes: a GCC-based compiler for creating x86-32 or x86-64 binaries from C or C++ source code, ports of popular open source projects like zlib, Lua, and libjpeg, and a few samples that will help you get you started developing with the NPAPI Pepper Extensions. Taken together, the SDK lets you write C/C++ code that works seamlessly in Chromium and gives you access to powerful APIs to build your web app.

Salt and Pepper indeed. A friend at a browser vendor was looking into Pepper and thought that the specs were definitely..... thorough shall we say? Take Pepper Audio by itself. A bit of a beast! :)

It is interesting to watch Google give C/C++ developers (and legacy code) a different path to the Web (beyond NPAPI and... ActiveX!). You can imagine this being increasingly important when you think about Chrome OS.

Ideally, the Web platform itself evolves fast enough that this project is always an onramp for legacy code.... what do you think?

@hbridge has an interesting view:

Pepper is very much a work in progress and we expect it to change -- that's why this is a preview! Feedback welcome :)

ActiveX was designed to provide unrestricted access to native APIs so it wound up being a security nightmare.

NaCl is designed to give access to native code performance, but only to APIs similar to what JS offers, so security model is same.

This is fantastic news. A lot of people were claiming that O3D was going to beat WebGL because of performance. Then the O3D team showed that the two could be complimentary, and they have taken the next step on that journey. As of today, O3D will stop being a plugin, and will become a JS library on top of WebGL. This is fantastic, as we need a nice API on top of the OpenGL-y WebGL library.

Here are their thoughts. Congrats to the O3D team, to the WebGL folk, and to the future:

We launched the O3D API about a year ago to start a discussion within the web community about establishing a new standard for 3D graphics on the web. Since then, we’ve also helped develop WebGL, a 3D graphics API based on OpenGL ES 2.0 that has gradually emerged as a standard, and is supported by other browser and hardware vendors like Mozilla, Apple and Opera.

At Google, we’re deeply committed to implementing and advancing standards, so as of today, the O3D project is changing direction, evolving from its current plug-in implementation into a JavaScript library that runs on top of WebGL. Users and developers will still be able to download the O3D plug-in and source code for at least one year, but other than a maintenance release, we plan to stop developing O3D as a plug-in and focus on improving WebGL and O3D as a JavaScript library.

We did not take this decision lightly. In initial discussions we had about WebGL, we were concerned that JavaScript would be too slow to drive a low-level API like OpenGL and we were convinced that a higher level approach like the O3D scene graph would yield better results. We were also cognizant of the lack of installed OpenGL drivers on many Windows machines, and that this could hamper WebGL’s adoption.

Since then, JavaScript has become a lot faster. We've been very impressed by the demos that developers have created with WebGL, and with the ANGLE project, we believe that Chromium will be able to run WebGL content on Windows computers without having to rely on installed OpenGL drivers.

The JavaScript implementation of O3D is still in its infancy, but you can find a copy of it on the O3D project site and see it running some of the O3D samples from a WebGL enabled browser (alas, no Beach Demo yet). Because browsers lack some requisite functionality like compressed asset loading, not all the features of O3D can be implemented purely in JavaScript. We plan to work to give the browser this functionality, and all capabilities necessary for delivering high-quality 3D content.

Google came out with a spec for doing this with hash bang URLs such as: http://shepherdinteractive.com/#!portfolio/interactive/.

What if we could tell Google and others something like:

and Google would grok http://shepherdinteractive.com/#/portfolio/interactive/ and convert it to http://shepherdinteractive.com/?_escaped_fragment_=portfolio/interactive/.

Want flexibility? Or want simplicity and think we should all just hash bang away?

For some time now, Adobe has been working with platform vendors to include the Flash plug-in pre-loaded. We've seen this ages ago in Windows, and more recently with Adobe's efforts in the Open Screen Project.

Now, there's news of something a little bit different. In our second Google-y post of the week, there's the news that Chrome now embeds Flash directly in the browser, starting today with the developer channel builds of Chrome.

While this doesn't change the game for developers--it won't materially impact Flash market share--it certainly provides a much more pleasant integration for users who will no longer need to think about updating Flash as a separate process to updating their browsers. (And since Chrome auto-updates, it's blissful upgrading indeed.)

Plug-ins with a Dash of Pepper

What *may* impact developers more is news of Adobe working with Google and Mozilla to create a new, deeper browser plug-in API. While no timelines are given, some technical details are provided via a Mozilla Wiki page.

Code-named "Pepper", the API provides all kinds of goodies denied to plug-ins before, such as using native GUI controls inside of a plug-in (i.e., scrollbars) instead of being forced to render its own and access to printing and the clipboard. Pepper also provides granular media APIs instead of forcing plug-ins to deal with graphics and audio on its own.

It will be interesting to see how successfully such an API can be implemented consistently cross-platform, but at first glance it seems to embrace about the right set of trade-offs.

ANGLE

This is exciting. On the Chromium blog Henry Bridge announced a new open source project called ANGLE which is implementing OpenGL ES 2.0 on top of Microsoft Direct3D APIs for Windows folk. This is a big deal as you can't assume good OpenGL drivers on Windows... but with ANGLE live could be better.

Why is this related to Chromium? WebGL:

We're open-sourcing ANGLE under the BSD license as an early work-in-progress, but when complete, it will enable browsers like Google Chrome to run WebGL content on Windows computers without having to rely on OpenGL drivers.

Current browser implementations of WebGL need to be able to issue graphics commands to desktop OpenGL to render content. This requirement isn't a problem on computers running OS X or Linux, where OpenGL is the primary 3D API and therefore enjoys solid support. On Windows, however, most graphics-intensive apps use Microsoft Direct3D APIs instead of OpenGL, so OpenGL drivers are not always available. Unfortunately, this situation means that even if they have powerful graphics hardware, many Windows machines can't render WebGL content because they don't have the necessary OpenGL drivers installed. ANGLE will allow Windows users to run WebGL content without having to find and install new drivers for their system.

Because ANGLE aims to implement most of the OpenGL ES 2.0 API, the project may also be useful for developers who are working on applications for mobile and embedded devices. ANGLE should make it simpler to prototype these applications on Windows, and also gives developers new options for deploying production versions of their code to the desktop.

Check out the source.

Native Client is ARM'd

NaCl allows you to gcc some code and have it run in a browser. Wooah :) The big news from that camp is new support for ARM which means NaCl for mobile..... and Chrome OS:

When we first released Native Client a year ago, we supported all popular operating systems (Windows, Mac OS X, and Linux) but only on machines with x86 processors. Today, we’re happy to say that you can build and run Native Client binaries for all of the most popular processor architectures: x86-32, x86-64, and ARM. Even better, our initial benchmarks indicate that Native Client executables perform at 97% of the speed of an unmodified executable on both ARM and x86-64 processors. These results indicate that a browser running on virtually any modern computer or cell phone could run a fast, performance-sensitive Native Client application.

However, we recognize that just running on today’s most popular architectures isn’t enough; if a new processor architecture emerges, it should be able to run all Native Client modules already released without requiring developers to recompile their code. That’s why we’re also developing technology that will enable developers to distribute a portable representation of Native Client programs using LLVM bitcode. Using this technology, a browser running on any type of processor could translate the portable representation into a native binary without access to the source code of the program.

Skipfish

For the security concerned .... how about running Skipfish "a fully automated, active web application security reconnaissance tool.":

• High speed: pure C code, highly optimized HTTP handling, minimal CPU footprint - easily achieving 2000 requests per second with responsive targets.
• Ease of use: heuristics to support a variety of quirky web frameworks and mixed-technology sites, with automatic learning capabilities, on-the-fly wordlist creation, and form autocompletion.
• Cutting-edge security logic: high quality, low false positive, differential security checks, capable of spotting a range of subtle flaws, including blind injection vectors.

Some cool news all around.... all Web... and all open source.

See addmap.js in action below - all the content in the green box is generated from the paragraph of text above it. You can try it out for yourself by clicking the screenshot.

Using addmap.js is easy - sign up for a Google Maps Key and provide it as a configuration parameter. Then call the analyse function with the ID of the element to analyse as the parameter:

The script uses YQL and Yahoo PlaceMaker under the hood, for more info and updates on this, check the blog.

Closure Lite itself consists of the following subset of APIs:

• goog.array
• goog.Disposable
• goog.dispose
• goog.dom
• goog.dom.DomHelper
• goog.events.NodeType
• goog.dom.TagName
• goog.dom.classes
• goog.dom.xml
• goog.events
• goog.events.BrowserEvent
• goog.events.Event
• goog.events.EventHandler
• goog.events.EventType
• goog.events.EventTarget
• goog.events.KeyEvent
• goog.events.KeyCodes
• goog.events.KeyHandler
• goog.events.Listener
• goog.functions
• goog.json
• goog.math.Box
• goog.math.Coordinate
• goog.math.Rect
• goog.math.Size
• goog.net.ErrorCode
• goog.net.EventType
• goog.net.XhrIo
• goog.net.XhrMonitor
• goog.net.XmlHttp
• goog.object
• goog.string
• goog.structs
• goog.structs.Map
• goog.structs.Set
• goog.style
• goog.Timer
• goog.userAgent
• goog.userAgent.product
• goog.window

It is build via the closure compiler itself, building from a set of goog.require() calls :)

Following their recent acquisition by Google, AppJet announced they would open source EtherPad, the collaborative, real-time, notepad. That's now done, and you can find the project home at - surprise, surprise - Google Code.

Checkout Instructions

Browse the Source

What's especially cool about this is that Etherpad is Javascript on both sides of the wire. In a new ReadWriteWeb article on Server-Side Javascript, I wrote that EtherPad is probably the most popular site powered by Javascript (anyone want to up the ante?). As server-side Javascript is getting interesting again, with Comet a major driver, it's a big deal that we now have the entire source tree for a Comet-style, server-side Javascript, application that's been proven in the real world.

AppJet also released appjet.jar when they discontinued the general server-side Javascript platform earlier this year. Unfortunately, the download link is broken on AppJet.com, so I don't know if there's any way to get hold of the official version. It does, however, live on as a cloud-hosted offering at JGate.

Web Sockets

First up, we have Web Socket support being turned on by default on the developer channel. If you want to be a really cool JS h4x0r you should write a server app using node.js. If you want it to work on older browsers, try out the old favourite shim tale of use Flash to degrade, and Mozilla support should be coming soon and surely IE9 will support it too ;)

Now you can code like this:

Chrome Extensions Beta

Although I curse at the weak support on Chrome Mac (coming by end of week though!), other Chromers can use the new beta extension system pioneered by the awesome Aaron Boodman and team:

Today, we're really happy to release a beta of extensions that begins to deliver on our initial vision. Extensions are as easy to create as webpages. Users can install and uninstall them quickly without restart, and extensions have a great polished look that fits in with Google Chrome's minimalist aesthetic. When developers upload an extension it is available to users immediately, with limited restrictions and manual reviews only in a few situations.

On the technical side, we've been able to use Google Chrome's multiprocess architecture to help keep extensions stable and safe. And Chromium's extensive performance monitoring infrastructure has helped us ensure extensions affect Google Chrome's speed as little as possible. You can learn more details about the internals of our system in the videos below.

I am excited about the new extension systems of Chrome and Jetpack, and wrote up thoughts on how we are jumping out of the page and into the runtime as Web developers.

rel="noreferrer" and target="_blank"

I missed the fact that in Chrome you can opt-in to a new process from a link. This is important as every tab is NOT necessarily in its own process. People assume that is the case (a one to one mapping) but it isn't (and has interesting security implications):

In many cases, though, Google Chrome needs to keep pages from related tabs in the same process, since they may access each other's contents using JavaScript code. For example, clicking links that open in a new window will generally cause the new and old pages to share a process.

In practice, web developers may find situations where they would like links to other pages to open in a separate process. As one example, links from messages in your webmail client would be nice to isolate from the webmail client itself. This is easy to achieve now, thanks to new support in WebKit for HTML5's "noreferrer" link relation.

To cause a link to open in a separate process from your web page, just add rel="noreferrer" and target="_blank" as attributes to the tag, and then point it at a URL on a different domain name. For example: