currency-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (rm redundant link)
m (Replace <entry-title> with {{DISPLAYTITLE:}})
 
(36 intermediate revisions by 13 users not shown)
Line 1: Line 1:
== Brainstorming ==
{{DISPLAYTITLE:currency brainstorming}}


Brainstorming for the proposed [[currency]] microformat.
Brainstorming for a possible [[currency]] microformat per the microformats [[process]]:
* [[currency-examples]]
* [[currency-formats]]
* [[currency-brainstorming]]


==The Problem==
The problem: how to explicitly specify a) that a figure/number relates to money; b) the currency of a stated figure; and c) the period in which that figure was current.
*The currency sign cannot be used reliably since the same sign (or symbol) may represent more than one currency. eg. $ is used for many different dollars (USD, AUD, CAD...) and even [http://en.wikipedia.org/wiki/Currency_sign#Examples other units like pesos].
*The language of the page is not sufficient to define the currency of prices in the page:
**More than one currency may be used by people who speak the same language.
**The page may be written in one language and still quote prices/figures in a different country's currency.
**Even if a country can be identified, more than one currency may be used in that country.
Converting currency figures is a reasonably easy problem to solve as indicated by the [[#Existing_Practices]]. However many automated conversion tools must make assumptions about the original figure's currency -- e.g. assuming a USD for all uses of $, or British Pounds for £ (which is also [http://en.wikipedia.org/wiki/Lira sometimes used to denote Lira]).
=== Currency Changes ===
I wish to expand on one of the points mentioned above: there might be two or more currencies in the same country: e.g. in Romania
* ROL - Romanian Lei [being phased out]
* RON - Romanian New Lei
* after Romania joins the EU, the RON will be replaced by Euro, too (not imediately, probably in 2-3 years)
Although the three letter code is different in this case, the currency is often given as ''Lei''. There are other countries, where similar examples exist/existed. The two currencies might have an identical name, yet they have 2 very different meanings. Usually there is a difference of 3-4 orders of magnitude between the old currency and the new currency.
[[discoleo]]
===Related problems===
<p>"Amounts" in arbitrary units is a bit harder and necessary for several applications.</p>
<p>For example, consider the work that has been done on a recipe microformat.</p>
[[recipe-examples]]
<p>Though we haven't reached this problem yet in the research, I can see it
coming:</p>
<p>Say you wanted to create a "shopping list" application which you could tell which recipes you wanted to cook, and have it automatically total up all the various amounts of ingredients and give you the net amount of stuff you wanted to pick up.</p>
<p>It would need to be able to determine precise amounts/units of each ingredient.  This might turn out to be like the currency problem, or it might be more complex, given the variety of units used in recipes, English vs. metric etc.  That's a case that might need a microformat.  We need more research and analysis to really justify it, but I can see it within the realm of probable possibility.</p>
== Individual Brainstorm Contributions ==
'''These should be collected by topic rather than author, and then perhaps cite/quote the author at the end of each paragraph instead to preserve some aspect of intent of possible opinion conveyance.''' - [[User:Tantek|Tantek]] 23:16, 18 March 2013 (UTC)
===Ken Griffith===
<p>Ben B's system is the most extensible of the proposals here, though it might be problematic to insert it as an inline element in a paragraph that mentions a currency amount.  It would be preferable to use only inline elements.</p>
<p>Regarding currency codes, it will be important to use an extensible code system. ISO 4217 is great for listing national currencies.  However, we need to look at how people actually use currency for transactions on the web.  There are a lot of businesses and people using systems like e-gold, Webmoney, etc - several billion dollars equivalent in annual transactions - a small but steadily growing percentage of web transactions.  So there should be a currency code list somewhere that can be extended beyond ISO 4217 to include private issue currency units that people actually use on the web.</p>


===Ben Buchanan===
===Ben Buchanan===
Line 118: Line 166:


====Straw man proposal====
====Straw man proposal====
'''Superseded; see [[#Straw_man]], below.'''


(this reflects Ciaran McNulty's proposals, above)
(this reflects Ciaran McNulty's proposals, above)
Line 126: Line 176:
**currency - class (required; uses ISO 4217) '''[or "type"?]'''
**currency - class (required; uses ISO 4217) '''[or "type"?]'''
**amount - class (required) '''[or "value"?]'''
**amount - class (required) '''[or "value"?]'''
**year - class (optional - for historic values only) (better "'''date'''", in [[datetime-design-pattern]]. Consider inflation in Germany in 1930s!)
**date - class (optional - for historic values only, in [[datetime-design-pattern]]. Consider inflation in Germany in 1930s!)
**symbol - class (optional - so that we know whether the symbol is present; or whether it needs to be generated by the user agent; it will also help user agents to ignore $ and other such symbols, when used for purposes other than to indicate a currency, or to  remove them, when translating to a different currency.)
**symbol - class (optional - so that we know whether the symbol is present; or whether it needs to be generated by the user agent; it will also help user agents to ignore $ and other such symbols, when used for purposes other than to indicate a currency, or to  remove them, when translating to a different currency.)
**unit - class (subdivison of currency; use as "symbol")
**unit - class (subdivison of currency; use as "symbol")
**equivalence - class (optional; conversion should be done by the user agent. Do we need this? Does it need a numeric value?)  
**<s>equivalence - class (optional; conversion should be done by the user agent. Do we need this? Does it need a numeric value?)</s>


All classes may occur only once, apart from ''symbol'' (to allow for "£14 6s 2d") and ''unit'' (to allow for "five pounds 23 pence").
All classes may occur only once, apart from ''symbol'' (to allow for "£14 6s 2d") and ''unit'' (to allow for "five pounds 23 pence").
Line 335: Line 385:
=== Gary Jones ===
=== Gary Jones ===


<pre><nowiki>
<source lang=html4strict>
<span class="currency">
<span class="currency">
   <abbr class="type" title="CAD">$</abbr>
   <abbr class="type" title="CAD">$</abbr>
   <span class="value">5.00</span>
   <span class="value">5.00</span>
</span>
</span>
</nowiki></pre>
</source>


Renders as:
Renders as:
Line 350: Line 400:
I do think that the use of "type" and "value" classes would be better than variations of "currency_symbol" and "amount". It follows the same principles as some other elemental formats ([http://microformats.org/wiki/hcard#Value_excerpting value excerpting]), meaning it's [http://microformats.org/wiki/naming-principles#Minimal_Vocabulary easier to remember]  and implement, and even ISO4217 has codes for "currencies" that don't use symbols:
I do think that the use of "type" and "value" classes would be better than variations of "currency_symbol" and "amount". It follows the same principles as some other elemental formats ([http://microformats.org/wiki/hcard#Value_excerpting value excerpting]), meaning it's [http://microformats.org/wiki/naming-principles#Minimal_Vocabulary easier to remember]  and implement, and even ISO4217 has codes for "currencies" that don't use symbols:


<pre><nowiki>
<source lang=html4strict>
<span class="currency">
<span class="currency">
   <span class="value">23</span> ounces of
   <span class="value">23</span> ounces of
   <abbr class="type" title="XAG">gold</abbr>
   <abbr class="type" title="XAG">gold</abbr>
</span>
</span>
</nowiki></pre>
</source>


Renders as:
Renders as:
Line 518: Line 568:


*The claimed "lack of interest" in dated amounts ignores the [[currency-examples|evidence that such figures are widely published on the web]]. Most of your preceding "why not"s ignore the [[abbr-design-pattern]]. [[User:AndyMabbett|Andy Mabbett]] 07:30, 2 Jan 2007 (PST)
*The claimed "lack of interest" in dated amounts ignores the [[currency-examples|evidence that such figures are widely published on the web]]. Most of your preceding "why not"s ignore the [[abbr-design-pattern]]. [[User:AndyMabbett|Andy Mabbett]] 07:30, 2 Jan 2007 (PST)
===Taylor Cowan===
Pretending to forget all that we've know up till now about microformats, what if we just wanted a way for web page designers to make their currency amounts unambiguous with respect to currency denomination and amount?
"one hundred bucks"
<pre><abbr class="currency" title="USD100">one hundred bucks</abbr></pre>
$100 (CAD)
<pre><abbr class="currency" title="CAD100">$100</abbr></pre>
10 cents
<pre><abbr class="currency" title="USD0.10">ten cents</abbr></pre>
compare:
 
<pre><span class="hmoney">10 <abbr class="unit" title="cent"><abbr
class="currency" title="USD">cents</abbr></abbr></span></pre>
man Yen
<pre><abbr class="currency" title="JPY10,000">man Yen</abbr></pre>
So within the title, we've got ISO###.##
Then later on we wanted to apply one of those amounts to the "price" of an hListing:
<pre><abbr class="currency price" title="USD100">one hundred bucks</abbr></pre>
==Straw man==
Based on Taylor Cowan's suggestion, above, and on [http://microformats.org/discuss/mail/microformats-new/2007-September/000915.html subsequent mailing list discussion], the following "money" microformat straw man is proposed:
<pre><nowiki>
        <span class="hmoney">
          [value]
        </span>
        <abbr class="hmoney" title="[value]">
          [text]
        </abbr>
</nowiki></pre>
Where "value"  is a number+ISO-code pair ("GBP5", "4 USD") using ISO curency codes and where parsers must accept the formats:
*[currency-code][number]
*[currency-code][space][number]
*[number][currency-code]
*[number]space[currency-code]
and where dated money amounts are included in an hCalendar:
<pre><nowiki>
    <div class="vevent">
      <span class="description">
        <span class="summary">
          The last Monet painting to be auctioned
        </span>
        fetched
        <abbr class="currency" title="USD95M">$95 million</abbr>
        in
        <span class="dtstart>2005</span>
      </span>
    </div>
</nowiki></pre>
Further comment is invited. A test page is available, at http://www.westmidlandbirdclub.com/test/money.htm
===Notes===
This works for sub-divisions of currencies:
<pre><nowiki>
        <abbr class="currency" title="USD 0.05">
          5c
        </abbr>
</nowiki></pre>
archaic and non-decimal currencies:
<pre><nowiki>
        <abbr class="currency" title="GBP 0.125">two shillings and sixpence</abbr>
        <abbr class="currency" title="GBP1.05">a guinea</abbr>
</nowiki></pre>
and slang:
<pre><nowiki>
        <abbr class="currency" title="USD 500">five-hundred buckaroos</abbr>
        <abbr class="currency" title="USD200">a couple Franklins</abbr>
</nowiki></pre>
===Issues===
*Is hmoney the appropriate class-name?
** hcurrency would be better. [[User:MaxwellTerry|MaxwellTerry]] 19:59, 13 Jan 2008 (PST)
*Is money a separate microformat, or a [[measure]]ment, with the ISO currency code as the unit-code?
** Currency != money; Currency is a superset / parent of money. If we're using ISO codes, then we should be focusing on the currency (not money) it applies to. [[User:Gazza|Gazza]] 18:48, 7 Jan 2008 (PST)
*This is still susceptible to the [[accessibility-issues#abbr-design-pattern]].
*Using amount suffixes such as K, M, B, or T are not necessarily supported by any International Standard. Shouldn't we just say that the complete number should be used in the <nowiki><abbr></nowiki> element? [[User:ManuSporny|ManuSporny]] 12:31, 5 Oct 2007 (PDT)
===Suggested amendments===
*Use just the abbr pattern and format [number]space[currency-code]. We should narrow our focus to make progress. Simplify, simplify, simplify! [[User:ManuSporny|ManuSporny]] 07:16, 5 Oct 2007 (PDT)
**Is this approach too inflexible?
** "5 GBP" is not an abbreviation of "5 GBP". [[User:AndyMabbett|Andy Mabbett]] 09:46, 5 Oct 2007 (PDT)
*** This problem is easily fixed by using <pre><span class="hcurrency">5 GBP</span></pre> [[User:ManuSporny|ManuSporny]] 11:52, 5 Oct 2007 (PDT)
** People publish amounts as, say, "5GBP" (with no space) in the wild. [[User:AndyMabbett|Andy Mabbett]] 09:49, 5 Oct 2007 (PDT)
*** Yes, they do, however we can still mark that up as <pre><abbr class="hcurrency" title="5 GBP">5GBP</abbr></pre>. You could argue that "5 GBP" is not an abbreviation of "5GBP", which is true - but I believe this is an acceptable compromise, afterall... we would be arguing over a single space character, which seems a bit pedantic. [[User:ManuSporny|ManuSporny]] 11:52, 5 Oct 2007 (PDT)


==References==
==References==

Latest revision as of 16:21, 18 July 2020


Brainstorming for a possible currency microformat per the microformats process:

The Problem

The problem: how to explicitly specify a) that a figure/number relates to money; b) the currency of a stated figure; and c) the period in which that figure was current.

  • The currency sign cannot be used reliably since the same sign (or symbol) may represent more than one currency. eg. $ is used for many different dollars (USD, AUD, CAD...) and even other units like pesos.
  • The language of the page is not sufficient to define the currency of prices in the page:
    • More than one currency may be used by people who speak the same language.
    • The page may be written in one language and still quote prices/figures in a different country's currency.
    • Even if a country can be identified, more than one currency may be used in that country.

Converting currency figures is a reasonably easy problem to solve as indicated by the #Existing_Practices. However many automated conversion tools must make assumptions about the original figure's currency -- e.g. assuming a USD for all uses of $, or British Pounds for £ (which is also sometimes used to denote Lira).

Currency Changes

I wish to expand on one of the points mentioned above: there might be two or more currencies in the same country: e.g. in Romania

  • ROL - Romanian Lei [being phased out]
  • RON - Romanian New Lei
  • after Romania joins the EU, the RON will be replaced by Euro, too (not imediately, probably in 2-3 years)

Although the three letter code is different in this case, the currency is often given as Lei. There are other countries, where similar examples exist/existed. The two currencies might have an identical name, yet they have 2 very different meanings. Usually there is a difference of 3-4 orders of magnitude between the old currency and the new currency. discoleo


Related problems

"Amounts" in arbitrary units is a bit harder and necessary for several applications.

For example, consider the work that has been done on a recipe microformat.

recipe-examples

Though we haven't reached this problem yet in the research, I can see it coming:

Say you wanted to create a "shopping list" application which you could tell which recipes you wanted to cook, and have it automatically total up all the various amounts of ingredients and give you the net amount of stuff you wanted to pick up.

It would need to be able to determine precise amounts/units of each ingredient. This might turn out to be like the currency problem, or it might be more complex, given the variety of units used in recipes, English vs. metric etc. That's a case that might need a microformat. We need more research and analysis to really justify it, but I can see it within the realm of probable possibility.


Individual Brainstorm Contributions

These should be collected by topic rather than author, and then perhaps cite/quote the author at the end of each paragraph instead to preserve some aspect of intent of possible opinion conveyance. - Tantek 23:16, 18 March 2013 (UTC)

Ken Griffith

Ben B's system is the most extensible of the proposals here, though it might be problematic to insert it as an inline element in a paragraph that mentions a currency amount. It would be preferable to use only inline elements.

Regarding currency codes, it will be important to use an extensible code system. ISO 4217 is great for listing national currencies. However, we need to look at how people actually use currency for transactions on the web. There are a lot of businesses and people using systems like e-gold, Webmoney, etc - several billion dollars equivalent in annual transactions - a small but steadily growing percentage of web transactions. So there should be a currency code list somewhere that can be extended beyond ISO 4217 to include private issue currency units that people actually use on the web.

Ben Buchanan

Verbose but extensible and explicitly defines all values (without breaking DRY):

<div class="currency">
  <p class="figure">
     <span class="code">code</span>
     <span class="sign">symbol</span>
     <span class="amount">12345</span>
  </p>
</div>

"figure" is there to both explicitly associate the code, sign and amount but also allow the potential for more than one currency figure to be placed within the container. It does anticipate further development though and is the most easily dropped item at the early stage.

Without figure:

<div class="currency">
     <span class="code">code</span>
     <span class="sign">symbol</span>
     <span class="amount">12345</span>
</div>

Super shortened, relying on the parser to identify everything via implied order/structure:

<div class="currency">ABC12345$</div>

Although the simplest solution, it has a notable vulnerability: some currencies have/had three-letter abbreviations for their currency sign, instead of a symbol. This would make it very difficult for a parser to accurately identify such a currency.

In addition, it should be noted that the order alone cannot be used to identify which parts are code, sign and amount; since many currencies are denoted with the sign after the number.

Super shortened, but specifying a currency code as a class:

<div class="currency ABC">12345$</div>

It defines...

  1. we're talking about money - ISO standard implied,
  2. we're talking about the USD variety,
  3. we're talking fifty units of that money,
  4. a parser could work out the numbers and the symbol.

The biggest limitation I can see for that shorthand is that the currency code is not displayed visibly to human readers. The currency code is useful information to viewers and ideally should be displayed.

Shortened (including dropping 'figure', but explicitly defining and displaying the currency code. This would allow a parser to treat any remaining numbers as the amount; and any remaining a-z or symbol as the sign:

<div class="currency">
  <span class="code">ABC</span>12345$</p>
</div>

Charles Iliya Krempeaux

Maybe something like...

Pay me <abbr class="currency" title="CAD">$</abbr>5.00 now!

Although something like the the following might be better...

Pay me <span class="money"><abbr class="currency" title="CAD">$</abbr>5.00</span> now!

But it might be more semantic salt than is considered necessary. Just having the abbr with the class-currency near a number might be good enough. But that's open for discussion though.

Ben Ward

Could pure HTML be sufficient?

<html lang="en-gb">
<p>My new T-Shirts cost £30, but it cost my friend in Canada <span lang="en-ca">$34</span></p> 
</html>

Arve Bersvendsen

<p lang="nb">Den kanadiske prisen på t-skjorten var <span class="currency CAD">34 $</span>.</p>

Mike Stickel

<span class="money"><abbr class="currency" title="CAD eng">$</abbr><span class="amount">5.00</span></span>

In this format the wrapping would be "money" or something similar followed by either the actual "amount" or the "currency", depending on what rules your country/language follows in regards to the order. Since there can be a difference between different languages within countries I thought it might be a good idea to include that in the "currency" definition of the formating, eg., "CAD eng" or "CAD fr". It could also give sites that list multiple languages a way to differentiate when they show multiple prices.

Good idea, but shouldn't a Microformat use existing markup for language attributes, eg.
<span class="money"><abbr class="currency" title="CAD" lang="en">$</abbr><span class="amount">5.00</span></span>
Reference w3.org: 8.1 Specifying the language of content: the lang attribute
Bob Jonkman 22:26, 12 Oct 2006 (PDT)

Ciaran McNulty

The only microformat that I've noticed currency units in is hListing, and that deliberately shies away from parsing the actual values because it's too free-form in most existing Listing formats.

My own preference would be for something like:

<p class="money">This item costs
  <span class="currency">GBP</span>
  <span class="amount">10.00</span>
</p>

Which with similar parsing rules to existing formats would also allow things like:

<p class="money">
  It'll cost you
  <abbr class="currency" title="50.00">fifty</abbr>
  <abbr class="amount" title="GBP">quid</abbr>
  , mate!
</p>

Or, a more complex example with multiple languages:

<p lang="en">Price:
<span class="money">
  <abbr class="currency" title="GBP">£</abbr>  
  <span class="amount">1,250.00</span> 
</span> 
<span lang="fr" class="money">
  (Prix:
  <span class="amount">1600,00</span>
  <abbr class="currency" title="EUR">€</abbr>
  )
</span>
</p>

Andy Mabbett

Straw man proposal

Superseded; see #Straw_man, below.

(this reflects Ciaran McNulty's proposals, above)

In order to use currency as a sub-class, the parent should be named 'money'

  • money - class (required) [or "currency"?]
    • currency - class (required; uses ISO 4217) [or "type"?]
    • amount - class (required) [or "value"?]
    • date - class (optional - for historic values only, in datetime-design-pattern. Consider inflation in Germany in 1930s!)
    • symbol - class (optional - so that we know whether the symbol is present; or whether it needs to be generated by the user agent; it will also help user agents to ignore $ and other such symbols, when used for purposes other than to indicate a currency, or to remove them, when translating to a different currency.)
    • unit - class (subdivison of currency; use as "symbol")
    • equivalence - class (optional; conversion should be done by the user agent. Do we need this? Does it need a numeric value?)

All classes may occur only once, apart from symbol (to allow for "£14 6s 2d") and unit (to allow for "five pounds 23 pence").

Examples

Thus:

	<span class="money">A widget costs 
		<abbr class="currency symbol" title="USD">$</abbr>
		<span class="amount">12.57</span>
	</span>
	<tr>
		<th>Spaghetti-knitter</th>
		<td class="money">
			<abbr class="currency" title="USD">
				<span class="amount">42.67</span>
			</abbr>
		</td>
	</tr>
	<span class="money">
	Can you spare
		<abbr class="amount" title="10">ten</abbr>
		<abbr class="currency" title="USD">
			<span class="unit">dollars</span>
		</abbr>?
	</span>
	<span class="money">
		It was worth 
		<abbr class="amount" title="0.5">50</abbr> 
		<abbr class="currency" title="GBP">
			<span class="unit">pence</span>.
		</abbr>
	</span>

(note, in the above, that "unit" does not relate directly to the amount in the amount's title abttibute - it's 0.5 pounds, not 0.5 pence.)

	<span class="money">In 
		<span class="year">1857</span>
		 a Dickens novel cost
		<abbr class="amount" title="0.05">1</abbr>
		<abbr class="currency" title="GBP">
			<abbr class="symbol unit" title="shilling">/</abbr>
		</abbr>
	</span>

(The above might be rendered as "... 1/ (worth £4.50 in modern terms" (or whatever the value would be).)

<span class="money">
	<abbr class="amount" title="14.32">
		<abbr class="currency" title="GBP">
			<abbr class="symbol" title="pound">£</abbr>14 
		</abbr>
			6<abbr class="unit" title="shilling">s</abbr> 
			4<abbr class="unit" title="old-penny">d</abbr>
	</abbr>
</span>
	<span class="money">
		<abbr class="equivalence" title="EUR">
			<abbr class="currency" title="FFR">10</abbr>
		</abbr>
	</span>

The following, simplified for clarity, from [1]:

    On
    <span class="currency">
	<abbr class=date" title="1922-08-01>August 1</abbr>, 
	the US Dollar still stood at 
	<span class="value">643</span> 
	<abbr class="type="GDM">Marks</abbr>
    </span>
    to the Dollar. But on 
    <span class="currency">
	<abbr class=date" title="1922-09-05>September 5</abbr> 
	the dollar had already risen to 
	<span class="value">1,440</span> 
	<abbr class="type="GDM">Marks</abbr></span>
    </span>

Is there anything sensible which can't be done with the above?

Assumptions
  • Working out values in secondary currencies is a (real-time or daily) job for server-side scripting or user agents.
  • If "£" is an abbreviation, then its title is "pounds sterling"; though note that "£5" is pronounced as "five pounds sterling" (commonly just "five pounds") and not: "pounds sterling five" in the same way that "$5" is pronounced as: "five dollars" and not "dollars five"
Issues
  • There will be complications where the entire currency has disappeared, (such as the last example; French Francs into Euros).
  • Where no symbol or unit is involved (chiefly in tables, where they will be in the header cell), should we allow:
	<tr>
		<th>Spaghetti-knitter</th>
		<td class="money USD amount">42.67</span></td>
	</tr>

HTML Entities

  • The following currency entities exist:
    • ¤ - & curren; - currency
    • ¢ - & cent; - cent
    • £ - & pound; - pound
    • ¥ - & yen; - yen
    • - & euro; - Euro

Guillaume Lebleu

In the context of a hListing's price, without a unit:

<span class="price"><abbr class="currency" title="EUR">€</abbr>100</span>

Rendered view:

100

In the context of a hListing's price, with a unit:

<span class="price currencyamount"><abbr class="currency" title="USD">$</abbv><span 
class="amount">25</span> <span class="unit" title="BLL">per 
barrel</span></span>
<span class="price currencyamount"><span class="amount">25</span> <abbr class="currency" 
title="USD">$</abbr><abbr class="unit" title="BLL">/bbl</abbr></span>

Note: the class "amount" may not always be required, but it is useful when the amount is represented as text, or when the amount is mixed within text. See historical example below.

Rendered view:

$25 per barrel

25 $/bbl

Outside of the context of a hListing (not all currency amounts are prices, for instance sales numbers):

<span class="currencyamount"><abbr class="currency" title="EUR">€</abbr>100</span>

Historical price (here currency rate):

<span class="price currencyamount">On <abbr class="datetime" 
title="1998-03-12T08:30:00-05:00">August 1</abbr>, the US Dollar still 
stood at <span class="amount">643 <abbr class="currency" 
title="DEM">Marks</abbr></span> to the <span class="unit currency" 
title="USD">Dollar</span>.</span>

In a table:

<table>
   <tr>
      <th class="currencyamount price">Price (<abbr class="currency" title="CAD">C$</abbr>)</th>  
   </tr>
   <tr>
      <td>100</td>
   </tr>
</table>

Rendered view:

Price (C$)
100

Gary Jones

<span class="currency">
   <abbr class="type" title="CAD">$</abbr>
   <span class="value">5.00</span>
</span>

Renders as:

$5.00

If the formatting of a currency is such that the type symbol comes after the value, then simply swap the order of the elements containing the type and value classes.

I do think that the use of "type" and "value" classes would be better than variations of "currency_symbol" and "amount". It follows the same principles as some other elemental formats (value excerpting), meaning it's easier to remember and implement, and even ISO4217 has codes for "currencies" that don't use symbols:

<span class="currency">
   <span class="value">23</span> ounces of
   <abbr class="type" title="XAG">gold</abbr>
</span>

Renders as:

23 ounces of gold

Following on from this, the use of a "money" class should not be used; currency does not have to be money, and having a "metal" class starts to make it convoluted. Currency is the parent of money, not the other way around.

Mike Schinkel

I'm taking Andy Mabbett's post and applying my thoughts to his.

Rather than:

	<span class="money">A widget costs 
		<abbr class="currency symbol" title="USD">$</abbr>
		<span class="amount">12.57</span>
	</span>

Why not just:

	A widget costs <span class="currency" title="USD">$12.57</span>

In the above, a number is assumed because their is not an "amount", and the number digit is the currency symbol. I guess what I'm saying is if there is a number in the HTML and it is the correct number (which I think will be the 80 percentile case, give or take, then why require additional markup for it?)

Rather than:

	<tr>
		<th>Spaghetti-knitter</th>
		<td class="money">
			<abbr class="currency" title="USD">
				<span class="amount">42.67</span>
			</abbr>
		</td>
	</tr>

Just:

	<tr>
		<th>Spaghetti-knitter</th>
		<td class="currency" title="USD">42.67</td>
	</tr>

Or:

	<tr>
		<th>Spaghetti-knitter</th>
		<td>
			<span class="currency" title="USD">42.67</span>
		</td>
	</tr>

In this case, which is a little more complicated:

	<span class="money">
	Can you spare
		<abbr class="amount" title="10">ten</abbr>
		<abbr class="currency" title="USD">
			<span class="unit">dollars</span>
		</abbr>?
	</span>

Why not use the following:

	Can you spare
	<span class="currency" title="USD">
		<abbr class="amount" title="10">ten</abbr>
		<span class="unit">dollars</span>
	</span>?

Here:

	<span class="money">
		It was worth 
		<abbr class="amount" title="0.5">50</abbr> 
		<abbr class="currency" title="GBP">
			<span class="unit">pence</span>.
		</abbr>
	</span>

Why not?

	It was worth 
	<span class="currency" title="GBP">
		<abbr class="amount" title="0.5">50</abbr>
		<span class="unit">pence</span>
	</span>?

I'm not going to try to mark up the following two since, thus far, no one has voted for dated money amounts or non-numerical representations (those might be better expressed in their own microformat: hHistoricalCurrency?):

	<span class="money">In 
		<span class="year">1857</span>
		 a Dickens novel cost
		<abbr class="amount" title="0.05">1</abbr>
		<abbr class="currency" title="GBP">
			<abbr class="symbol unit" title="shilling">/</abbr>
		</abbr>
	</span>


<span class="money">
	<abbr class="amount" title="14.32">
		<abbr class="currency" title="GBP">
			<abbr class="symbol" title="pound">£</abbr>14 
		</abbr>
			6<abbr class="unit" title="shilling">s</abbr> 
			4<abbr class="unit" title="old-penny">d</abbr>
	</abbr>
</span>

I don't understand what this is trying to accomplish (it seems incomplete), so I can't mark it up.

	<span class="money">
		<abbr class="equivalence" title="EUR">
			<abbr class="currency" title="FFR">10</abbr>
		</abbr>
	</span>

Again, I'm not going to try to mark up given the lack of interest in dated money amounts:

    On
    <span class="currency">
	<abbr class=date" title="1922-08-01>August 1</abbr>, 
	the US Dollar still stood at 
	<span class="value">643</span> 
	<abbr class="type="GDM">Marks</abbr>
    </span>
    to the Dollar. But on 
    <span class="currency">
	<abbr class=date" title="1922-09-05>September 5</abbr> 
	the dollar had already risen to 
	<span class="value">1,440</span> 
	<abbr class="type="GDM">Marks</abbr></span>
    </span>

My efforts attempt to minimize the disruption in the HTML file and only use additional markup when absolutely required. I believe some high volume websites still try to minimize the markup they serve, and this is bloated as it it. They may decide just to serve up a few digits rather than 50 character per price, especially on pages with lots of prices.

Taylor Cowan

Pretending to forget all that we've know up till now about microformats, what if we just wanted a way for web page designers to make their currency amounts unambiguous with respect to currency denomination and amount?

"one hundred bucks"

<abbr class="currency" title="USD100">one hundred bucks</abbr>

$100 (CAD)

<abbr class="currency" title="CAD100">$100</abbr>

10 cents

<abbr class="currency" title="USD0.10">ten cents</abbr>

compare:

<span class="hmoney">10 <abbr class="unit" title="cent"><abbr 
class="currency" title="USD">cents</abbr></abbr></span>

man Yen

<abbr class="currency" title="JPY10,000">man Yen</abbr>

So within the title, we've got ISO###.##

Then later on we wanted to apply one of those amounts to the "price" of an hListing:

<abbr class="currency price" title="USD100">one hundred bucks</abbr>

Straw man

Based on Taylor Cowan's suggestion, above, and on subsequent mailing list discussion, the following "money" microformat straw man is proposed:

        <span class="hmoney">
          [value]
        </span>

        <abbr class="hmoney" title="[value]">
          [text]
        </abbr>

Where "value" is a number+ISO-code pair ("GBP5", "4 USD") using ISO curency codes and where parsers must accept the formats:

  • [currency-code][number]
  • [currency-code][space][number]
  • [number][currency-code]
  • [number]space[currency-code]

and where dated money amounts are included in an hCalendar:

    <div class="vevent">
      <span class="description">
        <span class="summary">
          The last Monet painting to be auctioned
        </span>
        fetched
        <abbr class="currency" title="USD95M">$95 million</abbr>
        in
        <span class="dtstart>2005</span>
      </span>
    </div>

Further comment is invited. A test page is available, at http://www.westmidlandbirdclub.com/test/money.htm

Notes

This works for sub-divisions of currencies:

        <abbr class="currency" title="USD 0.05">
          5c
        </abbr>

archaic and non-decimal currencies:

        <abbr class="currency" title="GBP 0.125">two shillings and sixpence</abbr>

        <abbr class="currency" title="GBP1.05">a guinea</abbr>

and slang:

        <abbr class="currency" title="USD 500">five-hundred buckaroos</abbr>

        <abbr class="currency" title="USD200">a couple Franklins</abbr>

Issues

  • Is hmoney the appropriate class-name?
    • hcurrency would be better. MaxwellTerry 19:59, 13 Jan 2008 (PST)
  • Is money a separate microformat, or a measurement, with the ISO currency code as the unit-code?
    • Currency != money; Currency is a superset / parent of money. If we're using ISO codes, then we should be focusing on the currency (not money) it applies to. Gazza 18:48, 7 Jan 2008 (PST)
  • This is still susceptible to the accessibility-issues#abbr-design-pattern.
  • Using amount suffixes such as K, M, B, or T are not necessarily supported by any International Standard. Shouldn't we just say that the complete number should be used in the <abbr> element? ManuSporny 12:31, 5 Oct 2007 (PDT)

Suggested amendments

  • Use just the abbr pattern and format [number]space[currency-code]. We should narrow our focus to make progress. Simplify, simplify, simplify! ManuSporny 07:16, 5 Oct 2007 (PDT)
    • Is this approach too inflexible?
    • "5 GBP" is not an abbreviation of "5 GBP". Andy Mabbett 09:46, 5 Oct 2007 (PDT)
      • This problem is easily fixed by using
        <span class="hcurrency">5 GBP</span>
        ManuSporny 11:52, 5 Oct 2007 (PDT)
    • People publish amounts as, say, "5GBP" (with no space) in the wild. Andy Mabbett 09:49, 5 Oct 2007 (PDT)
      • Yes, they do, however we can still mark that up as
        <abbr class="hcurrency" title="5 GBP">5GBP</abbr>
        . You could argue that "5 GBP" is not an abbreviation of "5GBP", which is true - but I believe this is an acceptable compromise, afterall... we would be arguing over a single space character, which seems a bit pedantic. ManuSporny 11:52, 5 Oct 2007 (PDT)

References

Related pages