[uf-discuss] Microformats in Form Fields

Thu Oct 5 07:20:28 PDT 2006

Scott,

Thanks for the in-depth reply, lots of good points!  I've mulled it
over and here are a few thoughts.

On 10/5/06, Scott Reynen <scott at randomchaos.com> wrote:
> An empty hCard is not an hCard.
> hCard requires at least a name, and
> most other microformats have some basic requirements.  So I think
> it's bad semantics to say there's an hCard somewhere when there's
> not.

It's bad semantics, yes.  I don't know what the solution to that is,
because clearly in some cases (the editing case) what's being
presented is indeed a vcard and it's not reasonable for the
application to work out whether the form it's presenting is filled in
correctly or not and remove the vcard class if it's not.

I'd prefer to say that an hCard with missing elements *is* an hCard,
it's just invalid.  It's like saying that a web page that's missing
its <head> is invalid, rather than saying it's not HTML.

I'm sure we can find plenty of stuff in the wild that's marked up as
hCard that is missing a few mandatory fields, after all.

> Even in the case where the hCard data is there (a pre-filled
> form), it doesn't follow the current hCard parsing standards, so it's
> only an hCard if we're redefining what hCard is.

Well I think that's what's being discussed.  There are lots of reasons
to want to not change hCard seeing as it's so established, but I'm not
sure about the economy of coming up with a separate 'input hCard' uF
that only differs slightly.

> And I don't see the
> point of that.  Parsers will need to be rewritten to make use of this
> data regardless of the root class name.  Using the existing root
> class names seems to only ensure that parsers will also need to be
> rewritten if they want to ignore this data.

There are rewrites to parsers to accomodate new parsing rules all the
time, the a.include pattern is the latest that springs to mind.  That
said I'm not one of the people who's written a parser so I'm probably
undervaluing their time and effort somewhat and wouldn't like to write
it off as a trivial change.

> That the form is used for input is obvious.  That the form is used
> for input of hCards is not obvious, and I don't think adding
> class="vcard" makes it obvious.

Can I ask why?  If you know a form accepts input, and it's got
class="vcard" on it then it would seem to make sense that the
input[@class="given-name"] is expecting a first name.

I mentioned briefly that there might be the need for some sort of
convention such as tying the identifying class directly to the input
element, perhaps the vcard class would need to be tied to the form
element too?

> What was the problem with Drew's
> earlier suggestion of accept="text/html+vcard" to identify the
> accepted microformat input format?

I don't see how @accepts is relevant in the case of prefilling forms,
to be honest.

@accept specifies a list of acceptable upload MIME types.  In a
context like this where we're submitting form values rather than file
uploads I don't think it's relevant at all (I'm happy to be corrected
if I'm reading the spec badly, the HTTP  traffic involved in a form
submission is a grey area for me).

It's probably highly relevant in a situation where we're POSTing or
PUTing a full hCard in a RESTful manner though.

> I see no problem with that, but I still see no benefit in forcing
> that change on all existing parsers by using the old class names to
> mean new things.   Currently class="vcard" means "you can find contact
> data within tags containing vcard property names as classes" and what
> I'm seeing suggested here is changing class="vcard" to mean "you can
> find contact data within tags containing vcard property names as
> classes, or within the value attribute of input tags containing those
> classes,

Well, currently it's "you can find contact data within tags containing
vcard property names as classes, or within those tags' @title if
they're an abbr or within their @alt if they're an img or somewhere
else on the page if you find an object.include or a.include pattern"
(I'm sure I've missed a few).

I'm not suggesting a redefinition of any of the hCard classes, that
would be too much of a headache, but the parsing rules have been
incrementally changed in the past and this would be some further
changes.

> "or if those value attributes are blank and you have contact
> data, this would be a good place to paste it."

An existing parser wouldn't at all need to know about this, it would
need to say, quite rightly, that the hCard wasn't valid and not try
and do stuff with it.

However, if I was writing a 'smart pasting' application, there's
already a whole rich semantic structure in hCard that would let me
immediately work out that, for instance, a certain INPUT[@type="text"]
is expecing my given-name.

> That strikes me as a
> complicated redefinition of a microformat to suit a hypothetical edge
> case.

It is non-trivial, I agree.  However the whole discussion is based on
that exact edge case.  If there's no use case for prefilling form
fields with for, for instance, a stored hCard then most of the thread
so far is moot ;-)

The options discussed in a hypothetical hCard input system so far appear to be:

1) create a new root class other than vcard to indicate a form that's
fillable with hCard data.

  Benefits:
      Doesn't overcomplicate hCard with new parsing rules,
      doesn't require rewrite of existing parsers to ignore 'unparsable' data.
  Drawbacks:
      Requires completely new parsers to be written.
      Existing parsers would ignore data even if a valid hCard could
be extracted.

2) extend hCard's parsing rules to cover form elements and relying on
the FORM/INPUT semantics to indicate that stuff is inputtable.

  Benefits:
      Small addition to existing format rather than new one.
      Semantics of an input form and the eventual display format are the same.
  Drawbacks:
      Existing parsers would/could parse forms as invalid hCards,
would need re-writing.

Regards,

Ciaran McNulty