[whatwg] <progress> draft

[Ian Hickson]

On Tue, 28 Mar 2006, Ric Hardacre wrote:
> 
> i think it best to un-link the content and value as we cant predict all
> possible use cases, this
> 
> <meter value="0.48">48%</meter>
> 
> is a simple use case, where the content and value are obviously linked 
> but this is not:
> 
> <h4>Uploading File</h4>
> <meter value="0.25">400k / 16,000k</meter>

Did you actually mean 0.25?

Currently, this:

   <meter value="0.25">400k / 16,000k</meter>

...will show a 25% meter, and this:

   <meter>400k / 16,000k</meter>

...will show a 2.5% meter.

Assuming you meant 2.5%, I think that's a great example of why in fact not 
requiring the attribute is a good thing.


> now, the author could well be specifying min/max but if the file size is 
> not known until the script is run then their javascript may look 
> something like
> 
> <h4>Uploading File</h4>
> <meter id="themeter"></meter>
> 
> ...
> 
> eMeter.value = fUploaded / fTotal;
> eMeter.innerHTML = fUploaded + "k / " + fTotal + "k";

The way the spec is defined now, you don't even need to update .value. You 
can just update .textContent and that's enough to make it work.


> > > 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".
>
> which is laudable, and makes sense, but each will be updatable on the 
> fly. a meter has to have this ability, e.g. allowing CNN to show the 
> election votes cast on their home page, updated asynchronously. and with 
> that ability will come authors who use one exclusively, merely applying 
> style sheet rules (<meter class="votes">), or use either in place of the 
> other ad hoc, depending on their styling rules. thus there's no way that 
> a UA can be forced to show that a progress indicator is, indeed, 
> progressing.

Sure. But at least if authors want to do the right thing, they can, which 
they couldn't if we only provided one element.


On Tue, 28 Mar 2006, Ric Hardacre wrote:
> > 
> > Sure, but they have different meanings. Progress bars are intended to 
> > reach 100% unless cancelled; vote counts are not. In Mac OS, and many 
> > Gnome and KDE themes, <progress> will have an animated appearance by 
> > default; <meter> will not.
> 
> you mean the progress bars that just show a bar bouncing back and forth 
> or scrolling across and therefore not actually showing the amount of 
> progress?

Those are indeterminate progress bars, also supported by the current 
spec. But mpt didn't mean that; in Mac OS X, the progress bars have a 
subtly animated texture that indicates the direction of progress.


On Tue, 28 Mar 2006, mozer wrote:
> 
> I18N Matter for Progress:
> 
> The spec says :
> "If the value <http://whatwg.org/specs/web-apps/current-work/#value4>attribute
> is omitted, then user agents must also parse the
> textContent <http://whatwg.org/specs/web-apps/current-work/#textcontent0> of
> the progress <http://whatwg.org/specs/web-apps/current-work/#progress0>element
> in question using the steps
> for finding one or two numbers in a
> string<http://whatwg.org/specs/web-apps/current-work/#steps>.
> These steps will return nothing, one number, one number with a denominator
> punctuation character, or two numbers."
> 
> In Step for finding one or two number
> It's only look for 0-9 number.
> 
> So what about number in other languages ?

Most languages use 0-9. In fact I'm not aware of any that actually use 
other digits to report progress. However, my experience is limited. Could 
you point me to example sites that use other numbers to show progress or 
to show a meter level or report a measurement?


> So why not forcing use of <code>m</code> element for numbers
> 
> <progress><m>30</m> out of <m>45</m></progress>
> 
> in that case m has to be a number in whatever encoding even in RTL it 
> will be parsable

As currently defined, RTL actually works. I don't want to force the user 
of an element if it isn't required. (You can use an element, though, 
indeed one of the examples uses a <span> element like that.)


On Tue, 28 Mar 2006, Martin Atkins wrote:
> 
> Having the content be purely fullback, disregarded by a supporting UA, 
> means that there is the possibility for including some non-percentage 
> that is more useful when the information is presented in textual form.

Well, if you provide the value="" attribute, the content just gets 
ignored, so that's already supported.


> This seems like another situation where there needs to be only one, 
> obvious way to do it. Aside from anything else, it makes it much easier 
> to figure out how it works by reading examples if all of the examples do 
> the same thing.

It just seems like in almost all the examples people have given so far, 
the code is simpler if you allow the fallback to trigger the value, rather 
than requiring them to be duplicated. In one example above, the 
duplication actually caused an error to creep in (25% vs 2.5%).


On Tue, 28 Mar 2006, Simon Pieters wrote:
> 
> I think it's good to have a value="" attribute, because you might want 
> to have both plain text and an indicator, as can be seen in Hotmail:
> 
>  <p>12% of 250 MB <meter value="0.12"></meter></p>

I agree we want to have the value="" attribute as well, even with text 
inside; one of the examples in the spec is something like:

   <meter value="0.5">High Activity</meter>
   <meter value="0.25">Low Activity</meter>

...where the actual values are arbitrary, and merely relative to each 
other.


On Tue, 28 Mar 2006, Alexey Feldgendler wrote:
> 
> I think CSS is more appropriate for this task than an empty <meter> with 
> text outside.

CSS could probably be used for this as well, indeed.

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