Blackbird, G. Scott Olson's JavaScript logging library, truly has a catchy slogan. The slogan "Say hello to Blackbird and 'goodbye' to alert()" definitely captures what the Blackbird library aims to do; make logging messages in JavaScript extremely easy. And setup is very easy. By incorporating the following lines of code, you've now added the ability to set checkpoints which will display specific data you're interested in:
The video above by Ron Brinkmann is his mockup of a non-euclidean browser UI which looks a touch like the magnifying glass tool on the iPhone, and aims to give you your data in a readable way, while still showing the larger context:
The reason why I think an interface like this can be superior in many ways is that it allows you to specify an area of interest where you get full, detailed information yet you can still see the full document/page/object at the same time. Which means that one is able to avoid the zoom(in/out)-scroll-zoom(in/out)-scroll paradigm that you often get stuck in when using, for example, the iphone. In many ways it gives the user an analogue to the way peripheral vision works in the ‘real world’. You have an area of interest that you can focus on but then you’re also aware of the surroundings and glean information from that as well.
(The mockup I did above just shows a single point-of-interest but it’s certainly expandable to multiple points if you’ve got a touchscreen or other such device. And there’s all sort of little refinements you’d want to implement if you really wanted to make it swank - drag&drop from one place to another might want to keep the source area zoomed but also follow the dragged object with a zoom-region until you get to the appropriate destination. This all gets even sexier once eye-tracking becomes more available - the area you’re looking at would bubble up to full resolution but you’d still be able to quickly scan the entire page and re-target the area of interest. Somebody get busy on this, okay?)
In his post, Ron then shows other subtle examples, such as mapping this to peripheral vision.
Isn't it great that a browser point release these days adds so many features? We are starting to see this from Firefox, Opera, WebKit and others, and it is exciting!
The labs team got Geode out there, and quickly we have seen the addition of the W3C Geolocation API added to the Firefox core. I can test Where Are You with a native implementation.
@font-face
WebKit lead with their @font-face implementation, and getting browser #2 to support it is huge. Now you can load up a font using same-origin rules via simple CSS:
We now have lots of examples testing out the video and audio tags with support for both OGG Theora and OGG Vorbis.
This is something that the Web really needs to work out. The codec game is far from Open, and with native support we get to do cool things such as integrating media with canvas, svg, and plain old HTML. Take a video, add transparency, and skew it a little.... and add an overlay message.
XHR Updates
XHR Progress Notification
We’ve added a better way to get progress notifications for XML HTTP Requests. We’ve implemented the W3C Draft Spec on progress events. In Firefox 3 the events available on the XHR object were progress, uploadprogress, load, abort and error. For 3.1 we now support the loadstart, progress, load, abort and error events. (uploadprogress is also supported, but is deprecated.)
We’ve implemented the draft specification for access-control for cross-site requests. Web developers have long wanted to be able to get data from one site on another but same-origin restrictions on many types of requests prevent many developers from mashing up content. This new access control mechanism offers the ability for servers, content and web clients to cooperate to make a lot of new things possible on an opt-in basis. The spec is complex, and support is new, so if you’re interested reading the spec is probably the best thing to do. It contains examples and uses cases.
Fast JavaScript VM
An early version of TraceMonkey is here:
Beta 1 does include TraceMonkey, our super-fast JavaScript engine, but it’s not turned on by default. If you do want to turn it on, go to about:config, set javascript.options.jit.content to True, restart your browser and try it out.
This is an early beta, of course, so there will be issues. Please file bugs if you find sites that don’t work or cause crashes or hangs. The more testing we get, the better it will be when we turn it on.
Phew, good times for browsers == good times for Web developers.
UPDATE
More browser news, Flock 2.0 is out there, providing a very social browsing experience.
Ryan Stewart of Adobe joined us for episode 5 of the Open Web Podcast. We really want to be pragmatic Open Web citizens, so thought it would be good to hear from Ryan and get his point of view on what Adobe, and he, are thinking with respect to the Web as a-whole.
AIR: Ryan talked about how he sees AIR fitting into the landscape, and how he personally would love to see Geolocation APIs added
Open Source: Ryan shares his insight on the experience Adobe has gotten from their Open Source projects (Tamarin, Flex, ...)
It was a real pleasure to have Ryan come into the lions den. He is very honest with what he does and doesn't know from within, and doesn't hold back on his own thoughts.
Steve Souders posted on Runtime Page Optimizer a tool that you can think of as a performance proxy. It sits on the server side, and cleans up content before it is sent back to the browser.
What can it do? Steve let us know:
RPO automatically implements many of the best practices from my book and YSlow, so the guys from Aptimize contacted me and showed me an early version. Here are the performance improvements RPO delivers:
minifies, combines and compresses JavaScript files
minifies, combines and compresses stylesheets
combines images into CSS sprites
inlines images inside the stylesheet
turns on gzip compression
sets far future Expires headers
loads scripts asynchronously
RPO reduces the number of HTTP requests as well as reducing the amount of data that is transmitted, resulting in a page that loads faster. In doing this the big question is, how much overhead does this add at runtime? RPO caches the resources it generates (combined scripts, combined stylesheets, sprites). The primary realtime cost is changing the HTML markup. Static pages, after they are massaged, are also cached. Dynamic HTML can be optimized without a significant slowdown, much less than what’s gained by adding these performance benefits.
Steve had another couple of interesting posts recently:
Say no to IE6 discusses how we need to do something to help upgrade IE6 users (to IE7 is fine!)
Raising the bar talks about results from Steve's UA Profiler tests and how new browsers are pushing forward
As always with Dav, the utility comes with a full API and documentation, features useful methods like fryBacon() and stopFryBacon() and there are several clever custom events (baconReady, baconDone, baconStart) to subscribe to.
If you dive deeper into the workings of bacon you also find hidden messages of what the future might hold: void cook() An override method for extending this class to maybe fry eggs too.
I am now waiting for jQuery cocktail sausage and protoype T-Bone.
With Dojo 1.2, the build system can generate a 5.5KB gzipped (13KB ungzipped) dojo.js file, via the customBase layer option. Useful for iPhone development if you want to get under the 25KB uncompressed size limits for the Mobile Safari cache. That small dojo.js is basically just the loader and some bootstrap functions, but it allows you then to tune your build layers to meet the 25KB and dynamically load what you need as you go.
Also, the djConfig options afterOnLoad/require/addOnLoad allows loading Dojo after the page is loaded. Great for making progressively enhanced pages render even faster.
The event object contains two properties: .clientRects and .boundingClientRect, both of which refer to the result of the associated DOM methods.
In a nutshell, boundingClientRect gives you a single rectangle encompassing the entire area in which a paint operation could've taken place whereas clientRects gives you a number of rectangles, each encompassing an individual area that was drawn.
I have seen some of the great applications that SitePen produces, but unfortunately too many of them are for companies behind the firewalls.
It is great to see Sensei a really compelling Dojo application that SitePen wrote for their training class. This isn't one of those simple training examples that you normally get though. This says quality.
Revin Guillen explains:
When conducting Dojo training courses, we’ve found it to be very valuable to go beyond simple code snippets to demonstrate APIs, patterns, and other key concepts. Snippets and demos are useful, but they often lack a very important quality: context. Nothing beats having a full application in front of you—with code available to read and modify as you learn the ropes—so we built the Dojo Sensei Reader, a rich, powerful RSS reader realized as a single-page web application.
We designed Sensei specifically for training sessions. We wanted something that demonstrates the major areas of functionality Dojo offers, but as a single cohesive application rather than a collection of unrelated demos. We wanted something small enough that training groups could easily grasp the entire codebase, yet large enough to be worth using as a real-world application. We wanted something that shows the development process from start to finish, to demonstrate the level of polish you can achieve in a Dojo-based application. Beautiful as well as functional, it does all of this while providing a great, fast user experience.
One of the beautiful things about Sensei is that it proves that you don’t have to sacrifice maintainability to build a fast application. One key goal in our development process was to create an easy way for training groups to introspect the code, follow the app as it works, and even modify or augment its behavior at run-time by swapping code in and out. To deliver on this, we designed and integrated what we call Blox, a small JavaScript package with the power to make it all possible (it’s Sensei’s flux capacitor; we’ll cover it later). The result is a codebase that is very easy to work with but incurs negligible performance impact for its trouble.
Today, we are really excited to be able to announce a big personal change. Ben and I are joining forces, full time, for the first time. What are we doing? We are joining Mozilla to create a new group with the charter to create developer tools for the Open Web.
Mozilla is placing a big bet, not only on us, but in the developer tools space.
Why are we doing this? Ben and I are passionate about a couple of things: compelling software and developers. In various roles in the past, we have built tools that attempt to make developers productive. We are huge advocates for the Open Web, yet we feel that tools are lacking on our collective platform. We want to help make a difference.
As we ramp up this new group, we will be looking at the problem and seeing where it makes sense to step in. We are going to be experimenting, and thinking about how to make developers lives better in different ways, so we aren't expecting to see traditional tools come out of this group. Also, we don't want to do this alone. We want to involve the entire community which is one reason that we are so excited to kick off this work at Mozilla. We believe that we have a unique opportunity to put developers first. We can build these tools in the open, with total transparency; the Mozilla way.
We respect the work being done by other vendors, and very much want to work together. We can't wait to reach out early-on in the process, involving companies that believe in the Open Web like we do. Together we can drastically improve productivity, allowing developers to build compelling user experiences.
We are just getting started. As soon as we come up with some ideas, we will be sharing then with you and asking for community participation in various forms. You, the Ajaxian community, have been phenomenal over the years, and we can't wait to do more together.
Working with different API’s can present hurdles as we attempt to massage the same data in two different data structures - one for a grid and another for a pie chart. To address this specific challenge, I developed a short user extension Ext.ux.GVisualizationPanel enabling users to integrate visualizations into Ext JS applications without concern for these issues. The GVisualizationPanel adapts any Ext data Store into the google’s format and enables you to embed any type of visualization into a panel.
He then shows some examples, such as this intensity map:
TinyMCE: There’s a modified version of this included in Wordpress these days, and it’s extremely well supported by its developers. You get all the formatting options you’d expect, plus the ability to easily remove excess formatting tools with just a little code. As an added bonus, there’s a collection of plugins which enable even more advanced formatting options.
YUI Editor: Sadly, this one is quite often ignored, perhaps due to that fact it’s the product of a large corporation. Nonetheless, I know a kick-ass set of tools and utilities when I see one, and this editor is fit for any such best-of list!
You have 2 main configurations for this - Editor and simpleEditor. You’re not limited to these however, as once you get to grips with the API you can bespoke it with relative ease.
FCKEditor: FCKEditor is one of the longest standing web-based editors out there, and used in a great many open-source apps. It’s also available in a number of server-side languages
FreeRichTextEditor: FreeRichTextEditor is gaining more momentum these days, and comes available with 2 modes available straight out the box: design, code and preview.
WidgEditor: This is the work of client-side coding guru Cameron Adams, whose personal project has become an extremely viable, standards-based rich text editor for web applications. The JavaScript behind is also lean yet easy to read (should you want or need to understand it further), and the code output is smooth.
Are there others out there that you like? Any experiences that you would like to share? A friend recently jumped from a paid widget to TinyMCE saying that it was finally ready for prime time.
Sam Ruby has that way about him that sees things very clearly. He just took a peak at jQuery for the first time and was able to really put into words what I think jQuery enthusiasts like about the library:
The notable thing about this is that despite all of the asynchronous events taking place, the code is sequential (nested, but sequential), and that the JSON results of the AJAX call is immediately available to the function that is invoked when the selection changes.
This is based on the following code that he wrote:
