Expected Wufoo Markup Changes for HTML5 Forms Upgrade

by Wufoo  | 

Next Friday, we’ll be upgrading the markup on Wufoo public forms to HTML5 based on the research we gathered on [HTML5 form support](http://www.wufoo.com/html5/). We’re doing this to help improve the semantics of our forms, which is great for improved accessibility, and to make sure that Wufoo can be in a position to use the latest form features implemented by browsers as they come out. While these changes should not affect the majority of our users, we are pre-announcing the changes to give users that take advantage of our [Custom CSS](https://help.wufoo.com/articles/en_US/kb/Theme-Designer/#customCSS) features to adjust their CSS stylesheets so that nothing will look wonky after the transition. If you’re using a custom theme on your form **without** using the Custom CSS feature, you won’t have to do anything. All themes will upgrade automatically to accommodate the new HTML5 markup changes.

##HTML Changes

Currently, Wufoo forms were all written to conform to the XHTML 1.0 Transitional specifications set by the W3C.

On April 1st (and no, it will not be a joke), we’ll be using the more elegant HTML5 doctype.

To allow the new semantic markup to work on older version of Internet Explorer, we’ll also be including a reference to load the HTML5 Shim script.

##Type Changes

A number of fields will utilize the appropriate field types based on the information they’re collecting. The **Number** and **Currency** fields will both use `type=”number”` instead of `type=”text”` after the change. The **Email, Website and Phone Fields** in Wufoo will use the corresponding `email`, `url` and `tel` types. Unfortunately, because the hooks for handling the styling for browser side validation is not well supported yet, we’ll be adding the `novalidate` attribute to the `

` element to disable the automatic client side validation. On certain mobile devices like iPhone and Android, you’ll see that filling these fields will bring up more appropriate keyboard layouts to make going through them much quicker than before.

##Required Attributes

The following fields will add the new `required` attribute based on the field settings set for your form:

> Single Line Text, Paragraph Text, Address, Date, Email, File, Currency, Name, Number, Phone, Time, Website

Again, since we’ll be using the `novalidate` attribute on the forms, this will not initiate the client side validation from the browsers that support it. This is because hooks for styling validation messages are still spotty at best. We’re adding them, however, so that we can use the feature when it is better supported.

##Multiple Choice & Checkbox Fields

The changes we made to the Multiple Choice and Checkbox fields will probably be the most disruptive changes to people’s custom stylesheets. If you’re a designer that’s spent some extra time making these fields more fancy, please make note that the current markup, which looks something like this:




  •

    • Will now be using a `

    ` and `

    ` element to help make it easier for users filling out forms with screenreaders to more clearly associate the field question with the entire group of choices. The new markup structure will look like so:




  •

    • In your Custom CSS file, you’ll just want to look at anything that is styling `label.desc` and make sure to also add `legend.desc` to that CSS rule. That’ll probably catch most issues that might occur because of our update.

    ##Header

    The markup for the form’s title and description will change from:

    to using the new semantically friendly `

    ` element.

    If you’re using something like `.wufoo .info{}` or `.wufoo #header` in your CSS rules, that should steer you clear of potential conflicts and changes.

    ##Section Breaks

    Currently, **Section Breaks** in Wufoo use the following markup structure:

    • We’ll be adding the new `

    ` tag around the content like so after the markup changes go out:

    • This shouldn’t affect anyone’s current CSS rules if you’ve been using something like this:

    .section h3{
    color:blue;
    }

    However, this will allow us and users to start using the less hackish `section h3{}` selector to style these elements in the future.

    ##Running Total

    This shouldn’t affect too many users since it’s a fairly new feature, but the [Running Total](http://www.wufoo.com/2010/12/14/preview-prices-on-wufoo-payment-forms-with-running-total/) markup will be using the new `` tag, which means the current HTML structure will move from this:

    to this:

    ##And That’s It

    We have updated the [Wufoo Theme Kit](http://www.wufoo.com/download/themes/WufooThemeKit.zip) so that you can see all the new markup in one single document and be able to create themes accordingly. Again, this shouldn’t affect too many people on Wufoo. If you’re a web designer or have a designer working to manipulate the look of your Wufoo forms, then this is where you’ll want to have a look before our roll out next week.

    Comments

    • I don’t do a lot of this stuff even though I allow users to download an eBook I offer them after filling the form. I uploaded my eBook to google sites file cabinet, linked it in confirmation email and I’m done. No scripts nothing. They got to download it from somewhere, so why not from my own link?

      Posted March 25th, 2011 by Jaky Astik.

    • HI Jaky, I think you might have meant to comment on the latest blog post about attaching files to emails and sending using our WebHooks setup. Sending a link is just fine and it’s actually what we recommend to most users. You can see our earlier post talking about doing just what you said here:

      http://wufoo.com/2011/02/21/how-to-send-a-file-after-a-form-is-submitted/

      Posted March 25th, 2011 by Kevin Hale.

    • Really nice changes!

      What about date field? Is HTML5 field suitable for this?

      Posted March 25th, 2011 by Andrey Petrov.

    • I don’t think this was a wise move at all.

      The W3C won’t deliver their final draft for HTML5 before May 2011 and what you implemented is not aimed at mass production and is not yet ready for exploitation on a broad level. The WHATWG is doing a fine job but in my humble opinion, until HTML5 is fully validated and implemented correctly by the main browsers you shouldn’t have gone that far. HTML5 and CSS3, especially concerning forms, are not rendered in the same way by Chrome, IE9 and Firefox 4. You have broke a lot of stuff by doing this, which had real damages for the business of your power users with loads of customized advanced forms in production.

      Hidden fields now appear on IE9 because of security issues that the general public don’t fully comprehend. Fonts are not always rendered properly on buttons either.

      Your “legend” fields don’t float properly on Firefox 4 making them impossible to read.

      I haven’t check everything yet but if HTML5 is all nice and sound for marketing purposes, it just triggered a massive IE6-like disease where all browsers go different ways and do whatever they like, leaving developers to sort out the mess with multiple fallbacks and hacks.

      I really believe HTML5 is great for experimentation but not for production (yet). This not my personal feeling, this was the main statements by Microsoft, Google and Mozilla in every conferences or workshops I’ve attended lately.

      I have tons of forms, very little time to repair them all and feel no joy spending time finding out why something works well in Chrome and not in Firefox 4 and so on. This is not very professional.

      Posted March 25th, 2011 by Mike.

    • To be fair, it seems the problems my forms encountered where caused by maintenance on wufoo’s servers (I guess so since some were not responding properly for a while), probably from the switch to HTML5 and now most of my forms respond correctly (few minor things to modify but it’s way better). My problem with IE9 was totally unrelated as well, so sorry for complaining.

      I still do believe that it would have been wiser to wait for validation from the W3C though. And I still fear for our sanity with cross-browsers compatibility in future HTML5 development.

      Posted March 25th, 2011 by Mike.

    • Hey Mike, thanks a lot for voicing your concerns about this. We did a ton of research on this stuff before moving forward with any of it. The most important thing to us is browser implementation of features. Of course we’re watching the spec and rooting for it to be well written and have vendors adhere to it, ultimately what matters is what the browsers do. Every change we made the first priority was that it doesn’t break the form in any way in how it works or looks. Then our priorities for any particular feature was to see if it would improve accessibility, usability, or semantics. If there was all benefit and no harm, we implemented it. Ultimately this means we are actually using very little of what HTML5 forms theoretically have to offer, but that may change as technologies mature.

      We also certainly aren’t perfect. We’ve already had to tweak and fix some things. We always learn a lot when something like this goes out to a whole user base! If you are seeing specific forms with cross browser issues, please let us know and we’ll try and get you squared away.

      Posted March 25th, 2011 by Chris Coyier.

    • Test

      Posted March 25th, 2011 by Alex Burns.

    • Hey there, we have been using the form embed script to provide an https: version of the wufoo forms within our secure site and since this update, the html5 shiv hosted on Google code embedded in the forms as is now causing all our IE clients to receive security zone warnings when accessing the survey. This reflects very poorly on us and many of our users now think there is a security issue with our service when in actual fact, none exists. Is there an https: version of the google code repository or some other place you could fetch this from?

      Posted March 25th, 2011 by Jim Denmark.

    Add a Reply

    You may use HTML for style.