Re: [w3c/browser-payment-api] Currency Types and Rendering (#185)

@adrianhopebailie writes:
> I believe we should allow 3 letter ISO codes and URLs but then we need a way for requests where the currency is a URL to provide display hints to the browser.

Sure. And that's what @dlongley suggested up-thread: the URL can resolve to a document that describes these display hints. Because, honestly, I'm not sure "XBT" is going to mean much to most people.

This might mean defining at least a primitive (and extensible) format for that document sooner rather than later, but I think that's okay. Clearly we'll want something more advanced eventually, but I think this gets us at least to the property that you're suggesting:

```json
{
  "symbol": "BTC"
}
```

In terms of backward-compatible extensibility, a future version might expand this to look more like:

```javascript
{
  // Default Values
  "symbol": "Ƀ",
  "mantissaLength": "5",
  "position": "prefix",
  "spaceSeparator": false,

  // Locale Overrides
  "en": {
    "symbol": ["Bitcoin", "Bitcoins"], // corresponds 'en' to plural forms in Unicode CLDR
    "position": "suffix",
    "spaceSeparator": true
  },
  ...
}
```

(This is off of the top of my head, and not an polished suggestion; I just wanted to demonstrate how the format could potentially be expanded).

The one issue I see is that this gets us back to the question of who hosts format documents for currencies that may potentially be quite popular, such as Bitcoin. And that brings us back to the three-pronged approach, where we define non-URL codes for specific, well-known currencies that lack official ISO codes.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/issues/185#issuecomment-220091693