HTML5 forms in Zend Framework

David Papadogiannakis

Since W3C published its HTML5 specs in January 2008 many browsers have started their implementation of the improved XML structure and its new attributes. But what does this mean and how can we as developers benefit from all this on a form level? This talk is about implementing HTML5 specific tags in your forms created with Zend_Form.

New features HTML5 for forms and validation

First of all to clarify the meaning of all these new goodies, we first look at what’s available. HTML4 had a few different input elements that could be added to your form : text, password, hidden, checkboxes etc. HTML5 brings even more types that can be added to your <input> tag. For instance:

  • email
  • url
  • number
  • range
  • Date pickers (date, month, week, time, datetime, datetime-local)
  • search
  • color

The email attribute to start with isn’t much of a help in a basic browser that runs on your pc/laptop. It is handy though on a mobile platform as the keyboard changes to a type where the @ sign is not tucked away in some dark corner. The one major advantage in browsers that support this new feature is that they trigger a validation process (client sided!). No more tedious javascripting of your own to pre-validate email addresses. The same goes for the other fields. Each input type triggers a certain validation (which, unfortunately, is browser dependent!) so the user is aware of what is expected.

Besides the new input-types, HTML5 also provides some other tags that are interessing when dealing with our forms:

  • datalist
  • keygen
  • output

I won’t go into detail on these elements but I have them prepared in the codebase. First the datalist is a mixture of the input and select elements. With “basic” HTML it required some javascript to generate such a feature and even then it wasn’t flawless. The keygen is a client sided keygen generator for authentication purposes. I’ve tested it with Firefox 3.6.10 and Opera 10.60 and both generate a bit of a different element with different results. I quote from the w3schools site: “Currently, the browser support for this element is not good enough to be a useful security standard.”
The last element that is new is the output element, which well does nothing except that it is reserved for output. It’s just a container for different types of output, like calculations or script output.
That’s about it on the introduction to HTML5 and forms. Let’s proceed to the awesome part!

Applying HTML5 to your Zend_Form

(Note: all code can be found on GitHub)

Basically all that we need is an extended Zend_Form_Element_Text and some view helpers that do the rendering. In this case I’ve used Glitch as the namespace for the classes.
An example:

As you can see I’ve provided a basic set of key value pairs that are represented by constants to deliver the basics. Further down the I’ve used the constructor to decide to get the type of the element based on the name of the element if the type key is not given in the options argument. The type of the element points directly to the “type” attribute of the element. I’ve made the _getType method to map the element name to its matching type attribute. So far nothing exceptional, just some matching of keys and returning their values. As a treat I’ve build in get/set methods that allows us to disable automated filters and validators for our new elements. Next up is the actual element and for this example lets use the number field where I’ve implemented automated filters and validation based on the settings given to the element upon constructing it.

The init() method does a check for the attributes that are used in HTML5 (see specs) for the number type and adds a logical validator to the element. In this case the min and max attributes are used.

Now let’s take a crack at a view helper for the new types (yes, just 1 view helper!)

Now let’s build our form and add all the new elements.

As you can see, nothing special going on. With the small exception of the range and number fields where we have provided specs for the attributes and more important, specs for our server sided validation. For the range element I’ve disabled the automated filtering and validation with the keys ‘autoloadValidators’ and ‘autoloadValidators’ set to false.
(Note the onforminput attribute on the output element, there is code for that in the view layer)
The datalist, output and keygen elements do require some more code as they rely on their own new view helpers which renders the right tags but this is nothing you should be worried about as it all included in the download package.
So now that we have our HTML5 form filled with elements and just 1 step away from yes, RESULT! Paste this in your view

These lines render the entire form and add some javascript code to calculate the sum of the 2 form input fields.
Now to see the new form in all its glory I recommend Opera for viewing the beauty of your newly generated elements and take it for a test run. (Opera has the best support for the new input types)
(Reminder: there is client sided validation but that does not take away that you still are responsible for the data that comes in! Read: write your own validation chain.)

Now let’s see what happens when we don’t want the (still experimental) HTML5 elements. Just replace this code in your application.ini:

resources.view.doctype = "HTML5" with
resources.view.doctype = "XHTML1_STRICT"

Now refresh your page and see how everything just falls back to input elements with the attribute text instead of the funky HTML5 attributes.


One of the great joys (for me at least) of working with Zend and specific Zend_Form and Zend_Form_Element is that it so extendible!
With a few classes of your own you can create almost any kind of element you want, it’s all up to your imagination.
I hope that you will agree that we extend to support the future 😉

All code can be found on GitHub

Showing 24 comments
  • Wesley

    I can’t get your solution to work. I have set the doctype to HTML5, and it shows as such in my final html output, however, none of the elements are coming out as HTML5 elements, instead they are coming out as input type=text.

    public function getColorField(){
    $element = new Glitch_Form_Element_Text_Color(‘color’);
    return $element;

    public function getColorForm(){
    $form = new Zend_Form();
    require ‘Element.php’;
    $element = new Element();
    return $form;

    $this->view-form = $colorForm;

    the view script
    echo $this->form;



    • Wesley

      *the result is
      input type=”text” name=”orderdate” id=”orderdate” value=””

      (the blog blocked this )

  • David Papadogiannakis
    David Papadogiannakis

    Based on the information given, I would say that your application is not aware that it should also look for view helpers in the Glitch namespace.

    Could you try the following things to see if you get any result.
    If you are using resources based config

    resources.view.helperPath.Glitch_View_Helper = "Glitch/View/Helper/"

    Else the following should work in your controller:

    $this->view->addHelperPath('/Glitch/View/Helper', 'Glitch_View_Helper_');

    Or more general to be called from anywhere

    Zend_Layout::getMvcInstance()->getView()->addHelperPath('/Glitch/View/Helper', 'Glitch_View_Helper_');

    Also make sure that your doctype view helper is set to HTML5 else the Glitch_Form_Element_Text and the Gltich_View_Helper_FormText will ignore all new types and by default fall back to text.

    Let me know if the above suggestions worked out for you.

  • Wesley

    Thanks so much for your quick reply!

    I added the Glitch namespace to my Bootstrap like this:

    protected function _iniAutoload(){

    $autoLoader = Zend_Loader_Autoloader::getInstance();
    $resourceLoader = new Zend_Loader_Autoloader_Resource(array(
    ‘basePath’ => APPLICATION_PATH . ‘library/’,
    ‘namespace’ => ‘Glitch’

    return $autoLoader;

    When I delete this code I get an error that Glitch-yada-yada cannot be found.

    Also, I echo $this->doctype()->isHTML5(); in my View and it returns 1

    After reading your suggestions, I tried them anyway and it still does not work.

  • Wesley

    Also, I’m using ZendFramework 1.11

  • Wesley

    I resorted to


    Easy solution.

    Thanks for your help!

    • Michael

      Thank you for the article. I cant get it working the way you provided the solutions, because we use a generic Form Generator. But this article showed me the right way to do 🙂

  • David Papadogiannakis
    David Papadogiannakis

    Might be an easy solution but not really the way you want to go. Now you have to add that piece of code to every kind of element you want. And you’ll have to change that piece of code for every element once you switch from HTML5 back to something older.

    Did none of the 3 suggestions I gave work for you?
    Could you provide me with the error message you got with the code you posted?

  • Wesley

    I agree with you there, my solution isn’t the best, but it’s working…

    I’m not getting an error, I wish I was! I used Zend_Debug::dump($text) inside of FormText.php and no matter what I do it always returns “text”.

    I can tell that your helper is being called because the Zend_Debug tool is giving an output.

    I know it isn’t working because my html renders all HTML5 inputs as ‘input type=text’ as opposed to type=date, type=color, and etc.

    I also noticed that your view helpers work with regular Zend_Form_Element. So what I’m doing now is:
    $element=new Zend_Form_Element(‘datepicker’);


    return $element;

    then in my Controller I add:
    $this->view->addHelperPath(‘Glitch/View/Helper’, ‘Glitch_View_Helper_’);
    which works.

    • Wesley

      If I were to make a guess, I’d say that none of the Glitch_Form_Element_ elements are passing their type attributes to the viewer, which may be way setting them manually is working.

      Also, another weird thing happens with Glitch_Form_Element_Text_Number, this element echoes “array{0}” on the screen for every instance of itself. I’m not sure if these problems are related, but I was going to ask you about this later.

  • David Papadogiannakis
    David Papadogiannakis

    Could you provide me with a sample code of that? I can’t seem to reproduce the problem you are describing.

    As for setting the helper that is done in Glitch_Form_Element_Text based on their name if the option ‘type’ is not given. Maybe I’ll change this to being set by the elements instead of setting it magicly.

  • Polo

    I had a few problems getting this to work.

    I tried addHelperPath in both my bootstrap and controller and neither worked. I got the following error message: Fatal error: Class ‘Glitch_Form_Element_Text_Email’

    I then added registerNamespace(‘Glitch_’) to my bootstrap and received the following error message: Warning: include_once(Glitch\Form\Element\Text\Email.php) [function.include-once]: failed to open stream: No such file or directory

    As this path is different to the one in your library, I moved the Glitch/Form/Text directory to Glitch/Form/Element/Text and this has resolved the problem.

    Am I doing something wrong or is your directory structure in the library wrong?

    • David Papadogiannakis
      David Papadogiannakis

      Hi Polo,

      yeah it seems to be missing the Element sub directory.

      Thanks for the notification!

      • Polo

        No problem.

        Is it right that I needed to add registerNamespace(‘Glitch_’) in my bootstrap or have I done something wrong?

        Thanks for the plugin btw, it’s great! 🙂

  • Sebastian

    Thanks for your great library, it makes a lot of things easier!

    Two questions:

    You decide on the type of a form field by a) checking the element name for words like “date” or b) checking for the option “type”. Why can’t it be the constructor of the specific element class (like “Date”) that sets its type? Currently those classes don’t have any functionality at all.

    And secondly: Could you please give me a hint how to implement DataList for range fields? I only manage to add a separate field, but I need something like this:


    I’m looking forward to any help, thanks again!

    • Sebastian

      Oh, it stripped all my nice HTML code…
      Here’s the source:

      • David Papadogiannakis
        David Papadogiannakis

        Hi Sebastian,

        I’ll have a look as to how this could be achieved. It’s been a while since I’ve played with HTML5 and the new form elements so it might take a while to figure stuff out.

        I’ll let you know when I’ve found a solution.

        • Sebastian

          Wow, that was quick.
          I think I could deal with the constructor part by forking your project, perhaps I can get it to work. But the other one is not so easy, so I’d be glad if you’d look into it (if it interests you).

          • David Papadogiannakis
            David Papadogiannakis

            Hi Sebastian,

            I’ve send a pull request for the fix, which is an easy one btw. See

            As to your remark on the constructor part, well that was something I thought was useful back when I wrote the extension because 97% of the time you use the same elements with the same name.
            Now I think it shouldn’t act the way it does but I’ve never gotten around to rewriting that piece.

  • Neven

    Great article, only one thing.
    I can not seem to find the code you are talking about on the github repo you linked from the text.
    Is it removed or am i looking at the wrong place?

  • Nishant Shah

    I have download your solution from given GitHub path. But I am not able to find html5 controls in downloaded Zip file. Please help me to get it.

pingbacks / trackbacks
  • […] have any native HTML5 form elements, but with some help from Enrise you can use their HTML5 Form Elements. I won’t go over the intricacies of creating custom forms and elements, but I will quickly […]

  • […] have any native HTML5 form elements, but with some help from Enrise you can use their HTML5 Form Elements. I won’t go over the intricacies of creating custom forms and elements, but I will quickly […]

Start typing to search