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:
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:
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:
But I've found it suprisingly useful to still use Metawidget even when dealing with single widgets:
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.