[uf-discuss] Microformats in Form Fields
brian.suda at gmail.com
Thu Sep 28 05:05:40 PDT 2006
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.
On 9/28/06, Ciaran McNulty <mail at ciaranmcnulty.com> 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...
> microformats-discuss mailing list
> microformats-discuss at microformats.org
More information about the microformats-discuss