[uf-discuss] input microformats for auto-filling forms
Stephen Paul Weber
singpolyma at singpolyma.net
Tue Feb 15 12:49:11 PST 2011
-----BEGIN PGP SIGNED MESSAGE-----
Somebody claiming to be Glenn Jones wrote:
>> We should confine the definitions of microformat to classname and rel
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
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.
>> <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)
-----END PGP SIGNATURE-----
More information about the microformats-discuss