[uf-discuss] input microformats for auto-filling forms

[Stephen Paul Weber]

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