-----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. 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). In fact, using class if you are not going to have a meaningful value="" will just *confuse* existing parsers, leading them to get a blank object. >> Where a microformat property such as street-address in hCard can contain >> an array of values, these values will be added in order into the >> collection of form fields with the same classname. Sure. I again think using name here may be more correct, depeding on what you're doing. I believe most implementations allow multiple inputs of the name same to mean an array, though for safety one ought to append [] (IIRC pioneered by PHP, picked up by others due to the popularity of PHP) >> There are a number of plural properties in mircoformats that allow >> multiple values. In hCard the commonly used ones are tel, email and urls. >> To allow a form to extend to receive an unknown number of values >> auto-fill applications need to support a repeating pattern. This can be >> achieved with a new classname “repeat” which can be used in conjunction >> with a microformat property. The author needs to add an instructional >> classname to inform the application when to perform a repeat. I do not understand the use case here at all. How does this differ from the array value use case above? You seem to be defining behaviour here, which seems outside the scope of µformats. >> There are a number of circumstances where concatenating a plural >> microfromats property into a single string is required. The most common >> string concatenations involve a combination of spaces and/or comma’s. >> Auto-fill applications should concatenate three different patterns; >> comma-space-delimited, comma-delimited and space-delimited. These format >> operators have to be placed in the same classname attribute as the >> microformat property name. The concatenated string should be trimmed and >> there should be no trailing spaces or commas at the end of the string. Again, this seems very behaviour driven instead of data driven. >> There are number of circumstances where an “or” operator would be useful. >> If a classname attribute with more than one microformat property and the >> “or “ operator the auto fill application will make a selection between >> the properties. The first non-null value will be used. Where the >> microformat property is a multiple value all the values of the first >> property are used before any subsequent properties. This is straight-up a programming language / behaviour / scripting feature. Not data. >> <input type="vcard"> Interesting, but invalid and does not have a good fallback mechanism. - -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJNWubGAAoJENEcKRHOUZzeKCMP/23BuSumemZZO4jwOcFd8GbA mvjwSXQVjYogQyXriv1GrfSZIe78B4NN7ew54MulaPeEX00Iv/v5fyjzt4x1HTxD VQHLZERIaGtvrVQQ/g94+I+Bmrr6rA31t42ZWVJ7ytG8BnQ8QFjbK17vXgRP/bMg jjvqvMSzza/q1eWbAHzSYT3oQUVvH9yk3hB0zrBYEc6dpYJmu6ha7VbBqa2FNRrB fwsNzhAPJs/gn+6u1uT5Sp66TWXPzJkN8Lnw3Nz2Z9gaIl69Tc6rieatXT+cHoro XiVujlvRsb5sunrXiXWengjtjK2v1yOlQbolEL2W/wDYtoy09W/r4LE1OVJZXgN8 jQSCPsaQVu9p3yWL6k5L3rSlIn+mpqJHbnKyR2ueES+NcRfsuXbBJgjTeADqCHY2 KFaAB1qFWmLyZYv3guImkccOBUGLz+NIwjfdXAo061YHV6dQMJoa58KPqUHT1AFV fpXRyfBkxrfobX4OC4+qUWEHl+T3QbRkFkbduerbRDKEG8j2/0otLqDhe/RKfxSP 6XjTcbiuZ0UVSOTDRTFvLem45ADOIDp9IbipvFdB0rxDQES3NGI5tScfmyZLp6tm 7fNPqLMPzhEythJZ/IwhOwQOJnQdae50yTWLlYRYDRoXMOLX5Xv6h0/HiBYOnkyF Jc85+xMiMx4xI7DPxr8Z =Vbwz -----END PGP SIGNATURE----- _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
