HTML5 Forms introduce new form controls which need to be designed and discussed. Let's do that in this meta-bug to be sure they are coherent.
This doc is a UI design work by Google (for Chrome): http://docs.google.com/View?id=dch3zh37_0cf8kc8c4
I think we should began by discussing about the new input fields with a text control which are: - search - tel - email - url At the moment, the search input type is only about the style. For example, we could use OS X style for search fields. As we are going to add something for the search input type, should we do something for tel, email and url ? I was thinking about an icon but it could be too intrusive maybe ? I mean, too much. Technically, the tel input type is going to behave exactly like a simple text input type. We may add autocomplete using Contacts from Labs. email and url input types are going to behave exactly like a simple text input type too but when there value would be invalid (not an email/url), the field could be styled with a CSS rule (:invalid pseudo-class).
For autocompletion, I would like to use the contacts in my n900 phonebook. Would a generic API for extensions be a good solution, so that Firefox won't have to support every conceivable device natively? That way Fennec on n900 could ship with an extension for that platform activated by default, and another extension could be activated by default on Android, etc. On the desktop, I am surprised to see that Contacts work with Mac OS, but not with Thunderbird. I use the latter! If the Contacts team does not step up and provide Thunderbird support I guess some other extension developer will, provided this is made possible in an easy way.
For our in content UI we try to go pretty minimalist, and not really impose any particular design aesthetic on the Web page (which could look like anything). For instance our image loading and image broken icons are done in a sort of wireframe monochrome style that is meant to be as simple as possible. For these fields if we decide that a small symbol is useful for helping the user understand the context (like "I'm about to autocomplete on phone numbers"), then it seems like we would want to follow the same approach, designing very simple monochrome symbols. The platform specific search field that we previously worked on would pick up a simpler magnifying glass, etc. Also it's of course important that Web designers can override any styling that we provide. cc'ing Stephen for his input as well.
(In reply to comment #4) > Also it's of course important that Web designers can override any styling that > we provide. I agree. The best way to allow this might be through the same technique as when overriding the style of the <hr> element, which is by resetting the CSS used to create the styles. In this case it would either be the "background" property or the "background-image" property. Does this sound like a good solution?
How should inputs that have @list suggestions interact with formfill suggestions? The spec shows an example with <input type=url> with some <option value=.. label=..> followed by other suggestions.. perhaps previous formfill data or data from the browser's history. http://dev.w3.org/html5/spec/images/sample-url.png When searching, should @list suggestions always come first? If we used something like the location bar display, would we want to strip out the star for bookmarked items and maybe the favicon? One reason to maybe strip out the favicon is that the <option> tag can only specify a value (url) and label (title). There's nothing to specify other data like a favicon, so mixed @list suggestions and locationbar suggestions might look odd.
(In reply to comment #6) > How should inputs that have @list suggestions interact with formfill > suggestions? The spec shows an example with <input type=url> with some <option > value=.. label=..> followed by other suggestions.. perhaps previous formfill > data or data from the browser's history. > > http://dev.w3.org/html5/spec/images/sample-url.png The example suggests that the browser history might be included: "[...] the user agent had also found that the user had visited http://www.w3.org/Consortium/#membership and http://www.w3.org/TR/XForms/ in the recent past [...]" > When searching, should @list suggestions always come first? I would think so, and the example suggests this too. > If we used something like the location bar display, would we want to strip out > the star for bookmarked items and maybe the favicon? One reason to maybe strip > out the favicon is that the <option> tag can only specify a value (url) and > label (title). There's nothing to specify other data like a favicon, so mixed > @list suggestions and locationbar suggestions might look odd. We could display the blank page icon for author-provided entries or entries from the form history...
Maybe suggestions from the browser history or anything else (like Contacts for email/tel) should not be considered like @list but like autocomplete ? I think that's more coherent. Then, we have to choose if we want to mix autocomplete and @list suggestions in the same list. If we do, we should at least found a way to clearly distinct both kind of entries. Maybe @list suggestions could be showed always on top of the suggestions and don't hide when the typing doesn't fit the entry (contrary to autocomplete behavior).
Mounir: Alexander Limi (firstname.lastname@example.org) will be doing the UX support for all of these HTML5 fields, so you can ask him for feedback and reviews.
does anyone can tell me when can we expect to see html5 new input types (email, url, number, range, date pickers, search, color) with smart and appropriate ui ?
(In reply to sfornengo from comment #10) Especially email, url, and number inputs in Fennec - where it would display the optimal soft keyboard for each. See iOS Safari: http://screencast.com/t/ormhYNDdpyHz
Summary: HTML5 Form Controls UI → [meta] HTML5 Form Controls UI
You need to log in before you can comment on or make changes to this bug.