Those controls are written with the super-nice Prototype class system and custom events, so they’re super-tweakable and make it a snap to create extensions and customized versions. More controls are in the works, and there should be a beta release this year (or grab the code from github).
They support full keyboard navigation and provide accessibility hooks through WAI-ARIA.
John Gruber has spotted a library for iPhone web apps, from none other than Apple. This mysterious library, called PastryKit, seems to have flown under the radar as a Google search reveals precious little on it. In similar vein to other efforts, Apple's library provides support for native-feel websites - websites that run in Mobile Safari, but feel like native apps. (That's the objective anyway; some look-and-feel emulators are "good enough", while others get stuck in the uncanny valley).
Now with the same site in regular Safari (on your Mac/PC), open up the Develop Menu (if it's not there, enable it in Preference|Advanced). Choose User Agent > Mobile Safari 3.0 (or probably any other version number). And now you can see it in your browser. From Develop Menu, Web Inspector will let you view the script.
PastryKit accomplishes all three of the aforementioned things — hiding the MobileSafari address bar, providing fixed-position toolbars, and providing scrolling with momentum — by disabling regular scrolling and setting up its own view hierarchy and implementing its own scrolling.
The whole question of native iPhone apps was a hot topic last month after PPK whipped up a storm on the question of web apps replacing iPhone apps. The really interesting thing here is Apple's stance. They launched the iPhone with web intended to be the platform for 3rd party apps, then switched over to native apps and haven't done much to facilitate native-style web apps since then. Is a change coming? As Gruber puts it:
The $64,000 question, though, is whether PastryKit is something Apple intends (or that a team within Apple hopes) to ship publicly. It seems like a lot of effort to build a framework this rich just for this iPhone User Guide, so I’m hopeful the answer is yes. Perhaps something integrated with the next major release of Dashcode? And, perhaps with integrated UI layout tools, along the lines of Interface Builder?
Downloadify is an interesting solution to offer files as downloads without having to create temporary files and loop through a script that sets a force-download header.
As shown in the demo page offering a file for download and setting its content is as easy as this:
alert('You have cancelled the saving of this file.');
},
onError: function(){
alert('You must put something in the File Contents or there will be nothing to save!');
},
swf: 'media/downloadify.swf',
downloadImage: 'images/download.png',
width: 100,
height: 30,
transparent: true,
append: false
});
As you can see you have callbacks for all the possibilities and several parameters to style the flash movie overlaying the real "download this" button. The only issue I can see is that it doesn't work by sending the form via keyboard. This needs fixing.
Recently Google Translate announced the ability to hear translations into English spoken via text-to-speech (TTS). Looking at the Firebug Net panel for where this TTS data was coming from, I saw that the speech audio is in MP3 format and is queried via a simple HTTP GET (REST) request: http://translate.google.com/translate_tts?tl=en&q=text. Google Translate notes that the speech is only available for short translations to English, and it turns out that the TTS web service is restricting the text to 100 characters. Another restriction is that the service returns 404 Not Found if the request includes a Referer header (presumably one that is not for translate.google.com).
In spite of the limitations of the web service which certainly reflect the intention that the web service is only to be used by Google Translate, thanks to the new HTML5's Audio element and rel="noreferrer", the service may be utilized by client-side web applications
Others have been playing with text to speech too, such as this French Ubiquity command. I hope that Google makes it a public API of translate!
Rob Flaherty has done a little experimenting with data URIs and performance. The study only looked at Firefox 3.5 with empty cache, but the results were interesting for the questions they raise as much as the answers the provide.
He used a CSS file with 31 images and converted them all to data URIs using Nick Zakas's CSSEmbed. For an extra variant, he used DURIS to extract the data URIs to a separate CSS file so that the basic CSS in <head> becomes much smaller and therefore loads much faster.
All three scenarios yielded similar performance - with HTTPWatch, the times were 1.35s, 1.13s, and 1.13s. So the two data URI scenarios were only marginally better. But more interestingly, a commenter from South Africa chimed in with wildly different results (using Firebug): 4.04s, 1.44s, 1.92s. The implication is clear: latency can be a big factor in some cases, and round-tripping to fetch 31 images is going to bring that out.
Another interesting factor is perceived speed. This is, after all, arguably the most important thing when it comes to performance. Although the two data URI scenarios completed in the same speed, the second setup felt faster because it got the images out of the way and allowed the main stylesheet to load fast. The data URI images were then loaded in a stylesheet at the bottom of the page, after a script had been loaded.
The study also raises questions about data URI loading. A commenter posted a waterfall showing the data URI images take significantly longer to load than regular downloaded images. This is the kind of thing that needs more research and why the study is interesting because of the questions it raises.
Mozilla has said it will "probably" open a marketplace for Firefox add-ons sometime next year.
Add-ons product manager Justin Scott (reluctantly) announced the news this morning at an add-on-happy conference in Mozilla's home town of Mountain View, California. "We'll probably be doing a marketplace pilot in 2010," he said.
Scott did not provide details. But earlier in the morning, he did say that Mozilla has no intention of using DRM - not that you would have expected anything else. "I don't know what we'll do, but we won't do DRM," he said.
It wouldn't be too surprising to see Moz bolt in a payment model to the existing add-on repo, which already has a review process. Of course, once you start paying developers to build add-ons, many more add-ons will need to be reviewed and Mozilla will have to make tough decisions about to what extent add-ons will be reviewed, if at all, and what kind of charge, if any, will be imposed on add-on providers.
There are already some browser extensions that come with a price tag. This happens in both IE and Safari, both browsers lacking a vibrant extension community; and it also happens with Firefox, where there is a vibrant community of typically free, open-source, extensions.
An add-on marketplace would formalize the payment model and add a big incentive for developers to build seriously useful add-ons, given the possibility of reaching a market in the hundreds of millions. The flipside is that we might no longer see free versions of some of our favorite add-ons. Given its open-source DNA, it might be nice to see a "donate" button beside any of the free offerings in the store. (Update: Ryan Doherty points out in the comments there's already an add-ons contibution feature, pilot launched in July.)
It's also interesting to consider how an app store might open up a marketplace for new types of add-ons. For example, if you see the browser as a convenient sandbox to drop small desktop apps into, we could end up with simple games and utilities which might otherwise be released as shareware. Print-on-demand might be another application.
This is all hypothetical for now, but it's still fun to speculate on what could become of AMO!
Plugins are a fact of life when it comes to JavaScript libraries. These user-contributed code snippets provide tremendous features & functionality and save developers time by not having to re-invent the wheel. The hard part, though, is trying to filter out which ones are actually useful and compatible with your current library. Finding the right plugin can at times be a crap shoot. The MooTools team is trying to solve this issue for their community. Yesterday, the MooTools team launched the official MooTools plugin repository called MooTools Forge which aims to simplify finding the right MooTools plugin for your project.
For people trying to find plugins, we wanted a simple interface with visual focus on what’s available. Going through lists of plugins whose names are not always that intuitive or descriptive is both boring and inefficient. You might find yourself opening dozens of tabs just to see what the plugin can potentially offer. We want to try and put all the information you need to make a choice right in one place.
Focus has been given to making it easy see a demo, download plugins, and understanding how plugins actually work along with integration with GitHub to allow developers to easily manage their code.
Check out the video below for an overview of the MooTools Forge:
The golfing world had the Tiger Woods saga. Now our hero Doug Crockford, finder of the Good Parts, has gotten involved in some Online Booty Call drama.
Doug added an alert() to line 1 of his json.js files (DON'T HOT LINK TO THAT :)
I was talking to Doug about his keynote at Add-on-Con tomorrow, and asked him what the motivation was for this alert message. It turns out his webhosting service had contacted him about the unusually high amount of traffic on json.org. Doug investigated and discovered that OnlineBootyCall was linking directly to http://json.org/json.js, in spite of this statement in the file:
USE YOUR OWN COPY. IT IS EXTREMELY UNWISE TO LOAD CODE FROM SERVERS YOU DO NOT CONTROL.
Linking directly to http://json.org/json.js is bad. Certainly, it puts a load on Doug’s webhosting company that shouldn’t be there. But more importantly, it exposes the content site to security and performance vulnerabilities. Loading third party scripts into the parent window gives that third party access to cookies and other potentially confidential information in the page. Accessing that script from a third party domain requires an additional DNS lookup (which can be costly). Also, if the script is at the top of the page (which it is in this case) and the third party site is slow or not responding, the entire page is left blank for thirty seconds or more.
It’s best to reduce the number of third party scripts on your site. That was the reason Doug added the alert message to the top of json.js.
Of course, we hot link all the time. To Google Analytics. To the Yahoo/AOL/Google CDNs. Etc. The Web needs better mechanisms for packaging and running code. Doug likes to fight for just that. On one hand you can kinda snigger at the Online Booty Call situation, but I do admit to feeling a bit bad about the innocent folk that were harmed. I keep thinking of Bob Harris. The little JS guy that hotlinked. He is on vacation right now. He has no idea that his small site is alert'ing all of its users and they are all pissed. I feel sorry for him when he gets home to figure that out.
The first WebGL specification is here for your holiday leisure reading. The awesome Arun of Mozilla just posted this to the W3C device API group:
Today, the WebGL WG at Khronos released a public draft of the WebGL specification, and we really welcome (and need) wide review. Along with Mozilla folks, the WebGL WG has representatives from Opera, Google, and Apple, and nightly builds of Firefox, Chromium, and Safari have support for the draft specification. You can read a bit more about it in a blog post I wrote here. Essentially, WebGL is an HTML Canvas context. So you'd invoke it for now using:
The specification is still in draft status, so stuff will change, and your feedback is welcome :) We've already seen some compelling use of JavaScript libraries that straddle WebGL come out, such as X3DOM [4]. I expect to see more of that going forward, since WebGL is a pretty low level API that wraps OpenGL ES 2.0, with some concessions made for how JavaScript works (since OpenGL ES 2.0 is essentially a C API). The WebGL Wiki [5] has details on how you can test it in the browsers that support it.
I expect we'll want to have technical discussions about the Canvas API in general following this release, but for now this is an informative heads-up.
While this release is primarily a stability and performance release, we managed to sneak quite a bit of great new functionality into the various projects. All the significant changes have been outlined in the 1.4 release notes (including migration issues), and are far too numerous to list here: ranging from simple convenience changes, like dojo.Animation callbacks now being passed the node being animated, to completely new APIs like dojo.cache providing build interning outside of of dijit._Templated. Some changes are simply exposing long standing "private" API's: dojo._Animation is public as dojo.Animation now and dojo._contentHandlers has become dojo.contentHandlers exposing Ajax transport configuration for advanced users and giving an official commitment to the preservation of those APIs.
Dojo team member Dylan Schiemann said that:
Dojo 1.4 has substantial improvements yet again in performance, developer productivity, experience, and features. The community has come together to make this release well worth the upgrade
Key updates mentioned are:
IO Pipeline topics
dojo.cache
dojo.contentHandlers
dojo.hash with native HTML5 onhashchange event support where available
Traversal and manipulation for NodeLists (the return value for dojo.query)
dojo.ready (easier to type than dojo.addOnLoad)
Hundreds of refinements to the Dijit API and collection of Dijits, and a few new widgets in DojoX
DataChart widget and other improvements to charting
dojox.drawing lands!
Editor improvements and new plug-ins in both Dijit and DojoX
Grid is faster, and the EnhancedGrid lands!
ForestStoreModel for the TreeGrid
GFX improvements
dojox.jq, a very experimental module aimed at trying to match the jQuery API as close as possible, but using Dojo underneath
Dojo build system optionally supports the Google Closure Tools compiler
Significant speed improvements, especially in IE
The release notes go into great detail about the update so check it out for the full scoop.
With 1.4 out the door, the Dojo team is already looking at v1.5 which is slated for release on Q2 2010.
A couple of feature-packed jQuery podcasts have appeared in the past month or so: YayQuery (iTunes), a laid-back video podcast from folks in the jQuery community; and the official jQuery podcast (iTunes), hosted on the official jQuery blog and aiming to be a mix of news and interviews, hosted by Elijah Manor and Ralph Whitbeck.
It's a video podcast hosted by myself and three others, featuring laid-back discussions about current news and library/plugin releases; recently we've covered Brian LeRoux's Lawnchair script, JSON serialization options, dependency management and front-end performance techniques. We've just released our fifth episode.
Besides news, we also do a few segments where we dive deeper into particular areas of jQuery; we try to have a range of topics that will appeal to newbs and veterans alike.
- "Hiddenhancements", handy tricks inside jQuery you might not know about
- "Anti-Pattern for Performance of the Week" - Common coding practices that can get you into trouble, and how to avoid them
- "Plugin of the Week" - a new and/or awesome jQuery plugin that needs some evangelisin'
- "Beginner's Corner" - Things we wish we'd known when we were getting started with JavaScript and jQuery
- "nayQuery" - When to *not* use jQuery, and what options exist outside the $
The yayQuery hosts (Paul Irish, Rebecca Murphey, Alex Sexton and Adam J. Sontag) have years of experience being neck-deep in their own jQuery development, as well as providing support and training to the community
The official jQuery podcast has thus far interviewed jQuery creator Jon Resig, jQuery UI release manager Richard D. Worth, and none other than YayQuery host Paul Irish.
Although I curse at the weak support on Chrome Mac (coming by end of week though!), other Chromers can use the new beta extension system pioneered by the awesome Aaron Boodman and team:
Today, we're really happy to release a beta of extensions that begins to deliver on our initial vision. Extensions are as easy to create as webpages. Users can install and uninstall them quickly without restart, and extensions have a great polished look that fits in with Google Chrome's minimalist aesthetic. When developers upload an extension it is available to users immediately, with limited restrictions and manual reviews only in a few situations.
On the technical side, we've been able to use Google Chrome's multiprocess architecture to help keep extensions stable and safe. And Chromium's extensive performance monitoring infrastructure has helped us ensure extensions affect Google Chrome's speed as little as possible. You can learn more details about the internals of our system in the videos below.
I missed the fact that in Chrome you can opt-in to a new process from a link. This is important as every tab is NOT necessarily in its own process. People assume that is the case (a one to one mapping) but it isn't (and has interesting security implications):
In many cases, though, Google Chrome needs to keep pages from related tabs in the same process, since they may access each other's contents using JavaScript code. For example, clicking links that open in a new window will generally cause the new and old pages to share a process.
In practice, web developers may find situations where they would like links to other pages to open in a separate process. As one example, links from messages in your webmail client would be nice to isolate from the webmail client itself. This is easy to achieve now, thanks to new support in WebKit for HTML5's "noreferrer" link relation.
It is amazing how much easier it is these days to build pretty sweet mashups by using hosted services. Here's a screencast of using Yahoo, Bing and Google to build a search interface in under 25 minutes without having to read any API docs or installing SDKs by using YQL:
