Flickr, Viddler, Qik, Pownce and Revision3 are the first services to support oEmbed, an easy way to allow embeding media from a certain URL in a third party site.
oEmbed is a format for allowing an embedded representation of a URL on third party sites. The simple API allows a website to display embedded content (such as photos or videos) when a user posts a link to that resource, without having to parse the resource directly.
This means that if you for example find a nice photo on flickr, you can take the URL and easily turn it into embed-able data:
John Resig has completed 7 months of work to produce a port of Processing, the "programming language and integrated development environment (IDE) built for the electronic arts and visual design communities", which aims to teach the basics of computer programming in a visual context, and to serve as the foundation for electronic sketchbooks. One of the stated aims of Processing is to act as a tool to get non-programmers started with programming, through the instant gratification of visual feedback."
The first portion of the project was writing a parser to dynamically convert code written in the Processing language, to JavaScript. This involves a lot of gnarly regular expressions chewing up the code, spitting it out in a format that the browser understands.
The language includes a number of interesting aspects, many of which are covered in the basic demos. Here's a brief selection of language features that are handled:
Types and type casting - Type information is generally discarded, but becomes important in variable declaration and in casting (which is generally handled well).
Classes - The full class system is supported (can be instantiated, etc. just fine).
Method overloading and multiple constructors - Within classes you can have multiple method (or constructor) definitions - with the appropriate methods being called, based upon their signature length.
Inheritance - Even classical-style inheritance is supported.
Note: There's one feature of Processing that's pretty much impossible to support: variable name overloading. In Processing you can have variables and functions that have the same name (e.g. float size = 0; float size(){}). In order to support this there would have to be considerable overhead - and it's generally not a good practice to begin with.
The Processing API
The second portion of the project is the full 2d Processing API. This includes all sorts of different methods:
Shapes drawing
Canvas manipulation
Pixel utilities
Image drawing
Math functions
Keyboard and mouse access
Objects (point, arrays, random number generators)
Color manipulation
Font selection and text drawing
Buffers
Congratulations to John, and I look forward to seeing some fantastic visualizations in the browser thanks to this work.
Last, but never least, is Alex Russell of the Dojo Toolkit and SitePen. In Alex's five minutes of video footage for our JavaOne talk, he explained how Dojo enables you to built fantastic, responsive applications for everyone. The everyone piece revolves around accessibility too, which is core to Dojo thanks to work from Becky Gibson and others on the team.
The Dojo grid and charting packages are very rich these days, and continue to get better. Alex also noted in a separate discussion how there are subtle advantages to the charting package such as being able to print the darn things out nicely. Other flashier products may not allow that minor feature.
I have talked before about the desire for a Notification API on the Web. As a Mac user, I would love to see Growl from JavaScript, and there have been libraries written from as far back as protoGrowl.
The difference is between a JavaScript API that does notifications on the desktop, versus trying to get little custom notifications inside the browser window itself. I am talking about the former.
What was interesting was the implementation side, and the paths Brian went down to get this working. I asked him for his thoughts, and he wrote up the following:
One of the biggest new features in the latest version of Growl for Windows (v1.2 alpha) is the ability to receive notifications from websites running in your browser. i spent quite a bit of time working out the best way to handle this functionality and thought i would share my thought process.
since Growl can already receive notifications over the network, i figured that it would be easiset to build the Web-based notification system on top of that. Growl receives network notifications using a simple protocol over UDP. ok - first hurdle: browsers and javascript dont do UDP, so i figured i would have to go with some kind of add-on. i wanted the solution to work cross-browser, so Firefox extensions and ActiveX plug-ins were ruled out. i also wanted the solution to work for the broadest range of people, so i didnt want to write a custom add-on (a la Gears). i knew that Flash and Silverlight both had networking support, but neither can do UDP, so they were both quickly ruled out.
that left Java as the only other widely-installed cross-browser extension at my disposal. Java obviously has robust networking support, including UDP, so i headed down that path. the biggest problem now was that i have never created a Java applet, nor even written a line of Java code. but the syntax was familiar enough, and i was able to find some good sample code on the net that i was able to mash into a tiny applet that could send UDP packets. it actually worked brilliantly, and i was quite happy with myself for solving the problem so easily.
but of course, it was not that easy. there is that little restriction known as the 'same-origin policy'. running the applet on my localhost worked great, but as soon as i ran it from any other location, i would get a secuirty exception. i tried all kinds of combinations of values for the CODE and CODEBASE attributes, including file:// urls and even encoding the applet code as a data: uri, but i was thwarted at every turn (as so i should have been - the entire reason the restriction is in place is to prevent what i was trying to do). right before i gave up on the applet idea, i had the realization that if i could serve the applet up from the local host, then it would be able to communicate with the local host later. but configuring and installing a simple web server just to serve up an applet seemed like overkill. alas, the Java idea was a dead end.
so, it was back to the drawing board. what did the browser have access to that could bridge the gap? i decided to try a custom protocol handler, similar to the Itunes Music Store (itms://). a couple of simple registry entries and i had my growl:// protocol working. i had a helper process that sat in the background and everytime a growl:// url link was clicked, the browser would pass it off to my handler, along with the original url. i decided that i could pass any information as a JSON-encoded string in that url information. again, it worked great and seemed to be a good solution, but that made me sure that it must have a drawback. turns out the drawback in this case was that there was no way for the browser to know if the protocol handler was installed on the user's machine - if the protocol handler was installed, the browser passed it off nicely and all was good, but if the protocol was not installed, Firefox would present a dialog saying something like 'firefox doesnt know how to open the address because the protocol is not known' (IE and Safari both just returned a 404-type page). since i wanted websites to be able to use the communication feature if the user had Growl installed, but not mess up the experience if they didnt, this was a deal breaker.
i was starting to run out of ideas at this point, but i remembered the idea of serving up the Java applet locally. while i was pondering the details of that solution, i thought 'if i am going to have a local server to serve up the applet, why not skip the applet and just communicate with the local server?'. so i implemented a very simple webserver that runs when Growl is running that can be accessed at something like http://localhost:9889. the idea of using the url to pass JSON was repurposed and soon i was able to pass JSON-encoded Javascript objects to the local server, which code then parse the data and handle it in real application code. i couldnt use ajax to communicate with the local server (same-origin policy strikes again), so i decided to use the hidden iframe technique. i wrote a small js library to abstract everything out, so now you can write code in Javascript that almost mimics the code you would write if you included the Growl libraries in you application code:
Growl.notify(someKindOfNotification, 'Notification from the web', 'this is the description', Growl.Priority.VeryLow, false);
of course, receiving notifications from websites opens up the possiblity of spam and other noise, so applications that register from the web have their notifications disabled by default (thus requiring the user to explicity grant the notifications they wish to receive). but that is another topic for another day.
Ed: I decided to make today, "Extend the browser through APIs Day"
If you 'aint got a URL scheme, you are a nobody. That is what I thought when I saw fx:// on the first day of JavaOne.
The newest one of these that I have seen is mountpoint:// which is part of an Opera proposal for a File I/O API in the browser. You know me, extending the browser is a bit of a passion, so I was excited to see what they had come up with:
Traditionally, web applications have had little to no access to resources residing on the local filesystem. The ECMAScript interfaces for file I/O specifies a sandboxed file system, where a widget or other trusted component can gain access to the local file system.
The File I/O interfaces in this specification represent an abstract filesystem, without knowledge of the underlying filesystem's path separators, conventions for setting file properties such as read/write permissions.
The interfaces provide methods for opening files, writing to them, creating files and directories, moving or deleting them, and so forth.
In order to work with files, an application first has to acquire a mountpoint. A mountpoint is either a reference to a file or folder on a disk, or an abstract reference to a set of files which might not necessarily be within the same folder.
If your application wants to use the File I/O API, the browser user will be asked to select a location for the virtual file system, and then you will have access to play in the sandbox.
The core interfaces are:
The FileSystem interface
In a context where the FileSystem interface is made available to applications, the interface is instantiated as opera.io.filesystem. When present, this object provides attributes and methods for acquiring access to files and folders on the local filesystem.
The File interface
The File interface represents objects in a virtual filesystem, and can represent either a file or a folder. A file object consists of a number of properties, and methods for working on these objects
File objects that are marked as persistent must persist across restarts of the application.
The FileStream interface
The FileStream interface represents a File object opened for reading and/or writing, and defines methods and attributes for doing this work.
var geolocator = new navigator.GeolocationRequest();
geolocator.request({
success: function(location){/* We've got the location! */},
error: function(err){/* There was an error getting location. */},
accuracy: "neighborhood"
});
There is also a lot of talk around privacy and accuracy, and Apple has their own location manager too.
I hope that we can unify some of this, and give the browsers a geo location API soon. One simple JavaScript abstraction will enable a lot of great apps.
Ben and I gave a presentation at JavaOne on what's new with Ajax. Since this was JavaOne, we skewed a little more than we normally would to Java topics, and one of them was using the new Java Plugin, that has great new features such as being able to take a running applet out of the web page, and having it continue to live after shutting down the browser. Java is running out of process here, which also helps the "Java crashing the entire browser" problem.
Anyway, back to our demo. For some context, last year at JavaOne had us performing Guitar Hero on stage, so we knew that we had to use a gaming console in some way. This year it had to be the Wii, but instead of using the console, we decided to just use the controllers.
Wouldn't it be cool to control a Web page using the controllers? We thought so, and we set to it. You can talk to the Wiimotes via Bluetooth, so we needed a stack that would allow us to do just that. Java has a bluetooth stack. We could get an applet to talk to the Java stack. Hmm.
It actually took quite some time to test out the various stacks out there. In the end we went with a native system called Wiiuse that a lot of Wii hackers use. There is a wrapper library called Wiiusej that gave us exactly what we needed.
A quick test later and we had an application that was talking between the remote and the program. It turns out that the main controller sees a series of IR lights that are in the Wii sensor bar, and this allows you to simulate the system with any decent IR source. In the presentation room the big lights that shine on stage were strong enough to act as a sensor bar so we won't even have to use it. We can just point out to the crowd.
Anyway, back to the application. We then wrote a Java class that acts as a state machine for what the remote is doing. It understands the movements, which buttons are pushed, how fast you are moving the device. With this data we could build a simple darts game. With the state machine Java code, and an Applet wrapper that exposed the information, we were ready to get to the Ajax side of the house.
We painted a darts board onto the screen and then had JavaScript start polling the Applet for information via JSObject (As simple as: document.nameofapplet.pollmethod()). This turned out to be more stable than talking the other way, even though it meant we were polling instead of being entirely event driven. When the JavaScript code polled the applet it would pass back a data structure with the data for the coordinates of the remote, and whether the dart had been fired (button A to fire, button B to reload). We would move the dart image on the screen as you move the remote, and when fired we kicked off an animation to fire the dart at the board.
At first, it was all too simple. You setup the shot and it would get the right area every time. Not a fun game. We then decided to add some simple physics to the Ajax game. We took into account the velocity of the throw (if weak it would fall down) and how straight your shot was. If you wiggle around, the dart will not be accurate.
Anyway, this was a lot of fun, and shows that as much as we mock Java applets, if we forget about using them as fancy blink tags, and instead think of them as more extension points, maybe there is life for them.
The video below shows you a demo of the application, the source code with an explanation, and more details.
I've been talking about progressive enhancement here before and got a lot of flak in comments about it. It seemed that there was a general misunderstanding of progressive enhancement and unobtrusive scripting as a "passing fad" or "backward facing rather than being innovative".
I was asked by a design agency in London to go there and give a brown bag presentation (during lunch break) on the matter and took this as an opportunity to write up reasons and examples for progressive enhancement concentrating more on the why than on the how.
The gist would be to say: enhancing a product progressively means you'll always deliver a working product - as you have no idea how your product can fail in certain environments, you plan for it to fail. This ties in nicely with the agile manifesto - you always deliver software that works.
In my talk I came up with seven "rules" of pragmatic progressive enhancement:
Separate as much as possible
Build on things that work
Generate dependent markup
Test for everything before you apply it
Explore the environment
Load on demand
Modularize code
I've taken these ideas and backed them up with benefits you get by following them and code examples in a full article: Pragmatic Progressive Enhancement.
The article is licensed with Creative Commons and uses YUI in the example scripts, feel free to translate, remix and create examples using other libraries.
John Resig got in front of the camera, and the projector, as he gives us his thoughts on the state, and future of Ajax.
He starts out by discussing jQuery Core, and the features in the near term (1.2.4), short term (1.3) and beyond. He then delves into the UI side of the house with jQuery UI 1.5. He segues from jQuery to the future of browsers and JavaScript in general.
David Kees has written about Using Prototype to Load Javascript Files, which is an implementation of the general technique of loading functionality via scripts based on the availability of DOM elements.
He started using the technique to scratch an itch:
The calendar on this site only appears on pages that show blog-related information. That calendar is enhanced with Javascript allowing you to change the month displayed by the calendar without reloading the rest of the page. So, in order to ensure that these enhancements would be available everywhere the calendar is, I figured I had two options:
Code the inclusion of the Javascript file into every page which requires it. While a good solution, and one that has worked well in the past, sometimes it can be difficult to remember or realize that you've forgotten to include the file when you add new pages that require it.
Find a way to automatically include the file when it's needed. This would avoid the need to remember the need to include it when adding new pages that require it, but would result in a little more Javascript going on when the page loads.
Eric Meyer has felt a lot of pain due to line-height, which means us mere mortals are totally up the creak.
He posted about how line-height is abnormal and goes into detail on his learning curve, and the pain he saw which lead him too:
Why bring all this up? Because I went and poked line-height: normal with a stick, and found it to be both squamous and rugose. As with all driven to such madness, I now seek, grinning wildly, to infect others.
Here’s the punchline: the effects of declaring line-height: normal not only vary from browser to browser, which I had expected—in fact, quantifying those differences was the whole point—but they also vary from one font face to another, and can also varying within a given face.
I did not expect that. At least, not consciously.
He created a tool that visualizes all of this for you, so you can see the magic at work:
, Standards
