Re: [uf-discuss] Microformats in Form Fields
On Oct 5, 2006, at 9:20 AM, Ciaran McNulty wrote: 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. Yeah, after thinking about it more, I don't really think this really matters as much as I did before. Worst case scenario we get a bunch of unintentionally partial hCards where half the data gets ignored because it's in form inputs. And partial data is still better than no data. I do, however, still have a concern about this: 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. How would an application know whether the following should be parsed as a blank additional name, or filled in with a previously supplied given name? input type=text class=additional-name value= / Or is there no difference between stating that a property is blank, and not stating it at all? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
Someone can mark up a form as an hCard anyway, regardless of whether it's in the spec or not. I imagine at least one person has already tried it after reading this thread, to see what it looks like. Thus, parsers could be subjected to this construct regardless of whether it's in the spec. Thus, they have to at least handle it somewhat cleanly as an invalid case, if it's decided not to make it part of the spec. I don't think handling it vs. not handling it is as big a job as some may have implied. I don't have an opinion on the handling of the root element, but I have a feeling using the accept attribute may be problematic; it sounds like it's tied to file upload input elements (input type=file) [1]. Simply putting class=vcard on the form element sounds like the purest solution to me. Remember that there may be tens of parsers, but there can be millions of documents, so it's better to optimize for the author than the software developer--and I am a software engineer, so this isn't bias against developers. - David [1] http://www.w3.org/TR/html4/interact/forms.html#h-17.3 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
On 4 Oct 2006, at 19:37, Scott Reynen wrote: What is the benefit of using the same root class name for forms accepting a microformat as we use for the published microformat? The first that comes to mind: If the form is pre-filled then you have a valid vcard that could be parsed (with the addition of some form parsing rules). Take for example an ‘Edit Profile’ page that contains existing values. Whether that falls outside 80/20 I'm not sure.___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
On 10/5/06, Ben Ward [EMAIL PROTECTED] wrote: The first that comes to mind: If the form is pre-filled then you have a valid vcard that could be parsed (with the addition of some form parsing rules). Take for example an 'Edit Profile' page that contains existing values. That's a very good point, but it would depend on some changes to the uF parsing rules. Elements like textarea/ that just wrap values could be parsed normally but others like input type=text/ would need to be parsed using the @value, and I'm not sure what we'd have to do to be able to parse, for instance, radio buttons. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
On 05/10/06, Ciaran McNulty [EMAIL PROTECTED] wrote: Elements like textarea/ that just wrap values could be parsed normally but others like input type=text/ would need to be parsed using the @value, and I'm not sure what we'd have to do to be able to parse, for instance, radio buttons. Quick question (and this isn't mean as a troll or a leading one, it's just because right now I can't think of any): what uF could be valuably applied to a radio button? I guessed you might have two radio buttons saying home address and work address... but I can't see _many_ instances where radios or checkboxes would be vastly useful _for the uFs which exist right now_. I take everyone's points about updating parsers - I was entirely aware that would be one outcome of that proposal. As regarding vCard inside forms - well, that's fine. I don't think ignoring form as the root of data parsing is a good idea. I think ignoring inputs is more useful, because there are loads of reasons to put proper uF data inside a form element. as for class=vcard-input? not sure. I think class=vcard input - adding *two* things to the form - is a better compromise, but I don't think that's very microformatic. It's a bit like http verbs, I guess, the difference between POST and GET at a url, except in this case we have a vcard on inputs, and a vcard on display elements. One demands input in a format, the other displays data with extra semantics. I'm going to keep thinking on this, because - whilst it would require a change in parsers - it's an interesting idea. And, the more I think about it, the less workable putting uF classes onto name attributes is. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
On 10/5/06, Tom Armitage [EMAIL PROTECTED] wrote: Quick question (and this isn't mean as a troll or a leading one, it's just because right now I can't think of any): what uF could be valuably applied to a radio button? I guessed you might have two radio buttons saying home address and work address... but I can't see _many_ instances where radios or checkboxes would be vastly useful _for the uFs which exist right now_. Your example of home address/work address is a very good one! Another might be an hCalendar event's free/busy time status. Maybe [EMAIL PROTECTED]radio buttons weren't the best example, but I was trying to point out that form elements' values often lie in odd places that aren't covered by the parsing rules. That said, I'd expect that a few additions to the uF parsing rules, similar to those for IMG @alt and ABBR @title would cover more than 80% of the form use cases. A similar element that wouldn't automatically parse well is SELECT. It's fairly easy to come up with some use cases for this in forms - date selection is the first that springs to mind. It's also certainly possible that, for instance, my Person editing form could constrain me to choosing their ORG from a SELECT that's populated with organisations that are defined elsewhere. as for class=vcard-input? not sure. I think class=vcard input - adding *two* things to the form - is a better compromise, but I don't think that's very microformatic. It's a bit like http verbs, I guess, the difference between POST and GET at a url, except in this case we have a vcard on inputs, and a vcard on display elements. One demands input in a format, the other displays data with extra semantics. I agree with this. I think indicating that a form contains an hCard is semantically valid in and of itself, especially in the case of presenting an hCard in a form for editing. There's also nothing immediately wrong with saying that an empty form is an empty hCard, IMO. Decoupling the semantics that say 'this accepts input' is a very good idea. I'm not actually sure if any new class needs to defined to say that though - surely the semantics of FORM/INPUT elements say all of that anyhow? As you can probably gather from the above, my personal instinct would be to expand uFs' parsing rules to explain how to deal with forms. The fact the uF consists of form elements is surely enough to allow a 'smart pasting' implementation to figure out where to place data (although some guidance e.g. recommending that the field-identifying classes are applied directly to the INPUT might turn out to be necessary). Regards, -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
On Oct 5, 2006, at 5:17 AM, Ciaran McNulty wrote: I agree with this. I think indicating that a form contains an hCard is semantically valid in and of itself, especially in the case of presenting an hCard in a form for editing. There's also nothing immediately wrong with saying that an empty form is an empty hCard, IMO. 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. 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. 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. Decoupling the semantics that say 'this accepts input' is a very good idea. I'm not actually sure if any new class needs to defined to say that though - surely the semantics of FORM/INPUT elements say all of that anyhow? 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. What was the problem with Drew's earlier suggestion of accept=text/html+vcard to identify the accepted microformat input format? As you can probably gather from the above, my personal instinct would be to expand uFs' parsing rules to explain how to deal with forms. 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, or if those value attributes are blank and you have contact data, this would be a good place to paste it. That strikes me as a complicated redefinition of a microformat to suit a hypothetical edge case. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
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
Re: [uf-discuss] Microformats in Form Fields
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 [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
Re: [uf-discuss] Microformats in Form Fields
On Oct 4, 2006, at 10:18 AM, Stephen Paul Weber wrote: One thing about this would be that all current parsers would have to be tweaked to ignore form as the root of a data-extraction parseing. Which may be a good idea anyway? -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
On 28/09/06, Drew McLellan [EMAIL PROTECTED] wrote: That's the ticket. But you'd need a mixture of name and class to account for everything... e.g. fieldset class=fn n input type=text name=given-name / input type=text name=family-name / /fieldset (obviously incomplete example) drew. I'm not sure that name fields are appropriate; whilst they *should* be freely renamable, very often, at the back-end integration stage, things like this may get changed, or (depending on the system) may be unworkable. I've been thinking about this a while, and I think that one potential way of getting around the form fields wanting data that is microformattable issue is by making a _minor_ change to the microformat spec itself. Namely: whilst microformat classes on most elements indicate what the element *is*, microformat classes on inputs, selects, and textareas within form fields (ie: semantically correct input elements) indicate *what the form desires as input*. So: an hCard on a div and some lis indicates that I've got a contact of some form; a form with class vcard and various suitably classed inputs indicates a form that demands a vcard. That's it. As a proposla. it obviously requires some refinement, but it's easily enforceable in any application (because it's just based aronud parsing html) and it keeps the microformatting to the class attribute, where it's unlikely to ever be in conflict with any other demands. Thoughts? t. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
One thing about this would be that all current parsers would have to be tweaked to ignore form as the root of a data-extraction parseing. On 10/4/06, Tom Armitage [EMAIL PROTECTED] wrote: On 28/09/06, Drew McLellan [EMAIL PROTECTED] wrote: That's the ticket. But you'd need a mixture of name and class to account for everything... e.g. fieldset class=fn n input type=text name=given-name / input type=text name=family-name / /fieldset (obviously incomplete example) drew. I'm not sure that name fields are appropriate; whilst they *should* be freely renamable, very often, at the back-end integration stage, things like this may get changed, or (depending on the system) may be unworkable. I've been thinking about this a while, and I think that one potential way of getting around the form fields wanting data that is microformattable issue is by making a _minor_ change to the microformat spec itself. Namely: whilst microformat classes on most elements indicate what the element *is*, microformat classes on inputs, selects, and textareas within form fields (ie: semantically correct input elements) indicate *what the form desires as input*. So: an hCard on a div and some lis indicates that I've got a contact of some form; a form with class vcard and various suitably classed inputs indicates a form that demands a vcard. That's it. As a proposla. it obviously requires some refinement, but it's easily enforceable in any application (because it's just based aronud parsing html) and it keeps the microformatting to the class attribute, where it's unlikely to ever be in conflict with any other demands. Thoughts? t. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- - Stephen Paul Weber, Amateur Writer http://www.awriterz.org MSN/GTalk/Jabber: [EMAIL PROTECTED] ICQ/AIM: 103332966 NSA: [EMAIL PROTECTED] BLOG: http://singpolyma-tech.blogspot.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
On Oct 4, 2006, at 12:18 PM, Stephen Paul Weber wrote: One thing about this would be that all current parsers would have to be tweaked to ignore form as the root of a data-extraction parseing. I don't think it's quite that simple. What about cases where microformats exist within forms, but not as part of inputs? Here's the first example I found of an hcard wrapped in a form: http://www.markthisdate.com/contactform.html What is the benefit of using the same root class name for forms accepting a microformat as we use for the published microformat? Why not just use something like class=vcard-input? In addition to avoiding such conflicts, that seems more descriptive. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
Ben Ward wrote: What if I was to mark up the form (and fields) with hCard classes? What a coincidence! Just last night, I spoke to a couple of people about this exact concept at the WD06 after-party. Then I got home and looked here and found this thread had just recently started! :-) Generally, I think it would be a very good idea to do something like this, there are many benefits to it, especially for usability and accessibility. Brian Suda wrote: By giving more structure to Forms you are accomplishing several things... the posibility to do some sort of introspection on data inputs. This would be a boon to spammers, you are using hForm, now they can easily paste their structured spam data into your comments fields. (i know using obscure fields names is not security - but it is a hurdle to automation). I really don't think that's an issue. Spammers already have many methods at their disposal for such automation. For example, spammers already automate their comment spam processes because their tools are already aware of the markup structure used in many of the common CMSs. So, your argument is negligible because such automation is already a problem without this and the benefits for users (see below) far outweigh the negatives. Ryan Cannon wrote: Alternately, you could use @name to supply your semantics instead of @class. The server-side parser would need its internal data names standardized on hCard (not a bad idea, IMHO). I think that's a bad idea because you're tying the back end processes to the front end markup too closely. A site should be able to use the microformat *without* needing to modify their back end to cope with new name=value pairs. Besides, many server side systems don't allow such nice control over the the name attributes because they're automatically generated by the system when the HTML is generated. I don't know enough about the MIME type specs, but I wonder if we could reuse form @accepts to indicate that a form will take a particular microformat. e.g. something along the lines of: form method=post action=/user/create accepts=text/html+vcard ... /form That would be: input type=file accept=text/directory;profile=vcard See RFC 2425. It might also be useful to include text/html, application/xml and application/xhtml+xml in the attribute so that someone could upload either a vCard or an (X)HTML file containing an hCard. Some of the things I discussed with others recently include the accessibility and usability benefits. *Usability Benefits* Auto-fill features may become more successful. Auto-complete (which remembers previously used values) has been successful, particularly for password managers; but auto-fill (where the UA fills it in by heuristically guessing the field type) generally hasn't been. I think this idea has the potential to do a lot for the auto-fill case. It would reduce the amount of time it takes a user to fill out a form, particularly when they're continually asked for the same kind of information, such as contact info. *Accessibility Benefits* For a disabled user, filling out a form can be a long and tedious job. Depending on their input device, whether it be a keyboard, voice-recognition, on-screen keyboard or whatever else, entering the data manually can be quite time consuming. Also, their ability to spot and correct errors may not be as fast as a non-disabled person, so the less manual data entry required each time, the better. Additionally, someone with a cognitive disability may have difficulty understanding what some fields are asking for (especially if you've used some obscure label text they're not used to) and thus make it hard to complete. If the UA could understand the field, it could help explain it or fill it out for them. It would be so much quicker easier for them if their UA could either pre-fill most of the form for them or just submit a vCard/hCard. For the latter option, a user wouldn't even have to know what a vCard or hCard was, their UA could recognise the accepted MIME type (text/directory) and ask them to select a name from their address book, which would then implicitly select (or generate) the right vCard. *Types of Data* There a many types of data often requested on forms, some more than others, but the tend to fall into several categories. Some of these include the following: * Personal/Contact information: name, DOB, phone, e-mail, URI, address, etc. (vCard/hCard) * User signup forms: username/e-mail, password, confirmation password, forgotten-password questions and answers, etc. * Comment/feedback forms. * Event information: dates, descriptions, etc. (iCal, hCalander) * Payment information: credit card number, card type (visa, mastercard, etc.) and expiry date; or BSB, account name and number. For some of these types, there's work going on at the WHATWG to give them native controls in the browser (e.g. calandar widgets for dates,
RE: [uf-discuss] Microformats in Form Fields
On Thursday, September 28, 2006 9:21 AM Drew McLellan Wrote On 28/9/2006, Ryan Cannon [EMAIL PROTECTED] wrote: What if I was to mark up the form (and fields) with hCard classes? Good idea? Bad idea? I strikes me that it could be useful for auto- complete applications, but not sure if it would pollute the web with effectively a useless/empty hCard when the form is published. Wouldn't a solution to this be not to wrap the form fields in a *.vcard block? The information would then never actually generate a vcard using a parser, and a blank form is not technically a vcard in HTML. Alternately, you could use @name to supply your semantics instead of @class. That's the ticket. But you'd need a mixture of name and class to account for everything... e.g. fieldset class=fn n input type=text name=given-name / input type=text name=family-name / /fieldset (obviously incomplete example) I've been thinking about this a lot lately too. I've had a note on my fridge for about 2 months now that says simply Paste hCard. :) I recently wrote a form and it just made sense to mark it up with hCard semantics. To avoid polluting the uF-o-sphere, I didn't use the vcard as the @class on the root element. For each pair of label/inputs, I created a parent div with the @class of fieldrow + input name. Here's a sample fieldset of address fields: fieldset class=adr billing-address legendBilling Address/legend div class=fieldrow street-address label for=street-address title=Address Line 1Address:/label input type=text name=street-address id=street-address / /div div class=fieldrow optional extended-address label for=extended-address title=Address Line 2Address Line 2:/label input class=optional type=text name=extended-address id=extended-address / /div div class=fieldrow locality label for=localityCity:/label input type=text name=locality id=locality / /div div class=fieldrow region label for=regionState:/label select name=region id=region option value=ALAL/option ... /select /div div class=fieldrow postal-code label for=postal-codePostal code:/label input type=text name=postal-code id=postal-code size=10 / /div div class=fieldrow country label for=countryCountry:/label select name=country id=country size=1 option value=USUnited States/option ... /select /div /fieldset - Steve ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Microformats in Form Fields
On 29/9/2006, Steve Ganz [EMAIL PROTECTED] wrote: I've been thinking about this a lot lately too. I've had a note on my fridge for about 2 months now that says simply Paste hCard. :) I recently wrote a form and it just made sense to mark it up with hCard semantics. To avoid polluting the uF-o-sphere, I didn't use the vcard as the @class on the root element. I don't know enough about the MIME type specs, but I wonder if we could reuse [EMAIL PROTECTED] to indicate that a form will take a particular microformat. e.g. something along the lines of: form method=post action=/user/create accepts=text/html+vcard ... /form drew. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Microformats in Form Fields
On 29/9/2006, Drew McLellan [EMAIL PROTECTED] wrote: On 29/9/2006, Steve Ganz [EMAIL PROTECTED] wrote: I've been thinking about this a lot lately too. I've had a note on my fridge for about 2 months now that says simply Paste hCard. :) I recently wrote a form and it just made sense to mark it up with hCard semantics. To avoid polluting the uF-o-sphere, I didn't use the vcard as the @class on the root element. I don't know enough about the MIME type specs, but I wonder if we could reuse [EMAIL PROTECTED] to indicate that a form will take a particular microformat. e.g. something along the lines of: form method=post action=/user/create accepts=text/html+vcard ... /form That'd be 'accept', singular. drew. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
On 28 Sep 2006, at 13:33, Stephen Paul Weber wrote: What about using the same markup as the appropriate uF, but a different root class name (such as 'form')? That's a possibility I guess, but thinking for a moment in the context of the DOM, with the form fields filled in (and an appropriate parsing rule for reading values from form fields) you have a valid hCard/hEvent… Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Microformats in Form Fields
A cool implementation of this would be a form that optionally accepts the URL for an hCard and auto-fills the data by making an AJAX request to the entered page and transforming it with X2V. Of course this wouldn't require hCard markup in the forms, but you could build a slick library out of it. Once created, this could be some cool leverage for social networking sites to implement hCard—it gives their users more added value for having a profile. -- Ryan Cannon Interactive Developer MSI Student, School of Information University of Michigan http://RyanCannon.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
On 9/28/06, Ben Ward [EMAIL PROTECTED] wrote: Hello list, just a quick point for discussion: Lets say you have a personal registration form in your web app, for entering contact data which will later be output as an hCard in various places. What if I was to mark up the form (and fields) with hCard classes? Good idea? Bad idea? I strikes me that it could be useful for auto- complete applications, but not sure if it would 'pollute' the web with effectively a useless/empty hCard when the form is published. You must have been tuned into my brain today, because I was thinking about the same thing... I think the auto-form fill would be neat. Did you see Drews demo of that with openID? It didn't require the forms to use the microformat class names or anything. I hadn't thought about the empty hCard information that would accidentally be produced by marking form fields though. I think that is a good arguement for NOT doing it. -- Frances Berriman http://www.fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
Lets say you have a personal registration form in your web app, for entering contact data which will later be output as an hCard in various places. What if I was to mark up the form (and fields) with hCard classes? I've long thought that a form should be marked up as if the data was non-editable. This is especially relevant when presenting an object for editing, because the data is all there in the form. The problem is that under most uF parsing rules, input elements' @value will not be used to determine their content. However, a textarea would be parsable as you'd expect. I haven't read any previous discussion on this topic though so I don't know what the group consensus is... -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: [uf-discuss] Microformats in Form Fields
I think we are just about to independantly arrive at Live Clipboard. The way LiveClipboard works is through the use of a js library that parses the hCard/hCalendar and then inserts them into the form fields that you define. IF we standardised the form fields to match the same name as hCards (or some mapping) then you are back to a generic base library that anyone can used to smart paste structured data into form fields. By giving more structure to Forms you are accomplishing several things... the posibility to do some sort of introspection on data inputs. This would be a boon to spammers, you are using hForm, now they can easily paste their structured spam data into your comments fields. (i know using obscure fields names is not security - but it is a hurdle to automation). The other cool thing extracting data from a form gets you, is to build things like OpenSearchDescriptions, and/or other formats. I don't think there is critial mass on the web for these sorts of actions because things become so specialised. -brian On 9/28/06, Ciaran McNulty [EMAIL PROTECTED] wrote: Lets say you have a personal registration form in your web app, for entering contact data which will later be output as an hCard in various places. What if I was to mark up the form (and fields) with hCard classes? I've long thought that a form should be marked up as if the data was non-editable. This is especially relevant when presenting an object for editing, because the data is all there in the form. The problem is that under most uF parsing rules, input elements' @value will not be used to determine their content. However, a textarea would be parsable as you'd expect. I haven't read any previous discussion on this topic though so I don't know what the group consensus is... -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
Frances Berriman wrote: Did you see Drews demo of that with openID? It didn't require the forms to use the microformat class names or anything. Yeah, I've seen Drew's excellent auto-fill demo and had a couple of conversations with him about combining that with OpenID. This isn't so much about providing my own custom µf autofill as part of the web app (yet ;-) ), which would of course understand my bespoke form arrangement. It's more about putting the classnames in place that a separate tool, browser or bookmarklet could provide a more accurate/ powerful autofill than the guesswork based autofills we have at the moment. On 28 Sep 2006, at 12:53, Ciaran McNulty wrote: The problem is that under most uF parsing rules, input elements' @value will not be used to determine their content. However, a textarea would be parsable as you'd expect. That could be resolved by adding a new design pattern for input elements. Ben___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
What about using the same markup as the appropriate uF, but a different root class name (such as 'form')? On 9/28/06, Ben Ward [EMAIL PROTECTED] wrote: Frances Berriman wrote: Did you see Drews demo of that with openID? It didn't require the forms to use the microformat class names or anything. Yeah, I've seen Drew's excellent auto-fill demo and had a couple of conversations with him about combining that with OpenID. This isn't so much about providing my own custom µf autofill as part of the web app (yet ;-) ), which would of course understand my bespoke form arrangement. It's more about putting the classnames in place that a separate tool, browser or bookmarklet could provide a more accurate/ powerful autofill than the guesswork based autofills we have at the moment. On 28 Sep 2006, at 12:53, Ciaran McNulty wrote: The problem is that under most uF parsing rules, input elements' @value will not be used to determine their content. However, a textarea would be parsable as you'd expect. That could be resolved by adding a new design pattern for input elements. Ben___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- - Stephen Paul Weber, Amateur Writer http://www.awriterz.org MSN/GTalk/Jabber: [EMAIL PROTECTED] ICQ/AIM: 103332966 NSA: [EMAIL PROTECTED] BLOG: http://singpolyma-tech.blogspot.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
On 28/9/2006, Ryan Cannon [EMAIL PROTECTED] wrote: What if I was to mark up the form (and fields) with hCard classes? Good idea? Bad idea? I strikes me that it could be useful for auto- complete applications, but not sure if it would pollute the web with effectively a useless/empty hCard when the form is published. Wouldn't a solution to this be not to wrap the form fields in a *.vcard block? The information would then never actually generate a vcard using a parser, and a blank form is not technically a vcard in HTML. Alternately, you could use @name to supply your semantics instead of @class. That's the ticket. But you'd need a mixture of name and class to account for everything... e.g. fieldset class=fn n input type=text name=given-name / input type=text name=family-name / /fieldset (obviously incomplete example) drew. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Form Fields
Hi all, On Sep 28, 2006, at 4:12 AM, Drew McLellan wrote: What if I was to mark up the form (and fields) with hCard classes? Good idea? Bad idea? I strikes me that it could be useful for auto- complete applications, but not sure if it would ‘pollute’ the web with effectively a useless/empty hCard when the form is published. There's various related bits of discussion on this in and around these pages: http://microformats.org/wiki/rest/ To be precise, it is here: http://microformats.org/wiki/rest/description I'm definitely a fan of uf-marking input forms, as it does allow both i) meaningful output, and ii) hypermedia-driven markup. Though, I am curious how the various parsers out there would/should treat empty fields... -- Ernie P. On Sep 28, 2006, at 5:05 AM, Brian Suda wrote: By giving more structure to Forms you are accomplishing several things... the posibility to do some sort of introspection on data inputs. This would be a boon to spammers, you are using hForm, now they can easily paste their structured spam data into your comments fields. (i know using obscure fields names is not security - but it is a hurdle to automation). The other cool thing extracting data from a form gets you, is to build things like OpenSearchDescriptions, and/or other formats. I don't think there is critial mass on the web for these sorts of actions because things become so specialised. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
