[whatwg] <progress> draft

[Ian Hickson]

Based on everyone's feedback, I've removed the ability to use "%" in 
value="" attribute values for <progress> and <meter>. This simplified the 
processing model quite a bit.

You can still use percentages (and per-mille, and so forth) if you put the 
content in-line, which is the recommended behaviour:

   <progress>5%</progress>


On Sun, 26 Mar 2006, Matthew Raymond wrote:
> 
> Actually, assuming <progress> has |min| and |max| attributes, you could 
> have defaults of |min| 0.0 (or 0%) and |max| as 1.0 or (100%). In this 
> way, you could have |max| as the number of kilobytes for a file and 
> update the value of <progress> with just the number of kilobytes 
> transferred, and the progress bar would show the fraction of |max| that 
> the value is. (Not sure we need a |min| attribute. the use case seems 
> weak.)
> 
>    With regard to "[number]%", it can simply be equal to "[number/100]".

That's basically what the spec says.


On Fri, 24 Mar 2006, Simon Pieters wrote:
> >
> > What do people think? Is it valuable to be able to do:
> > 
> >    <progress value="5%"/>
> > 
> > ...instead of either of these:
> > 
> >    <progress value="0.05"/>
> >    <progress>5%</progress>
> > 
> > ...?
> 
> No, direct relationship to the DOM makes implementation and authoring 
> more straight forward, I think. I don't see much advantage in allowing 
> different formats in the value="".

That was my conclusion too. I've gone with that.


On Fri, 24 Mar 2006, James Graham wrote:
>
> +1
> This seems to be a case where "there should be one, and preferably 
> only one, obvious way to do it" holds.

Well, there are two ways -- update the textContent, and update the 
attribute. But for the attribute, there's only one syntax. We could remove 
the attribute as well, and force authors to use textContent, though...


On Sat, 25 Mar 2006, Michael 'Ratt' Iannarelli wrote:
> 
> With the meter element I am not convinced that there is a need for a 
> progress element. Considering this definition of meter...

There is a big difference between the two. They result in drastically 
different UIs.

See, for example, this page:

   http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGControls/chapter_18_section_5.html

In HTML5 we've collapsed Relevance Indicators and Level Indicators into 
one element, but Progress Indicators are definitely in a separate class, 
IMHO. (The existance of indeterminate progress bars is another clue.)


> 1. Any of various devices designed to measure time, distance, speed, or
> intensity or indicate and record or regulate the amount or volume, as of the
> flow of a gas or an electric current.[1]
> 
> ...certainly a meter could measure progress.
> 
> |	<meter value="43" max="58">Pages Translated: 43 of 58.</meter>

(Note that as defined, the attributes aren't needed -- this:

   <meter>Pages Translated: 43 of 58.</meter>

...will work exactly the same.)


> Having two elements that represent pretty much the same thing, (a 
> progress bar is a type of meter after all), is redundant. There are 
> going to be plenty of web authors using meter for progress, (just 
> because the spec says not to ;p).

If we only provided one, we'd guarentee that authors picked the wrong one. 
At least by providing both, we can get closer to getting the right thing.


> Whether the progress element stays or goes the numeric attributes for 
> meter/progress should be purely floating point numbers. Supporting 
> denominator punctuation characters complicates.

For the attributes, I agree, and have now changed the spec.

I think it's very valuable for accessibility and fallback to provide a way 
to get the textContent to just use %s, though.


> I find processing the textContent of a meter or progress element an 
> interesting approach but to me it seems like an overly complicated way 
> to determine the values of the attributes, (much like current tag soup 
> processing). I would rather the page author either declare the 
> attributes or have the meter or progress element default to value="0" 
> and max="1".

The problem is if people do as you describe above:

   <meter value="43" max="58">Pages Translated: 43 of 58.</meter>

...and then try to update this on the fly, they'll always only update one 
of them. And this will make the fallback case get out of sync.


> I think we need a method to attach the meter (or progress should it 
> stay) element to specific tasks. (If there is one already, I missed it.) 
> Perhaps a task attribute? If the task attribute is set the element is 
> indeterminate until the data needed to establish a meter/progress bar is 
> received.

Could you expand on this?


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

That's a big difference. It means the UI for one has to show that it is 
static, and the UI for the other has to show that it should "end".


> The "how" progress will be dynamic has yet to be defined in the
> spec.

Updating the attributes or the textContent on the fly, at the moment.


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

I don't really understand how task="" would work; could you expand on 
this?


> One element to implement as opposed to two.

I think we should shy away from overloading elements -- the <input> 
element showed that overloading an element to do multiple things doesn't 
reduce the implementation complexity, it increases it.


On Sun, 26 Mar 2006, Matthew Raymond wrote:
> 
> I would agree. The <progress> element is little more than something 
> along the lines of <meter measure="progress">.

   <progress>

...seems shorter than

   <meter measure="progress">

...and I think our experience with <input type=""> should make us shy away 
from this language design style.


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

The difference is that when you pause a download, you know that if it says 
"50%" it is half-done, whereas if you have a disk gauge, 50% just means it 
is 50%, and doesn't have any particular "end state" in mind.


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

Woah. Before we go off and make a seriously powerful UI, I think we should 
study what people are actually doing on the Web! I don't see people doing 
pressure-gauge UIs, or vote-o-meter gauges. I do see people making simple 
relevance indicator gauges, reporting disk usage, and rendering dynamic 
progress meters.


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

Yeah, the Rendering section is going to be a lot of fun.


On Tue, 28 Mar 2006, Ric Hardacre wrote:
> 
> edited:
> 
> Disk Quota: <meter min="0" value="0.45" max="1">45%</meter>
> Cloud Cover: <meter min="0" value="0.45" max="1">45%</meter>
> Download Progress: <meter min="0" value="0.45" max="1">45%</meter>
> 
> pedantically added the enclosed 45% text for non-supporting UAs.

With the current spec, you can just do:

   Disk Quota: <meter>45%</meter>
   Cloud Cover: <meter>45%</meter>
   Download Progress: <meter>45%</meter>

...and it'll just work. No need for any attributes at all. :-)


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

See above. :-)


> if the <meter> tag defaults to min="0" max="1" and value="0" with no 
> high,low or optimum--

--which it does--

> --then it would certainly look and act the same as a progress bar. 

No, it wouldn't. Progress bars look nothing like gauges on modern UIs.


> so the question is: is the relationship as <input type="password"> is to 
> <input type="text">? or is it more like <b> vs <strong>? (where one is 
> purely stylable and the other has meaning). i think the former is 
> unlikely but there may be a case to be made for the latter.

I think it's more like the difference between <em> and <strong>. Similar 
-- but different -- semantics, different presentation. Easily confused, 
but that doesn't make them the same.


> but as with <b> vs <strong> the authors and hackers will abuse it, one 
> will get used in place of the other just as Michael has shown, and there 
> will be no way of running a w3c style validator to check for correct 
> usage.

If we have just one element, the situation would IMHO be worse.

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