Archive for category Firefox

HTML5 forms validation in Firefox 4

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.

Firefox 4 Beta

A new beta for mobile this way comes. Outstanding issues addressed include reduced memory usage, improved text rendering install size reduction on Android.

Animating With Firefox’s mozRequestAnimationFrame

Firefox 4 is going to be a very exciting release. Robert O'Callahan details one of the new features, which should help animation, called mozRequestAnimationFrame. First the motivation:

In Firefox 4 we've added support for two major standards for declarative animation --- SVG Animation (aka SMIL) and CSS Transitions. However, I also feel strongly that the Web needs better support for JS-based animations. No matter how rich we make declarative animations, sometimes you'll still need to write JS code to compute ("sample") the state of each animation frame. Furthermore there's a lot of JS animation code already on the Web, and it would be nice to improve its performance and smoothness without requiring authors to rewrite it into a declarative form.

setTimeout and setInterval can only go so far; as Robert describes, we sometimes need something between purely JavaScript-driven animation using setTimeout and having to go full declarative using CSS3 or SMIL. mozRequestAnimationFrame is one potential way to get better synchronization and performance from JavaScript based animation.

Some sample code from Robert using it:

JAVASCRIPT:
var start = window.mozAnimationStartTime;
function step(event) {
   var progress = event.timeStamp - start;
   d.style.left = Math.min(progress/10, 200) + "px";
   if (progress <2000) {
      window.mozRequestAnimationFrame();
   } else {
      window.removeEventListener("MozBeforePaint", step, false);
   }
}
window.addEventListener("MozBeforePaint", step, false);
window.mozRequestAnimationFrame();
 

It's not very different from the usual setTimeout/Date.now() implementation. We use window.mozAnimationStartTime and event.timeStamp instead of calling Date.now(). We call window.mozRequestAnimationFrame() instead of setTimeout().

Note that you will generally get about 50 frames per second using mozRequestAnimationFrame. As Robert describes in another blog post, this is a feature not a bug:

On modern systems an application usually cannot get more than 50-60 frames per second onto the screen...So even if an application updates its window 100 times a second, the user won't be able to see more than about half of those updates...firing a MozBeforePaint event more than about 50 times a second is going to achieve nothing other than wasting CPU (i.e., power). So we don't. Apart from saving power, reducing animation CPU usage helps overall performance because we can use the free time to perform garbage collection or other house-cleaning tasks, reducing the incidence or length of frame skips.

I hope that other browsers pick up this feature.