W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2004

[whatwg] Status bars and progress indicators

From: Matthew Thomas <mpt@myrealbox.com>
Date: Tue, 21 Sep 2004 16:20:22 +1200
Message-ID: <8E115451-0B85-11D9-B3A9-000A95AD3972@myrealbox.com>
On 21 Sep, 2004, at 1:55 PM, Matthew Raymond wrote:
> ...
>> "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?

That would have been an interesting question to ask in 1989, before 
people began using HTML for Web applications despite being unable to 
use many basic GUI controls.

> They may just use Java applications, which don't have many of the 
> mentioned limitations,

Yes they do. If an unsigned applet opens a window, it has a status bar 
that cannot be turned off with the message "Warning: Applet window".

> or a combination of XAML and JScript.

Similarly, if an alert is opened via JavaScript, it is distinguished in 
some way from a native alert, though the exact distinction depends on 
the UA <https://bugzilla.mozilla.org/show_bug.cgi?id=31573>.

If XAML does not offer similar protection, Internet Explorer users will 
get hammered.

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

Which people would obey just as much as they obey all those "Best 
viewed at x * y resolution" instructions, i.e. not at all.

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

But it makes UI bugs more likely because authors have to update two 
values instead of one.

> ...
>    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%"/>

I tried that argument with <scale> earlier, and lost.

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

All those should work (assuming the "gage" misspelling was corrected), 
with the exception of "14 Percent", which I can't imagine anyone using 
instead of "14 %". The parsing is simple: if there's only one number in 
the contents, treat it as a percentage if "%" is present and as a 
decimal fraction otherwise. And if there's more than one number in the 
contents, treat the first two numbers as a fraction.

-- 
Matthew Thomas
http://mpt.net.nz/
Received on Monday, 20 September 2004 21:20:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:20 UTC