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 1.0 copy + paste.
This article is a stub. You can help the microformats.org wiki by expanding it.
- 1 proposals
- 1.1 hCard properties on form elements
- 1.2 Design goals for “input microformats”
- 1.3 Auto-fill application vs generalist parsing documentation
- 1.4 The input classname
- 1.5 Form fields should use the classname attribute
- 1.6 Text inputs and textareas
- 1.7 Multiple form fields for plural microformat properties
- 1.8 Selects
- 1.9 Checkbox inputs
- 1.10 Radio inputs
- 1.11 Hidden input fields
- 1.12 HTML5 input types
- 1.13 DateTime, Number and Range input types
- 2 see also
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.
- how to markup a containing
<div>element with the root class name
- how to markup
<input type="text" >elements with hCard property names
- 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.
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
vcard-input would break all current parsers. To add the demarcation we should use a new class
<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.
<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.
<input class="fn" id="name" type="text" /> <textarea class="note" name="bio" cols="20" rows="2"></textarea>
Multiple form fields for plural microformat properties
Where a microformat property such as
street-address in hCard can contain an array of values, these values will be added in order into the collection of form fields with the same classname.
<input class="street-address" name="address1" type="text" /> <input class="street-address" name="address2" type="text" /> <input class="street-address" name="address3" type="text" />
Values can be passed into selects where a match can be found against the content or value of an option. The example below shows how a select could be used to define the
type of a
tel. The auto-fill application should check the content of the option first then its value attribute. Where a property such as a tel type is plural and the select element has the
multiple attribute an auto-fill application should set multiple values in the select.
<div class="tel"> <input class="value" name="telephone-number" type="text" /> <select class="type" name="telephone-type" multiple="multiple"> <option value="none">Select phone type</option> <option value="home">Home</option> <option value="work">Work</option> <option value="pref">Pref</option> <option value="fax">Fax</option> <option value="cell">Mobile</option> <option value="cell">Pager</option> </select> </div>
Checkbox inputs can be used much like a multiple select. The values have to match the controlled vocabulary of the microfomat property being targeted.
<div class="tel"> <input class="value" type="text" /> <input class="type" name="type" value="home" type="checkbox" />Home <input class="type" name="type" value="work" type="checkbox" />Work etc… </div>
Radio inputs can be used to force a single selection from a controlled vocabulary. There are very few single value controlled vocabularies in the microformats schemas, but
rating in hReview would be a good example.
<input class="rating" name="rating" value="5" type="radio" />5 <input class="rating" name="rating" value="4" type="radio" />4 <input class="rating" name="rating" value="3" type="radio" />3 etc…
Hidden input fields
In general, the use of hidden fields should be discouraged, but they are use useful for the post processing of language specific formatting. A good example of this would be hResumes use of
duration to define how long someone has had a job. This is most often done with month/year drop down selects as on linkedin.com.
<select id="month-started"> <option value="1">January</option> … </select><br /> <input id="year-started" type="text" /> <input class="duration" type="hidden" onchange="someCustomFormatting()" />
In the example above the
HTML5 input types
Although HTML5 has new semantic input types such as
url their primary purpose is to describe data types rather than the context of data use. We may know that the input in the example below is a date, but we only know that it is a start date of an event by the use of the classname attribute
<div class="vevent"> <input class="dtstart" type="datetime" />
For clarity and consistency in authoring rules, an auto-fill application should not try and imply context from the input type. All the non date and number based input types
tel should be treated as if they were a simple text input.
color input is not supported as it is not yet used as a data type in the current or proposed schemas
DateTime, Number and Range input types
The new HTML5 DateTime input types still do not give the data context, but they do inform us of specific formatting requirements. Where possible the auto-fill application should format the DateTime value as per the
type. If the passed data does not contain the DateTime fragment required for the specific format the input should be left blank.
<input class="dtstart" type="date" /> 1996-12-19 <input class="dtstart" type="month" /> 1996-12 <input class="dtstart" type="time" /> 17:39:57 <input class="dtstart" type="datetime" /> 1996-12-19T16:39:57-08:00 <input class="dtstart" type="datetime-local" /> 1996-12-19T16:39:57
The number and range inputs need to be type checked before data is past into the form fields. No invalid dates or numbers should be passed into the form fields.
Min and Max checking on form fields
max attribute exists for a number or datetime input the value being passed needs to be checked to make sure it is in range before the input is updated.