Re: <progress> element and attributes vs. content

On Fri, 14 Aug 2009, Adrian Bateman wrote:
> 
> Is the progress element intended to draw a control and also show the 
> contained text? I presume not.

Correct.


> We often see the Windows progress/activity bar annotated with a 
> percentage shown as text and I suspect developers will want to achieve 
> something similar on the web.
> If the progress element doesn't draw the contained text then web 
> developers may often want the value in mark-up after the element. They 
> will then have to deal with the case when the browser doesn't support 
> the progress element, is showing the contents as fall-back text, and 
> they don't want the text to display twice. I'm also concerned about how 
> fragile the content parsing rules may turn out to be in practice.

They can do this by using the attributes.


> I agree with Henri - I would also prefer to remove the content parsing 
> and have the display based only on the attributes. I think the notion of 
> only updating the content is a nice idea but may actually make things 
> more complex in practice. If the progress element only depends upon the 
> attributes, web developers can decide whether the control is just 
> providing extra information (where it doesn't require any fall-back 
> text) or whether then need to include fall-back. They can also decide 
> whether they want the fall-back text to update with the progress 
> control.
> 
> For example:
> 
> <div><progress value="10" max="100"></progress> 10% complete</div>
> 
> or
> 
> <div><progress value="10" max="100">10%</progress></div>

They can do that now too -- all of these work:

  <div><progress value="10" max="100"></progress> 10% complete</div>
  <div><progress value="10" max="100">10%</progress></div>
  <div><progress>10%</progress></div>


On Fri, 14 Aug 2009, Tab Atkins Jr. wrote:
> On Fri, Aug 14, 2009 at 12:51 PM, Adrian Bateman<adrianba@microsoft.com> wrote:
> > On Friday, August 14, 2009 10:46 AM, Tab Atkins Jr. wrote:
> >> On Fri, Aug 14, 2009 at 12:29 PM, Adrian Bateman<adrianba@microsoft.com>
> >> wrote:
> >> > I'm also concerned about how fragile the content parsing rules may 
> >> > turn out to be in practice.
> >
> >> This is anecdotal, but to me it appears that they're rather robust, 
> >> at least for English.
> >
> > I think this is my specific concern - how well does this work 
> > internationally?
> 
> Well, it pays absolutely no attention to the language within the string.  
> The only relevant bits are that the numbers must be displayed using 
> arabic numerals [0-9], and they must be displayed without using a 
> grouping separator (all digits must be consecutive).
> 
> Someone with more internationalization experience than me (that is, 
> someone with *any* internationalization experience) can probably make a 
> better judgement on how well this would work on international text.

It works pretty well for most simple cases (integer percentages, in 
particular, are handled pretty well). For things more complicated, the 
attributes should be used -- even for English. For example:

   <progress value="12332122" max="531534217">12,332,122 of 
   531,534,217</progress>


On Fri, 14 Aug 2009, Tab Atkins Jr. wrote:
> 
> I'm wondering if it's possible to revise the algorithm to ignore 
> grouping glyphs commonly used internationally.  Even using the , as a 
> thousands separator, as is common in English, would break parsing.

This is a can of worms I'd rather not open.


On Fri, 14 Aug 2009, Jonas Sicking wrote:
> 
> However that makes something like this fun:
> 
> <progress>200 av 1,024</progress>
> 
> Is that 20% (comma interpreted as thousand separator) or is that 0.5% 
> (comma interpreted as decimal separator)?

Neither -- there are three numbers there, so the algorithm fails to find 
two numbers.


On Fri, 14 Aug 2009, Adrian Bateman wrote:
> 
> It seems unreasonable to end up with a spec that works or not depending 
> upon which language you are using. I don't think it matters which 
> language it works for; if there are common languages it doesn't work for 
> (and it seems like this is the case) then I suggest we should drop the 
> content parsing from the spec and instead rely on the attributes.

There are cases that the simple algorithm doesn't handle, in all 
languages, but as far as I can tell, the simple cases (the common cases) 
work in most if not all languages.


On Mon, 17 Aug 2009, John Drinkwater wrote:
> 
> 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.

We could indeed do this.


> 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.

I'm not convinced this is as big an issue as you describe.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'