hcard-input-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (Design goals)
m (The input classname)
Line 26: Line 26:
=== Auto-fill application vs generalist parsing documentation ===  
=== Auto-fill application vs generalist parsing documentation ===  
Auto-filling a form and parsing its contents are two different operations, although they share the same conventions and schemeas. The discussion on how a microformat parser should extract values from form elements can be different to the needs of an application that can auto-fill a form using microformat data.  
Auto-filling a form and parsing its contents are two different operations, although they share the same conventions and schemeas. The discussion on how a microformat parser should extract values from form elements can be different to the needs of an application that can auto-fill a form using microformat data.  
=== The <code>input</code> classname ===
To aid discovery and differentiate the use of microformats for the use of auto-fill applications we should use an <code>input</code> classname in conjunction with the root microformats classname. The current suggestion of appending the root classname with <code>input</code> ie <code>vcard-input</code> would break all current parsers. To add the demarcation we should use a new class <code>input</code>
Proposed markup:
<pre><nowiki>
&lt;form class=&quot;vcard input&quot;&gt;
&lt;label for=&quot;name&quot;&gt;title&lt;/label&gt;
&lt;input class=&quot;fn&quot; id=&quot;name&quot; type=&quot;text&quot; /&gt;
&lt;form&gt;
</nowiki></pre>
This would allow authors and applications to determine the intended use case i.e. the microformat mark-up is for form auto-fill. It would also be a simple task to update the current generalist parsers to ignore the mark-up if they were looking for content only. By default, most of the current parsers would already ignore an empty form marked-up with microformats as the required properties such as fn in hCard would be blank.
=== Form fields should use the classname attribute ===
It is tempting to consider using the form field name attribute as an alternative to the classname attribute, but this would break the current authoring conventions and all current parsers.  We should confine the definitions of microformat to classname and rel attributes.
Proposed markup:
<pre><nowiki>
&lt;input class=&quot;fn&quot; id=&quot;name&quot; type=&quot;text&quot; /&gt;
</nowiki></pre>
=== Text inputs and Textareas ===
The mapping of content into text inputs and textareas is relatively straightforward, matches are made on the classname attribute and the whole value is used to fill in the form field.
Proposed markup:
<pre><nowiki>
&lt;input class=&quot;fn&quot; id=&quot;name&quot; type=&quot;text&quot; /&gt;
&lt;textarea class=&quot;note&quot; name=&quot;bio&quot; cols=&quot;20&quot; rows=&quot;2&quot;&gt;&lt;/textarea&gt;
</nowiki></pre>


== see also ==
== see also ==

Revision as of 14:35, 15 February 2011

This page is for documenting previous efforts at formats for web forms that input contact information (people or organizations/venues) towards brainstorming the use of hCard for input into forms for enabling hCard forms auto-fill and hCard copy + paste.

This article is a stub. You can help the microformats.org wiki by expanding it.

proposals

hCard properties on form elements

Use hCard properties as class names on form elements inside a container (such as a containing <fieldset> or the containing <form>) to indicate that those form elements accept values with the semantics of the respective hCard properties.

Example:

  • how to markup a containing <form>, <fieldset>, or <div> element with the root class name vcard.
  • how to markup <input type="text" > elements with hCard property names

Details:

  • how to markup <select> elements (e.g. for state/region and country name, many examples)
  • how to markup compound input fields, e.g. City, State Zip all in one field (per Yelp add business example)

Design goals for “input microformats”

Use the current microformat authoring conventions and schemas where possible. This goal should be understood in the light that most microformats are designed as hierarchical structures and whereas forms are not. Some breaking changes maybe required to deal with this fundamental difference, but these should be kept to a minimum.

Where possible any differences in authoring should be dealt with by creating a common superset of additional classes for auto-filling applications. This approach will limit the cognitive load on authors and allow the reuse of current parsers.

A primary design goal must be the consideration of i18n. This most effects dates and durations. The individual implementations may allow for language specific formatting, but it should not be part of this specification.

It should be reasonably easy for an author to add classes to a pre-existing form without having to change its data structure.

Auto-fill application vs generalist parsing documentation

Auto-filling a form and parsing its contents are two different operations, although they share the same conventions and schemeas. The discussion on how a microformat parser should extract values from form elements can be different to the needs of an application that can auto-fill a form using microformat data.

The input classname

To aid discovery and differentiate the use of microformats for the use of auto-fill applications we should use an input classname in conjunction with the root microformats classname. The current suggestion of appending the root classname with input ie vcard-input would break all current parsers. To add the demarcation we should use a new class input

Proposed markup:

<form class="vcard input">
<label for="name">title</label>
<input class="fn" id="name" type="text" />
<form>

This would allow authors and applications to determine the intended use case i.e. the microformat mark-up is for form auto-fill. It would also be a simple task to update the current generalist parsers to ignore the mark-up if they were looking for content only. By default, most of the current parsers would already ignore an empty form marked-up with microformats as the required properties such as fn in hCard would be blank.

Form fields should use the classname attribute

It is tempting to consider using the form field name attribute as an alternative to the classname attribute, but this would break the current authoring conventions and all current parsers. We should confine the definitions of microformat to classname and rel attributes.

Proposed markup:

<input class="fn" id="name" type="text" />

Text inputs and Textareas

The mapping of content into text inputs and textareas is relatively straightforward, matches are made on the classname attribute and the whole value is used to fill in the form field.

Proposed markup:

<input class="fn" id="name" type="text" />
<textarea class="note" name="bio" cols="20" rows="2"></textarea>




see also