javascript

¿ Nunca te pasó ?...Que estabas escribiendo un email y presionaste BACK sin enviarlo ? Seguro que si.

Este mini-modulo que estuve elaborando los últimos días, intenta evitar ese trauma.

Es un "remix" de FormCheck (disponible para 4.7) pero mucho más light, sin tanto JavaScript, buscando que sólo cumpla un objetivo mínimo. Funciona muy bien en IE6, IE7, FF1.5+ y Safari 3.

Espero les sea útil y, obviamente, si quieren participar para hacerlo un módulo en serio, son bienvenidos.

Form Alert Module

I just created the Spry Framework Module to facilitate the implementation of some Spry Goodness into Drupal.

The Spry framework for Ajax is a JavaScript library for web designers that provides functionality that allows designers to build pages that provide a richer experience for their users. It is designed to bring Ajax to the web design community who can benefit from Ajax, but are not well served by other frameworks.

I was thinking about this idea to make captcha easier for normal (non spam) users.
What if the captcha module would also offer an option to to hide the captcha with client side javascript and solve the captcha with client side javascript? That way the captcha would be invisible (but still correctly solved on submission) for users with javascript enabled. It degrades gracefully for users without javascript enabled to the standard captcha. I guess it's possible to do it for the default math captcha. For the image based captcha's it is of course near impossible.

The basic premise to make this work is, of course, that spambots do not have a javascript interpreter. Otherwise it is just silly. I don't have an idea how advanced the spam bots are these days.

any thoughts on this?

Ran across this 'speedtest' page today, it has interesting results especially cross-browser:

http://mootools.net/slickspeed/

If you run it on FF ( at least on my iMac and a nearby Vista machine ) moo and prototype are much faster, but extjs wins hands down on Safari ( OS X ) and IE7 on Vista. jQuery is middling IMHO the benefits in developer satisfaction are worth the speed cost vs prototype.

Discuss.

With the announcement today of another four weeks before Drupal 6 freeze, we have another chance to get some critically needed Javascript patches into Drupal core.

Very few Javascript patches go through, mostly for lack of in-depth reviews. Please, everyone on this list, take your turn in reviewing Javascript patches! Better yet, wade in and help make improvements to the patches.

Here's a link to Javascript issues needing review:

http://drupal.org/project/issues/drupal?components=javascript&states=8%2...

A few highlights:

Just a quick pointer to the jQuery Interface Sortable module that we added last week. In 5.x, it depends on the excellent jQuery Update and jQuery Interface modules. In 6.x (or HEAD -- I'm still trying to figure out how I got that 6.x release node in there), it only requires jQuery Interface.

I posted a module today that will be of interest to anyone wanting to use tabs on their site without having to do custom coding.

It's called Panels Block, http://drupal.org/project/panelsblock. With it you can expose a set of panels as a block via a new option on the panels edit form. (Only the content added to the 'left' area is made available as a block.) There are two ways to display the content: default (sort of like a regular panel) and tabs. (The tabs.module, part of Javascript Tools, is required.)

As more of us start using jQuery, we're getting the same jQuery plugin included in two, three, or more modules. Personally I've included tabs, cookie, and history in the jstools package. I've now seen the form plugin in three different modules. As well as duplicating work and code, we get swollen pageloads that load multiple copies of the same file from different locations (one for each module). And, potentially, problems if two different modules use different versions of the same plugin, and one overwrites the other.