[whatwg] Input elements & microdata
nyarly at gmail.com
Tue Feb 19 01:00:30 PST 2013
There was an email from last year suggesting that the values of input
elements be derived from their value attributes - the purpose there being
to be able to control the form via the microdata interface. I've only been
able to read it in the archives - the brief exchange was between Igor
Nikolev and Ian Hickson, who was curious about use cases.
Conversely, it would be useful to be able to use input elements to contain
item values, and at the moment, since their values would be derived from
their textContent, they're useless for that. Specifically, it's often
reasonable to present a representation as the default values in a form and
allow for updates simply by posting the changed values. It seems unwieldy
to need to replicate that information in e.g. data elements.
While it would be simple to treat the defaultValue as the item property
value for elements (and for radio inputs, let the representation mark the
selected input as the itemprop), it seems counter to the spirit of the
proposal. The alternative would be to do something like excluding
unsuccessful input elements during the property crawl - which would allow
all such inputs to be marked as itemprop="name" and only the selected one
contribute to the itemscope's property list.
I think Igor had a point though - a consequence of making input elements
useful as itemprop elements would be that it ought to be possible to assign
values to inputs via HTMLElement.itemValue= and see those values reflected
in the form. It seems like it wouldn't be the best means to manipulate
form data though, since e.g. radio inputs would behave strangely under the
current interface (yes_radio.itemValue="no" should probably change the
value of the button, not which button is selected).
I find the use case of a form to present key/value data compelling, and
being able to apply microdata vocabularies to same strikes me as
More information about the whatwg