[whatwg] <progress> draft

[Ric Hardacre]

Ian Hickson wrote:

[snip]

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

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>

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";



depending on if styling rules allow the value and content to both be 
rendered, or maybe the author is conscious of allowing the progress
to be shown on different target devices.

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



Ric Hardacre
http://www.cyclomedia.co.uk/