[uf-discuss] Microformats in Form Fields

Thu Oct 5 10:53:54 PDT 2006

Nice summary! I agree the issues are non-trivial, but I'm glad  
somebody is hashing them out...

On Oct 5, 2006, at 7:20 AM, Ciaran McNulty wrote:

> 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
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss