The CSS Regions capabilities currently in Chrome are pretty rudimentary, but I’m also working with some nightly WebKit builds which definitely take the feature to the next level (they include CSS Object Model support which enables the scripting of CSS Regions — that’s when they get really interesting). I’ll have plenty more samples and prototypes in the near future.

var ss = document.styleSheets[0];
ss.insertRule('#content::selection {color: #'+
              newForegroundColor+'; background: #'+
              newBackgroundColor+';}', 0);

Note that I only tested this code in Chrome and Safari (I’m only targeting WebKit browsers for now), however it can work with Firefox with the correct "moz" prefixed style name. I haven’t yet tested or investigated IE.

If you know another way of changing text selection properties in JavaScript, let me know.

In Firefox, you can use the display:none style as noted in this Mozilla Developer Network documentation, however this won’t work in Chrome or Safari (although FileReader is currently not supported in Safari, you might as well think ahead for when it is). A better way of doing it, therefore, is to use visibility:hidden.

The only problem is that when something is hidden using its visibility property, it’s still actually in the DOM, and space is therefore allocated for it even though you can’t see it. If you want to get your file input completely out of the way, therefore, you can use something like this:

<input type="file" id="fileInput" onchange="handleFiles(this.files)" style="visibility:hidden;position:absolute;top:-50;left:-50"/>

Your file input will still be in the DOM (even though it’s hidden and off-screen), however it won’t take up any visual space.

Here’s the full HTML code:

<a href="javascript:onLoad();">Load a File!</a>
<input type="file" id="fileInput" onchange="handleFiles(this.files)" style="visibility:hidden;position:absolute;top:-50;left:-50"/>

And here’s the JavaScript code:

function onLoad() {
    id('fileInput').click();
}

function handleFiles(files) {
    var file = files[0];
    var reader = new FileReader();
    reader.onload = onFileReadComplete;
    reader.readAsText(file);
}

function onFileReadComplete(event) {
  // Do something fun with your file contents.
}

Note that this code is only going to work in current versions of Chrome and Firefox, but is expected to work in future versions of IE (10) and Safari (6).

HTML:

<a href="javascript:onDownload();">Download</a>

JavaScript code:

function onDownload() {
    document.location = 'data:Application/octet-stream,' +
                         encodeURIComponent(dataToDownload);
}

The only limitation is that I can’t figure out a way to give the downloaded file a name (and have concluded that it’s not currently possible, though I’m happy to be proven wrong). I’ve only tested the code in Safari and Chrome, and in both cases, the file name defaults to "download" (with no extension). All the data is in the file, but it’s not a very intuitive experience for the end user.

I’ll be releasing the application shortly which should demonstrate why downloading data directly from the client can be useful. In the meantime, I’m curious if this is something any of you might use, and if so, if you think the file name issue should be fixed.

Let me know in the comments.

WebKit Developer Tools

Each section below describes a section of the WebKit developer console.

Elements

• Traverse, inspect, and edit the DOM.
• Inspect and edit CSS.
• View a diagram of the CSS box model and edit its metrics.
• View and edit a DOM element’s properties.
• Manage DOM breakpoints. Breakpoints can break on:
  • Subtree modification.
  • Attribute modification.
  • Node removal.
• View an element’s event listeners.
• Right-click on any element in a web page, and select “Inspect Element” from the context menu to bring it up in the developer console.
• Note that edits are for testing purposes only and are not saved (though I believe there are extensions which make tracking your changes easier).

Resources

• Allows you to inspect (and in some cases, edit) various elements of a web application:
  • Frames (all externally loaded files).
  • Databases (SQLite).
  • Local storage.
  • Session storage.
  • Cookies.
  • Application cache.

Network

• Detailed inspection of network metrics broken down by resource.
• Metrics include:
  • Name of the resource.
  • Request method (GET, POST, DELETE, etc.).
  • Status (200, 404, etc.).
  • Type (content type, i.e. text/javascript, text/css, etc.).
  • Size.
  • Time in milliseconds.
  • Timeline waterfall (start and end time of all resource requests relative to each other, including latency).
  • Exactly when the DOMContentLoaded and Load events were fired.
• Resource types can be filtered (for instance, if you just want to watch images).
• You can click on a resource to see a detailed view which includes:
  • HTTP headers (both request and response).
  • A preview of the resource (HTML source, image, etc.).
  • Cookies.
  • Detailed timing information including:
    • DNS lookup.
    • Connecting.
    • Sending.
    • Waiting.
    • Receiving.

Scripts

• View all the scripts being used by the current page.
• Manage breakpoints.
• Flow control (pause, resume, step over, step into, and step out).
• View the call stack.
• Inspect variables by scope.
• Manage context-specific breakpoints:
  • DOM (see above).
  • XMLHttpRequest.
  • Event listener.
  • Workers.

Timeline

• Detailed breakdown of the timeline related to loading your site including:
  • Loading.
  • JavaScript parsing.
  • JavaScript execution.
  • Calculating styles and layout.
  • Rendering.
  • Events.
• Timeline of memory consumption.

Profiler

• CPU: shows where execution time is spent.
• Heap: shows memory distribution.

Audits

• Various tests and diagnostics that can be run on a page or application.
• Included audits:
  • Network Utilization
    • Recommends things like using gzip, leveraging browser caching, using proxy caching, and reducing cookie size.
  • Web Page Performance
    • Recommends things like removing unused CSS rules, changing the order of scripts and styles, etc.
• Extensibility APIs for creating your own audits.

Console

• View parse errors and JavaScript execution errors.
• Write to the console from within your code using the console.log() function (the new alert()).
• Supports multiple strings and objects as arguments. Objects can be expanded and inspected.
• Execute JavaScript directly from the console.
• Enable pausing, or breaking, whenever a runtime error is encountered (as opposed to just logging it).

Task Manager (Chrome only)

Similar to the Windows Task Manager or the Activity Monitor on OS X, the Task Manager shows metrics by tab, process, and extension. Fields include:

• Process ID.
• Memory (shared and private).
• JavaScript memory.
• CPU.
• Network throughput.
• Frames per second.
• Image cache size.
• Script cache size.
• CSS cache size.
• SQLite memory.

Debugging APIs

Below are all the APIs that I know of that can be used to programmatically debug and/or audit a web application:

• console.log
  • Logs strings and objects to the console.
• performance.timing
  • Networking metrics that reflect page load performance.
• performance.memory
  • Fields:
    • jsHeapSizeLimit
    • totalJSHeapSize
    • usedJSHeapSize
  • Requires the -enable-memory-info command line flag.
• window.onerror event handler
  • Allows global error registration.
  • Typical usage is to send the data to your server where it can be aggregated and reports can be generated.
• console.profile('name'), console.endProfile('name'), and console.profiles (returns an array of Profile objects):
  • Programmatic ways of starting, stopping, and analyzing profile information.
  • Data can be captured and sent back to the server for aggregation.
• console.markTimeline()
  • Programmatically add “marks” to your timeline view.
• Extensibility APIs for creating your own audits.

Remote Debugging

Remote debugging allows you to debug a remote browser instance. This is nice on the desktop, but will become critical on mobile devices.

• Start Chrome with the --remote-debugging-port command line flag.
• Starts a mini web server.
• External browsers can connect to that port and profile tabs remotely.
• Implemented at the WebKit level, so all WebKit browsers will get it.

Additional Resources

Believe it or not, there’s actually more. If you haven’t gotten enough, check out these excellent resources:

• A Re-introduction to the Chrome Developer Tools (by Paul Irish).
• Chrome Developer Tools for Speed (by Paul Irish).
• Google Chrome Developer Tools: 12 Tricks to Develop Quicker (by Paul Irish).
• 25 Secrets of the Browser Developer Tools (Andi Smith).
• Google Chrome Developer Tools.

Since I’m not a very good designer, I usually try to do as much styling, design, and graphics in code as I can. For instance, when I wrote this mobile compass application in HTML, I did all the graphics programmatically using Canvas and CSS.

I’m now working on a project that requires one of those loading spinner animations that Apple seems to have made famous, so naturally, I started looking into ways to create one purely in code and/or CSS (no external assets). Fortunately, I found a great post on the Signal vs. Noise blog demonstrating exactly what I wanted to do. However, I decided to take it one step further, and write some JavaScript to generate both the required CSS and the HTML. The advantage of generating everything dynamically is that you can configure things like the size, color, and the number of bars in the animation at runtime.

Here’s an example of some randomly generated loading spinner animations which are 100% CSS and HTML generated by JavaScript (Chrome and Safari only for now). If you’re interested in the code, here’s the original CSS from Signal vs. Noise, and below is my port to JavaScript (view the source of the demo to see how to use it). It only works in WebKit-based browsers for the time being, but I’ll update it as browser capabilities get better. It works in WebKit-based browser, and in Firefox.

Check out the example.

var Spinner = {
  SPINNER_ID: '_spinner',
  prefix: (navigator.userAgent.indexOf('WebKit') != -1) ? 'webkit' : 'moz',
  getSpinner: function(size, numberOfBars, color) {
    if (document.getElementById(this.SPINNER_ID) == null) {
      var style = document.createElement('style');
      style.setAttribute('id', this.SPINNER_ID);
      style.innerHTML = '@-'+this.prefix+'-keyframes fade {from {opacity: 1;} to {opacity: 0.25;}}';
      document.getElementsByTagName('head')[0].appendChild(style);
    }
    var spinner = document.createElement('div');
    spinner.style.width = size;
    spinner.style.height = size;
    spinner.style.position = 'relative';
    var rotation = 0;
    var rotateBy = 360 / numberOfBars;
    var animationDelay = 0;
    var frameRate = 1 / numberOfBars;
    for (var i = 0; i < numberOfBars; ++i) {
      var bar = document.createElement('div');
      spinner.appendChild(bar);
      bar.style.width = '12%';
      bar.style.height = '26%';
      bar.style.background = color;
      bar.style.position = 'absolute';
      bar.style.left = '44.5%';
      bar.style.top = '37%';
      bar.style.opacity = '1';
      bar.style.setProperty('-'+this.prefix+'-border-radius', '50px', null);
      bar.style.setProperty('-'+this.prefix+'-box-shadow', '0 0 3px rgba(0,0,0,0.2)', null);
      bar.style.setProperty('-'+this.prefix+'-animation', 'fade 1s linear infinite', null);
      bar.style.setProperty('-'+this.prefix+'-transform', 'rotate('+rotation+'deg) translate(0, -142%)', null);
      bar.style.setProperty('-'+this.prefix+'-animation-delay', animationDelay + 's', null);
      rotation += rotateBy;
      animationDelay -= frameRate;
    }
    return spinner;
  }
}

1. JSONP
2. Cross-Origin Resource Sharing

JSONP

JSONP gets around the same origin policy by loading JavaScript from another domain into a dynamically generated <script> tag (script tags are not subject to the same origin policy which is what enables things like ads to be served from different domains). In your request (formed as the src attribute of the script tag), you typically specify a callback function that you have already defined in your application. The JavaScript that gets loaded into the dynamically generated script tag will call the specified function, passing in the requested JSON data.

(Note that JSONP requests are probably best handled by robust frameworks like the jQuery.getJSON() function.)

I’ve used JSONP in the past for things like this prototype client-side news reader, but the project I’m working on now uses XML as well as JSON, so I decided to use a different approach.

Cross-Origin Resource Sharing

Cross-origin resource sharing is similar to cross-domain policy files in the Flash word, but they are done through HTTP headers. The specification defines several different headers, however the only one I’ve needed so far is the response header Access-Control-Allow-Origin. Allowing my server to share resources with my local machine was as easy as adding the following line of PHP code before writing to the output buffer:

header('Access-Control-Allow-Origin: http://seeker.home');

(Seeker is the name of my development machine, named after the excellent Jack McDevitt novel.)

Of course, once I move the client-side portion of my application (the HTML, JS, and CSS files) to my server, I can delete or comment this line out since the application will be served from the same domain from which it needs to request data. In the meantime, however, it’s made local development much easier.

Cross-origin resource sharing is part of the XMLHttpRequest Level 2 specification, and is supported in all modern browsers.

var hello = document.createElement('p');
hello.innerText = 'Hello, world!';
document.getElementById('myDiv').appendChild(hello);

Nice and easy, but what if you want to prepend the child rather append? You could do this:

var hello = document.createElement('p');
hello.innerText = 'Hello, world!';
var myDiv = document.getElementById('myDiv');
myDiv.insertBefore(hello, myDiv.firstChild);

Or, you could just add a prependChild function to Element, like this:

Element.prototype.prependChild = function(child) { this.insertBefore(child, this.firstChild); };

Just make sure that the code above evaluates early on in your application initialization, and start prepending all you want. (Of course, if you’re using jQuery, prepend is already well in hand.)

As someone who has worked on the Flash Platform at Adobe for the last nine years, I just wanted to provide some additional context around yesterday’s announcement. Your coverage was very good, so no complaints, but I feel like it’s worth emphasizing a few things.

Part of Adobe’s story is enabling cross-platform solutions, but since Flash has never been supported on iOS, we weren’t able to deliver on that vision in the context of mobile browsers. With mobile browsers as good as they are now (the ICS browser looks amazing, and mobile Safari has always been awesome), it just makes more sense to use HTML.

In the context of installed applications, however, our story is stronger than ever. We recently released AIR 3 which is an extremely solid option for delivering installed applications through app stores across devices. Installed mobile applications is an area where we have been very successful delivering on our cross-platform vision, so that’s where we’re going to invest. Additionally, I think that model more closely matches the way we use our devices; I think mobile browsers are primarily used for accessing content, and the tendency is to use installed apps for more interactive content like applications and games.

Another point I want to make is in response to Sarah’s comment yesterday about Flash working better on some devices than others. That’s true. Getting Flash to work consistently across all the chipsets that we support (and with all the different drivers out there — some of which are better implemented than others) is a huge amount of work, and requires a lot of engineering resources. At some point, we had to ask ourselves if we wanted to be the kind of company that continues to use resources to pursue something we weren’t convinced made sense just because it’s what we’ve always done, or if we wanted to be more forward thinking. I think we absolutely made the right decision.

It’s also worth pointing out that we’re still investing heavily in Flash in the areas where it makes more sense like installed mobile and desktop applications, and the desktop browser. Specifically, the Stage3D APIs we introduced in AIR 3 are going to provide an in-browser gaming experience like nobody has ever seen (look for videos of Unreal running in the browser), and the new APIs for hardware accelerated video are going to mean higher quality video that uses less CPU and battery. These are areas that HTML5 has not yet fully addressed, so Flash can lead the way. We will continue to use Flash for doing things that HTML can’t, and for the things that HTML can do, we will embrace it.

That brings me to my last point: I think there’s this perception out there that Adobe dislikes HTML, and that yesterday was somehow a bitter concession. As someone inside the company, I can tell you that there are a lot of us who are very excited about what we can do with HTML5. Personally, I’ve been researching and working on HTML projects for quite some time at Adobe, and I’ve been working with a lot of very smart people who are as passionate about it as I am. There are definitely people out there (both inside Adobe and outside) who are passionate just about Flash, but I think it’s more accurate to say that the overwhelming majority of us are simply passionate about the web, and about building awesome experiences. Flash has always been about providing functionality that HTML couldn’t, however now that HTML5 can provide a lot of that functionality, we’re going to have a lot of fun seeing what we can do with it.

So in summary, look for Adobe to continue to push Flash forward in areas that HTML doesn’t yet address, to push HTML forward with contributions to WebKit and tooling, and to provide cross-platform solutions in whatever technology makes the most sense.

If you want to hear it read on-air, it’s at the 45:00 mark in the video below.

What is an Offline Mobile Web Application?

An offline mobile web application has the following properties:

• It’s written in HTML, CSS, and JavaScript, and it’s served from a web server.
• It functions without an internet connection.
• When users save the application to their home screen, they get a custom icon and start-up image (the image that is displayed briefly on iOS while the app is loading and initializing).
• The application can be updated over the network just by opening it (as opposed to going through an app store).

The Components of an Offline Mobile Web Application

There are four primary pieces of functionality that offline mobile web applications need:

1. Configuration. For iOS devices, there are a few tags you can add to your application to make it look and act much more like a native application.
2. Custom icons and start-up images. To fit in with native applications, offline web applications should specify custom icons and start-up images for iOS.
3. Caching. Offline web applications use the HTML5 application cache to make themselves available offline.
4. Updating. Offline mobile web applications need to update the local cache when the application has changed on the server.

Configuration

On iOS, you can use several different meta tags to make your mobile web application look and feel much more like a native application. For instance, to get rid of the browser chrome when your application is launched from the home screen (in other words, to tell iOS to use a minimal web control rather than full-blow Safari to display your application), use the following tag:

<meta name="apple-mobile-web-app-capable" content="yes" />

To customize the look of the iOS status bar, you can use a meta tag with the "name" attribute set to "apple-mobile-web-app-status-bar-style". In my HTMLCompass example, I wanted the status bar to be as unobtrusive as possible, so I configured it to be black and translucent like this:

<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent"/>

Finally, it’s important to configure Safari’s viewport using a meta tag with the name "viewport". In order to configure the viewport properly for my HTMLCompass example (including preventing the user from zooming in and out of the application), I use the following tag:

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0"/>

For more information on configuring web applications on iOS, see Apple’s document, Configuring Web Applications. For a detailed description of everything you can do with your application’s viewport, see Viewport Settings for Web Applications.

Custom Icons and Start-up Images

Creating custom icons for your application is an important part of making it look like it belongs installed on a device. It’s not strictly necessary, but default icons (or icons derived from screenshots) will not give your application a high-quality, polished look and feel. (Note that I believe this is currently only supported on iOS devices; Android seems to use your "favicon" as your application’s icon, instead.)

Specifying custom icons is as easy as including one or more link tags in the <head> section of your application. The only trick is to make sure that you specify different icons for different screen resolutions. On iOS devices, that currently means icons for pre-retina screens (iPhone 3G and 3GS), retina displays (iPhone 4 and iPhone 4S), and the iPad. Below are the tags referencing the various icons for my HTMLCompass example:

<!-- Home screen icons -->
<link rel="apple-touch-icon" sizes="57x57" href="icons/apple-touch-icon-57x57.png" />
<link rel="apple-touch-icon" sizes="72x72" href="icons/apple-touch-icon-72x72.png" />
<link rel="apple-touch-icon" sizes="114x114" href="icons/apple-touch-icon-114x114.png" />

Specifying start-up images is almost as easy, however in addition to taking different screen resolutions into account, you also have to take into account different orientations for the iPad (iPhones and iPods can’t start applications in landscape mode). Below are tags referencing the three start-up images I created for my HTMLCompass example (note that I didn’t bother making one for the iPhone 3G or 3GS):

<!-- iPad -->
<link rel="apple-touch-startup-image" href="starts/ipad-landscape.jpg" media="screen and (min-device-width: 481px) and (max-device-width: 1024px) and (orientation:landscape)" />
<link rel="apple-touch-startup-image" href="starts/ipad-portrait.jpg" media="screen and (min-device-width: 481px) and (max-device-width: 1024px) and (orientation:portrait)" />
<!-- iPhone (retina) -->
<link rel="apple-touch-startup-image" href="starts/iphone-retina.jpg" media="screen and (max-device-width: 640px)" />

(Note that the size of these images must be exactly correct for them to function as expected.)

There’s a little more to know about configuring and specifying application icons. For instance, iOS automatically makes your icons appear three-dimensional and glossy by applying filters, however if you decide that you’d rather add such effects yourself, it’s possible to specify that your icons are "precomposed." For more information, see Apple’s documentation entitled Configuring Web Applications.

Caching

Caching your application so that it’s available for offline use is surprisingly easy. You essentially place a manifest file on your server which lists all the files that you want saved to the application cache. Below is the manifest file for HTMLCompass.com:

CACHE MANIFEST

# Version: 1.04

CACHE:
index.html
icons/favicon.png

You then need to reference the manifest file in your application’s <html> tag, like this:

<html manifest="compass.manifest">

That’s essentially it. For more information on the syntax of your manifest file (which supports additional functionality), see the cache manifest syntax section of the WHATWG offline web application specification.

Here are three important tips that will make working with cached web applications smoother:

1. Don’t forget to configure the MIME type on your web server (as described here). If you don’t map the extension of your manifest file to the MIME type "text/cache-manifest," you will not get the caching behavior you’re expecting.
2. I recommend adding a version comment to your manifest file (see example above). The version comment has no official use, however just making a change to your manifest file will cause your application to be re-downloaded. For example, if I change my index.html page without changing my manifest file, the local cache on the client will not be updated. After changing my index.html file, I can increment the version number in my manifest file which will cause the change to index.html to be picked up.
3. Once your application has been cached, the development process becomes more difficult. Specifically, after you make a code change, it will not show up in your browser until you update the cache with the new version. Rather than having to make a change to your manifest file in order to pick up your application changes, the best solution I’ve found is to simply change the reference to your manifest file in your <html> tag so that it points to something nonexistent. For instance, when I’m developing, I change the reference to my manifest file to compass.manifest.TODO. That causes a 404 which causes the application to be reloaded from the server rather than loaded from the cache. (The reason I append "TODO" is so I’ll find it while performing one last check of my code before checking it in.)

Updating

Now that you have your application caching, you need to know how to update it. There are four simple steps to updating an offline web application:

1. Change your manifest file so the browser knows to grab the new version (see previous section).
2. Listen for an event letting you know that the new version of your application has been downloaded and is ready.
3. Swap the old version for the new version.
4. Reload the page (optional).

Telling clients that a new version of your application is ready is as easy as making a change to your manifest file (updating the "version" comment, most likely). In order to be notified of when the new version is downloaded and the cache is ready to be updated, simply listen for the updateready event on the applicationCache like this:

window.applicationCache.addEventListener('updateready', ...);

Inside your event handler, tell the application cache to update itself like this:

window.applicationCache.swapCache();

Updating your application cache is an asynchronous operation meaning
it happens in the background while the old version of your application loads, renders, and executes. That means even though you have just updated the cache with the new version of your application, the user will still see the old version. You can either do nothing (so that users will see the new version the next time they use the app), or you can programmatically refresh the page with code like this:

window.location.reload();

To put it all together, my HTMLCompass example has a function called checkForUpdate which looks like this:

function checkForUpdate()
{
  if (window.applicationCache != undefined && window.applicationCache != null)
  {
    window.applicationCache.addEventListener('updateready', updateApplication);
  }
}

function updateApplication(event)
{
  if (window.applicationCache.status != 4) return;
  window.applicationCache.removeEventListener('updateready', updateApplication);
  window.applicationCache.swapCache();
  window.location.reload();
}

There are several other events thrown by the application cache that you can hook into in order to achieve various functionality. For instance, when your code detects that a new version of your application is available, you may choose to show the user a notification or even a progress bar indicating how much is still left to download. For a full list of application cache events, see the event summary section of the offline web application specification.