[whatwg] Status bars and progress indicators

Matthew Thomas wrote:
> On 8 Sep, 2004, at 8:16 AM, Daniel O'Connor wrote:
>> A multi-purpose statusbar for specific controls/ collections of
>> controls would be useful imho: overriding (intercepting?) the UA's
>> statusbar for XmlHttpRequests/ transactions between the server, as
>> well as providing a useful place for feedback to a user.
> 
> "Scripts can't turn off the status bar."  
> <http://www.microsoft.com/technet/security/secnews/articles/ 
> itproviewpoint081104p2.mspx>
> 
> If a browser vendor can't trust you enough to let you turn off the  
> status bar, I doubt they'll ever trust you enough to let you replace it  
> with your own.

    The root of the problem is that if you can't use basic application 
widgets, will people even use HTML for web applications? They may just 
use Java applications, which don't have many of the mentioned 
limitations, or a combination of XAML and JScript.

    (Personally, I don't understand why they won't let programs turn off 
the status bar when the user still can. You could simply ask the user to 
hide the status bar before starting the program. Does Microsoft block 
detection of whether or not the status bar is hidden, by the way? If so, 
the application could simply refuse to run unless the user disables the 
status bar.)

> A standard <progressmeter> (or <progress>) element might be useful, so  
> that non-page progress indication can be more consistent, instead of  
> every app developer coming up with their own zany animation. For  
> backward compatibility, it could be a container element, like this:
> 
>     <progressmeter>(86 %)</progressmeter> Uploaded 46 K of 54 K
> 
> A graphical UA would take the "(86 %)", strip out the non-numeric stuff  
> (i.e. everything except the "86" and the "%"), recognize it as 0.86,  
> and replace the element with a graphical progress meter representing  
> that fraction:

    I'd prefer something like this:

<progressmeter value="86%">(86 %)</progressmeter>

    This is useful in two ways. First, it makes parsing bugs less likely 
because the browser doesn't have to process the child text. Instead, it 
simply reads a percent value into a property, which browsers have been 
able to do since the early days of browsing.

    Second, using a property to determine the value allows you to forget 
about child elements when you don't want the bar to be seen or don't 
care about graceful degradation:

<progressmeter value="86%"/>

> If such an element is introduced, a <gauge> element should be  
> introduced at exactly the same time, so that the Web doesn't fall into  
> the same trap Mac OS did when it had one but not the other, and  
> developers were confusing people by using progress indicators to  
> indicate non-progress fractions (like relevance and quota usage).
> 
>     <dt><a href="http://www.quirksmode.org/dom/webforms2.html">Web
>     Forms 2.0 - notes and comments</a></dt>
>     <dd class="uri">http://www.quirksmode.org/dom/webforms2.html</dd>
>     <dd>Relevance: <gauge>14 %</gauge></dd>
> 
> Which in a graphical UA would produce:
> 
>     _Web Forms 2.0 - notes and comments_
>         http://www.quirksmode.org/dom/webforms2.html
>         Relevance: [##:::::::::]

    This is fine, but I still feel that the child text should be for 
graceful degradation only. What happens, for instance, if the webmaster 
uses something other than a percent sign?

    <gage>14 Percent</gage>
    <gage>14 out of 100</gage>
    <gage>14 / 100</gage>
    <gage>7 / 50</gage>
    <gage>0.14</gage>

    By using |value| (or whatever name you want to use for the 
attribute), you can avoid the ambiguity:

    <gage value="14%">Fourteen Percent</gage>
    <gage value="14%">14 / 100</gage>
    <gage value="14%"/>

Received on Monday, 20 September 2004 18:55:14 UTC