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

[Tantek Çelik]

On Fri, Feb 18, 2011 at 13:28, Stephen Paul Weber
<singpolyma at singpolyma.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Somebody claiming to be Tantek Çelik wrote:
>>On Tue, Feb 15, 2011 at 12:49, Stephen Paul Weber
>><singpolyma at singpolyma.net> wrote:
>>> Somebody claiming to be Glenn Jones wrote:
>>>>http://microformats.org/wiki/hcard-input-brainstorming
>>>
>>> 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 general I would agree that is true.  class and rel have very nice
> semantics that fit with most of what has been attempted with µformats so
> far.  I'm just saying there's a difference between "most-robust syntax" and
> "never anything but class and rel"

Agreed. I think the point is that for practical purposes it makes
sense to just stick to class/rel discussions, unless there is a
specific significant advantage to using something else (more than just
"what if" - which is a theoretical discussion not worth the time).


> For example, XOXO is a µformat (albeit a very simple one) that does not make
> extensive use of class or rel,

XOXO is certainly an odd one out of the bunch. I'm not sure how much
explicit (vs. implicit) use it is getting in practice, what (if any)
applications have been built that consume and do anything interesting
with it.

If you know of any specific sites that explicitly publish it for a
particular end-user benefit, or specific sites that explicitly consume
XOXO for some end-user feature, please document them:

http://microformats.org/wiki/xoxo-examples-in-wild

http://microformats.org/wiki/xoxo-implementations



> also XMDP

XMDP is not really a microformat - rather, it's more like supporting
technology for adding machine referencable definitions and URLs for
vocabulary terms.

No one publishes actual content (what microformats are really for)
marked up with XMDP.

I designed XMDP purely to provide a way to map newly created XFN rel
values to precise URIs that a system based on URIs (e.g. RDF) could
reason with. In practice I'm not sure how much URI-based reasoning is
happening on the public web (applications I've seen all just treat the
XFN rel values as tokens).

For more on this see:

http://microformats.org/wiki/xmdp-origins


>>> 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).
>>
>>However, the challenge is that the name attribute can only accept a
>>*single* value (similar to "id").
>
> That's a good point.  Are there common cases where a form input is usefully
> multiple attributes?  (A real question, I honestly don't know if that's
> common).

Yes, specifically the web developers is *already using a name* in
their web form implementation, and then if we ask them to add
*another* name for microformats purposes. But this is not possible
since inputs can only take one name value.  Same problem as "id".

It makes them both not particularly practical for microformats vocabularies.


>>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".
>
> While this seems somewhat reasonable, as suggested on the wiki page we are
> discussin there are still 2 problems with the suggested use of classnames:
>
> 1) Does nothing useful under existing UAs

The "does nothing useful under existing UAs" is just stop energy and
not a valid argument. Of course technology that hasn't been developed
yet does nothing in existing UAs. It would be odd if it did.


>  (whereas name would make good
>        autocomplete work).

Citation needed. If you want to research existing input/name "formats"
that implementations might be using, please document them on the wiki
so we can understand what might "work".  Perhaps on a page like:

http://microformats.org/wiki/input-name-formats


> 2) Breaks parser expectations (a parser will see the hCard classes, for
>        example, and try to parse an hCard.  So parsers will get blank or
>        filled-with-placeholder hCards from form pages).

In practice this is not a problem, we iterate on microformats parsing,
and parsers update. E.g. with the very successful (and necessary)
value-class-pattern.

Unless you can provide a specific scenario (what page, what parser,
what specific bad user experience), I'm calling theoretical on this
(thus undeserving of further discussion).

If you know of specific real-world issues with parsing input elements
for microformats, especially in the context of hCard, please note them
here under the brainstorm for input parsing:

http://microformats.org/wiki/hcard-parsing-brainstorming#input_element_handling

Thanks,

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5