Improve your forms using HTML5!

This article shows a few ways Web Forms 2 can better your forms.

( Read the article )

You should add that autofocus may only have one occurence in every single document...

Also, please use quotes around attribute values! You've got some responsibility on here (as opposed to your personal website). This could be copied a hundred or thousand times! Quotes make that much more readable... without them, discerning between attribute names and attribute values might be difficult (it is for me).

Originally posted by _Grey_:

Also, please use quotes around attribute values! You've got some responsibility on here (as opposed to your personal website). This could be copied a hundred or thousand times! Quotes make that much more readable... without them, discerning between attribute names and attribute values might be difficult (it is for me).

Although I agree with you on the fact that quotes (double quotes that is) make the code more readable, it isn't necessary according to the specification.

It was the first thing that popped into my mind when I read the article, why are there four different ways to specify attributes? Is that a way of saying "This is how we're bringing structure to a document." ? (Empty attributes are another thing... required="required" doesn't make sense too.)

Oh, Anne, nice intro to Web Forms 2.0

Ah, I was wondering if I would upset people with using different types of attribute syntax. What's the specific problem you have with it? I mean, browsers have to support it this way, validators will allow it and it saves a few characters when you're hand authoring.

Omitting the type="" attribute on <input> and method="" on <form> when set to "get" is allowed in HTML4 as well. Mentioning this here because the article might lead you into thinking otherwise!

Thanks for the part about omitting attributes. Does omission of the action attribute on the form element work in non-WF2 browsers?

@WalterTamboer: I know it is not required. If it was, I would have said it was wrong. It's just that the equal sign is absolutely no help in discerning attribute names from their values. Quotes (double quotes, yes) are there for a reason.

(Empty attributes are another thing... required="required" doesn't make sense too.)

Well... it's SGML legacy... to be able to omit a (boolean) value, it must be the same as the name, thereby giving absolutely no information and thus can be omitted.
I think it's unnecessary, though... "true" could be just as good (just define it that way). Imho, a few WF2 attributes also (used to?) use "true" rather than their attribute names as a value for these attributes.
 

Post edited Friday, 15. December 2006, 00:35:07

What will the errors look like when Opera starts supporting the "required" attribute? (It may work in a recent build, but I'm using the normal release (9.02 build 8585).

Interesting to see the display of icons in the text input for type=url and type=email. (They only appeared when setting "input:required { background:yellow }".) Also interesting to see that that style doesn't colour a textarea that is required.

Originally posted by _Grey_:

Well... it's SGML legacy... to be able to omit a (boolean) value, it must be the same as the name, thereby giving absolutely no information and thus can be omitted.I think it's unnecessary, though... "true" could be just as good (just define it that way). Imho, a few WF2 attributes also (used to?) use "true" rather than their attribute names as a value for these attributes.

I actually like the SGML approach. It is slightly annoying when the attribute name is long, like <hr noshade="noshade">, and arguably confusing in some cases: With disabled="disabled" is the disabling of the form control disabled or enabled?

But while it could easily be mapped into a boolean "true" or "false", the "false" option makes little sense. Leaving aside that I had preferred a 'shade' attribute for a 'noshade' attribute, that's legacy it makes no sense to change now, you would not want to state <hr noshade="false">, you would go for <hr> instead (or <hr/> in an XHTML context).

gemsling, to make required="" work you have to add a name="" attribute to the form controls as well. (If they don't have a name="" attribute they are not submitted so it doesn't make much sense to have required="" apply in that case.) I'll see if I can get the article updated. [Article has been updated now and an example has been added. We might make it prettier in due course.]

Post edited Friday, 15. December 2006, 23:24:33

Originally posted by jax:

But while it could easily be mapped into a boolean "true" or "false", the "false" option makes little sense. Leaving aside that I had preferred a 'shade' attribute for a 'noshade' attribute, that's legacy it makes no sense to change now, you would not want to state <hr noshade="false">, you would go for <hr> instead (or <hr/> in an XHTML context).

And if you work dynamically? Is it enough to just "add" the attribute to the DOM Node or do you still have to "set" it (i.e. assign a value)? If you have to set it, a "false" value makes much sense. Because it is the value to set if the option is disabled. So instead of coding something to either set it to the attribute name (first get that name, then set it) or remove the attribute you could just use "true" or "false" to set the attribute, without any need to get the attribute name or to remove the attribute etc.

Atm I don't have the knowledge/resources to look up how that works to set (boolean) attributes, so excuse any errors.

You would use a DOM attribute. As in:

inputRef.disabled = false

@anne: But that presumes that there is (or should be) a "false" value, which was being contested by jax, as far as I understand.

I suggest you learn something about ECMAScript and DOM attributes versus content attributes first before making such remarks. The content attribute does indeed not have any other valid value than the empty string and the attribute name itself. The presence of the content attribute makes the control disabled, its absense might make it enabled depending on some other factors. The DOM attribute is just something that takes a boolean and when set it affects whether or not the content attribute is present.

1) Links to http://www.whatwg.org/specs/web-forms/current-work/#url and http://www.whatwg.org/specs/web-forms/current-work/#email would have been appreciated.

2) Typo: "Soon you'll be able to simple write the following" => "Soon you'll be able to simply write the following"

Good improvements, implemented.

@anne: I cannot imagine a more friendly and informative answer. Thanks.

Originally posted by anne:

I suggest you learn something about ECMAScript and DOM attributes versus content attributes

This distinction is quite hard to understand for many, and I think it would help if we use the conventional JavaScript terminology "property" consistently, as in the DOM object doesn't have "attributes" but "properties" where the HTML markup contains "attributes".

The next step is to understand that there is no direct mapping between attributes (HTML) and properties (JS objects). Something marked up as <div test="foo"> will create a DIV object but not a DIV.test property in DOM-compliant browsers. It will still have a "test" attribute but you must use DIV.getAttribute('test') to see that its value is "foo".

Perhaps this distinction in itself is worth an article..?

HTML5 calls them both attributes. When it's needed to distinguish between the two one is referred to as content attribute and the other as DOM attribute. That's the convention I was following. (The term property is already used a lot in CSS.)

Originally posted by hallvors:

This distinction is quite hard to understand for many, and I think it would help if we use the conventional JavaScript terminology "property" consistently, as in the DOM object doesn't have "attributes" but "properties" where the HTML markup contains "attributes".

I would for clarity prefer consistent use of 'property' precisely for that reason. There is scope for confusion CSS/JS, but is much less likely.

Not to rain on your parade, since advancement is always good, but... aren't the proposed changes so far simply a watered-down subset of XForms? From what I've read of their specification, it seems that many proposed benefits still require fairly extensive scripting - and that's what we're trying to avoid here in the end, no? Wouldn't the Opera developers' time be better spent adapting and implementing what's already a full W3C recommendation?

I've just bought myself the domain schräder.se. Sadly, Opera does not accept my email address containing the letter 'ä'. Well, no email provider supports it either from what i know, som it ain't that hard yet!

By the way, this article is great. Why not link to all other articles describing the new features of HTML5?

I think internationalization of e-mail hasn't happened yet :-(. There are no other articles on HTML5 yet that I know of.

Originally posted by anne:

Ah, I was wondering if I would upset people with using different types of attribute syntax. What's the specific problem you have with it? I mean, browsers have to support it this way, validators will allow it and it saves a few characters when you're hand authoring.

This is exactly why I begin to hate HTML5. I like the idea of adding features to HTML without reinventing everything from scratch. The WhatWG follows a nice approach here. But this way of legalizing bad coding styles is not what I had whished to see from the WhatWG. Maybe you can save a few characters, but this will make all efforts towards unificating the web (from a coding perspective) fail.

Of course browsers will have to support this. But this is a chicken-hen-problem. Not only browsers are processing web content. Writing programs that make use of information provided by web sites could work so much easier if they could just read the page as an XML tree and get the information. So why can't just web developers start acting like hens and give life to a new, friendly web where information is more important than individual coding styles?

Freedo

freedo, "bad coding styles" is highly subjective. Previous iterations of HTML allowed this too. HTML5 also has an XHTML5 serialization if you prefer to code in XML.

I'm wondering what people are thinking by creating something like (x)html5 with the implementations that are demonstrated. It's good that they are working to standardize these things however I believe in the seperation of actual layout of a document and the coding parts. I believe these propositions are trying to join these things all together.

To think that some parts of html (and more specifically CSS) are still somewhat different in several browsers. Speaking of CSS there still isn't a browser that fully does everything in the description of CSS 1.0 the way it 'should', with CSS 2.0 being somewhat blurry as well and more CSS versions coming. I really wonder how this HTML 5 will actually improve anything over the use of javascript. Actually javascript is finally being 'standardized' (or rather I like to say 'compiled') with a push in the back from AJAX.

I'm just wondering what the advantages of HTML 5 will be and why people will start using this instead of the standards they have been using for such a long time already.

Actually I'm not questioning that it is very usefull to try and go for a new version of (x)html, but I think that short-term implementation of a new (x)html version really won't be happening. Maybe these drafts coming from whatwg will contain some good improvements over the current standards and it will catch on. I just think that browsers will not be able to keep up with these types of things. And there are so many applications making some type of use of the (x)html standard that doing something radically new and worth hyping --which is in my opinion needed if you actually plan on launching something like html5 (look at AJAX).

I guess this is just some food for thought and my 2 cents on this topic. I actually have no comments on your actual article Anne and actually found it a nice read. I really am wondering about what the future of the web is and how rapid the expansion of technologies now that AJAX hit the web --demonstrating it is possible to make some major changes in the way pages are designed.

Originally posted by freedo:

This is exactly why I begin to hate HTML5. I like the idea of adding features to HTML without reinventing everything from scratch. The WhatWG follows a nice approach here. But this way of legalizing bad coding styles is not what I had whished to see from the WhatWG. Maybe you can save a few characters, but this will make all efforts towards unificating the web (from a coding perspective) fail.

Of course browsers will have to support this. But this is a chicken-hen-problem. Not only browsers are processing web content. Writing programs that make use of information provided by web sites could work so much easier if they could just read the page as an XML tree and get the information. So why can't just web developers start acting like hens and give life to a new, friendly web where information is more important than individual coding styles?

Syntax wars is the least interesting part in spec development, it creates the most heat and provides the least energy. I could live with the SGML-inspired syntax of HTML as well as the XML syntax of XHTML, though I could agree that having two syntaxes may seem needless. But they are closely related and it is relatively simple to generate one from the other. Furthermore by having one standardised parsing (if that project succeeds) making a parser is a whole lot simpler.

Browsers have to do that anyway. Most content is not well-formed XML, and while there are XHTML browsers (more or less according to the rules), if they have any ambition to actually show web pages they have to parse non-XML HTML. Not only browsers, XSLT is required to handle HTML as well (whether current XSLT processors would flawlessly transform HTML5 documents according to the rules I don't know). Surely there will be XML processors that won't be able to handle this, but if they have ambitions to handle arbitrary web pages they would need a pre-processor to turn HTML5 into XML, for instance by XSLT.

What matters is that two different processors will create the same DOM from the same document. That would let presentation be separate from semantics, as BadGuy worries about (well, kind of anyway, there are more issues). This spec largely describe current practices, or new features naturally falling back to current practices (the backwards compatibility), so there should be little need to wait for a new generation of browsers (but existing browsers may need extensions for them to handle new features, and while that should be possible, this hasn't really been done yet).

Is placeholder already a part of the spec as well? I know Safari supports it, but I don't know if it has made it to the spec yet?

I just hope some of this stuff is in/makes it to XHTML. HTML is dead -- get over it. So much of a pain to parse unless (like browsers) you already have code for it written.

The del.icio.us link is wrong - it tries to add this:
http://dev.opera.com/article/view/improve-your-forms-using-html5/
lacking the 's' in articles. It does seem that many people have figured it out though, since the article is on del.icio.us' front page right now

jdevalk, probably a Web Forms 3 feature or perhaps it makes it into HTML5 when the specifications are merged, dunno.

singpolyma, parsing HTML isn't that more difficult. I actually wrote a parser based on the HTML5 specification which basically handles all the worlds HTML during Christmas with some other people, in Python though. But all these features are also available in the XHTML namespace. The extensions are being made to both HTML and XHTML.

I've released an open source cross-browser JavaScript implementation of the WHATWG Web Forms 2.0 Repetition Model: http://code.google.com/p/repetitionmodel/

I've also created a repetition model test suite so that my implementation and others (i.e. Opera) can be verified while at the same time the capabilities of the repetition model are demonstrated.

The recommended method for HTML 4.x to use labels is:

<input ... id="ControlID">
<label for="ControlID">Label text</label>

References:

http://www.w3.org/TR/html401/interact/forms.html#h-17.9.1
http://en.selfhtml.org/html/referenz/attribute.htm#label (SelfHTML is originally a german project, not yet well translated into english)

Will this work in "HTML 5" too? The specs for WebForms 2 and HTML 5 are not yet really complete...

Post edited Friday, 16. March 2007, 08:47:06

Yes. Note that what's used in the samples is correct in HTML4 as well.

I also want to thank fot another great article. I can't wait for Your translate in polish - thanks for great work! Greetings for polish readers:)

Brilliant idea Anne. Thanks for very interesting article. btw. I really enjoyed reading all of your articles. It’s interesting to read ideas, and observations from someone else’s point of view… makes you think more. Greetings

I find this article useful and am going to transalte it and some hot points of article discussions in italian.

Greetings

HTML5/XHTML5 is a good step forward, however we are not complete yet. I am seeing this topic pretty late.

I have a question though. How can we control the Error Messages which appear? For example, the error message for the email may be a bit too blunt for corporates and the messages would need to be in the same language the webpage is. Also, if you input the email id as something@something, without a .com or similar extention, the form is validated. Ideally, you should also be putting the extension as .com or .net or something similar to be able to even send an email.

Can someone help he understand...

Checks for required ect are done onsubmit by Opera...
But what can i do when i intercept the submit and still want to have the functionallity that i get by marking my form-fields with required?
There is still stuff I have to do by my own via js but does this mean I cant use the functionallity that is provided automaticly with the new form attributes (and types)?

Any Ideas? Anyone?

Despite some opinions I personally think that REQUIRED attribute perfectly applies to SELECT and will not conflict with anything that worked previously. At least not much than REQUIRED attribute on INPUT elements.

This is very common case when first option of select is empty one, and user need to select something else from the list to comply. If there is a need to submit empty value, REQUIRED attribute should not be used. Simply as that!

Here is other person that asked the same question.