[whatwg] Status bars and progress indicators

Matthew Thomas wrote:
> 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.

    The fact that WHAT WG even exists undermines this argument. Clearly,
there is demand for new features and markup to improve the basic
capabilities of web applications. The problem is not that you can't make
web applications. The problem is that web applications should not be
limited to what you can do in HTML4.

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

    Which begs the question: "Why can't we have signed HTML-based web
applications?"

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

    As opposed to the author having to wonder how each UA is going to
parse the child text. Or were we going to define in detail how to parse
the text?

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

    Please provide a link and some details, as I am not entirely sure 
what you mean. What I was able to find of <scale> was significantly more 
complicated than <input type="range">.

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

    Both spellings are correct, according to
http://dictionary.reference.com. What do you find so compelling about
the longer, less phonetic spelling?

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

<gage><img src="fourteen_percent.gif"></gage>
<gage>14 x 1/100</gage>
<gage>Points (Max. 100): 14</gage>
<gage>14 Percentile</gage>
<gage>[*******                                    ]</gage>

    Why waste time creating rules for a parser to address all this when 
we can stick in one attribute to solve this. Browsers are already set up 
to read percents from attributes. Why complicate the browser's HTML 
parsing with something like this?

Received on Wednesday, 22 September 2004 18:55:28 UTC