Re: [whatwg] progress draft

2006-03-28 Thread 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:

   progress5%/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/
 progress5%/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=58Pages Translated: 43 of 58./meter

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

   meterPages 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=58Pages 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 

Re: [whatwg] progress draft

2006-03-28 Thread 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.4848%/meter

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


h4Uploading File/h4
meter value=0.25400k / 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

h4Uploading 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/


Re: [whatwg] progress draft

2006-03-28 Thread 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:


 p12% of 250 MB meter value=0.12/meter/p

Regards,
Simon Pieters




Re: [whatwg] progress draft

2006-03-28 Thread 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:


  p12% of 250 MB meter value=0.12/meter/p


I think CSS is more appropriate for this task than an empty meter 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] progress draft

2006-03-28 Thread 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, 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?




Re: [whatwg] progress draft

2006-03-28 Thread 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 codem/code element for numbers

progressm30/m out of m45/m/progress

in that case m has to be a numberin whatever encoding even in RTL it will be parsable

Mohamed


Re: [whatwg] progress draft

2006-03-28 Thread 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 meter, 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] progress draft

2006-03-25 Thread Henri Sivonen

On Mar 25, 2006, at 12:11, Michael 'Ratt' Iannarelli wrote:

Having two elements that represent pretty much the same thing, (a  
progress bar is a type of meter after all), is redundant.


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


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/




Re: [whatwg] progress draft

2006-03-25 Thread Michael 'Ratt' Iannarelli

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.

Just my thoughts,

Michael 'Ratt' Iannarelli




Re: [whatwg] progress draft

2006-03-24 Thread Simon Pieters

Hi,

From: Ian Hickson [EMAIL PROTECTED]

What do people think? Is it valuable to be able to do:

   progress value=5%/

...instead of either of these:

   progress value=0.05/
   progress5%/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=.


Regards,
Simon Pieters