Whilst Google supports this in the satellite and hybrid maps, the basic ones still can’t be turned. Which is why I took CSS3 transformations (wrapped in a very useful jQuery plugin) and voila – rotating is possible:

Read more about the implementation and some of the things that need fixing in the original blog post about map rotation.

On the client side:

And the backend....

Nice!

I was recently reminded about Dmitry Baranovsky’s Javascript test, when N. Zakas answered and explained it in a blog post. First time I saw those questions explained was by Richard Cornford in comp.lang.javascript, although not as thoroughly as by Nicholas.

I decided to come up with my own little quiz. I wanted to keep question not very obscure, practical, yet challenging. They would also cover wider range of topics.

There are fourteen questions in all, starting here:

    (function(){
      return typeof arguments;
    })();

“object”

“array”

“arguments”

“undefined”

eBooks have gone mainstream, and right now the open ePub format is getting a lot of attention, being the iPad's book format of choice. Often overlooked in gadget-centric media is the fact that ePub is based on web standards, and therefore amenable to being rendered in the browser, sans plugins. Pure Javascript ePub readers are starting to crop up, and Keith Fahlgren has written about several of them:

Just in the last few days, details emerged of two new JavaScript ePub readers, rePublish from Blaine Cook (@blaine) and JSEpub (screenshot) from August Lilleaas (@augustl). These two new readers join @liza’s epubjs, which will be a year old on Tuesday. An improved version of epubjs powers the ePub Zen Garden, which helps “dispel the myth that digital books can’t also be crafted works of visual design.”

All are open source, and as Keith notes in the comments, there's also the commercial BookGlutton project. BookGlutton (which we covered earlier) shows the promise of browser-based eBooks: it lets you embed books as lightbox-powered widgets, and supports annotation.

The underlying structure of ePub is described on wikipedia:

EPUB consists of three specifications:
Open Publication Structure (OPS) 2.0, contains the formatting of its content.[5]
Open Packaging Format (OPF) 2.0, describes the structure of the .epub file in XML.[6]
OEBPS Container Format (OCF) 1.0, collects all files as a ZIP archive.[7]
Basically, EPUB internally uses XHTML or DTBook (an XML standard provided by the DAISY Consortium) to represent the text and structure of the content document, and a subset of CSS to provide layout and formatting. XML is used to create the document manifest, table of contents, and EPUB metadata. Finally, the files are bundled in a zip file as a packaging format.

In the case of unzipping, Keith points out the inflate library has been around since 1999. One can imagine other applications for zip too; for example, it's often used as a format for bundling code (Java JARs, Python Eggs, Firefox and Chrome extensions), so reliable unzipping makes it possible to build browser-based IDEs and exploration tools against such archives.

Louis Gorenfeld some very detailed explanations on how to fake 3D including some of the formulas used in the days of 8 bit.

He is also working on some demo code which you can help him with by providing some JS/Canvas demos:

I woke up the next morning to learn about this all and see a post that Román did talking about our hot linking. I immediately responded saying how sorry I am. I aim to highlight the great work that is done, not cause an issue.

Román is a great guy and kindly offered to collaborate and show friendship with Ajaxian (and myself) by putting together more amazing demos to share on the blog. Inline. Not hot-linking. :)

Here they are

These effects are CSS level 1 and 2.1 only. There is no javascript, css3 or whatever, just html and css.

They are all based on the CSS 2D displacement map technique that Román Cortés discovered when he created the infamous CSS Coke Can effect. Since displacement maps are very versatile, Román Cortés wanted to show us more and different applications of these.

The Ajaxian Prism

This is simple displacement map usage to distort the borders of the prism, with a transparent .png image on top to add the shadows, orange semi-transparent bg and the Ajaxian's "a" logo. The background painting is an original artwork by Román Cortés. Move the area around to see the effect the prism has on the underlying painting.

Van Gogh's Starry Night

Van Gogh's Starry Night separated in 3 layers and displacement map sinusoidal distortions applied to two of them.

Sliding and Slicing

A really simple displacement map + rearranged image makes this effect possible. Watch the window blinds do their thing as you move the scollbar.

The Coke Can spinning in the opposite direction of the original

There some comments in the original code can posting that the spinning direction was unnatural. So, here he did spin as the commenters wanted it. To make it possible, he had to mirror the label texture and adapt the source code.

The smashed can

By using several cylindrical displacement map layers with a growing radius and png transparent textures, it is possible to do voxel surface rotations like this one.

Thanks for Román for being so reasonable, and for creating such fun examples for us all. We hope to go deeper on the implementation of some of these examples in the future.

Mozilla Labs has released the magical 1.0 version of Weave and the doors are now open for developers.

When I was a part of Mozilla Labs day to day, I always loved the vision and team behind Weave. I kept wanting the implementation to match the vision, but it is a tough problem and it takes time to bake. Well, it is getting there now.

Weave is special because it offers a series of back-end services (more than just sync) that are build with users (and their privacy) in mind, rather than business models. I have talked to a couple of entrepreneurs recently and thought that there ideas could be implemented nicely on top of Weave.

It is still early days, but I am jazzed to see the platform getting opened up. I am hoping to get clients for Safari, Chrome, and IE.... and look forward to a webOS client too :)

Anthony Calzadilla has a fun Friday example for us. He has a tutorial on how he animated an AT AT using CSS.

He goes over the different areas and how he uses animation and transforms.

For example, the head of the beast:

Øyvind Kinsey is, and he just created jsContract an alpha library to give you some pre and post condition abilities.

Here is an example:

A lot of contract code for little functionality.... good old contracts ;)

It is interesting to read how Øyvind instruments the code. Run a test through the translator tool and you get:

One thing that got lost in the commotion of the extensions launch is a feature that is near and dear to my heart: Google Chrome 4 now natively supports Greasemonkey user scripts. Greasemonkey is a Firefox extension I wrote in 2004 that allows developers to customize web pages using simple JavaScript and it was the inspiration for some important parts of our extension system.

Ever since the beginning of the Chromium project, friends and coworkers have been asking me to add support for user scripts in Google Chrome. I'm happy to report that as of the last Google Chrome release, you can install any user script with a single click. So, now you can use emoticons on blogger. Or, you can browse Google Image Search with a fancy lightbox. In fact, there's over 40,000 scripts on userscripts.org alone.

Not all of the scripts will work. The deeper the integration, the less chance of success. We now have user scripts supported in a variety of browsers, and hopefully they get more and more portable.

If browsers could surface the functionality to mainstream users, good things could happen beyond us power users.

Well, they may not have been in a pub.... but a deadly duo did get together to try to solve this problem.

Dustin Moskovitz (Facebook co-founder and former CTO) and former-Googler/Facebooker Justin Rosenstein decided to try something different when they started to implement a Collaborative Information Manager tool at their new startup . They have created a new high level language that is part JavaScript, part Protocol Buffers. The language is LunaScript.

What was their motivation?

All of us on the Asana team have deep backgrounds writing rich web applications at companies like Google and Facebook. We've been continually frustrated by how long it takes to write software, and by a nagging feeling that in some deep sense we've been writing the same code over and over. Even when using the latest and greatest frameworks and disciplines, writing fast, highly interacting web applications involves a lot of accidental complexity:

First you need server code to figure out what data the browser needs. Hopefully you have an ORM layer, but you still need to carefully structure your code to minimize your backend dispatches, and you need to carefully keep that in sync with your front-end code lest you don't fetch enough data or hurt performance by fetching too much. If it's a Web 2.0-style app, you re-implement a ton of that server-side code in JavaScript, once for creating the page and then again as controller code for keeping it up to date and consistent. And when the user changes something, you bottle that up -- typically in a custom over-the-wire format -- and send it as an XHR to the server. The server has to de-serialize it into different data structures in a different language, notify the persistence store, figure out what other clients care about the change, and send them a notification over your Comet pipe, which is handled by yet more JavaScript controller code. Offline support? More code.

This is not a one-off task: it's rote work that adds complexity to every feature that you build in every application. By the time that you are done with all this, the important and novel parts of your application are only around 10% of your code. We wondered whether we could build a programming system in which we just wrote that 10% -- the essential complexity -- and a compiler handled the other 90%.

And this lead them to their solution:

Inspired by incremental computing, we're building Lunascript as a simple way to write modern web applications. Lunascript has a syntax and easy of use reminiscent of JavaScript, but a powerful pure-functional lazily-evaluated semantics historically confined to academic languages.

A Lunascript application specifes a data model and a function from the model to the view or user interface, annotated with handler functions from user inputs to model mutations. From this the Lunascript compiler produces a functioning Web2.0 application -- the client-side JavaScript, the server-side SQL, and everything in between -- complete with real-time bidirectional data synchronization. There's no need to write separate code to help the server figure out which values need to be sent to the client: the server can do this by simulating the UI. Because a LunaScript application only specifies how the UI should look given the current data (rather than how the UI should be updated as changes happen) it's impossible to write a UI that loads correctly but does not stay correct as changes are made.

"What does it look like?" I hear you cry. Time for a hello world, and since Comet is in the mix, that means a chat server:

You will notice the protobufferness at the top, and the fn of less characters, and E4X-like.

To learn more, let's listen in to Dustin as he gives us a walk through the world of LunaScript:

I talked to the guys and asked a few questions which they answered..... what questions do you have for them though? Are you excited about what a higher level abstraction could give you? Or do you like to be close to the metal?

The SVG-Edit team recently announced SVG-Edit 2.4, code named Arbelos. New features include:

- Raster Images
- Group/Ungroup
- Zoom
- Layers
- Curved Paths
- UI Localization
- Wireframe Mode
- Change Background
- Draggable Dialogs
- Resizable UI (SVG icons)
- Convert Shapes to Path

Try out the demo here:
http://svg-edit.googlecode.com/svn/branches/2.4/editor/svg-editor.html

Check out the project page:
http://svg-edit.googlecode.com

Read the release notes:
http://code.google.com/p/svg-edit/wiki/VersionHistory

Steve Jobs didn't hold back when talking about Google and Adobe. That is great. Life is so much more fun when people speak their mind. I remember hearing a story when Sir Steve was asked why mac keyboards where the way they were. He grabbed a PC keyboard and started to rip out "stupid keys" (print screen, F keys, and the like) and swore a lot.

We love to paint with broad black and white brushes these days don't we? Whenever I hear people talking about Google being "evil" or not.... I sit back and think about how interesting it is that companies become "people", especially in this country.

It makes sense when you look up Corporation:

Corporations are recognized by the law to have rights and responsibilities like actual people.

That may have been a convenient (and often almost genius) abstraction by lawyers, but it is screwed up. It feels like the times when you use inheritence in a way that isn't a ISA relationship, but it does kinda make the code nice. We have all done that, until we learned to favor composition. Corporations ISA Person? No. They are composed of them though.

I have been thinking about this ever since the recently surprise court decision the other day that "allows corporations and unions to pour unprecedented amounts of money into elections."

Lawrence Lessig had some interesting commentary:

The court decision does feel totally wonky to me. Right now, $ has a direct bearing on elections, and allowing multi-nationals (who have the money) to rain it down makes no sense.

Fun aside

My renaissance friend Graham Glass talks about how corporations can be considered a single conscious in his series on "the mind".

The issue with the vast number of corporations is that they are profit driven entities whose charter is to bring financial reward to shareholders. While you could argue that we as a species are driven by the selfish gene, corporations are driven by profits. Duh. Capitalism.

Google is a company. It is driven by this same goal. Now, there are various paths to a particular goal to make profits. Some companies sell things that kill people (weapons, cigarettes, etc). Others offer medical devices. All companies are not equal. Having spent time at Google, I do feel like the place isn't just an evil cult. The people that make up the consciousness were very driven strong willed people that cared about the company mission (universal access to information and all that) more than just the $. Sure some folks are focused on that. Also, although the wool could be placed over your eyes, the guys at the top of the chain have their hearts in the right place. While Larry and Sergey are there, decisions will be made that aren't solely based on profit. They want to create a different kind of legacy and company.

That being said, I think it is quite easy to fall into a trap such as:

If we do something here to block competition, we can make more $ and since we are Good Guys we can do better things with that money!

Google will sometimes do things that could be considered "evil" by some. That is life.

The good news with Google is that their search and ads business deals in a trust economy. It doesn't take much to switch from Google to Bing. Google knows that. Even though they have some HUGE advantages (technical [data centers, talent], brand, etc) the low barrier to change is huge.

Not all corporations are profit driven

I had the huge pleasure of working for Mozilla, which is a mission based corporation. Wow does that make life different. While you have to sustain yourself, it does mean that you think of the world very differently. You would rather go out in a blaze of glory doing something great for the mission, than just slowly die not doing much. Every choice you make .... you think of the mission.

It was interesting to work there knowing that I actually wouldn't want Firefox to be a 90% browser. You can fall into the similar trap as above and think:

We are mission based! If we had that domination we would use it for good!

But, not having that power in one hand is even better. Imagine working somewhere thinking "in my wildest dreams, the market would be shared somewhat evenly with the competition." The Open Web is amazing in that there is NO SINGLE VENDOR. If we are able to keep a decent balance between browsers (and thus the platform as we know it) then we have a balance of powers. Sure, in some ways you can't move as fast as a dictatorship, but there is a reason we don't want dictatorships in our government (even if the trains run on time!)

And, this brings me to the Adobe half of the Steve Jobs equation. Flash isn't dead. HTML5 is slowly going to put a dent into it if we ever get some of the use cases just right (e.g. video), but Adobe has a good penetration and can move at the speed of a dictatorship. The iPhone/iPad combo not shipping Flash will have an interesting dynamic here too, hopefully helping the HTML5 video cause. There is still much more work to be done. Flash and browser plugins have had a long history at forging new paths, and the Web can come in behind them and standardize. May that continue.

I do watch for single-owned platforms such as Flash, Silverlight, or now the Apple platform (even though they do great work on the HTML5 side of the house). I don't want any of those vendors to have too much power. The thought of a Web that required the use of their technology makes me shudder (we have a piece of that with Flash video). Right now I can turn off those plugins and life moves on. Sure I can't Hulu or Netflix, but that will change. I would miss some of the Flash sites that my kids use, but they could even be partially ported over to HTML5 these days.

I don't want to "kill" these other platforms as they offer competition and spur on the industry. I just don't want any one of them to take over. It may seem like the world would be better if we all just used Macs and iPhones and iPads, but would it? Do you think Steve would be a benevolent dictator?

Erm, no.

And thus I find myself torn. I really want to go out and by that iPad....... but when is it "too late". Surely I have a few years right? I can enjoy the shiny new toy? :)

Faruk Ate? also has a nice post on where he see's Flash going which is bolder than mine :)

What do you think?

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:

1. Should be convenient for authors to make any element in a page display fullscreen
2. Should support in-page activation UI for discoverability
3. 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.
4. Should accommodate potential UA security concerns, e.g. by allowing the transition to fullscreen mode to happen asynchronously after the user has confirmed permission

New API for all elements:

PLAIN TEXT

JAVASCRIPT:

1.  
2. void enterFullscreen(optional DOMElement element, optional Screen, optional boolean enableKeys);
3. void exitFullscreen();
4. boolean attribute supportsFullscreen;
5. boolean attribute displayingFullscreen;
6. //"beginfullscreen" and "endfullscreen" events
7.  

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.

Would you like a fullscreen API?

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.

The Freeciv.net crew has benchmarked a path in their canvas game. It is one data point, and tests more than just Canvas itself because a lot of code is running in the game. Thus, it ends up testing the union of a particular JavaScript path and the rendering of the canvas.

Here are the results:

With Bespin we had slightly different results, and the bulk of the bottleneck was in the blitting of the canvas. Optimizations were made to canvas over the initial phase of Bespin so the various browsers would leap frog each other. Good times :)

The key pieces used:

It helps to see the can and the wrapper that is placed around it.

[Edit: Fixed the hotlinking - well played Román - he Rick-rolled us]

Alex’s work is an alpha-prototype that shows the feasibility of the project and it requires a custom build of Firefox to use — it’s not easy to demo. However, the code sample below shows how the technology works. In this example, we are transposing a matrix at lightening speed:

PLAIN TEXT

JAVASCRIPT:

1.  
2. jetpack.statusBar.append({
3.   html: "Transpose!",
4.   onReady: function(widget){
5.     $(widget).click(function(){
6.       var myStorage = jetpack.cuda-storage;
7.       var matrix = new Array();
8.       var size = 32;
9.       for(var i=0; i<size *size; ++i)
10.         array[i] = i;
11.       var transposedMatrix = myStorage.transpose(size, matrix);
12.       transposedMatrix.forEach(function (v) { console.log( v ); })
13.     });
14. });
15.  

Alex discussed why this matters:

People are using the internet to collaborate more than ever before. Collaboration on the internet has been evolving at a rapid pace, and the applications and technology that will drive the next wave of internet collaboration will require even greater technical complexity and more significant computing resources than is currently available through the browser environment today. While text documents, videos, music, and image-base forms of collaboration are now common place, there are many needs require a level of compute performace beyond the web platform as it exists today, such as:

• consumption of high-quality digital video or music streams,
• complex image or speech recognition,
• manipulation and processing large pictures of nature or space,
• processing large sets of tabular data locally in the browser,
• complex animations with DOM elements (via DirectX or OpenGL),
• exploring 3D worlds, such as SecondLife or an OpenSim Grid,
• real-time audio and video editing,
• having an integrated development environment that runs entirely in the browser

There are endless examples of such complex uses of the internet platform that are just not feasible with the status quo web platform. Developers have tried to overcome such barriers in the past with client-side enhancements like ActiveX, Netscape Plugins, Java Applets, but each in its own way was flawed and failed to gain mass adoption. It is possible that the Native Client project will change all this, but standardization of such initiatives across the browser landscape is a lengthy endeavor. For the near future the tools that the developer uses to provide a rich user experience remain JavaScript and ActionScript, plug-ins, such as the ones previously mentioned, are significantly limited by the architectural mismatch of performance requirements they place on the CPU.

Ben tends to get a little giddy when he hears about GPU access :)

The study asks some interesting questions revolving around the development side of the tablet. Are developers going to develop for it? What are they looking for? What are they excited about from a technology perspective?

I found it interesting to see the type of companies looking to build apps:

Games will still probably be huge on the device, but it is great to see other types of apps at the ready.

Then we have the feature requests:

Even if there is a way to run iPhone apps, it is clear that people will be spending effort creating truly native experiences. There are core differences beyond screen size here. Very different capabilities to take into account.

We are seeing an increase in consumer devices. I recently talked about the table stakes of 2010 and beyond. As a consumer it is exciting to see the vision of connected devices become real. As a developer, although there is new opportunity, it is incredibly daunting. How many proprietary SDKs can one learn and fund development on?

This is where the Web comes in. The Web has the potential to become the unifying platform across devices. This isn't about write once run anywhere, but it is about offering advanced solutions to deliver experiences across the devices using shared code, services, and APIs.

Back to Appcelerator. They publish this study right before the tablet launch. Hmm.... something tells me that Titanium (now in mobile and desktop versions) will support Tablet. As companies struggle with the pull of delivering functionality to many devices, Titanium has an opportunity of helping developers out. We have heard that Titanium is going to GA some time soon (probably in March) and we will then see pricing plans and some new products (probably around analytics and metrics). Apparently more desktop and mobile applications will be developed using Titanium than Adobe AIR this year. That would be quite a feat.

What are your thoughts on the Tablet and the Web? What did you get out of the survey?

Here is Jeff talking about their work with Scoble:

Robert O'Callahan (moz layout guru) shares why he thinks Mozilla should stand firm on the H.264 issue comparing it to the ActiveX issue from the past.

With Chrome and Safari supporting H.264 (and not open video formats such as Ogg Theora) some users and developers have asked for Mozilla to support it too in Firefox. Mozilla is certainly a user-centric group (which is how they have gotten so far with Firefox) but remember that they are mission based: to keep the Internet open.

Here is some of RoCs opinion. I am glad he shared it:

Taking such positions is nothing new for Mozilla and history has proved us right for doing so, in particular regarding ActiveX and Web standards in general.

Perhaps it's not widely known, but Gecko has had code to support hosting ActiveX controls, dating back as far as 1999. ActiveX controls are very much like system video codecs. ActiveX support would have been very useful to users ever since 1999, and still would be now --- certainly in corporate intranets, and everywhere in China and South Korea. Enabling ActiveX support would probably boost our market share significantly. Most users have useful ActiveX controls on their machines. But for the last ten years, even during Mozilla's most desperate days, we have consistently refused to turn this feature on, because we believe that ActiveX is not good for the Web.

I'm not suggesting that the consequences of exposing system codecs to the Web would be identical to exposing ActiveX. That's unlikely, and unknowable. But favouring our principles over short-term gains for users is nothing new for Mozilla, and when we've done it in the past, history shows it was the right thing to do.

Chris Blizzard has a very detailed perspective too, linking up the history of GIF, MP3, and On2 :)