Mounir Lamouri looks at native browser-side form validation in Firefox4 – while re-iterating the need for re-validating on the server-side too. The objective of the browser-side form validation is to relieve JavaScript of the need to do a lot of basic form checking. Lanouri writes:

”All new input types introduced with HTML5 forms except search and tel benefit from internal validation.Firefox 4 is going to support email and url and the validation will check if the value is a valid email or url respectively.”

Also discussed is added pattern matching support and a new pseudo-class that applies on submit controls when a form has an invalid element.

In computer science, a fiber is a particularly lightweight thread of execution.

Like threads, fibers share address space. However, fibers use co-operative multitasking while threads use pre-emptive multitasking. Threads often depend on the kernel’s thread scheduler to preempt a busy thread and resume another thread; fibers yield themselves to run another fiber while executing. The article on threads contains more on the distinction between threads and fibers.

Fibers describe essentially the same concept as coroutines. The distinction, if there is any, is that coroutines are a language-level construct, a form of control flow, while fibers are a systems-level construct, viewed as threads that happen not to run concurrently. Priority is contentious; fibers may be viewed as an implementation of coroutines, or as a substrate on which to implement coroutines.

The above is taken from Wikipedia, which is discussing the computer science concepts behind fibers.

Few languages support fibers natively (though support was recently added to Ruby). We write most of our server code in JavaScript and run it under Google’s v8 engine, the same JS runtime that Chrome uses. Fortunately the v8 codebase is excellently structured, so we were able to add fiber support in just a few days. Our changes take the form of a patch (currently pending review) to v8cgi, a library of server-oriented extensions to v8.

// Make the new fiber runnable. It won’t start until the current fiber suspends

// or joins.

fiber.becomeRunnable();

// Wait for the fiber to finish.

fiber.join();

That’s almost the entire API. We don’t need any synchronization primitives because only one fiber runs at a time and control only changes when suspend() or join() is called.

There is a tension between writing clear, well-abstracted code and writing code that makes efficient use of the database. Adding fibers to v8 allowed us to resolve this tension. In taking a small amount of time to solve this problem “right” up front, we’ve made our entire engineering team more efficient for the long run.

Read the post to get the background, and to see the refactoring that is done to get to this place.

Asana seems to be really enjoying rethinking the world of Web frameworks. I can’t wait to see their products!

Slick Selector Engine

The biggest update is the inclusion of the new Slick standalone selector engine. The engine was developed by Thomas Aylott, Fabio Costa and Valerio Proietti with accuracy and portability in mind, allowing the engine to not only provide MooTools developers with excellent selector support but also the ability for it to be included in other projects as well. The MooTools team created over 3,000 tests to ensure that even the most obscure scenarios were considered. The inclusion of Slick also allowed the team to extend the Element method to allow creation of DOM elements using complex CSS selector expressions. Very cool!

Core Updates

The MooTools team also focused on enhancing the core API in preparation for MooTools 2.0 by deprecated every $- prefixed function and nd moving those to the relevant natives namespaces:

We have revised the whole base of our library to speed up MooTools, to provide an even more beautiful API and to make our library future-proof. In order to reduce the amount of global variables we have moved all $-prefixed functions into their according namespace ($splat » Array.from, …). In short we think that with 1.3 you are getting the best MooTools experience ever.

New Build Manager

Building a new version of MooTools has always been easy using the builder and now it’s been improved via the new Packager preprocessor which allows you to create custom MooTools builds from Github repositories. It handles code dependencies and already provides support for several MooTools plugins. The new Packager is a PHP 5.2+ library but can also be found as a Python app thanks to Aaron Newton’s work.

MooTools Runner

To make sure that MooTools continues to adhere to the projects’s specifications, Christoph Pojer & Arian Stolwijk spent some time over the summer building a new spec testing engine called MooTools Runner which has been adopted by all major MooTools projects - Core, More and Slick. The engine is based on Jasmine and runs all specs within just 2 seconds. In addition, code coverage was increased to about 95%, ensuring excellent test coverage for Core.

Download it!

Once you’re ready, you can grab the latest version of MooTools or roll your own via the following links:

Microsoft, if you want a way to declare a context-menu in HTML in a browser-agnostic way that is both forward and backwards compatible use HTML5’s <menu> element! Even IE6 supports it without any hacks because it was part of HTML4 and thus, not an anonymous element.

As browser UI begins to converge and websites become more and more integrated into the OSes we use, the menu element is there to describe native toolbars, menus and context menus that the user-agent could expose. It would thus make sense to use this to specify the jump lists as it can easily expand in capabilities in the future and it’s way easier for other vendors to get on board with than the horrible hack that was favicon.ico.

I tend to stay away from the HTML5 vs Flash “debate”, principally because I think it’s inane. Both platforms offer certain advantages over the other and some interesting results can be achieved by utilizing their strengths. Case in point, Flash’s built-in webcam support and WebGL’s hardware-accelerated 3D graphics are features that only exist in their respective platforms (for now). Bridging the technologies produces something unattainable by only using one, as the following quick examples illustrate.

How does he integrate these two technologies?

Passing webcam data to Javascript involves a few steps. The BitmapData drawn from the Video object needs to be compressed to JPEG and encoded to Base64 for the data URI to read it. This can be a very taxing process in native ActionScript, but is nearly negligible when done in haXe orAlchemy. In this case, I’m using both. The JPEG compression is performed by metalbot’s Alchemy JPEG encoder, while the Base64 encoding is handled by Bloodhound’s haXe crypto library.

Peter then uses Flash’s ExternalInterface to pass the string back to JavaScript and turns the webcam JPEG output into a data URL that can be fed into an HTML Image tag and fed into WebGL. Craziness!

Dave Balmer (formerly YUI, currently working with me on webOS) has created a fantastic cross platform mobile Web framework called Jo. What do I mean by cross platform? webOS, iOS, Android, Symbian, Safari, Chrome, and even Dashboard Widgets. It’s philosophy is:

If you want to jam an existing web page into an application framework, jo probably isn’t for you. jo is designed to create applications. While it will play nicely with a mixture of new and old web development techniques, it uses HTML5 as a development stack and does not require direct DOM manipulation.

You can setup your views in JavaScript, or also declaratively using special tags:

Over on my personal blog I talk about a 3D slide deck I’ve created that uses HTML5, CSS3, and a bit of SVG (video). The main idea behind this deck is to be able to ‘zoom’ into topics to as deep a level as necessary. Slides are nested, like an outline.

For example, I gave a talk at Future of Web Apps recently on HTML5, CSS3, and other web technologies and only had 40 minutes, so I just skimmed the surface of the slides. However, in a few days I’ll be speaking at Fronteers and will be diving deep into SVG and Canvas, so those slides can be zoomed into. The goal is for me to have a universal slide deck that can ‘accordian’ open and closed to fill either a 40 minute session or an all day workshop, kind of like stretchtext.