Support HTML5 elements

Hi,

Here's a patch that adds support for email, number, range, search, and telephone field. I also added support for the placeholder text on the new field.

I don't think is complete there's still some fields and properties missing but I think is a good start.

Quick Documents on creating the New fields:

  $form['email'] = array(
    '#type' => 'emailfield',
    '#placeholder' =>'abc@text.com',
    '#title' => t('Email Field'), 
    '#size' => 60, 
  );
  $form['number'] = array(
    '#type' => 'numberfield',
    '#placeholder' =>'1234',
    '#title' => t('Number Field'), 
    '#size' => 60, 
  );
  $form['telephone'] = array(
    '#type' => 'telfield',
    '#placeholder' =>'123-456-7890',
    '#title' => t('Telphone Field'), 
    '#size' => 60, 
  );
  $form['range'] = array(
    '#type' => 'rangefield',
    '#max' => 100,
    '#min' => 10,
    '#value' => 15,
    '#title' => t('Range Field'), 
  );
  $form['search'] = array(
    '#type' => 'searchfield',
    '#title' => t('Search Field'), 
    '#size' => 60,
    '#result' => 50,
  );

You can also control how invalid fields are display using css with the dynamic pseudo-class ':invalid'.

Oh Also here's a quick screenshot on how these form elements display on Chrome.

Subscribe

I like the idea of having some level of support for html5 form elements. Hope we get this in soon.

Here's an updated patch. I got rid of the placeholder attributes since it can be implemented with the form api attributes key.
I also added the url element and simplified all the element's type name.

Just assigning to myself.

subscribing

Hey,

Here's an updated patch that provide support for the placeholder attribute as per our conversation on irc. Since the html5 spec allows the placeholder attribute to go in the text and password field I added it to both. And of course the new elements :-D.

One thing to note. I kinda got lazy and just added the process callback to the new elements. That's actually not necessary for the new elements since we're the one's implementing the theme function for those elements. We can actually implement the placeholder attribute in the theme function but I decided to be consistent instead. If anyone thinks I should change it just let me know and I will.

There were a few whitespace issues that this patch addresses ... but other than that I think this looks pretty clean.

subscribe

sub

subscr

Last patch breaks Drupal if you are using CCK (almost mandatory) with the module Number:

Fatal error: Cannot redeclare theme_number() (previously declared in xxxxx\sites\all\modules\cck\modules\number\number.module:583) in xxxxxxxxxxxx\sites\all\modules\elements\elements.module on line 245

So probably it would be needed to change the theme function names to avoid conflicts.

Yea, it does break cck. We had change the number field to numberfield so it can play nice with cck. But it must had gotten lost in the follow up patches. I'll submit and update patch reverting back to numberfield

Yea, We probably should use [type]field. I had done that in my 1st patch then back out of it :-/.

Just a thought: Not considering that one field has already been named [type]field - wouldn't it be more suitable to name the fields [type]element, considering that this module's name is "Elements" and not "Fields" or something like that?

I like [type]field because is consistent with drupal's form api.

Switching it back to active, because of the naming issues with other modules.

been doing some work parallel to this, mainly attribute related (like datalist and stuff) and server-side validation related, a field taking a pattern attribute should also check against this pattern on the server-side, but one of the problems is that the markup takes regex in JS format, whereas the server needs it in PHP format...

sry, didn't mean to cross-post :x

Just a quick update ... FF4 Beta now supports "search", "tel", "url" & "email"