[uf-discuss] Microformats in Form Fields
Dr. Ernie Prabhakar
drernie at opendarwin.org
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:
> 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
> 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
>> 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
> 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
>> "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
> 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.
> Doesn't overcomplicate hCard with new parsing rules,
> doesn't require rewrite of existing parsers to ignore
> 'unparsable' data.
> 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.
> Small addition to existing format rather than new one.
> Semantics of an input form and the eventual display format are
> the same.
> Existing parsers would/could parse forms as invalid hCards,
> would need re-writing.
> Ciaran McNulty
> microformats-discuss mailing list
> microformats-discuss at microformats.org
More information about the microformats-discuss