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