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