Saturday, October 11th, 2008

This Week in HTML 5: Web Forms 2, Search, and more

Category: HTML

<p>In Mark’s eighth roundup of HTML 5 land, he delves into the merging of Web Forms 2, which gives us fun things like:

Then Mark discusses input type=”search”:

Andy Lyttle wants to standardize one particular feature of <input type=”search”> (which is already supported by Safari, but not standardized): placeholder text for input fields. The text would initially display in the input field (possibly in a stylized form, smaller font, or lighter color), then disappear when the field receives focus. Lots of sites use Javascript to achieve this effect, but it is surprisingly difficult to get right, in part because no one can quite agree on exactly how it should work. Mozilla Firefox displays the name of your current search engine in its dedicated search box until you focus the search box, at which point it blanks out and allows you to type. Safari’s search box is initially blank (at least on Windows), and only displays the name of your default search engine after it has received focus and lost it again. Google Chrome’s “omnibox” displays “Type to search”, right-justified, even when the omnibox has focus, then removes it after you’ve typed a single character. Adding an <input placeholder> attribute would allow each browser on each platform to match their users’ expectations (and possibly even allow end-user customization) of how placeholder text should work for web forms. Discussion threads: 1, 2, 3. So far, there is no consensus on whether this should be added to HTML 5, or what the markup would look like.

And, he finishes with some interesting posts:

Related Content:

9 Comments »

Comments feed TrackBack URI

as addition somthing like: input type=”text” mask=”##-##-##-####” would be nice.

Comment by Aimos — October 11, 2008

“Lots of web authors copy-and-paste HTML markup; anything that helps that “just work” is a good thing.”
.
This way lies madness.

Comment by eyelidlessness — October 11, 2008

Indeed, I must agree with eyelidlessness, this is a slippery slope. Loose interpretation and excessive forgiveness of any language, including markup an lead to alot of headaches. You make it easy to copy and paste, but what about having to actually look at that markup once something goes wrong?
.
I also can’t figure out why we need multiple subtypes for text input, and multiple subtypes for date input. a plain text input with a pattern matching option (similar to what Aimos has shown) or along the lines of what .NET offers would be preferable yes? HTML 5 is beginning to suffer from creeping featurism. When are enough bells and whistles enough?

Comment by TNO — October 11, 2008

@TNO: I strongly disagree on the input subtypes. Where you implement an umbrella pattern but require the sub-part patterns to be written by users, the absolute most likely scenario is that users will implement patterns which don’t conform to the expectations of the umbrellas, creating inconsistent user experience and bugs. If you don’t believe me, go look for a spec-compliant URI validation regex. You might find one (I wrote it), but I doubt it (I doubt it’s been indexed yet).
.
Where the general types are basically concatenated versions of the subtypes, where is the bloat? And what is the harm in providing options for which use cases abound?
.
Looking at the listed input types, I don’t see any bells and whistles. I’ve wanted each one of those on multiple occasions; they’re extremely basic. Nearly every language provides either the ability to produce and interpret those data forms, or the ability to get there with a couple very simple function calls.

Comment by eyelidlessness — October 12, 2008

My concern was over features that would fall on deaf ears when more control is needed and you end up falling back to custom validation anyway for your domain specific need (If I want to disallow yahoo.com urls or email addresses from russia for example)
.
But now that I’ve read over the spec again I noticed the pattern attribute which I didn’t see before (its been a few months).
.
http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#attr-input-pattern
.
With this option available I don’t have an issue anymore with the additions. I was under the impression until now that instead of having a generic pattern matching option it was just planned to add types according to common usage TODAY without considerations to more specific needs and future developments

Comment by TNO — October 12, 2008

Yeah, input.pattern is awesome. It’s one of the things that makes me think the HTML5 group really “gets” the fact that they’re supposed to be making existing practices easy and extensible.

Comment by eyelidlessness — October 12, 2008

I think the date input is long overdue.

Comment by Jordan — October 13, 2008

I wish they are not expecting my users to introduce ISO8601 dates when using the keyboard.
On the other hand, I miss some of the typical validation attributes such as exclude-min and exclude-max.

Comment by icoloma — October 13, 2008

“I wish they are not expecting my users to introduce ISO8601 dates when using the keyboard.”
.
Then write a date pattern you prefer. I imagine the expectation is that people will write widgets around the in-built validation patterns and let the browser do the validating for them.

Comment by eyelidlessness — October 13, 2008

Leave a comment

You must be logged in to post a comment.