The shim, once loaded in a device’s browser, opens and maintains a socket connection to the server, according to to Shim’s developers. Shim was written in 2011 by Chris Marstall, Creative Technologist at the Boston Globe. The software has been open sourced. Write the Shim originators on git.hub:

Whenever a new page is requested, the page’s URL is broadcast to all connected browsers, which then redirect themselves to that URL, keeping all devices in sync. Shim info is available on git.hub.

In conjunction with the release of Platform Preview 7, we wanted to give the community the opportunity to ask questions of some of our IE and Chakra engineers. So we’re going to host a 2-hour Q&A chat on Twitter tomorrow morning beginning at 9am PST.

They’ll be fielding questions starting tomorrow Thursday, November 18th from 9-11am PST and you can participate by sending your questions to @ie and using the hashtag #ie9.

Check out the blog post for full details of the Q&A session.

Full Disclosure: I work for Microsoft.

• Touch event support for mobile interfaces including flick and move gestures
• Browser capability loading – which means that every browser gets the least amount of code necessary to make it work
• Transition support for the animation module – meaning only browsers that don’t support CSS3 transitions get the JavaScript animation fallback
• An update to the CSS grids to allow for more flexible layouts
• A ScrollView widget similar to the one in Apple iOS
• The uploader has been transitioned over from YUI2 to YUI3

So check out what is on offer and give the YUI team feedback on what would be nice to have and what is broken. In their own words:

The goal of a preview release is to make it as easy as possible for all of us in the community to evaluate progress of the upcoming release and provide feedback. Please take some time to test 3.2.0pr1 and let us know what you find by filing tickets in the YUI 3 bug database marked as “Observed in version” 3.2.0pr1. We’ll do our best to address preview-release questions on the YUI 3 Forums, too.

There are three ways to get started with the preview release: YUI 3.2.0pr1 is available on the CDN via the 3.2.0pr1 version tag — so you can reference preview-release files like http://yui.yahooapis.com/combo?3.2.0pr1/build/yui/yui-min.js. If you switch to this seed file for the preview release, all subsequent use() statements will continue to load YUI 3.2.0pr1. Or You can download the full YUI 3.2.0pr1 from YUILibrary.com, including source code and examples for all components. Or you can simply explore the functioning examples roster.

Probably the most impressive thing (next to the new Add-Ons Builder based on Bespin) was the upcoming Features of Firefox 4:

• HTML5 Video display
• Painting with Canvas
• Image manipulation with Canvas – pixel testing, face detection with opencivitas
• Green screen technologies in images and video by detecting pixel colours.
• HTML5 embedded inside SVG (yes!)
• SVG as an IMG
• SVG as a CSS background
• SVG filter/mask/clip
• SVG animations
• Inline SVG inside HTML5
• CSS3 (selectors, @font-face, 2D Transforms, Transitions, Shadow, Gradients ,calculations – calc(2em-10px) )
• APIs: Geolocation, Offline (IndexDB, localStorage, AppCache, FileAPI – binary content of a file input, file drag and drop, web workers, websockets)
• Websockets controller running the presentation from the mobile.
• WebGL

They proved some of the points with demos:

CSS3 filters and SVG masking on HTML5 Video:

Highly interactive video interface with SVG masking and transitions:

WebGL in Firefox 4 and on Android:

After this, Tristan Nitot covered some of the other features of Firefox 4, especially the upcoming speed improvements:

As to upcoming features to the core of Firefox, we heard about:

• TraceMonkey (a new Javascript engine)
• Lazy Frame Construction
• Reducing I/O from the main thread
• Improved startup Time
• Hardware accelleration
• GPU text/graphics/video rendering
• Using GPU for text rendering
• JavaScript JIT (JaegerMonkey)
• HTML5 parser running own thread
• slicker interface
• no more modal dialogs
• no startup interuptions
• updates in the background

For an in-depth report on all the things shown, check out this live blog post.

The Web is getting some new DPI love, and the new iPhone 4 display personifies this fact. The new display is fantastic for the consumer, and an opportunity for the design enlightened to build truly beautiful web sites. There is a big difference:

However, how do we as developers deal with this new world?

Aral Balkan has a nice post that goes into detail on the new opportunity and shares samples and ideas.

As with so many things on the Web, some of this has been thought of a loooong time ago. Dave Hyatt wrote about this back in 2006.

Walt Dickinson put together a guide to the retina display and using CSS3 media queries:

Aral explains that "in the Retina-specific CSS, he loads in 32x32 icons as background images and specifies their dimensions in CSS pixels as 16x16 using the background-size CSS property."

It is interesting to see a device pixel ratio used rather than specifying a DPI itself.

What else can be done to help folks in this new world?

Aral talks about how the browser could natively help via convention:

I'd like to suggest that browsers adopt the same naming convention that Cocoa Touch uses to find and load high-DPI versions of image and video assets. That is, if I embed an image using the following code…

PLAIN TEXT

HTML:

1.  
2. <img src="flower.jpg" alt="A beautiful rose"/>
3.  

… it should load in flower.jpg when the device-pixel-ratio is 1 but it should attempt to find an image called flower@2x.jpg at the same relative path if device-pixel-ratio is 2 (and so on, for higher pixel-ratios), falling back to the original graphic if it can't find a high-resolution version.

(And the same convention could be used to load video assets.)

Maybe there are server side techniques that could be put in place to automatically serve up the most optimized image for a given DPI. This would stop a bunch of 404s, but requires more work on the part of the server monkey.

This is good news for SVG and libraries like Raphael, who are well suited for scaling. When playing with an iPhone 4 it was amazing how quickly you noticed the bitmaps that were too low res... they stick out like a sore thumb. Expectations have changed.

What else can we do?

The honourable PPK has detailed the leap forward with CSS (in between watching his Dutch team do well in the World Cup. Not that I am friggin jealous ;)

The sea of green on the CSS compat tables is fantastic news for the Web:

More on IE9 and CSS from PPK:

IE9 promises to be an excellent browser. Its CSS support is now at par with that of the other browsers — although each browser still has its specific areas where it performs less. But we cannot in good faith say that IE is behind the others any more.

There are only a very few declarations in my test that IE9 does not support. CSS columns, gradients, text-shadow, resize, and text-stroke are the only ones, and the latter two are WebKit-only.

Even better news: Microsoft’s filters seem to have just disappeared from IE9. It supports normal opacity; no more filters required. Also, the gradient filter is gone, leaving IE (temporarily?) not supporting it.

Another golden oldie that got dropped is cursor: hand, the MS proprietary alternative to cursor: pointer. That’s not really important in practice (IE6 already supported both syntaxes), but it’s a powerful symbol of the changes that the IE team has wrought.

With so much excellence around I was almost glad when I found one single bug: IE9 doesn’t handle white-space: pre-line right. This bug will be fixed, though. It’s typically a minor point that crops up in a beta and is removed from the final product.

And, it isn't just CSS that is turning green. Kangax does a fantastic job at looking at JScript and the DOM. Not only does he show the good, but also the areas that still need improvement such as:

Unfortunately, the entire host objects infrastructure still looks very similar to the one from IE8. Host objects don’t inherit from Object.prototype, don’t report proper typeof, and don’t even have basic properties like “length” or “prototype”, which all function objects must have.

Kangax is doing a lot of good here. The more tests and call outs on what IE needs to do to be standards compliant the better. With the new rate of progress from the IE team, it isn't like the old days where you thought you were talking to deaf ears. Microsoft is listening, and even better than that, they are doing. Now is the time to give them as much info as we can.

What would you like to see?

With the third platform preview, we introduce support for the HTML5 Canvas element. As you know our approach for standards support is informed both by developer feedback and real word usage patterns today, along with where we see the web heading. Many web developers have asked us to support this part of HTML5 and we definitely took this feedback into account as we prioritized our work.

Like all of the graphics in IE9, canvas is hardware accelerated through Windows and the GPU. Hardware accelerated canvas support in IE9 illustrates the power of native HTML5 in a browser. We’ve rebuilt the browser to use the power of your whole PC to browse the web. These extensive changes to IE9 mean websites can now take advantage of all the hardware innovation in the PC industry.

Preview 3 completes the media landscape for modern websites with hardware accelerated video, audio, and canvas. Developers now have a comprehensive platform to build hardware accelerated HTML5 applications. This is the first browser that uses hardware acceleration for everything on the web page, on by default, available today for developers to start using for their modern site development.

The third platform preview continues to support more of DOM and CSS3 standards that developers want. Examples here include DOM Traversal, full DOM L2 and L3 events, getComputedStyle from DOM Style, CSS3 Values and Units, and CSS3 multiple backgrounds.

Also included in the third platform preview is support for using the Web Open Font Format (WOFF) through CSS3 font face.

Oh, and Acid3 is coming along too..... as well as a lot of performance improvements.

Congrats to the IE team.

The Chrome and HTML DevRel team at Google have released a new portal, HTML5 Rocks, that packages together some of the great resources available on HTML5 and the renaissance of browsers.

Whether it be references on what you can do, to readiness to shims to get use features now.

Beyond the resources, there is the killer HTML5 Slide Presentation and interactive playground.

A lot of nice stuff, all in one place. This is the first release, and we are sure to see a lot of additions coming soon. What would you like to see?

“A man's got to do what a man's got to do.” said the cowboy John Wayne. Mozilla's new intern with the same name knows that Mozilla needs to do... and it needs to do performance. It isn't just about JavaScript performance though, the battle for the hearts and minds is perceived performance. This is a tough game for Mozilla as the average user giving Chrome a shot is doing so on a fresh browser with no history, bookmarks, or add-ons. If you download a fresh Firefox nightly you may be surprised at how fast it is!

John has been doing some analysis comparing the perceived performance compared to Chrome:

and came up with some recommended actions for the team:

• With just a few changes in the Firefox start-up process, we could greatly enhance the feeling of Firefox’s speed. The changes listed below are recommendations to help better the overall Firefox experience.
• Draw the OS spinner icon as little as possible, but one solid break isn’t bad and might be better than one really long spinner.
• Draw the browser chrome while the window is being animated (drawn) to size. So that most of the drawing happens simultaneously rather than sequentially.
• Make a new ‘website loading’ icon with less visual weight that animates faster but is slightly larger (would allow a user to ‘see’ the faster animation).
• ‘Lazy’ load tabs that are being restored (already being talked about).
• Load upgrades and add-on updates upon browser close, not browser start.
• Delay loading the website’s title until the website is ready for interaction.

*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.

“Safari continues to lead the pack in performance, innovation and standards support,” said Philip Schiller, Apple’s senior vice president of Worldwide Product Marketing. “Safari now runs on over 200 million devices worldwide and its open source WebKit engine runs on over 500 million devices.”

Safari Reader makes it easy to read single and multipage articles on the web by presenting them in a new, scrollable view without any additional content or clutter. When Safari 5 detects an article, users can click on the Reader icon in the Smart Address Field to display the entire article for clear, uninterrupted reading with options to enlarge, print or send via email.

Powered by the Nitro JavaScript engine, Safari 5 on the Mac runs JavaScript 30 percent faster than Safari 4, three percent faster than Chrome 5.0, and over twice as fast as Firefox 3.6.* Safari 5 loads new webpages faster using Domain Name System (DNS) prefetching, and improves the caching of previously viewed pages to return to them more quickly.

Safari 5 adds more than a dozen powerful HTML5 features that allow web developers to create media-rich experiences, including full screen playback and closed captions for HTML5 video. Other new HTML5 features in Safari 5 include HTML5 Geolocation, HTML5 sectioning elements, HTML5 draggable attribute, HTML5 forms validation, HTML5 Ruby, HTML5 AJAX History, EventSource and WebSocket.

The new, free Safari Developer Program allows developers to customize and enhance Safari 5 with extensions based on standard web technologies like HTML5, CSS3 and JavaScript. The Extension Builder, new in Safari 5, simplifies the development, installation and packaging of extensions. For enhanced security and stability, Safari Extensions are sandboxed, signed with a digital certificate from Apple and run solely in the browser.

Some great features in there. Let's get into some details:

Performance

Sam Pullara quickly ran Sun Spider on Chrome 6.0.422.0 and Safari 5 and the result is very close to a dead heat:

Safari 5 Total:         279.2ms +/- 1.9%     | Chrome 6 Total:      274.6ms +/- 6.2%
-------------------------------------------- | --------------------------------------------
  3d:                    36.0ms +/- 2.4%     |   3d:                   43.6ms +/- 18.0%
    cube:                12.8ms +/- 4.3%     |     cube:               16.0ms +/- 11.0%
    morph:               10.6ms +/- 6.4%     |     morph:              14.6ms +/- 32.2%
    raytrace:            12.6ms +/- 5.4%     |     raytrace:           13.0ms +/- 11.7%
                                             |
  access:                32.2ms +/- 5.0%     |   access:               30.6ms +/- 11.0%
    binary-trees:         5.4ms +/- 12.6%    |     binary-trees:        1.4ms +/- 48.6%
    fannkuch:            12.8ms +/- 4.3%     |     fannkuch:           12.2ms +/- 4.6%
    nbody:                8.6ms +/- 7.9%     |     nbody:              13.8ms +/- 17.3%
    nsieve:               5.4ms +/- 20.6%    |     nsieve:              3.2ms +/- 17.4%
                                             |
  bitops:                17.6ms +/- 13.8%    |   bitops:               22.6ms +/- 6.3%
    3bit-bits-in-byte:    2.4ms +/- 28.4%    |     3bit-bits-in-byte:   1.6ms +/- 42.6%
    bits-in-byte:         5.2ms +/- 10.7%    |     bits-in-byte:        5.8ms +/- 9.6%
    bitwise-and:          4.0ms +/- 69.5%    |     bitwise-and:         7.0ms +/- 0.0%
    nsieve-bits:          6.0ms +/- 0.0%     |     nsieve-bits:         8.2ms +/- 6.8%
                                             |
  controlflow:            2.8ms +/- 19.9%    |   controlflow:           2.4ms +/- 28.4%
    recursive:            2.8ms +/- 19.9%    |     recursive:           2.4ms +/- 28.4%
                                             |
  crypto:                16.6ms +/- 4.1%     |   crypto:               19.0ms +/- 9.3%
    aes:                  9.6ms +/- 7.1%     |     aes:                 7.6ms +/- 14.6%
    md5:                  4.0ms +/- 0.0%     |     md5:                 5.6ms +/- 12.2%
    sha1:                 3.0ms +/- 0.0%     |     sha1:                5.8ms +/- 9.6%
                                             |
  date:                  34.6ms +/- 2.0%     |   date:                 28.2ms +/- 7.2%
    format-tofte:        20.0ms +/- 0.0%     |     format-tofte:       13.4ms +/- 8.3%
    format-xparb:        14.6ms +/- 4.7%     |     format-xparb:       14.8ms +/- 7.0%
                                             |
  math:                  26.2ms +/- 4.0%     |   math:                 29.4ms +/- 8.8%
    cordic:               7.6ms +/- 9.0%     |     cordic:              9.4ms +/- 25.8%
    partial-sums:        13.0ms +/- 0.0%     |     partial-sums:       15.2ms +/- 10.7%
    spectral-norm:        5.6ms +/- 12.2%    |     spectral-norm:       4.8ms +/- 11.6%
                                             |
  regexp:                12.8ms +/- 4.3%     |   regexp:               16.0ms +/- 0.0%
    dna:                 12.8ms +/- 4.3%     |     dna:                16.0ms +/- 0.0%
                                             |
  string:               100.4ms +/- 1.4%     |   string:               82.8ms +/- 2.0%
    base64:              11.6ms +/- 5.9%     |     base64:              6.6ms +/- 10.3%
    fasta:               14.0ms +/- 0.0%     |     fasta:              12.0ms +/- 0.0%
    tagcloud:            23.0ms +/- 0.0%     |     tagcloud:           23.8ms +/- 5.7%
    unpack-code:         35.2ms +/- 3.0%     |     unpack-code:        29.0ms +/- 0.0%
    validate-input:      16.6ms +/- 4.1%     |     validate-input:     11.4ms +/- 6.0%

Standards

Now, lets look at how they size up in BrowserScope:

Incredibly close. Not that it should be a shock, since both parties are using WebKit under the hood (although the JS engines are totally different, and many other differences!)

Extensions

Panic were up on stage showing off Code Notes, a nice example of extensions for Safari:

The Coda Notes extension is built entirely in JavaScript, HTML, and CSS; the extension bar is basically an HTML file, and the page-flip effect is accomplished using a CSS transform. We draw on a transparent canvas element injected over the target page. Live text editing is done by setting the contentEditable attribute on the body of the page, thus turning Safari into an editor.

Great to see the new extension mechanisms on the Web are all of the Web (Chrome, Safari, Jetpack). Very cool indeed.

Erm. Hmm. Faruk has it right:

The point isn't that all of the examples should work in all browsers, but that it most of them actually do.... which you can see if you fake the user agent or monkey with the JS to let you through.

The point isn't that Apple shouldn't be touting Safari as a great browser. We have seen other sites such as Chrome Experiments and Mozilla Hacks that showcase what those browsers can do, but they also don't block other browsers.

In general, it is good to showcase HTML5 samples, and hopefully the team will turn on feature detection and we can focus on the good side of things. There are some nice demos here!

A bunch of people are saying "wait a minute! only 2 of the demos are HTML5." Remember guys, HTML5 has become the term for "anything cool in the browsers." It is the new Ajax. It isn't about what is in one particular spec.

He discusses how search engines themselves could show interesting information on extensions:

Now search engines could go back to being app stores ;)

Beyond that, the browser itself could be told about a related extension. Others have talked about this of course.

I wrote about AppDiscover an experiment at doing just this for not only extensions but applications themselves. The browser should have a generic way to be told about related work, and could surface to users in interesting ways. If we can agree on the semantics, then we could put together quick extensions to do this, and hopefully browsers will bake this in.

The full video is also available which goes into detail on the main themes of the next release of Firefox (3.7 is dead, long live 4!)

• Fast: making Firefox super-duper fast
• Powerful: enabling new open, standard Web technologies (HTML5 and beyond!),
• Empowering: putting users in full control of their browser, data, and Web experience.

What do developers get?

• Bidirectionally connected apps (Web Sockets)
• Better Ajax-y interactions (PushState)
• New interactions (gesture + multi-touch)
• Easier layout and styling (CSS3)
• HTML5 Parser
• Content creation (contentEditable, HTML5 forms)
• Structured data storage (IndexedDB)

You would have guessed at most of these, but maybe not the WebSimpleDB/IndexedDB one. If a project has "simple" in the name, it normally isn't.... just like when a project has "open" in the name. It is a strange name since we have simple storage through localStorage and friends.

IndexedDB is a better name, and it is interesting stuff. Instead of the SQL databases that require standardizing on a version of SQLite (which is insane) it is JSON native. You work with the data store like this:

and you can go native JSON with the object store:

Take a look at all of the low level cursor code and you may cry a little :)

Back to Firefox 4. The media loves a binary black vs. white view of the world. Flash is Dead. HTML5 is saviour. Chrome is "the winner". IE is over. Regardless of any actual numbers.

Alpha geeks are big on Chrome these days, but Firefox has massive numbers and is still doing well, despite the fact that, in my opinion, better days are to come. Firefox will catch up on the technology side with multi-process and their new JagerMonkey VM work. Performance will become table stakes yet commodity. Where Firefox can shine is where no other browser will go. Mozilla is mission based and cares about users in a more holistic way. This is the empower goal. You should own your data. Your browser should do more for you (not just get out of the way). Firefox is uniquely positioned for this, and you can see the start of the work via the Contacts work from Mike Hansen.

Also note how the team is discussing Firefox 4. Totally in the open. What will Safari 5 have? Chrome 6 has platform status, IE9 is doing a better job.... but no one does it as well as Mozilla IMO.

I look forward to the continued browser competition. Great news for us developers!

Today, they updated the preview as they said they would (claiming they will do new releases every 8 weeks or so).

Table stakes these days is performance. IE8 is so far behind, but the IE team is showing that with IE9 they will be strong contenders:

To go along with this, we haver the GPU story of hardware acceleration. Test drive some new demos such as this Flickr Explorer or the browser flip

There are other tools too:

The Developer Tools in IE9 Platform Preview 2 include new features. The Console window is now a full tab that includes diagnostic information from IE. Developers can use the “Change User Agent String” menu item to experiment with sending different that UA strings to sites with every request, selecting from preset strings or creating their own custom string. This complements another feature we’ve included – the new IE9 UA string. (Steve! Update BrowserScope! :)

This is good timing. Giorgio Sardo of Microsoft is on a browser panel that Ben and I are moderating at Web 2.0 Expo today. The panel has other heavy hitters: Douglas Crockford (Yahoo!), Brendan Eich (Mozilla), Charles McCathieNevile (Opera Software), and Alex Russell (Google). We are going to have some fun :)

First we have the performance. It is cool that they only compare with themselves:

Seeing V8 get faster is exciting for me personally. Not only does it mean Chrome gets faster, but I also get the advantage of a faster webOS and a faster node.js!

Then we get the HTML5 features that aren't hidden behind runtime flags:

Under the hood, today's release contains the goodness of some new HTML5 features, namely Geolocation APIs, App Cache, web sockets, and file drag-and-drop capabilities.

And in the global market share game, at least according to net applications, IE is below 60%:

This is great news, and I hope that we continue to see that pie spreeeead out nicely. A nice balance of IE, Firefox, Chrome, and others would be very nice to see indeed. The browsers are doing solid work right now. My Firefox nightly is starting to scream, and still is second to none in the "get it to do exactly what I want" category. It continues to be a fun 2010 :)

The initial work has been taken to the next level with the Account Manager Add-on by Dan and co:

How Does It Work?

The Account Manager specification proposes two small changes to Web sites:

1. The browser needs to know how to register, sign in, and sign out of your site. You will need a static JSON document, automatically discovered by the browser, which describes what methods the site supports and how they should be executed. For example, a web site might describe their support of “connect” (sign in) like this:
   PLAIN TEXT
   JAVASCRIPT:

   1.  
   2.   "methods": {
   3.     "username-password-form": {
   4.       "connect": {
   5.         "method": "POST",
   6.         "path": "/accounts/LoginAuth",
   7.         "params": {
   8.           "username": "Email",
   9.           "password": "Passwd"
   10.       }
   11.   }
   12.  

   This example tells the browser that the site supports signing in with a form POST to /accounts/LoginAuth, and what parameter names to use for the username and password (Email and Passwd respectively).

2. The browser needs a way to check which user (if any) is currently signed in. To do this, you need to set an HTTP header in the same code where you would set a cookie with a session ID. If you can’t set an HTTP header, you can also supply a URL the browser will ping.

   The header would look like this:

   X-Account-Management-Status: active; name="Joe User"
   

   That would tell the browser that “Joe User” is now signed in, so it can provide the appropriate UI (to switch users or sign out).

Read the full specification for more.

He created a browser survey form to capture information on the size of peoples cache, and this jumps out at you:

The data shows that 55% of people surveyed have a cache that’s over 90% full.

And we wonder why our servers are often serving up content to empty caches? Here Steve tells the story:

In 2007 Tenni Theurer and I ran an experiment to measure browser cache stats from the server side. Tenni’s write up, Browser Cache Usage – Exposed, is the stuff of legend. There she reveals that while 80% of page views were done with a primed cache, 40-60% of unique users hit the site with an empty cache at least once per day. 40-60% seems high, but I’ve heard similar numbers from respected web devs at other major sites.

Why do so many users have an empty cache at least once per day?

I’ve been racking my brain for years trying to answer this question. Here are some answers I’ve come up with:

• first time users – Yea, but not 40-60%.
• cleared cache – It’s true: more and more people are likely using anti-virus software that clears the cache between browser sessions. And since we ran that experiment back in 2007 many browsers have added options for clearing the cache frequently (for example, Firefox’s privacy.clearOnShutdown.cache option). But again, this doesn’t account for the 40-60% number.
• flawed experiment – It turns out there was a flaw in the experiment (browsers ignore caching headers when an image is in memory), but this would only affect the 80% number, not the 40-60% number. And I expect the impact on the 80% number is small, given the fact that other folks have gotten similar numbers. (In a future blog post I’ll share a new experiment design I’ve been working on.)
• resources got evicted – hmmmmm

OK, let’s talk about eviction for a minute. The two biggest influencers for a resource getting evicted are the size of the cache and the eviction algorithm. It turns out, the amount of disk space used for caching hasn’t kept pace with the size of people’s drives and their use of the Web. Here are the default disk cache sizes for the major browsers:

• Internet Explorer: 8-50 MB
• Firefox: 50 MB
• Safari: everything I found said there isn’t a max size setting (???)
• Chrome: < 80 MB (varies depending on available disk space)
• Opera: 20 MB
• Those defaults are too small. My disk drive is 150 GB of which 120 GB is free. I’d gladly give up 5 GB or more to raise the odds of web pages loading faster.

Even with more disk space, the cache is eventually going to fill up. When that happens, cached resources need to be evicted to make room for the new ones. Here’s where eviction algorithms come into play. Most eviction algorithms are LRU-based – the resource that was least recently used is evicted. However, our knowledge of performance pain points has grown dramatically in the last few years. Translating this knowledge into eviction algorithm improvements makes sense. For example, we’re all aware how much costlier it is to download a script than an image. (Scripts block other downloads and rendering.) Scripts, therefore, should be given a higher priority when it comes to caching.

Time to bump the default size, and get some smarter algorithms in place. Or, you can always run a cache server like polipo ;).

Here is what Lindsey says:

It seems like nearly every week we read about an interesting new hosted test for people to visit and run their browsers through (recent examples include html5test.com and findmebyip.com). Developers really love to poke at the black boxes they code for - and the matrix of browsers, OS, and networks is enormous. One thing I, and I presume other developers, would love to see are the aggregated results for these tests by user agent. Considering this is exactly what we built Browser to accomplish for our test categories, and that a user-hosted test feature has been on our Roadmap, the Browserscope team is happy to announce that we're opening up an alpha of our User Tests feature.

Conveniently, this past week a User Tests use case came up for me at work and so it's been a driver for building this feature. We began working on a UI component that we wanted to test for speed of task completion. After building up a test page with a timer and some deltas it dawned on me just how cool it would be to open up this test to the world, and aggregate the results. The test is kind of strange in that the the UI component is out of its context, and you can argue about the mechanics of the test itself, but I still feel like the results may be informative. Interestingly too, this test is exactly the kind of thing we would *not* want to feature on the homepage of Browserscope (it's more of a performance test than a spec/binary test). And yet, the backend system with its median aggregation, scalability, and user-agent parsing library is a perfect fit. So check it out - and see how other people are doing on the test (courtesy of Browserscope).

This is definitely a release early/often feature, and we want to be explicit that things may change or break in the API while we're in alpha mode. We may have to take the service offline briefly to fix things. But if you write tests for browsers and want to aggregate your results, sign in to Browserscope, register your test page and then read the HOWTO to start saving your results in the system. Please send any feedback to me or to our mailing list. We really hope to make this an easy system to use for the tests you're already hosting.

I hope that we see a bunch of tests in there. One advantage of the browser scope approach is that it self-updates. A lot of the other sites are static, and when new browser versions come out the new feature data isn't reflected. It could be cool for example, if the readiness visualization pulled the data from a JSON feed from BrowserScope :)

Thanks for doing this Lindsey and team!

Want to do it too? Check out the APIs and how you can do it all, including showing the thumbnails: