On Tue, Feb 15, 2011 at 12:49, Stephen Paul Weber <singpol...@singpolyma.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Somebody claiming to be Glenn Jones wrote: >>http://microformats.org/wiki/hcard-input-brainstorming > >>> We should confine the definitions of microformat to classname and rel >>> attributes. > > Strongly disagree. As I understand it, µformats are about defining > vocabularies and how those vocabularies can be best encoded using existing > HTML semantics. Restricting to class and rel is short-sighted.
microformats are both about a scientific process for researching and defining vocabularies, AND the simplest/easiest/most-robust syntax for using those vocabularies. To date experience has shown that class and rel microformats make the most sense. In the early days there were thoughts about also using "id" attributes for vocabulary but those have been discarded as impractical. > For example, in this case, while having class="fn" may be beneficial (if you > want to parse the form as a microformat) using name="fn" is more > semantically correct if what you want to do is autofill or similar. > name="fn" also has the advantage of already doing a lot for you in terms of > autofill in most major browsers (who key off the name attribute for their > autofill). Of course web authors should use the name attribute when it is semantically correct to do so. However, the challenge is that the name attribute can only accept a *single* value (similar to "id"). Whereas one of the aspects of class and rel that made them work so well with existing web pages and their markup is that both class and rel contain a space separated *set* of values. Thus it makes sense to prefer (restrict if you will) our use and recommendation of microformats to "class" and "rel", rather than forcing authors to pick one value for "name". This is probably worthy of writing up as an FAQ as I've seen this question arise before and I also *did* consider (and reject without bothering to write it down) using the "name" attribute like this. Here is the existing parsing brainstorming regarding treating <input> elements specially: http://microformats.org/wiki/hcard-parsing-brainstorming#input_element_handling >>> <input type="vcard"> > > Interesting, but invalid and does not have a good fallback mechanism. It might make more sense to have something more abstract and connected to the user interface of the platform, e.g. input type="contact" -- brings up a contact/addressbook application picker and then under the hood, define the API for accessing that data in terms of the hCard microformat vocabulary. Tantek -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5 _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
