Other rounds: [One|Two|Three|Four|Five]
We're back again with another round of "Bug or Feature?" highlighting a particular behavior in one or more browsers, that, well, could be a Bug, or it could be a Feature... we'll open up the comments for your vote and opinion.
Alright, what's today's "Bug or Feature"?
Synopsis:
Everyone knows the basic form elements [button|fieldset|input|textarea|select]. Within the [input] element there are several types: [button|checkbox|file|hidden|image|password|radio|reset|submit|text].
However there is a quirk/loophole/bug/feature with the <input> element that some browsers are taking advantage of.
By default, if you don't specify the type attribute, or specify a value that isn't recognized as one of the above types the browser should default to "text" (and every browser does) - however some browsers take advantage of certain key types and then render the field in their own special ways.
For example if you use: <input type="search" value="Keywords..."/> in Safari and Chrome it will render like this:
As you can see a little 'x' is provided automatically to allow users to clear the value with a mouse click.
If you don't specify a value Safari will provide a faded tip in the box indicating what the field is for:
Ok, what about other types? and other browsers?
For example if you use: <input type="email"/> in Opera it will render like this:
The little email icon helps identify the field as being a field expecting an email address as the input value and it also increases the default size of ~20 characters to ~25characters (depending on your font selection)
If you use: <input type="url"/> in Opera it will render like this:
Again Opera adds a little icon and increases the field size to ~28 characters.
Know of any other values for type that one or more browsers treat in a special way? If so, let us know!
So now the Question is...
Is this a Bug? Or a Feature?
Vote "Bug" or "Feature", and add your thoughts.
Update: 100 bonus points for Rafael! As noted in the comments below the "url" and "email" types that Opera rendered uniquely just happen to be 2 of the types specified in Web Forms 2.0 and they happened to be 2 of the less decorated fields. The full set of new field types is supported in Opera and they look and work great! We'll post some screen shots of these fields shortly.
Opera's Web Forms 2.0
Date:
DateTime (local):
DateTime:
Time:
Month:
Week:
Number:
Range: (numbers added for visual aid only)
Submit a bug
Posts
6 comments:
I think it is a feature - moreso I expect other browsers to start copying it.
I use Arora a fair bit (based on webkit) and it too has the faded "search" box but doesn't have the "x" for deleting the search terms.
In my opinion it is also a feature. This behavior is better than just ignoring the whole element. All presented here input types are just some variations of standard text inputs. So, I really like this "bug".
As for new input types, Opera has implemented basic support for WebForms spec, so all input types mentioned in the spec (http://www.w3.org/TR/2006/WD-web-forms-2-20060821/#extensions) should work.
We can't say this a bug.. Its just a feature... "They" have implemented many new features and also enhanced it... So you cant say these as bugs
I certainly like the idea and therefore feel it is a feature but I wish there were some "rules" or "guidelines" around this.
I hope that other browsers follow Safari/Chrome/Webkit with the type="search" option.
As for the email and url types? hmmm I don't know. If they somehow natively provided some sort of self validation that would be cool but they don't seem to need any special rendering.
I looked at the Web Forms 2.0 stuff in Opera - they are very nice. Not quite as "sexy" as I would like but thats fine.
Finally I would really like a type="color" field that would let you select a color (with a picker). I've built these with HTMl/Javascript before but it is a lot of effort that if done natively would be really easy.
I will however reserve the right to call this a bug. Only because I know that one day in the future IE will support some types that are either implemented wrong or are completely proprietary. e.g. type=".netDate" or type="MSOutlookMeeting" which would make my blood boil.
for me at the moment it's neither nor.
As long as this isnt't working in the most frequented browsers it's just useless.
If this would be standard I would highly appeciate such "features"
but just if I would be able to style them extensivley and in case of the date (calendar) elements if I could define a format for the date value.
Post a Comment