On 10/5/06, Tom Armitage <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]"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 _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss