Re: <progress> element and attributes vs. content

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 UTC