Re: [whatwg] draft

[fantasai]

Ian Hickson wrote:


On Tue, 28 Mar 2006, fantasai wrote:

Another issue is the possible use of U+2212 MINUS SIGN intead of U+002D 
HYPHEN-MINUS. This last, at least, should be handled whenever the number 
is parsed from the text content rather than in an attribute.


In the text, negative numbers aren't supported (if you use the fallback to 
source the numbers, the minimum is fixed to 0 and the maximum must be 
greater).


Not for progress, but for , you should be able to.

# Note: The meter element should not be used to indicate progress (as in a
# progress bar). For that role, HTML provides a separate progress  element.

I think this should be normative.

~fantasai

Re: [whatwg] draft

[Martin Atkins]

Ric Hardacre wrote:
> 
> i think it best to un-link the content and value as we cant predict all
> possible use cases, this
> 
> 48%
> 
> is a simple use case, where the content and value are obviously linked
> but this is not:
> 
> Uploading File
> 400k / 16,000k
> 

I agree with this.

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.

It also simplifies the model:
* Ignore content completely.
* Mirror the content of the value attribute into the value JS property
and vice-versa.

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.

Re: [whatwg] draft

[Ian Hickson]

On Tue, 28 Mar 2006, James Graham wrote:
> 
> AFAICT, the design without a value attribute rocks. If only the whole 
> spec could make fallbak content such an integral part of the design...

Heh.


On Tue, 28 Mar 2006, Michel Fortin wrote:
>
> The attribute may be of a standardized format, but the content ought to 
> be localizable, shouldn't it?
> 
> If so, number formats varies around the world, how should these be 
> handled?
> 
> 12.20 / 3,000.00
> 12,20 / 3 000,00
> 12,20 / 3.000,00
> 
> I don't think it is possible to extract localized numbers reliably 
> without knowing the locale first, and you may not want the browser 
> trying to be that *clever* either.

In all of the cases above, beter would display "0", because none of them 
have exactly two numbers. And it just struck me that in fact the other 
example that I replied to would also show zero if you removed the 
attribute.

You are correct that if you localise the string to a non-technical syntax 
(i.e. a syntax that doesn't match "[0-9](.[0-9])?"), it will need the 
attribute to work correctly.


> All this means that if someone relies on setting the content in a web 
> application to set the value and maximum, when later the application is 
> internationalized the meter will misbehave until you add the attribute. 
> It will misbehave but only when having thousand separators or decimal 
> values -- any such error may be left unnoticed easily.

That's a fair point. 


On Tue, 28 Mar 2006, fantasai wrote:
> 
> Another issue is the possible use of U+2212 MINUS SIGN intead of U+002D 
> HYPHEN-MINUS. This last, at least, should be handled whenever the number 
> is parsed from the text content rather than in an attribute.

In the text, negative numbers aren't supported (if you use the fallback to 
source the numbers, the minimum is fixed to 0 and the maximum must be 
greater).

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

Re: [whatwg] draft

[fantasai]

mozer wrote:

Hello
 
I18N Matter for Progress:
 
In Step for finding one or two number

It's only look for 0-9 number.

So what about number in other languages ?
 
So why not forcing use of m element for numbers
 
30 out of 45
 
in that case m has to be a number in whatever encoding even in RTL it 
will be parsable


RTL languages are encoded logically, just like LTR languages. What
appears *first* is first, not what appears to the *left*. Numbers are
always LTR. I don't think there's any issue wrt bidi.

Numbers in other languages could be an issue. I don't expect to see
e.g. Chinese numbers in a progress meter or gauge--they use Western-style
digits for calculations and such--but I wouldn't be surprised to see Arabic
use its own numbering system.

Another i18n issue is commas vs. periods as the decimal point.

A typographical issue is the use of punctuation or spaces as the thousands
separator.

Another issue is the possible use of U+2212 MINUS SIGN intead of U+002D
HYPHEN-MINUS. This last, at least, should be handled whenever the number
is parsed from the text content rather than in an attribute.

~fantasai

Re: [whatwg] draft

[Michel Fortin]

Le 2006-03-28 à 16:07, Ian Hickson a écrit :


Currently, this:

   400k / 16,000k

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

   400k / 16,000k

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


The attribute may be of a standardized format, but the content ought  
to be localizable, shouldn't it?


If so, number formats varies around the world, how should these be  
handled?


12.20 / 3,000.00
12,20 / 3 000,00
12,20 / 3.000,00

I don't think it is possible to extract localized numbers reliably  
without knowing the locale first, and you may not want the browser  
trying to be that *clever* either.


See  for some more  
formats.


All this means that if someone relies on setting the content in a web  
application to set the value and maximum, when later the application  
is internationalized the meter will misbehave until you add the  
attribute. It will misbehave but only when having thousand separators  
or decimal values -- any such error may be left unnoticed easily.



Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/

Re: [whatwg] draft

[James Graham]

Ian Hickson wrote:

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


AFAICT, the design without a value attribute rocks. If only the whole 
spec could make fallbak content such an integral part of the design...

Re: [whatwg] 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
> 
> 48%
> 
> is a simple use case, where the content and value are obviously linked 
> but this is not:
> 
> Uploading File
> 400k / 16,000k

Did you actually mean 0.25?

Currently, this:

   400k / 16,000k

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

   400k / 16,000k

...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
> 
> Uploading File
> 
> 
> ...
> 
> 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 (), 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,  will have an animated appearance by 
> > default;  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 attribute
> is omitted, then user agents must also parse the
> textContent  of
> the progress element
> in question using the steps
> for finding one or two numbers in a
> string.
> 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 m element for numbers
> 
> 30 out of 45
> 
> 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  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 see

Re: [whatwg] draft

[Matthew Paul Thomas]

On Mar 29, 2006, at 12:02 AM, Ric Hardacre wrote:


Matthew Paul Thomas 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,  will have an animated appearance by  
default;  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?

...


No, I mean all of them. For example:
*   
implemented as 
*



--
Matthew Paul Thomas
http://mpt.net.nz/

Re: [whatwg] draft

[mozer]

Hello
 
I18N Matter for Progress:
 
The spec says :
"If the value attribute is omitted, then user agents must also parse the 
textContent of the 
progress element in question using the steps for finding one or two numbers in a string
. 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 ? 
So why not forcing use of m element for numbers
 
30 out of 45
 
in that case m has to be a number in whatever encoding even in RTL it will be parsable
 
Mohamed

Re: [whatwg] draft

[Ric Hardacre]

Matthew Paul Thomas wrote:

On Mar 28, 2006, at 9:05 PM, Ric Hardacre wrote:


Ian Hickson wrote:
...
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.

...


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,  will have an animated appearance by 
default;  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?

Re: [whatwg] draft

[Matthew Paul Thomas]

On Mar 28, 2006, at 9:05 PM, Ric Hardacre wrote:


Ian Hickson wrote:
...
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.

...


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,  will have an animated appearance by 
default;  will not.


--
Matthew Paul Thomas
http://mpt.net.nz/

Re: [whatwg] draft

[Alexey Feldgendler]

On Tue, 28 Mar 2006 17:49:15 +0800, Simon Pieters <[EMAIL PROTECTED]>  
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:


  12% of 250 MB 


I think CSS is more appropriate for this task than an empty  with  
text outside.



-- Opera M2 9.0 TP2 on Debian Linux 2.6.12-1-k7
* Origin: X-Man's Station at SW-Soft, Inc. [ICQ: 115226275]  
<[EMAIL PROTECTED]>

Re: [whatwg] draft

[Simon Pieters]

Hi,

From: Ian Hickson <[EMAIL PROTECTED]>

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'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:


 12% of 250 MB 

Regards,
Simon Pieters

Re: [whatwg] 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


48%

is a simple use case, where the content and value are obviously linked 
but this is not:


Uploading File
400k / 16,000k

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

Uploading File


...

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 (), 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/

Re: [whatwg] draft

[Ian Hickson]

Based on everyone's feedback, I've removed the ability to use "%" in 
value="" attribute values for  and . 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:

   5%


On Sun, 26 Mar 2006, Matthew Raymond wrote:
> 
> Actually, assuming  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  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:
> > 
> >
> > 
> > ...instead of either of these:
> > 
> >
> >5%
> > 
> > ...?
> 
> 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.
> 
> | Pages Translated: 43 of 58.

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

   Pages Translated: 43 of 58.

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

   Pages Translated: 43 of 58.

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


>  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: 
> 
> Cloud Cover: 
> 
> Download Progress: 
> 
> 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 i

Re: [whatwg] draft

[Ric Hardacre]

Michael 'Ratt' Iannarelli wrote:

edited:

Disk Quota: 45%
Cloud Cover: 45%
Download Progress: 45%

pedantically added the enclosed 45% text for non-supporting UAs.

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   could 
direct the user agent to display a progress-style bar when someTask is 
initiated.


One element to implement as opposed to two.


+1

if the  tag defaults to min="0" max="1" and value="0" with no 
high,low or optimum then it would certainly look and act the same as a 
progress bar.  would therefore appear to be a special case

of meter.

so the question is: is the relationship as  is to 
? or is it more like  vs ? (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.


but as with  vs  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.



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