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

RE: <progress> element and attributes vs. content

From: Adrian Bateman <adrianba@microsoft.com>
Date: Mon, 24 Aug 2009 17:51:55 -0700
To: Ian Hickson <ian@hixie.ch>, Tab Atkins Jr. <jackalmage@gmail.com>, "Lachlan Hunt" <lachlan.hunt@lachy.id.au>, Jonas Sicking <jonas@sicking.cc>, "Joe D Williams" <joedwil@earthlink.net>, Smylers <Smylers@stripey.com>, "John Drinkwater" <john@nextraweb.com>
CC: "public-html@w3.org" <public-html@w3.org>
Message-ID: <9EF3B2C14D3B794EB33689E0E1BDFEEA3EF9B010EC@NA-EXMSG-C120.redmond.corp.microsoft.com>
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



Received on Tuesday, 25 August 2009 00:54:24 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:50 UTC