[whatwg] <progress> draft

Matthew Raymond mattraymond at earthlink.net
Sun Mar 26 20:57:37 PST 2006


Michael 'Ratt' Iannarelli wrote:
> Greetings,
> 
> Henri Sivonen wrote:
>> It isn't redundant when they are not the same thing. They are not the 
>> same thing here.
>>
>> Have you read mpt's earlier posts on the topic?
>> http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-September/002211.html 
> 
> Yes, I have read mpt's (and others') posts on this topic. I still feel 
> the progress element is redundant.
> 
> <meter min="0" value="0.45" max="1"></meter> represents some value that 
> is 45 percent of the whole. A graphical user agent is going to display a 
> bar of some length with 45 percent of that bar highlighted in some 
> fashion. It is otherwise meaningless without a label.
> 
> Disk Quota: <meter min="0" value="0.45" max="1"></meter>
> 
> Cloud Cover: <meter min="0" value="0.45" max="1"></meter>
> 
> Download Progress: <meter min="0" value="0.45" max="1"></meter>
> 
> The only difference between meter and progress is the potential for 
> progress to be dynamic. The "how" progress will be dynamic has yet to be 
> defined in the spec. If the method turns out to be as simple as setting 
> an attribute task="someTask" then <meter task="someTask"> </meter> could 
> direct the user agent to display a progress-style bar when someTask is 
> initiated.
> 
> One element to implement as opposed to two.

   I would agree. The <progress> element is little more than something
along the lines of <meter measure="progress">. Ian tries to say that a
progress bar indicates "change" rather than a "state", but a progress
bar shows the state of completion, not change. If you pause a download,
for instance, the progress bar will hold at a specific value without
changing at all. A progress bar doesn't show change any more than a
meter or gage does, and things you use a <meter> for frequently change.
In fact, AJAX applications may change <meter> values continuously.

   Personally, I think we should use something like a |measure|
attribute, where the value of the attribute is the thing the <meter>
measures. If all other attributes are at their default values, |measure|
might default to "progress". User agents could use this attribute to
determine rendering. The value "progress" would cause the element to
render as a progress bar. The value "votes" might show a localized
patriotic-style meter, and "pressure" could yield a Jules Verne-style or
steampunk gage. In this manner, we provide valuable semantic information
without requiring an element for each given measurement type, and you
can use the fallback rendering in situations with unknown values.

  Side note: I anticipate a high level of interest in the detailed
styling of <meter> using CSS. We need to go over exactly how this can be
accomplished without adding pseudo-elements specifically for meters.



More information about the whatwg mailing list