[uf-discuss] Microformats in Form Fields

[Ciaran McNulty]

On 10/5/06, Tom Armitage <tom.armitage at gmail.com> wrote:
> Quick question (and this isn't mean as a troll or a leading one, it's
> just because right now I can't think of any): what uF could be
> valuably applied to a radio button? I guessed you might have two radio
> buttons saying "home address" and "work address"... but I can't see
> _many_ instances where radios or checkboxes would be vastly useful
> _for the uFs which exist right now_.

Your example of home address/work address is a very good one!  Another
might be an hCalendar event's free/busy time status.

Maybe INPUT at type="radio" buttons weren't the best example, but I was
trying to point out that form elements' values often lie in odd places
that aren't covered by the parsing rules.

That said, I'd expect that a few additions to the uF parsing rules,
similar to those for IMG @alt and ABBR @title would cover more than
80% of the form use cases.

A similar element that wouldn't automatically parse well is SELECT.
It's fairly easy to come up with some use cases for this in forms -
date selection is the first that springs to mind.

It's also certainly possible that, for instance, my Person editing
form could constrain me to choosing their ORG from a SELECT that's
populated with organisations that are defined elsewhere.

> as for class="vcard-input"? not sure. I think class="vcard input" -
> adding *two* things to the form - is a better compromise, but I don't
> think that's very microformatic. It's a bit like http verbs, I guess,
> the difference between POST and GET at a url, except in this case we
> have a vcard on inputs, and a vcard on display elements. One demands
> input in a format, the other displays data with extra semantics.

I agree with this.  I think indicating that a form contains an hCard
is semantically valid in and of itself, especially in the case of
presenting an hCard in a form for editing.  There's also nothing
immediately wrong with saying that an empty form is an empty hCard,
IMO.

Decoupling the semantics that say 'this accepts input' is a very good
idea.  I'm not actually sure if any new class needs to defined to say
that though - surely the semantics of FORM/INPUT elements say all of
that anyhow?

As you can probably gather from the above, my personal instinct would
be to expand uFs' parsing rules to explain how to deal with forms.
The fact the uF consists of form elements is surely enough to allow a
'smart pasting' implementation to figure out where to place data
(although some guidance e.g. recommending that the field-identifying
classes are applied directly to the INPUT might turn out to be
necessary).

Regards,

-Ciaran McNulty