Saturday, October 11th, 2008
This Week in HTML 5: Web Forms 2, Search, and more
Category: HTML
- input type=”email”
- input type=”url”
- inpu type=”number”
- input type=”range”
- input type=”date”
- input type=”time”
- input type=”datetime”
- input type=”week”
- input type=”month”
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:
- Following up on last week’s article on clickjacking, the security researcher who discovered (and named) it has posted details of his discovery. Short version: it’s even worse than we thought, but vendors are working on it. Here’s a proof-of-concept against Adobe Flash that, quite literally, spys on you (via your webcam) without the usual warning dialogs; here’s Adobe’s response. NoScript now offers enhanced protection against some clickjacking attack vectors.
- Anne van Kesteren gives an update on IE 8′s support for HTML 5 and other emerging standards.
- Matt Ryall has a good article on HTML 5, headings and sections, which documents the differences between HTML 4 and 5′s header elements. My personal opinion: I once wrote a 500 page book in Docbook, a non-HTML markup language for technical writers. Docbook 3 had separate elements for
<sect1>,<sect2>,<sect3>, &c, and it was a massive pain in the ass to cut-and-paste sections, or try to reuse them in different documents. Docbook 4 added a generic<section>element which can be nested indefinitely, and all those problems went away. Lots of web authors copy-and-paste HTML markup; anything that helps that “just work” is a good thing.
Related Content:
as addition somthing like: input type=”text” mask=”##-##-##-####” would be nice.
“Lots of web authors copy-and-paste HTML markup; anything that helps that “just work” is a good thing.”
.
This way lies madness.
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?
@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.
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
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.
I think the date input is long overdue.
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.
“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.