Value Class Pattern - Microformats Wiki

The value class pattern is a standard set of techniques to markup the value of a microformats property in part of an element, a title attribute, or across multiple elements, and how to parse & normalize those markup techniques.
This section is informative.
Use the value class pattern when you need to markup:
For these purposes, the special class name value is used to mark-up the relevant data excerpt from larger element content.
This section is informative.
The value-class-pattern is feature complete, ready for use in markup, and supported in implementations such as search engines, parsers, and Firefox Operator. H2VX supports parsing date and time separation but not value-title. See also the blog announcement.
The microformats2-parsing specification normatively references the value-class-pattern, and microformats2 parsers implement it.
This section is informative.
Here is markup for a home phone number:
In this case, the value of tel is +1.415.555.1212, not Home: +1.415.555.1212.
Sometimes the value for a microformats property must be split into multiple pieces in the content of the element representing that property. Multiple elements with a class name of "value" (value elements) can be used to extract and concatenate these pieces into a single value for microformats properties which expect simple strings or tel values.
Another example, this time using a localized (British) telephone number:
In this case, the valid data for the telephone number is +441223123123, but the way in which phone number is presented in Britain will include the (0), for local dialling. That is, from anywhere in the world you may dial +441223123123, or from within Britain you may dial 01223123123. Common local publishing interferes with the data, since dialling +4401223123123 is an invalid number.
In the mark-up, two value classes target the part of the telephone number string that makes an international, valid number, whilst allowing conventional presentation.
Another example, adding a place name to a geo co-ordinate:
Whilst the entire string is a geo point, it's only the decimal encoded co-ordinates which must be consumed by a microformats parser, so the value class isolates it from the degrees form, which the publisher includes for completeness.
In this example, description has a child ‘value’, and that child has a grandchild ‘value’. However, the parsing of value classes stops at the first level, so the data for description is: <em class="value">Puppies Rule!</em><strong>But kittens are better!</strong>, not just Puppies Rule!.
Some microformats properties expect an ISO8601 datetime value, e.g. hCalendar dtstart and dtend, hAtom published and updated, and all microformats2 dt-* properties.
Authors may use the value class pattern to separately specify the date and the time, which are then combined to specify a single datetime value.
Example, this hCalendar 'dtstart' property with 'value' elements:
Alternatively, if you're not able to use the HTML5 <time> element:
both produce the following 'dtstart' value:
and iCalendar converters produce the following DTSTART:
Note: The lack of a timezone indicates a "floating" datetime, that is a datetime independent of any particular timezone. Examples of floating datetimes could be an alarm clock you set to ring at 7am, or the common 9am-5pm workday.
Note for iCalendar DTSTART: The implied "00" seconds here is only due to iCalendar syntax requirements, and not actually meaningful.
For all date time properties (as defined in their respective microformats specifications), the following rules apply in addition to (and in some cases replacing) the above value class pattern parsing rules.
When a "value element" is found, parse a value from the element as follows:
If by parsing the "value" element(s), at least a specific date has been found, then the "value" is overall valid, and the parser assembles the overall datetime value by concatenating the specific date (PROPOSED: normalized to YYYY-MM-DD), " " (space character) and specific time (if time was specified, with 00 minutes implied if no minutes are provided), and specific timezone (if timezone and a specific time was specified).
The following are format specific details and optimizations that make use of the value-class-pattern.
Typically events that start and end the same day only display the date of the event once (makes sense per the DRY principle) (real world examples: Upcoming, ... more examples with URLs would help for thoroughness).
Thus it would be convenient if we could imply an hCalendar event "dtend" date from its "dtstart" date when only the time (and optionally timezone) was specified for its "dtend", e.g.:
and in HTML4/XHTML1:
To simplify this further for authors, hCalendar processors could treat the specifying of just the time per the value-class-pattern date and time value rules, and thus eliminate the need for the "value" span inside the "dtend" span:
and in HTML4/XHTML1:
hCalendar to iCalendar converters should produce the following iCalendar fragment (as part of a valid .ics file) from all of the above four examples:
Note that the implied "00" seconds here is only due to iCalendar syntax requirements, and not actually meaningful.
Examples "in the wild":
microformats implementations which consume hCalendar and generate iCalendar MUST in addition:
Similarly, in blog posts that indicate both when they were "published" and "updated", the date is usually only displayed once, typically when "published" (real world examples with URLs would help for thoroughness).
Thus it would be convenient if we could imply an hAtom entry "updated" date from its "published" date when only the time (and optionally timezone) was specified for its "updated", e.g. for a blog post that was updated the same day: