W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: <progress> element and attributes vs. content

From: John Drinkwater <john@nextraweb.com>
Date: Mon, 17 Aug 2009 11:02:39 +0100
Message-ID: <4A892ABF.7070908@nextraweb.com>
To: "public-html@w3.org" <public-html@w3.org>
Smylers wrote:
> Tab Atkins Jr. writes:
> 
>>I would be inclined to take the English tradition (, as thousands
>>separator, . as decimal separator) as the default, as it is more
>>common on the web than the other.  Otherwise, there is *literally* no
>>way to resolve the ambiguity.
> 
> Yes there is: with commas or other punctuation characters the algorithm
> for parsing 2 numbers from a string will fail.  Displaying nothing
> (which an author is likely to notice, and which a user is less likely to
> believe as correct) is much better than displaying the wrong number.
> 
> Many uses of <progress> will involve small integers, which use neither
> decimal points nor thousands separators, or integer percentages.


This is true. If floating point number were removed from the spec 
(progress already has fine enough grain with percentages imo), the 
issue would likely go away - what would be left is the simple case 
of <progress>88%*</progress> parsing.


> Many people don't put thousands separators in numbers, especially not
> those which are only 4 or 5 digits long.
> 
> HTML mark-up itself uses a full stop for a decimal point, so authors are
> likely to be familiar with it.

A large difference here is that the text content is used and updated 
by the browser. Some users will naÔvely use their system of numbers 
and find it will not work - at which point they need an attribute, 
and a javascript shim to output correct figures - and will find the 
element isnít as useful to them as it is to the spec writers.


But still, I would prefer that the progress element didnít content 
parse, as it puts requirements on the visible data included in 
documents.


-- 
John Ď[Beta]í Drinkwater        |      john@nextraweb.com
Received on Monday, 17 August 2009 10:01:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:43 GMT