Shim was developed within the Boston Globe’s media lab as a way to study how Web sites look on various devices and browsers. A laptop intercepts all wifi traffic – this is redirected to a custom node.js server – which inserts a javascript, or “shim,” at the head of each web page that is visited.
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.
The awesome Guillermo Rauch and Nathan White have taken one of the Web code katas and played with it. Before the Web we had [wW]indows. Maybe that is why developers are keen to implement windows within the Web page, mainly to see if it can be done. We had the great Emil and Erik building desktops on the Web before we were in Web nappies. Now we have Ext Desktop, and many more.
The latest fun from Guillermo and Nathan is ChromeKit, which gives you windows that look like Google Chrome.
The one tweak to the code kata this time around, is their use of CSS3 goodness to show off skewing windows as they are tiled together.
Chris Winberry needed an HTML parser for a project he was working on and started to use John’s parser but found it to be a touch too strict for some of the HTML he was using (sloppy HTML? never). It was also too heavy to run on a server that would see considerable traffic, and so, being lazy, he wrote a new one from the ground up that is both light weight (extremely simple DOM) and very forgiving.
Which brings us to node-htmlparser which works in both Node:
Opera Mini made it into the Apple Store yesterday. People weren’t sure if it would make it in (as it duplicates functionality from Apple) but it did. This is good news. From playing with it myself, I feel a little like @gruber but what is more interesting to me is that there is room for innovation on the iPhone platform for browsers.
Firefox Mobile was exciting to me from a “what can a mobile browser do” perspective more than a “I get to use it” due to N900 and WinMo being the first platforms. I was excited to see that Dave Townsend grabbed the webOS PDK and started to play with a port:
The desktop has seen a rich space for innovation of browsing. By contrast we have seen awful browsers on mobile, and only recently have we seen quality on that side of the house. There has been innovation in the touch experience etc, but it feels like there is so much that we could do.
The richer UI of Firefox Mobile, plus Weave support, plus add-on support in general is fantastic.
Opera being smart about downscaling assets is fantastic.
But, there is more to be done, and hopefully we see Firefox on iPhone too!
Oh, and letting me set my own darn cache size would be nice too :)
How quickly do users actually upgrade their browsers? It’s a question that seems to come up frequently and is definitely on the minds of developers who want to know when they’ll be able to leverage the best features for their apps. Overall, I think the major browser makers try to share important usage information but the this specific data isn’t reported often enough. It was great to see that Pingdom did their own analysis of the issue and even offered a comparison of the upgrade mechanisms used by the browser makers.
From the report, it shows that Google’s Chrome has by far the fastest upgrade time of all the browsers, generally converting users within a month of a new release. This is very impressive and primarily due to the browser’s use of automatic updating.
Microsoft, Mozilla, Apple & Opera all take a milder approach with Mozilla being slightly more direct using user prompts that try to explain the benefits of upgrading instead of forcing them to.
It’s certainly a balancing act between keep users up-to-date and allowing users to have a choice. What do you feel is the best update solution?
Ben and I are often touting the fact that we are about to see amazing Web applications as browsers support more and more of “HTML5″ and the engines under the hood have become world class.
The GWT team has developed something that truly shows off this engine in their port of Quake2 to GWT. Seeing the game run with amazing fps in a browser, with online multiplayer network support via WebSockets, is something to truly behold.
Stefan Haustein, Ray Cromwell and Joel Webber were at a GWT summit and happened upon Jake2 the Java port of Quake2 that runs on top of JOGL for OpenGL. Ray could see that Joel had a glint in his eye, and the porting began!
To get the rich 3D graphics they went for WebGL using a GWT wrapper library that Stefan had built. Jake2’s heavy use of java.nio.Buffers were handled by implementing JRE classes that mapped those to WebGL typed arrays. File system code that used RandomAccessFile was emulated by using HTML5 LocalStorage. The OpenAL audio system was implemented using HTML5 audio.
The various team members got varying fps depending on their machines. A Linux notebook managed 60fps, a Mac Pro got 45fps, and a Macbook Pro got 25fps. WebKit was able to perform the best of the browsers right now because it doesn’t have the multi-process per tab tax that means a lot of OpenGL buffer copying.
I think this is a big deal in a couple of ways:
You can build fantastic games that use rich 3D engines and fast network access right on the Web. How do you “join a game”? You just share a URL! Tweet away! Now you can have these rich games just a URL a way. No install required.
Game engines push a platform. Although we are talking about building an older game engine (doubt that the latest and greatest engines would run like this!) this is PLENTY for building rich effects and applications. Take some of this richness and look at something like Google Docs. How much smoother and nicer can it be? We can create beautiful applications with effects like butter right now.
Credit
Ray Cromwell (who posted on this here) contributed audio/mouse/keyboard and localstorage for prefs, plus some minor GL shader debugging. Joel Webber and Stefan Haustein did the other 80% (Joel did the majority of the original code surgery to get the multiplayer game running under GWT minus graphics, Stefan did the heavy lifting on WebGL and singlehandedly ported the single-player game logic)
People still claim that “the browser is slow” and “JavaScript is slow”. Not in 2010 my friends!
Who needs Native Client now when you can build apps and games like this! Well, to be fair, there is a niche of folks who want to use C libraries and frankly prefer that world… so NaCl is for them.
For the rest of us though? Our world keeps getting better, almost daily!
Sputnik touches all aspects of the JavaScript language defined in the 3rd edition of the ECMA-262 spec. In many ways it can be seen as a continuation of and a complement to existing browser conformance testing tools, such as the Acid3 test. While we are always focused on improving speed, Sputnik is not about testing how fast your browser executes JavaScript, but rather whether it does so correctly.
Since we released the Sputnik tests as an open source project, the most requested feature has been the ability to run the tests in a browser, and we are excited to launch that functionality today. The new test runner lets you run the tests from a single URL and quickly see the results in your browser. This makes it easier both for users to see how well their browser conforms to the JavaScript spec, as well as for browser makers to find bugs and incompatibilities.
The dart board shows relative conformance based on the number of tests that hit or miss. Of course, in the real world, all tests are not equal. This has been an issue with Acid tests. The race to 100 is socially interesting, but if you miss a few core tests that could be worse than meeting 10 corner cases in SVG :)
What can you do if you want to enable a fullscreen experience on the Web? You can’t. Or, use Flash. Some claim that you shouldn’t offer this ability as it is a security liability. Someone can put a fullscreen view that tricks the user into giving it information.
However, as much as I think user security is important, it doesn’t seem like we can punt and not do anything because of this. A user agent can do a lot of things to help out.
Some (majority?) of the use cases revolve around full screen video. Eric Carlson has a WebKit checkin that enables that one case. You can webkitEnterFullScreen() on a HTML5 video element and be on your way.
You can see this in action on the SublimeVideo HTML5 player. Play the video in WebKit nightly and alt-click the “full size” arrows.
Video is great, but what about general purpose? What if you could fullscreen any element? Robert O’Callahan threw up a strawman:
Should be convenient for authors to make any element in a page display fullscreen
Should support in-page activation UI for discoverability
Should support changing the layout of the element when you enter/exit fullscreen mode. For example, authors probably want some controls to be fixed size while other content fills the screen.
Should accommodate potential UA security concerns, e.g. by allowing the transition to fullscreen mode to happen asynchronously after the user has confirmed permission
While an element is fullscreen, the UA imposes CSS style “position:fixed; left:0; top:0; right:0; bottom:0″ on the element and aligns the viewport of its DOM window with the screen. Only the element and its children are rendered, as a single CSS stacking context.
enterFullscreen always returns immediately. If fullscreen mode is currently supported and permitted, enterFullscreen dispatches a task that a) imposes the fullscreen style, b) fires the beginfullscreen event on the element and c) actually initiates fullscreen display of the element. The UA may asynchronously display confirmation UI and dispatch the task when the user has confirmed (or never).
The enableKeys parameter to enterFullscreen is a hint to the UA that the application would like to be able to receive arbitrary keyboard input. Otherwise the UA is likely to disable alphanumeric keyboard input. If enableKeys is specified, the UA might require more severe confirmation UI.
In principle a UA could support multiple elements in fullscreen mode at the same time (e.g., if the user has multiple screens).
enterFullscreen would throw an exception if fullscreen was definitely not going to happen for this element due to not being supported or currently permitted, or if all screens are already occupied.
Much talking of exact API issues and more security…. but hopefully inertia does it job and we get something.
