value-class-pattern: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (value-excerption-pattern moved to value-class-pattern: Turns out, ‘excerption’ is a non-obvious word, and referring to this pattern as the ‘value-class-pattern’ instead is going to lower an unnecessary barrier to entry.)
(Updated. New parsing rules, more robust examples, handling for the value-title classname extension (visible and hidden forms).)
Line 1: Line 1:
<entry-title>Value Excerption Pattern</entry-title>
<entry-title>Value Class Pattern</entry-title>
''The value excerption pattern is derived from [[hCard#Value_excerpting|value-excerpting]] in hCard. As such, it is already somewhat supported in parsers. '''However''', the precise parsing behavior is not yet finalized, so the pattern should be used only with extreme caution, and with the awareness that the editing of more precise parsing rules could impact your pages.''
''The value class pattern is derived from [[hCard#Value_excerpting|value-excerpting]] in hCard. As such, it is already somewhat supported in parsers. '''However''', the precise parsing behavior is not yet finalized, and the documentation is a work in progress. The pattern should be used with some caution, and with the awareness that future parsing rules could impact your pages.''
 
__TOC__
__TOC__
<div class="vcard">
<div class="vcard">
; <span class="role">Editor</span>  
; <span class="role">Editor</span>  
Line 7: Line 9:
</div>
</div>


Sometimes, only a part of an element's content is used as the value of a microformat property. This may occur when a property has optional sub-properties, such as <code>tel</code> in [[hCard]]. Other times, the most logical, semantic element for the property class name may include other content.  
Sometimes, only a part of an element's content is to be used as the value of a microformat property. This may occur when a property has optional sibling properties, such as <code>tel: type</code> and <code>tel: value</code> in [[hCard]]. Other times, the most appropriate structure for a property may include other content.


For these purposes, the special class name <code>value</code> is used to excerpt out the relevant element content.
For these purposes, the special class name <code>value</code> is used to mark-up the relevant data excerpt from larger element content.


==Simple Examples==
==Simple Examples==
Line 28: Line 30:
</source>
</source>


In this case, the value of <code>tel</code> is <code>+1.415.555.1212</code>, not <code>Home: +1.415.555.1212</code>.
In this case, the <code>value</code> of <code>tel</code> is <code>+1.415.555.1212</code>, not <code>Home: +1.415.555.1212</code>.


Another example, this time using <code>price</code> in [[hListing]]:
Another example, this time using a localized (British) telephone number:


<source lang=html4strict>
<source lang=html4strict>
  <p class="price">
  <span class="tel">
    I want to sell for
  <span class="type">Home</span>:
    <span class="value">£15</span>
  <span class="value">+44</span> (0) <span class="value">1223 123 123</span>
  </p>
  </span>
</source>
</source>


In this case, <code>price</code> will parse as <code>£15</code>, rather than as the entire sentence.
In this case, the valid ''data'' for the telephone number is <samp>+441223123123</samp>, but the way in which phone number is presented in Britain will include the <samp>(0)</samp>, for local dialling. That is, from anywhere in the world you may dial <kbd>+441223123123</kbd>, or from within Britain you may dial <kbd>01223123123</kbd>. Common local publishing interferes with the data, since dialling <kbd>'''+440'''1223123123</kbd> is an invalid number.
 
In the mark-up, two <code>value</code> classes target the part of the telephone number string that makes an international, valid number, whilst allowing conventional presentation.


Another example, using <code>dtstart</code> in [[hCalendar]]:
Another example, using <code>dtstart</code> in [[hCalendar]]:
Line 50: Line 54:
</source>
</source>


Whilst the entire string ‘Friday 25th May <nowiki>[…]</nowiki>’ is semantically the date, it's the ISO 8601 encoded form alone which must be consumed by a microformats parser, so the <code>value</code> class isolates it.
Whilst the entire string ‘Friday 25th May <nowiki>[…]</nowiki>’ is date information, it's only the ISO 8601 encoded form which must be consumed by a microformats parser, so the <code>value</code> class isolates it.
 
==Basic Parsing==


==Parsing==
* Where an element with a microformat property class name has an descendant with class name <code>value</code>, parsers should read the inner-text of the ''<code>value</code>'' element only, ignoring other text node descendants.
* Where an element with a microformat property class name has an descendant with class name <code>value</code>, parsers should read the inner-text of the ''<code>value</code>'' element only, ignoring other text node descendants.
* Where multiple descendants of a property all have a class name of <code>value</code>, they should be concatenated, without inserting additional characters or white-space.
* Where there are multiple descendants of a property with class name of <code>value</code>, they should be concatenated ''without'' inserting additional characters or white-space.
* Where an element <code>foo</code> with class <code>value</code> has a <em>descendant</em> <code>bar</code> with class <code>value</code>, the entire content of <strong><code>foo</code></strong> is taken as the <code>value</code>. Nesting additional elements with class of <code>value</code> cannot be used to further isolate a property's value.
* Descendants with class of <code>value</code> must not be parsed deeper than one level. That is, where an element <code>foo</code> with class <code>value</code> has a <em>descendant</em> <code>bar</code> with class <code>value</code>, the content of <strong><code>foo</code></strong> is taken as the <code>value</code>. Nesting additional elements with class of <code>value</code> cannot be used to further isolate a property's value.
 
e.g.
 
<source lang=html4strict>
<p class="description">
  <foo class="value">
    <bar class="value">Puppies Rule!</bar>
    <strong>But kittens are better!</strong>
</foo>
</p>
</source>
 
In this example, <code>description</code> has a child ‘<code>value</code>’, and that child has a ''grandchild'' ‘<code>value</code>’. However, the parsing of <code>value</code> classes stops at the first level, so the data for <code>description</code> is: <samp><code>&lt;bar class="value">Puppies Rule!&lt;/bar>&lt;strong>But kittens are better!&lt;/strong></code></samp>.
 
==Advanced Value Excerption==
 
===<code>class=value-title</code>===
 
The <code>value-title</code> class name allows the publisher to indicate the data value for a parent property is contained in the <code>title</code> attribute of an element.
 
This can be used to provide a synonym within content, or used to quietly publish alternate, machine forms of information for microformats parsing, without affecting the consumption of your content.
 
For example, you can use casual localization with dates:
 
<source lang=html4strict>
<p>It was <span class='dtstart'><span class='value-title' title='2008'>last year</span></span> that I realised my addiction to cashew nuts would cost this country so dear.</p>
</source>
 
Parsing rules for <code>value-title</code> are the same as for <code>value</code> above, with the following additions:
 
* Where a microformats property has a child <code>value-title</code>, the content of the <code>title</code> attribute of that element must be parsed, ''instead of'' the inner-text of the element.
 
====Using <code>value-title</code> to publish machine-data====
 
The initial usage of <code>value-title</code> is used to publish alternate, parsable forms of property values in a visible context. However, there have developed some cases in microformats where it necessary to include a data form to ensure accurate parsing, which publishers do not want visible in their page.
 
For example, full [[ISO8601]] dates can be confusing to readers of the page (both as a tooltip and when read aloud to users of screen reader technology), and enumerations such as <code>type</code> in hCard's <code>tel</code> use US-English terms, which are not part of pages in any other language.
 
Since both of those scenarios are unacceptable, for these cases, and these alone, there exists a further extension of value-excerption, allowing the parsable form to be published ‘silently’ in parallel with the local content. This pattern is used as follows:
 
<source lang=html4strict>
<p class='tel' lang='en-gb'>
    <span class='type'>
        <span class='value-title' title='cell'> </span>
        mobile
    </span>
    <span class='value'>+44 7773 000 000</span>
</p>
</source>
 
The <samp>cell</samp> property value is parsed, but <samp>mobile</samp> is displayed on the page.
 
In the case of dates:
 
<source lang=html4strict>
<p class='dtstart'>
    <span class='value-title' title='2009-03-14T16:28-0600'> </span>
    March 14th 2009, around half-past four
</p>
</source>
 
The microformats parser will read the ISO format date <samp>2009-03-14T16:28-0600</samp>, but users will only see <samp>March 14th 2009, around half-past four</samp>. The ISO-form date above does not get exposed to any user at all.
 
=====How does this work?=====
 
Browsers collapse the <code>value-title</code> span down to a width of <code>0</code>, effectively providing no visual rendering, whilst keeping the element in the DOM. With no physical dimensions, there is no ‘hover’ state, so no tooltip is revealed. Furthermore, the empty element is not passed to assistive technology layers such as VoiceOver.
 
We conducted [[value-excerption-value-title-test|thorough testing]] of these parsing behaviors to ensure accessibility.
 
'''Note: Whilst the <code>value-title</code> element is more gracefully written without whitespace inner-text (or as self-closing <code>&lt;span /></code> element in XHTML), current tools such as WYSIWYG editors and HTML-Tidy will erroneously discard them, meaning that the parsable data could be thrown away by some publishing tools, or even parsers themselves. As such, <code>&lt;span class='value-title'> &lt;/span></code>, including a single whitespace character as content, is the recommended pattern for this time.'''
 
Parsing this final <code>value-title</code> extension imposes some stricter restrictions on usage. These restrictions exist to reduce the impact of <abbr title="Don't Repeat Yourself">DRY</abbr> violations, reducing the risk of sites spoofing data, and encouraging the best scenario for maintaining both forms of data accurately.
 
So, where an element with class <code>value-title</code> is to be parsed as the data for a property, and that element also contains no non-whitespace content (ergo, it is ‘empty’), the following rules apply:
 
* The ‘empty’ value-title element must be the '''first, non-whitespace child''' of the property element. That is, it should follow immediately after the property is declared, before the human-readable form, and without any additional nesting.
* The ‘empty’ value-title element can only be used for specific properties. Microformat specifications must explicitly state which of their properties can be used with this extension of value-exception.
* Where an ‘empty’ value-title element is to be used as the property value, it must be the _only_ such <code>value</code> content. That is, it overrides all other <code>value</code> and <code>value-title</code> siblings and/or cousins.
* Tools written to perform Conformance Testing and/or Validation of microformats ''should'' attempt to compare the machine-data and human legible forms of the property data, and advise authors if the forms do not match.
 
''At time of publication, this document post-dates other microformat specifications, such that they may not yet indicate which properties are to be compatible with this pattern. In the interim, the properties documented on the [[machine-data]] page are to be considered normative.''
 
We require a thorough test-suite for this pattern. In the interim, here is an incomplete test suite:
 
=====Conforming Tests=====
 
======One======
 
<source lang=html4strict>
<p class='tel'>My
    <span class='type'>
        <span class='value-title' title='cell'> </span>mobile
    </span> phone number is <span class='value'>+44 1245 333 333</span>
</p>
</source>
 
Result
 
<source lang=text>
TEL
    TYPE = cell
    VALUE = +44 1245 333 333
</source>
 
======Two======
 
<source lang=html4strict>
<p class='vevent'>
    My <span class='summary'>Birthday Party</span> will be held
    <span class='dtstart'>
        <span class='value-title' title='2009-04-01'>tomorrow</span>
    </span>
    and last until
    <span class='dtend'>
        <span class='value-title' title='2009-04-05'> </span>
        the following Tuesday (April 5th)
    </span>.
</p>       
</source>
 
Result
 
<source lang=text>
VEVENT
    SUMMARY = Birthday Party
    DTSTART = 2009-04-01
    DTEND = 2009-04-05
</source>
 
=====Tests of Non-Conforming Code=====
 
======One======
 
In this case, the human text appears before the <code>value-title</code> element, so the machine-data value has a weaker association with the property declaration. The likelihood of the data not being maintained correctly — the data value being ignored by an editor — is increased.
 
<source lang=html4strict>
<p class='tel'>My
    <span class='type'>
        mobile
        <span class='value-title' title='cell'> </span>
    </span> phone number is <span class='value'>+44 1245 333 333</span>
</p>
</source>
 
Result
 
<source lang=text>
TEL
    TYPE = none/default/unknown ('mobile' is unknown in hCard)
    VALUE = +44 1245 333 333
</source>
 
======Two======
 
In this case, the <code>value-title</code> element is used for a property that is not valid for use with this pattern.
 
<source lang=html4strict>
<p class='vevent'>You are invited to
    <span class='summary'>
        <span class='value-title' title='FooCamp'> </span>
        BarCamp
    </span>
</source>
 
Result
 
<source lang=text>
VEVENT
    SUMMARY = BarCamp
</source>


==Related Pages==
==Related Pages==
* [[value-excerption-pattern-issues]]
* [[value-excerption-pattern-issues]]
* [[hcard#Value_excerpting|hCard: Value Excepting]]
* [[hcard#Value_excerpting|hCard: Value Excepting]]
* [[value-excerption-pattern-brainstorming]]
* [[value-excerption-pattern-brainstorming]]
* [[machine-data|Machine Data in Microformats]]
* [[machine-data|Machine Data in Microformats]]

Revision as of 08:33, 30 March 2009

<entry-title>Value Class Pattern</entry-title> The value class pattern is derived from value-excerpting in hCard. As such, it is already somewhat supported in parsers. However, the precise parsing behavior is not yet finalized, and the documentation is a work in progress. The pattern should be used with some caution, and with the awareness that future parsing rules could impact your pages.

Editor
Ben Ward

Sometimes, only a part of an element's content is to be used as the value of a microformat property. This may occur when a property has optional sibling properties, such as tel: type and tel: value in hCard. Other times, the most appropriate structure for a property may include other content.

For these purposes, the special class name value is used to mark-up the relevant data excerpt from larger element content.

Simple Examples

Here is an hCard fragment for marking up a home phone number:

vCard:

TEL;TYPE=HOME:+1.415.555.1212

hCard:

 <span class="tel">
   <span class="type">Home</span>:
   <span class="value">+1.415.555.1212</span>
 </span>

In this case, the value of tel is +1.415.555.1212, not Home: +1.415.555.1212.

Another example, this time using a localized (British) telephone number:

 <span class="tel">
   <span class="type">Home</span>:
   <span class="value">+44</span> (0) <span class="value">1223 123 123</span>
 </span>

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, using dtstart in hCalendar:

 <span class="dtstart">
    Friday 25th May, 6pm
    <span class="value">2008-05-25T18:00:00+0100</span>
 </span>

Whilst the entire string ‘Friday 25th May […]’ is date information, it's only the ISO 8601 encoded form which must be consumed by a microformats parser, so the value class isolates it.

Basic Parsing

  • Where an element with a microformat property class name has an descendant with class name value, parsers should read the inner-text of the value element only, ignoring other text node descendants.
  • Where there are multiple descendants of a property with class name of value, they should be concatenated without inserting additional characters or white-space.
  • Descendants with class of value must not be parsed deeper than one level. That is, where an element foo with class value has a descendant bar with class value, the content of foo is taken as the value. Nesting additional elements with class of value cannot be used to further isolate a property's value.

e.g.

 <p class="description">
  <foo class="value">
    <bar class="value">Puppies Rule!</bar>
    <strong>But kittens are better!</strong>
 </foo>
</p>

In this example, description has a child ‘value’, and that child has a grandchildvalue’. However, the parsing of value classes stops at the first level, so the data for description is: <bar class="value">Puppies Rule!</bar><strong>But kittens are better!</strong>.

Advanced Value Excerption

class=value-title

The value-title class name allows the publisher to indicate the data value for a parent property is contained in the title attribute of an element.

This can be used to provide a synonym within content, or used to quietly publish alternate, machine forms of information for microformats parsing, without affecting the consumption of your content.

For example, you can use casual localization with dates:

<p>It was <span class='dtstart'><span class='value-title' title='2008'>last year</span></span> that I realised my addiction to cashew nuts would cost this country so dear.</p>

Parsing rules for value-title are the same as for value above, with the following additions:

  • Where a microformats property has a child value-title, the content of the title attribute of that element must be parsed, instead of the inner-text of the element.

Using value-title to publish machine-data

The initial usage of value-title is used to publish alternate, parsable forms of property values in a visible context. However, there have developed some cases in microformats where it necessary to include a data form to ensure accurate parsing, which publishers do not want visible in their page.

For example, full ISO8601 dates can be confusing to readers of the page (both as a tooltip and when read aloud to users of screen reader technology), and enumerations such as type in hCard's tel use US-English terms, which are not part of pages in any other language.

Since both of those scenarios are unacceptable, for these cases, and these alone, there exists a further extension of value-excerption, allowing the parsable form to be published ‘silently’ in parallel with the local content. This pattern is used as follows:

<p class='tel' lang='en-gb'>
    <span class='type'>
        <span class='value-title' title='cell'> </span>
        mobile
    </span>
    <span class='value'>+44 7773 000 000</span>
</p>

The cell property value is parsed, but mobile is displayed on the page.

In the case of dates:

<p class='dtstart'>
    <span class='value-title' title='2009-03-14T16:28-0600'> </span>
    March 14th 2009, around half-past four
</p>

The microformats parser will read the ISO format date 2009-03-14T16:28-0600, but users will only see March 14th 2009, around half-past four. The ISO-form date above does not get exposed to any user at all.

How does this work?

Browsers collapse the value-title span down to a width of 0, effectively providing no visual rendering, whilst keeping the element in the DOM. With no physical dimensions, there is no ‘hover’ state, so no tooltip is revealed. Furthermore, the empty element is not passed to assistive technology layers such as VoiceOver.

We conducted thorough testing of these parsing behaviors to ensure accessibility.

Note: Whilst the value-title element is more gracefully written without whitespace inner-text (or as self-closing <span /> element in XHTML), current tools such as WYSIWYG editors and HTML-Tidy will erroneously discard them, meaning that the parsable data could be thrown away by some publishing tools, or even parsers themselves. As such, <span class='value-title'> </span>, including a single whitespace character as content, is the recommended pattern for this time.

Parsing this final value-title extension imposes some stricter restrictions on usage. These restrictions exist to reduce the impact of DRY violations, reducing the risk of sites spoofing data, and encouraging the best scenario for maintaining both forms of data accurately.

So, where an element with class value-title is to be parsed as the data for a property, and that element also contains no non-whitespace content (ergo, it is ‘empty’), the following rules apply:

  • The ‘empty’ value-title element must be the first, non-whitespace child of the property element. That is, it should follow immediately after the property is declared, before the human-readable form, and without any additional nesting.
  • The ‘empty’ value-title element can only be used for specific properties. Microformat specifications must explicitly state which of their properties can be used with this extension of value-exception.
  • Where an ‘empty’ value-title element is to be used as the property value, it must be the _only_ such value content. That is, it overrides all other value and value-title siblings and/or cousins.
  • Tools written to perform Conformance Testing and/or Validation of microformats should attempt to compare the machine-data and human legible forms of the property data, and advise authors if the forms do not match.

At time of publication, this document post-dates other microformat specifications, such that they may not yet indicate which properties are to be compatible with this pattern. In the interim, the properties documented on the machine-data page are to be considered normative.

We require a thorough test-suite for this pattern. In the interim, here is an incomplete test suite:

Conforming Tests
One
<p class='tel'>My 
    <span class='type'>
        <span class='value-title' title='cell'> </span>mobile
    </span> phone number is <span class='value'>+44 1245 333 333</span>
</p>

Result

TEL
    TYPE = cell
    VALUE = +44 1245 333 333
Two
<p class='vevent'>
    My <span class='summary'>Birthday Party</span> will be held
    <span class='dtstart'>
        <span class='value-title' title='2009-04-01'>tomorrow</span>
    </span>
    and last until 
    <span class='dtend'>
        <span class='value-title' title='2009-04-05'> </span>
        the following Tuesday (April 5th)
    </span>.
</p>

Result

VEVENT
    SUMMARY = Birthday Party
    DTSTART = 2009-04-01
    DTEND = 2009-04-05
Tests of Non-Conforming Code
One

In this case, the human text appears before the value-title element, so the machine-data value has a weaker association with the property declaration. The likelihood of the data not being maintained correctly — the data value being ignored by an editor — is increased.

<p class='tel'>My 
    <span class='type'>
        mobile
        <span class='value-title' title='cell'> </span>
    </span> phone number is <span class='value'>+44 1245 333 333</span>
</p>

Result

TEL
    TYPE = none/default/unknown ('mobile' is unknown in hCard)
    VALUE = +44 1245 333 333
Two

In this case, the value-title element is used for a property that is not valid for use with this pattern.

<p class='vevent'>You are invited to
    <span class='summary'>
        <span class='value-title' title='FooCamp'> </span>
        BarCamp
    </span>

Result

VEVENT
    SUMMARY = BarCamp

Related Pages