currency-brainstorming: Difference between revisions
AndyMabbett (talk | contribs) m (→Straw man proposal: clarification) |
AndyMabbett (talk | contribs) (→Straw man proposal: Ciaran McNulty's ideas) |
||
| Line 152: | Line 152: | ||
====Straw man proposal==== | ====Straw man proposal==== | ||
(this reflects Ciaran McNulty's proposals, above) | |||
In order to use currency as a sub-class, the parent should be named 'money' | In order to use currency as a sub-class, the parent should be named 'money' | ||
Revision as of 09:49, 20 September 2006
Brainstorming
Brainstorming for the proposed currency microformat.
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...
- we're talking about money - ISO standard implied,
- we're talking about the USD variety,
- we're talking fifty units of that money,
- 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.
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
It seems to me that the issues with currency (whether or not microformats are involved) are, or at least include:
- Conveying the currency of the amount. Consider:
<span class=currency-GBP>5.99</span>
[where currency-GBP could be styled in such a way that the pound-sterling symbol is prepended (or appended, according to the applicable language), in the same way that "" tags don't require separate quote marks - how would this degrade on non-CSS browsers, though?] This could equally be achieved by a pseudo (X)HTML tag:
<currency type="GBP">5.99</currency>
or some other mechanism; I'll use that pseudo-tag from now on, for illustrative purposes.
- Consider a defunct currency; one old UK Shilling (written "1/" or "1/-", the hyphen representing zero pennies; equivalent of a modern GBP 0.05):
<currency type="GBP" unit="shilling">1</currency>
- and:
<currency type="GBP" unit="old-penny">6</currency>
or:
<currency type="GBP" equivalence="0.05">1/</currency>
- and:
<currency type="GBP" equivalence="0.025">-/6</currency>
Indeed, we may wish to enable our user-agents to interpret an amount of money in modern parlance:
<currency type="GBP" unit="shilling" date="1890">1</currency>
might be interpreted as: 1/- (worth £4.50 in modern terms)
- There would be further complications where the entire currency has disappeared, (such as French Francs into Euros) rather than just the fractions of the main unit (as old English shillings/ pennies, into "new" pence):
<currency type="FFR" equivalence="EUR0/1.52">10</currency>
- Working out values in secondary currencies is a (real-time or daily) job for server-side scripting or user agents, surely?
- If "£" is an abbreviation, then its title is "pounds sterling"; though note that "£5" is pronounced as "five pounds sterling" and not: "pounds sterling five" in the same way that "$5" is pronounced as: "five dollars" and not "dollars five"
Straw man proposal
(this reflects Ciaran McNulty's proposals, above)
In order to use currency as a sub-class, the parent should be named 'money'
money
- currency - class (required)
- amount - class (required)
- year - class (optional - for historic values only)
- symbol - class (optional - so that we know whether the symbol is present; or whether it needs to be generated by the user agent)
- equivalence - class (optional; conversion should be done by the user agent Do we need this? Does it need a numeric value?)
- unit - class (subdivison of currency)
Thus:
<span class="money">A widget costs <span class="USD symbol">$</span> <span class="amount">12.57</span> </span>
<tr> <th>Spaghetti-knitter</th> <td class="money"> <span class="USD"> <span class="amount">42.67</span> </span> </td> </tr>
<span class="money">In <span class="year">1857</span> a Dickens novel cost <abbr class="amount" title=0.05>1</abbr> <span class="GBP"> <abbr class="unit" title="shilling">/</abbr> </span> </span>
<span class="money"> <abbr class="equivalence" title="EUR"> <span class="FFR">10</span> </abbr> </span>
Is there anything sensible which can't be done with the above?