Thomas posted about it on his site and shared that it uses an early build of scripty2 which lead me to peak around on GitHub. It looks nice indeed.

You can see the evidence of Script.aculo.us throughout the UI. The calendar morphs between months as you flip around. Jumping between headers rolls around nicely (e.g. reporting mode from insertion). Inline modal popups. Nicely done.

The level of quality is “It runs and some pages render!” This build is not at all suitable for normal browsing use. Please don’t use it with your usual Firefox profile. There are numerous known issues starting with bogus memory management (leaking everything in the parser!), lack of fragment parsing support, lack of quirks mode, HTML elements being represented as DOM nodes that behave like XHTML elements and the integration with CSS layout being inefficient. The baseline Gecko source isn’t synced with the trunk, so the other parts of Gecko don’t have all the latest patches. The parser doesn’t reflect the most recent spec changes. meta element-based encoding declarations and BOM sniffing don’t work.

If a page doesn’t render, try reloading or navigating back and forth.

For background, please refer to a recent
newsgroup posting of mine. (Summary: The parser core is mechanically translated from the Validator.nu HTML Parser.)

Sam Ruby talked a little about the implementation:

He starts from a single source, in Java. The Java code can be compiled to Java byte codes, JavaScript source, or C++ presumably making use of Mozilla libraries for things such as memory management. If he can do that, it seems to me to be a rather small leap from there to producing C++ using, say, either Ruby or Python libraries for memory management, as well as a thin binding to the language. C# would also be a reasonable target.

If this could be done, and made available under a liberal license, it could go a long way towards making available consistent and performant implementations of the HTML5 parser algorithm everywhere.

You can build snow flakes with code like this:

Or a pretty garden like this.

It offers a couple unique features from other project folder downloads such as customization, valid XHTML, HTML, and CSS, but the most unique is bookmarking.

Deploy*'s bookmarking feature allows the user to go through the form only one time and then bookmarking the next page (deploy.php). When the user returns to that bookmark it instantly generates another .zip folder with all the settings the user had previously entered.

If you have a Mac you could add that bookmark to your dock and it's only a click away. Windows and Linux users could also add the bookmark to their desktop and it will always be right there waiting.

This is just the beginning of course. You could imagine that it would get a whole lot more useful if you could deploy to a cloud and have a project setup for you. Imagine if the options were more like "Give me Rails 2.2 with jQuery." There is room to take this further.

Wouldn't it be nice to take a view of your application and see where the behaviour has been added? That is what is shown above, and it is courtesy of Allan Jardine and his new Visual Event tool.

Once you hover over an event, you get to see the code that will run:

Each type of event has its own icon, and all you need to do is use the bookmarklet to run it on any page.

When working with events in Javascript, it is often easy to loose track of what events are subscribed where. This is particularly true if you are using a large number of events, which is typical in a modern interface employing progressive enhancement. Javascript libraries also add another degree of complexity to listeners from a technical point of view, while from a developers point of view they of course can make life much easier! But when things go wrong it can be difficult to trace down why this might be.

It is due to this I've put together a Javascript bookmarklet called Visual Event which visually shows the elements on a page that have events subscribed to them, what those events are and the function that the event would run when triggered. This is primarily intended to assist debugging, but it can also be very interesting and informative to see the subscribed events on other pages.

It turns out that there is no standard method for finding out what listeners have been attached to any particular node in a document, so I've resorted to parsing the event cache stored by the various Javascript libraries. Currently only jQuery and YUI are supported, but additional libraries can be added with ease.

Allan is keen to hear your thoughts. What would you like to see?

One common issue in my experience are intricate dependencies between the UI and data models. Decoupling these is a huge benefit with respect to maintainability. The PubSub model is a great way to do it!

I've got a brief post along with a demo and sample code for a really compact PubSub tool, as well as a short discussion on the somewhat non-trivial javascript that makes it work with minimal code.

The demo app uses code such as:

Marcus then goes through the PubSubBroker code itself.

I am a big fan of pubsub app development. I have talked about this wrt custom events in the past.

This is incredibly exciting, as it shows how Ajax libraries are working together more and more. Instead of reinventing the wheel in different ways for each project, is it possible to find some core pieces that can be nicely shared? Of course, if our world was nicer and we could share code by linking in a nice way maybe this would happen more.

As I mentioned in my thanksgiving note, the work that the Ajax library developers do is hugely important and impactful, and having them work together can only be great news.

Take a look at this public email to the Dojo Foundation on the vote:

Overview

The Sizzle project is a JavaScript library for performing selections
across a DOM tree using CSS selectors. The library is designed to be
standalone (have no external dependencies), lightweight, fast, and
extensible. This culminates in a library that is perfectly suited for
integration into other libraries. While it's feasible that a developer
may use Sizzle directly the target audience for it is other library
authors.

The code for Sizzle can be found in the following Git repository:
http://github.com/jeresig/sizzle/tree/master

All of the code for the project has been written by John Resig and is
released under an MIT license. There are some patches pending from
some other contributors (namely Prototype).

Right now the following libraries are adopting or are looking to adopt
Sizzle as their primary CSS selector engine:

• jQuery
• Prototype
• Dojo
• MochiKit
• TinyMCE
• PURE
• reglib
• Haxe

It's likely that Sizzle will become the unified engine behind a
majority of the JavaScript libraries on the market (if not in numbers
then certainly in market share).

The project is owned by John Resig who will serve as BDFL/Project lead
if the project is accepted. There is no formal voting process, as of
yet, but it's likely that one will come about, considering the number of
projects using the codebase.

If the project is accepted to the foundation then all contributors to
the project will be required to have a CLA and follow the policies of
the Dojo foundation.

It's very likely that Sizzle will eventually expand into other areas
of JavaScript libraries (such as DOM manipulation and event binding).

That last line excites me too! It is interesting to see this happen in the Dojo Foundation. Remember, Dojo was founded out of toolkits coming together to aggregate forces. Kudos to everyone involved, and good luck!

It is a tour de force of not only a huge widget library, but he explains how it is much more:

So what's so smart about SmartGWT? Let me try to explain. SmartGWT is not just another Widget library. While most Ajax frameworks focus primarily on presentation and displaying mostly read-only data, either local or via XML / JSON, SmartClient was built with server side integration in mind. Most enterprise applications are not just about about data presentation, but about being able to propagate data changes made by the user to the backend. So while its tempting to use library X that has a cool tree widget, it's not until you actually try to use it your application that you encounter the real world hard problems. For example, how do you take data from your business objects on the server to not only display in a tree widget, but also be able to update your data model when, say, the user reorders the tree nodes or make edits / deletes in the UI. How do you display hierarchical data where nodes may have hundreds of children? And so on..

Most Ajax frameworks stop short and leave it up to the user to manage state on the client side and propagating the changes to the server. This is not a trivial problem! Over the past few years UI widget libraries have improved significantly and there are now various options available to users. Simply put, having good looking widgets is not the hard problem today. In addition to having good looking widgets, having end-to-end integration of the UI components with the backend is the hard problem. It's this 20% of the functionality that takes 80% of the time in building most enterprise applications.

The showcase will give you a good feel for what is out there, and it contains some interesting items including:

• Miller Columns: The ColumnTree provides an alternate navigation paradigm for Tree data, sometimes called "Miller Columns" and seen in iTunes
• Nested Grid: A convenient way to display 1-n relationships
• Printable Views: SmartGWT supports printable views of its components.
• Advanced Filter Builder: a databound filter builder.
• Tile View: Representation of data as "tiles". Again, TileGrid supports data binding so sort / filter and edits can be easily performed.
• Calendars : A Google Calendar like widget that supports databinding so edits and drag drop changes can easily be propgated to the server for persisting.
• TreeGrid : Supports multiple columns, editing, column locking, lazy loading and more.
• Live Grid / Tree: Grid / Tree virtual scrolling or live grid

Really amazing work. Sanjiv recently had a Q&A session with InfoQ where he talks about the approach taken in developing SmartGWT and the his thoughts on the differences between SmartClient and Ext.

A common use for forms is user authentication. To indicate that
an HTTP URL requires authentication through such a form
before use, the HTTP 401 response code with a WWW-Authenticate challenge "HTML" may be used.

For this authentication scheme, the framework defined in RFC2617
is used as follows. [RFC2617]

challenge = "HTML" [ form ]

form      = "form" "=" form-name
form-name = quoted-string

The form parameter, if
present, indicates that the first form element in the
entity body whose name is the
specified string, in tree order, if any, is the login
form. If the parameter is omitted, then the first form
element in the entity body, in tree order, if any, is
the login form.

There is no credentials production for this
scheme because the login information is to be sent as a normal form
submission and not using the Authorization
HTTP header.

Mark then goes on to say:

This idea has been kicked around for more than a decade. Microsoft wrote User Agent Authentication Forms in 1999. Mark Nottingham asked the WHATWG to investigate the idea in 2004. Better late than never, Ian Hickson summarizes the feedback to date. No doubt this new proposal will generate further discussion. No browsers currently support this proposal.

The idea makes total sense to me. The old HTTP BASIC style of authentication is a dying bread due to the annoying popup style and implementation. It needs a shake up, don't you think?

Firstly, catch-alls are the ability to use the SpiderMonkey only __noSuchMethod__ meta programming trick. The good news is that this seems to be coming to ECMAScript Harmony (I hope we here how the ECMA working group meeting went in Kona soon!).

Erik used this trick to build a createSuper method:

which you can then use via var supr = createSuper(this);

Of course, as Erik points out, you can just use FooClass.superClass.method.call(this, …);

See how you can add fun (or annoying ;) transitions to your S5 prezos, even on the iPhone:

Greg Salisbury has released a new JavaScript debugger called XBug that "currently runs on the Windows XP/Vista platform, but, it can also be used to debug webpages on Windows or Linux servers. It's cross-browser compatible, and works with Chrome, Firefox 2/3, IE 6/7, and Safari 3. After selecting your web page, you can then trace or step through your javascript code in real-time. Set breakpoints, and watchpoints in a separate code window, see a trace log while your code is executing, inspect variables, and even get an indexed list of the functions/methods in your scripts."

Fancy a try? Grab the msi and get to it.

I noticed the new iPod Engraving Gallery that is a nice use of Coherent to show a slick UI with engraving suggestions.

I was also talking to a friend that has leopard beta bits and he was playing with an updated Dashcode. It appears that the Coherent library is now used for the widgets too. Yay data binding!

Rodrigo Reyes has announced a new project called AbstractCanvas, a GWT project that sits on top of HTML Canvas and Java2D.

The same code can thus run in the browser, or on the server.

You can then write code such as:

Kojax is a mobile development platform, according to my sources, that will allow Microsoft- — and third-party-developed — applets run in an Ajax-like way, using a combination of Visual Studio tools and JavaScript, on Java-based mobile phones.

Erm, is this just JavaScript running on the JVM? This is the big deal instead of the PDC touted "write using .NET and deploy everywhere"?

Mary goes on:

What kinds of mobile applets are we talking about here? Nothing iPhone-like, such as restaurant reviews or “I am Rich.” More like a virtual wallet for online payments, a group messaging service and photo-sharing app — things that build on top of Windows Live for Mobile services. Some of these Kojax-based applets will ad-funded; others will likely be transaction- and subscription-based.

Another interesting part of the Kojax tips I’ve received: Microsoft allegedly is aiming its Kojax applet plans primarily at users in emerging markets.

The Kojax work may or may not be related to a recent Unlimited Potential initiative about which I recently heard, known as “Mobile First.” Mobile First is all about users whose first Microsoft-related experience tends to be in the mobile-phone, rather than the PC, realm. (Given Microsoft’s recent acknowledgment that China Mobile will offer the first handsets running Internet Explorer 6, it’s not far-fetched to see how/why Microsoft is putting so much emphasis on emerging-market customers.)

I haven’t been able to glean much more about Kojax and Microsoft’s mobile applet plans. So before you ask, I don’t know what stage Kojax is at: It could be anything from a glimmer in a Microsoft development team’s eye, or something in private beta.

Chromium can't be everything to all people. People use web browsers in a variety of environments and for a wide variety of jobs. Personal tastes and needs vary widely from one user to the next. The feature needs of one person often conflict directly with those of another. Further, one of the design goals of Chromium is to have a minimal light-weight user interface, which itself conflicts with adding lots of features.

User-created extensions have been proposed to solve these problems:

• The addition of features that have specific or limited appeal ("that would be great as an extension").
• Users coming from other browsers who are used to certain extensions that they can't live without.
• Bundling partners who would like to add features to Chromium specific to their bundle.

They then define the goals:

An extension system for Chromium should be:

• Webby

• Developing and using extensions should be very similar to developing and using web pages.
• We should reuse the web platform wherever possible instead of creating new proprietary APIs.
• Web developers should be able to easily create Chromium extensions.
• Installing and using an extension should feel lightweight and simple, like using a web app.

Rich

• It should be possible to create extensions as polished as if they had been developed by the Chromium team.
• Eventually, it should be possible to implement major chunks of Chromium itself as extensions.

General

• There should be only one extension system in Chromium that handles all types of extensibility.
• Infrastructure like autoupdate, packaging, and security should be shared.
• Even traditional NPAPI plugins should be deployable as extensions.

Maintainable

• The system should require low ongoing maintenance from the Chromium team, and minimize potential for forward compatibility issues.
• We should not need to disable deployed extensions when we release new versions of Chromium. 

Stable

• Extensions should not be able to crash or hang the browser process.
• Chromium should assign blame to extensions that are overusing resources via tools like the task manager and web inspector.
• Poorly behaving extensions should be easy to disable.

Secure

• It must not be possible for third-party code to get access to privileged APIs because of the extension system.
• Extensions should be given only the privileges they require, not everything by default.
• Extensions should run in sandboxed processes so that if they are compromised, they can't access the local machine.
• It should be trivial for authors to support secure autoupdates for extensions.
• We must be able to blacklist extensions across all Chromium installations.

Open

• Extension development must not require use of any Google products or services.
• Extensions should work the same in Chromium as in Google Chrome.

As the new kid on the block, they get to learn from the good and bad of other add on systems (IE, Firefox, etc). What would you like to see? I love the idea of being able to do as much as possible by using the Web platform as it is, and doing things like adding some new APIs, but also additions to CSS and the like versus a new system.

I would also love to see the Chromium folks working with others to start sharing some work here. For example, it would be great to have the vbox/hbox work shared. David Hyatt did a lot of work there back in the day with WebKit already.

Ed Spencer has coded up a bra size calculator in JavaScript:

One of the more mesmerizing websites I've worked on recently was for a lingerie boutique in the UK. Aside from the unenviable task of having to look at pictures of women in lingerie all day, I was also forced (forced!) to write a bra size calculator.

The theory behind bra size calculation is arcane and somewhat magical. Understanding of it does not come easily to man nor beast, so it is lucky that I, falling cleanly into neither category, have passed through pain and torment to save you the trouble.

After hours of testing he came up with the BraCalculator:

Check it out in action

Greg Reimer is doing really interesting work with reglib and he now has a neutral post on events and how he favours the pattern of mouse enter / leave to mouse over / out.

He shows an example using the pyramid illustrations (as above) and then ends with:

The title of this post is a bit misleading. The mouseenter/leave events are never used. It's all still accomplished via mouseover/out, but there's enough information available in the handling element, event.target and event.relatedTarget elements--and their positions relative to each other--to know whether to execute the handler. Since the actual mouseenter/leave events don't bubble, and in any case are IE-only, reglib wants nothing to do with them. This code is checked in to the trunk, and with a little more testing will be released as reglib version 1.0.5.

One thing also, I'd be curious to know if anybody knows of a reason this would be *undesirable* behavior.

What do you think?

That is what HTML 5 defines, and Dustin Diaz agrees as he lays down the skinny:

Doctypes have long been in standardista discussions circles. Why to use them. Which one to use. Which one is best. These are all <sarcasm>really fun details</sarcasm> to get into, but the most important aspect of any doctype is simply having one, since without one, you’re stuck in the lovely world of “quirks mode”. If you’re interested in understanding the anatomy of a doctype, then by all means, dive in.

There is really, absolutely no reason you need the rest of the doctype in your declaration unless you’re validating code. Furthermore, it does not mean that your page is even invalid. In the end, it puts your webpages into standards mode, which is what really matters. (Plus it’s easy to memorize ;)

Try it out. It will fix your box model in IE6 and clobber all those other funny gotchas when you’re in quirks mode. Cheers.

Do you concur?

If you skip in 20 minutes to the presentation above you will find Charles Jolley talking about SproutCore:

During this presentation I actually built and deployed a small application on stage but the most interesting thing, I think, is the part where I talk about how thick client frameworks like SproutCore change the way you build your server side as well. It’s a model I call “microservices.”

SproutCore 1.0 is coming together nicely, and we keep seeing improvements such as mixin support that allows you to simply: