RE: <progress> element and attributes vs. content

On Mon, 24 Aug 2009, Adrian Bateman wrote:
> On Monday, August 24, 2009 5:29 PM, Ian Hickson wrote:
> > 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>
> [...]
> > 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>
> [...]
> > 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:
> > > A large difference here is that the text content is used and updated by
> > > the browser. Some users will naively 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.
> 
> The issue I see is that many of these clarifications require adding the
> attributes anyway. A content parsing algorithm that works mostly for
> simple cases is one that is going to be a source of bugs to web
> developers. Having content parsing in the spec adds to spec complexity,
> adds to implementation complexity, and adds to what web developers need
> to understand. I don't think this extra complexity is worth the cost
> compared to supporting only the attributes which are simple, predictable,
> and mirror the programming model used for this type of control on other
> platforms.

I would agree with you, except that I think in this case the simple case 
is more than even the vaunted 80% -- I think almost all uses of <progress> 
are going to be something really simple like an integer percentage.

Also, it's worth remembering that it's only a fallback for legacy UAs -- 
and a fallback for legacy UAs for which scripted alternatives aren't being 
provided, at that. Thus, it's probably not a big deal to just give 
non-prettified numbers (e.g. "2492 of 191001 bytes downloaded").


On Mon, 24 Aug 2009, Adrian Bateman wrote:
> On Monday, August 24, 2009 4:47 PM, Ian Hickson wrote:
> > On Fri, 14 Aug 2009, Tab Atkins Jr. wrote:
> > >
> > > Agreed precisely; the content parsing is both useful (in that we 
> > > only have to specify things once, visible vs invisible metadata and 
> > > all that) and just plain cool.  ^_^
> > >
> > > Removing it would immediately kill a lot of the appeal of the 
> > > element, and almost certainly end up with more people *only* 
> > > updating the attributes and letting the content drift out of sync 
> > > (once <progress> starts getting UA support, that is).
> > 
> > Ok. Left it in. Thanks.
> 
> Is there any data that suggests that not having a content parsing 
> feature that supports simple content really kills the appeal of a 
> progress control?

It was suggested that there was anecdotal evidence that authors like the 
fallback (cheers at presentations), but I don't know that we have any 
better data than that.


> In contrast, there are plenty of progress controls on other platforms 
> that don't have this feature and they do get used.

This "feature" is ease of migration from one version to another -- and 
lots of successful platforms, like Win32 and .NET, have had entire 
strategies based around providing such migration paths.


> In addition, as I mentioned previously, it is common for people to show 
> a progress control and also update text. This doesn't seem like an 
> impractical burden on developers.

Indeed, it's not impractical to update the progress twice. In fact, this 
doesn't even make that unnecessary -- in the case where you want to show 
progress _and_ the progress bar, you can't use the feature being 
described here anyway. This feature is only about providing fallback and a 
progress bar at the same time.

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

Received on Monday, 31 August 2009 06:32:44 UTC