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

[Tantek Çelik]

On Tue, Feb 15, 2011 at 12:49, Stephen Paul Weber
<singpolyma at 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