<button value="OK"/>
And the device gets to choose how to render that using a native widget:
I think this is a great level of abstraction. But in my opinion the W3C made a mistake when they specified:
<input type="checkbox"/>
See that type attribute? It's referring to the widget type. But it really should be referring to the data type. Then we could write:
<input type="boolean"/>
<input type="date"/>
<input type="integer"/>
<input type="color"/>
<input type="date"/>
<input type="integer"/>
<input type="color"/>
And the device gets to choose how to render that. If it were a simple device, or it didn't understand the data type, it could just render a text box. But better implementations could offer nicer UIs. Date pickers. Spinners. Color pickers. Browsers could compete by offering better widgets.
Think how much time our industry has wasted re-implementing HTML date pickers and spinners. Hundreds of widget libraries across all development platforms (PHP libraries, Java libraries, .NET libraries, etc).
I came to this realisation while using Metawidget. Typically you tell Metawidget to generate an entire form, composed of many widgets:
<m:metawidget value="#{myForm}"/> ...which gives... |
But I've found it suprisingly useful to still use Metawidget even when dealing with single widgets:
<m:metawidget value="#{myForm.name}"/>
<m:metawidget value="#{myForm.age}"/>
<m:metawidget value="#{myForm.dateOfBirth}"/>
<m:metawidget value="#{myForm.age}"/>
<m:metawidget value="#{myForm.dateOfBirth}"/>
Here we are deferring the actual widget choice to Metawidget. So Metawidget can choose it for us based on the best widgets available on the target device, our locale, our accessibility requirements etc. Maybe that's a plain text box. Or maybe it's a RichFaces date picker. Or an ExtGWT spinner.
It's nice to defer that choice, because now all the widgets can automatically upgrade over time as the platform improves. If this were in HTML too, it'd save an enormous amount of re-implementing. And it would provide a new battleground for browser competition.
Better for developers. Better for browser vendors. Better for consumers.
2 comments:
I think, it's too complex to work with separate fields.
When I work with one metawidget, I can save my entity back on one line of code. Also, when I use one metawidget design of form isn't my headache. But when I work with single fields it's not much better then work without metawidget at all...
I would say it is better for the browsers to render the fields as the end users will feel comfortable with the type(style) of button displayed evenly in every website, rather than the properties altered by the developers in HTML5. CSS is always there to style them if they need HTML by default can be more intelligent than just styling
Post a Comment