Microformats in Form Fields

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.

Opinions?

Ben_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On 9/28/06, Ben Ward <listsben-ward.co.uk> 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-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On 28/9/2006, "Ben Ward" <listsben-ward.co.uk> 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.

There's various related bits of discussion on this in and
around these
pages:
http://microformat
s.org/wiki/rest/



drew.
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

> 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-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

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 <mailciaranmcnulty.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...
>
> -Ciaran
> _______________________________________________
> microformats-discuss mailing list
> microformats-discussmicroformats.org
> http://microformats.org/mailman/listinfo/microforma
ts-discuss
>


-- 
brian suda
http://suda.co.uk
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

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-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

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 <listsben-ward.co.uk> 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-discussmicroformats.org
> http://microformats.org/mailman/listinfo/microforma
ts-discuss
>


-- 
- Stephen Paul Weber, Amateur Writer
<http://www.awriterz.org&g
t;

MSN/GTalk/Jabber: singpolymagmail.com
ICQ/AIM: 103332966
NSA: stephen4northstar-academy.org
BLOG: http://singpolym
a-tech.blogspot.com/
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

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://microformat
s.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-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

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-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

Marking up form inputs to associate them with microformat
classes would indeed be very useful in Live Clipboard
scenarios.  We've discussed techniques for auto-binding Live
Clipboard copy controls to microformats within a web page,
using either script or rich client code.  Auto-binding paste
controls to marked-up forms would complete the circuit.

Matt Augustine
Software Development Engineer
CSA Concept Development Team
Microsoft Corporation


-----Original Message-----
From: microformats-discuss-bouncesmicroformats.org
[mailto:microformats-discuss-bouncesmicroformats.org] On Behalf
Of Brian Suda
Sent: Thursday, September 28, 2006 5:06 AM
To: Microformats Discuss
Subject: 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 <mailciaranmcnulty.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...
>
> -Ciaran
> _______________________________________________
> microformats-discuss mailing list
> microformats-discussmicroformats.org
> http://microformats.org/mailman/listinfo/microforma
ts-discuss
>


--
brian suda
http://suda.co.uk
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss