Firebug 1.2 is nearing final beta. After testing it’ll be promoted to stable. The main focus for the next release is going to be performance, stability, and testing. Some new features are on the todo list, such as adding new CSS rules, viewing bound DOM event handlers, and exporting CSS changes. More details are available in my notes from the meeting. It’s very exciting to have Mozilla more involved, and bodes well for the future of Firebug.
Dmitry Baranovskiy of Atlassian has created Raphaël "a small JavaScript library that should simplify your work with vector graphics on the web. In case you want to create your own specific chart or image crop-n-rotate widget, you can simply achieve it with this library."
Raphaël uses SVG and VML as a base for graphics creation. Because of that every created object is a DOM object so you can attach JavScript event handlers or modify objects later. Raphaël’s goal is to provide an adapter that will make drawing cross-browser and easy. Currently library supports Firefox 3.0+, Safari 3.0+, Opera 9.5+ and Internet Explorer 6.0+.
JSBridge is an incredibly alpha, but interesting new project, lead by Mikeal Rogers, that bridges Python and JavaScript with respect to Mozilla. It uses mozrunner, the Python library that can power Mozilla applications (e.g. Firefox).
Once you fire up jsbridge MozRepl will kick into gear, and you will be able to interact across the bridge. "This includes JavaScript < -> Python object translations and a callback mechanism for Python responses to custom events fired in the javascript environment."
Of course, this isn't related to IronMonkey the project that allows you to write Python (and Ruby and ...) on top of Tamarin.
Alx Dark has created The Tombs of Asciiroth a fully functional roguelike-meets-puzzle-arcade game.
Asciiroth is a a complete, functional, open source game, written using GWT, and distributed either as an Adobe AIR application, or as a game you can play over the web. In the latter case, it uses Gears to provide saved game support. (So bottom line is you can play it using AIR or Firefox... IE is too slow, Opera/Safari aren't supported by Gears.) It also has a map editor that is distributed as an Adobe AIR application.
It is very cool to see applications written using Ajax, and then using both Gears for in-browser functionality, and AIR for desktop deployment.
I am really jazzed about the first entry in a new series on HTML 5. Mark Pilgrim (of Python, Greasemonkey, Open Web, writer extraordinaire, and creator of Google Doctype) has started the series This Week in HTML 5 which aims to keep us up to speed on the spec, and progress across the board (what are browsers implementing etc).
In the first episode he discusses the progress with workers, interesting clarification around providing text instead of images, and more.
Anyway, over to Mark:
The biggest news is the birth of the Web Workers draft specification. Quoting the spec, "This specification defines an API that allows Web application authors to spawn background workers running scripts in parallel to their main page. This allows for thread-like operation with message-passing as the coordination mechanism." This is the standardization of the API that Google Gears pioneered last year. See also: initial Workers thread, announcement of new spec, response to Workers feedback.
Additionally, the spec now tries to define what authors should do if they know they have an image but don't know what it is. Quoting again from the spec:
If the src attribute is set and the alt attribute is set to a string whose first character is a U+007B LEFT CURLY BRACKET character ({) and whose last character is a U+007D RIGHT CURLY BRACKET character (}), the image is a key part of the content, and there is no textual equivalent of the image available. The string consisting of all the characters between the first and the last character of the value of the alt attribute gives the kind of image (e.g. photo, diagram, user-uploaded image). If that value is the empty string (i.e. the attribute is just "{}"), then even the kind of image being shown is not known.
If the image is available, the element represents the image specified by the src attribute.
If the image is not available or if the user agent is not configured to display the image, then the user agent should display some sort of indicator that the image is not being rendered, and, if possible, provide to the user the information regarding the kind of image that is (as derived from the alt attribute).
Great to see this series kick into gear, and having Mark keep us in the loop on the very important HTML 5 effort.
I was wary about posting on this one, as it does involve scantily clad women. If that offends you, skip now, and please accept my apologies, and I know that this probably fits better for a Friday Fun posting, but let's get to it:
Ok, so when I was on the Adobe AIR tour, some folks showed me an AIR app that The Sun, a gossip rag / newspaper in the UK was working on. Sure you can get the news from the website, and through RSS feeds, but how about a branded experience? (as Ryan Stewart would say!)
This newspaper puts aside the third page to introduce you to a "lovely lass" each day. This is part of their brand, and probably is a reason why it is the most read newspaper in the world (a little sad but true?).
Thus, they decided to try writing an article alert application with a twist... that being one of the lasses would walk onto your screen when there is news and show it to you. I had to admit, that I didn't think that Ajax would be able to do that.
The question is, do these brand experiences take off? Is this a gimmick? Do people really just liking their RSS feeds with as little disruption as possible.... or do they cling to certain brands and enjoy that extra touch. I somehow doubt that anyone would want a "Desktop Ajaxian" where Ben and I come out to give you the news ;)
One little annoyance that I saw after running it, is the dock icon coming and going as they poll the AIR app. I hope that is fixed in the next version of AIR (Mike Chambers just put out a call for requests).
Adding any form of macros or additional scopes and indirections, including symbolic constants, is not just redundant, but changes CSS in ways that make it unsuitable for its intended audience. Given that there is currently no alternative to CSS, these things must not be added.
He has some very compelling points in there, some of which I agree with, and others that I don't:
This PHP version proves that it is not necessary to add constants to CSS. Just like the existence of the WebKit implementation cannot be taken as proof that constants in CSS are useful, so the PHP implementation cannot prove that either. But the PHP implementation has the benefit of letting authors determine the usefulness for themselves, without modifying CSS on the Web.
You can obviously use pre-processors to do many macro situations. This doesn't mean that it is the right place for functionality like this. I don't want to force every CSS request through PHP. I also like having functionality in CSS itself, as that can be shared across projects and developers without "oh, and by the way this looks a little different as we pre-process it with a magic Rails action". Something as important as variables should be low level IMO.
It is quite likely that somebody who is trying to learn CSS will give up learning it when he sees that style sheets that occur on the Web don't actually look like the tutorials he started from. Difference in upper- and lowercase or in pretty-printing are hindrances to learning, too, but limited ones: you soon learn to ignore those differences. But symbolic constants are different in each style sheet and have to be interpreted and understood each time anew.
A touch too strong. Things change. Tutorials get out of date. C'est la vie. And, you can always use old form.... and the feature is so simple that it won't take you weeks to work it out!
People who understand CSS in principle may still have trouble understanding the indirection provided by the em unit, many have trouble with the advanced selectors in level 3, and many more won't understand, e.g., any of the properties that have to do with bi-directionality or vertical text. For each feature that is added to CSS there must be a careful balance (based on an informed guess, because these things are difficult to test) between the number of users that will be excluded by that feature and the number for whom it is essential that it be added.
I agree in the balance. There are some crazy complicated parts of CSS. However, simple variables is trivial in comparison! Also, I think it will be used a hell of a lot more frequently.
Treating symbolic constants as an independent module would make them available for use in other contexts than CSS, would make them available to precisely the people who need them without hindering other people, would allow them to be developed without impact on CSS, and allow them to be developed more easily into what they are sure to develop into anyway: full macros, able to replace anything, not just CSS values, and able to make files shorter instead of longer.
I agree about modularity. There will be issues with scope and such, and we will have to fight to keep the system as simple as possible.
However, I can't wait to be able to re-skin something by changing the variables only that represent semantic parts of my application. Search and replace isn't good enough. Having tools that see the #xxxxxx and show you a color aren't good enough. You end up reading a lot more CSS than you write, so we should help that use case. I don't think CSS should become a programming language with if statements and the like, and I doubt this is a gateway drug to that.
I created an introductory example discussing custom events as an implementation of the Observer pattern. I posted this on my personal blog first and quickly got a port from my Prototype version to Malte's jQuery port (and now we have a DOMAssistant and Appcelerator versions). I hope others keep them coming so we can aggregate a simple example of custom events and how it works across various toolkits:
The example dynamically adds functionality based on checkboxes to simulate events that could change processing and uses the fire() and observe() methods from Prototype.
I strap on behaviour to a list of names. When you click on the name, something can happen. To do this I could have done the following:
$$('ul#leftchoices li').each(function(el) {
el.observe('click', function(e) {
if ($('colorchange').checked) {
changeColor();
}
if ($('contentchange').checked) {
changeContent(el.id);
}
});
});
In the click event itself, I do various checks and kick off behaviour. That can be fine for small actions, but what if you want to do more? This is when I prefer to abstract out the action and just fire an event:
At this point, this bit of code becomes dumb. It doesn't know what to do when you select the item, and it just hopes that somewhere, someone is listening. That is where the observers come in, such as this one that changes the main content based on the selected name:
When someone clicks on the checkbox, this method is fired and an observer is either added, or taken away.
Once you start building applications with this in mind, you may find a bit of a sea change. You start to think about the various events as a public API that you can easily expose to observers. Gone is the simple ability to look at one method and see what is happening, but the loose coupling gives you the ability to easily layer in your architecture. Based on some settings, behaviour can be dynamically added. You could even expose these events in a way that makes it easier for Greasemonkey hackers to come in and work with your application. All in all, a win-win for anything more than a simple example.
Although this example uses Prototype, you could do the same with the other top class JavaScript libraries. In fact, if someone wants to port this example to Dojo, jQuery, Mootools, YUI, or anything else, send me the files and I will put them up so we can all compare how custom events are done in the various toolkits.
Matthew Congrove took some time to play with the iPhone SDK, but it wasn't his bag, so he decided to go back to building a Web application for the iPhone, and was pleasantly surprised with the updates to Safari that enabled new things:
In the midst of all my research for help I stumbled across something that I, like most, had completely forgotten about; the iPhone update wasn't just for native third-party applications, but it also upgraded the existing applications. Yes, that includes Safari. The upgrade for the iPhone's on-board browser added in support for CSS animations and transitions, a JavaScript accessible database, a few new DOM selectors and more. For me this meant that the myDailyPhoto web application could look and feel more like it was a native Cocoa Touch enabled experience. As soon as the idea crossed my mind I sat down to churn out this little test app.
To get the flick effect Matthew wrote the following CSS:
In the code-on-demand style, a client component has access to a set of resources, but not the know-how on how to process them. It sends a request to a remote server for the code representing that know-how, receives that code, and executes it locally.
Joe Gregorio reminded us of this quote to remember that JavaScript fits in nicely with REST and the cloud:
The word 'code' here means JavaScript. Well, at the time it was written all the examples given were Java applets, but the idea is the same, that code is downloaded and executed. The takeaway here is that JavaScript is a fully fledged RESTful part of the web, and those JavaScript APIs, just like the hyptertext I pointed out yesterday, are RESTful points of integration of Cloud Computing.
It's almost as if the web were designed for this stuff.
Michael Mahemof is working a lot with TiddlyWiki and posted on how the project injects HTML into an iframe, and then get them out later. This enables you to use the browser parser to do its thing:
Ext 2.2 has been released, and it has features to complement the usual maintenance bug fixes and performance updates (Ext now works better in Firefox 3).
Technically, while the individual Checkbox and Radio controls are not new, they may as well be, considering the overhaul they have had in this release. Gone are the ugly standard browser input controls, now replaced by attractive, visually-consistent Ext-ified versions (a long-overdue improvement).
In addition to that, we’ve added group controls for both that support complex layouts with just a config option or two. Previously in order to accomplish similar grouping layouts you would have had to create a container with a ColumnLayout and manually place your controls across multiple column configs.
Another component that has been missing in Ext is a browser history utility to enable history stack navigation within your single-page Ext application. The new Ext.History singleton makes it extremely easy to do exactly that, and it uses an event-based API to notify you when the browser history as changed.
These two components were contributed to Ext by community member TJ Stuart (thanks TJ). The MultiSelect is a traditional list control that allows for selecting multiple list items, and the ItemSelector combines two MultiSelects into a more sophisticated control that includes drag-and-drop list selection and bulk selection and deselection among other features.
This is an official extension provided as a sample for implementing a useful form component. Not everyone needs a form upload component, but if you do, you can’t live without it. This control is fully styled and has an API consistent with other Ext form controls. It also supports both Text+Button (read-only text) and Button-only modes, and can participate fully in form layouts.
This official extension provides a great demonstration of extending an existing Ext component to provide functionality that you need in your own application. Again, loading an XML document into a tree is not needed by everyone, but if you do need something similar, this should be a great demo.
This extension was originally written up as a demo for one of our previous blog posts. However, it proved to be such a hit with the community that we transformed it into an official extension. This is another useful example of extending a standard Ext component, in this case to interface with an external API.
The video above is a "concept" called Aurora, created by Jesse James Garrett of Adaptive Path. Give it a play and you will see his vision for a very visual immersive, space-age-like environment that is very social.
This isn't about these concepts though. The Mozila Labs folks have a call for participation:
Today we’re calling on industry, higher education and people from around the world to get involved and share their ideas and expertise as we collectively explore and design future directions for the Web.
You don’t have to be a software engineer to get involved, and you don’t have to program. Everyone is welcome to participate. We’re particularly interested in engaging with designers who have not typically been involved with open source projects. And we’re biasing towards broad participation, not finished implementations.
We’re hoping to lower the barrier to participation by providing a forum for surfacing, sharing, and collaborating on new ideas and concepts. Our goal is to bring even more people to the table and provoke thought, facilitate discussion, and inspire future design directions for Firefox, the Mozilla project, and the Web as a whole.
Time to get creative and put on your inventor hat. Maybe your idea can get into Firefox?
Facelift Image Replacement (or FLIR, pronounced fleer) is an image replacement script that dynamically generates image representations of text on your web page in fonts that otherwise might not be visible to your visitors. The generated image will be automatically inserted into your web page via Javascript and visible to all modern browsers. Any element with text can be replaced: from headers (<h1>, <h2>, etc.) to <span> elements and everything in between!
sIFR takes over the elements and puts small swf files into place. FLIR on the other hand generates images on the server and puts them in place. They both suffer from the progressive switch in place that you often see as you watch the page load.
Also, one downside is that once the text is an image you can't copy and paste it. Ben can once again drool over the typography.
Bruce Johnson of the GWT team has continued the deep dive into GWT with a posting on a new GWT 1.5 feature: JavaScript overlay types. This feature goes beyond the JNSI technique to "make it easy to integrate entire families of JavaScript objects into your GWT project. There are many benefits of this technique, including the ability to use your Java IDE's code completion and refactoring capabilities even as you're working with untyped JavaScript objects."
The first example that Bruce gives is to mix JSON objects with Java:
