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,
e-mail controls to allow selection from an address book and URI controls
to allow selection from your bookmarks/history).
But even with native controls, it doesn't identify the purpose of the
control. e.g. a date control could be a date of birth,
departure/arrival date, booking date, or whatever. If we had a
microformat that, for example, identified a particular date control as a
DOB, it would be easy to auto-fill.
--
Lachlan Hunt
http://lachy.id.au/
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
