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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]"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 [EMAIL PROTECTED]"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@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss