[uf-new] Measurement brainstorming (was: Measure & currency)
andy at pigsonthewing.org.uk
Fri Oct 5 07:03:30 PDT 2007
On Fri, October 5, 2007 14:57, Chris Newell wrote:
>> Microformats put the burden, where possible, on parsers, not
>> publishers, in order to make life as easy as possible for publishers.
> Agreed, but this is a balance. If it's hard to parse you'll get buggy
*If*; For some value of "hard to parse".
This process is about making sure that's not the case.
> for "measure" (where the unit-codes encompass all SI
> permutations etc) parsing the string to separate the value from the
> unit-code gets more tricky and potentially ambiguous. For example:
> <span class="hmeasure">2m<sup>2</sup></span>
That would be:
<abbr class="hmeasure" title="2m2">2m<sup>2</sup></abbr>
using "m2", or whatever is that standard for representing square-metres.
> I guess this wouldn't be too bad if we can state that numbers within
> unit-codes are always in <sup> tags.
>>> - Users may want to style the unit-code differently from the
>>> numerical value and the separation would make this easier.
>> They are not prevented from doing so by the current proposal.
> I didn't say they were.
Then your comment appears redundant.
>>> - Users wouldn't have to remember rules about the format of the
>> What rules?
> The Strawman proposal states "where parsers must accept the formats:
"parsers" not "users".
** via webmail **
More information about the microformats-new