[uf-discuss] Microformats in Form Fields

Tom Armitage tom.armitage at gmail.com
Thu Oct 5 02:11:00 PDT 2006


On 05/10/06, Ciaran McNulty <mail at ciaranmcnulty.com> wrote:
> Elements like <textarea/> that just wrap values could be parsed
> normally but others like <input type="text"/> would need to be parsed
> using the @value, and I'm not sure what we'd have to do to be able to
> parse, for instance, radio buttons.
>

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_.

I take everyone's points about updating parsers - I was entirely aware
that would be one outcome of that proposal.

As regarding vCard inside forms - well, that's fine. I don't think
"ignoring form as the root of data parsing" is a good idea. I think
ignoring <input>s is more useful, because there are loads of reasons
to put "proper" uF data inside a form element.

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'm going to keep thinking on this, because - whilst it would require
a change in parsers - it's an interesting idea. And, the more I think
about it, the less workable putting uF classes onto name attributes
is.


More information about the microformats-discuss mailing list