[whatwg] Status bars and progress indicators

On 23 Sep, 2004, at 1:55 PM, Matthew Raymond wrote:
> ...
>>>    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.

Not really, because What-WG didn't exist in 1989, or even 1999, and  
people continued creating Web applications regardless.

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

That's great, but it's nothing to do with whether or not people will  
"even use HTML for web applications". UAs need not make their  
interfaces completely molestable in order to attract application  
authors. And some interface restrictions are necessary, and probably  
will always be necessary, in order to countervail the increased  
likelihood of people running code that they have not properly  
considered.

(This is nothing particularly shocking. Microsoft have been decreasing  
the extent to which the interface of Internet Explorer can be subverted  
since version 5.5 SP1 four years ago.)

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

You can: serve them over HTTPS. But whether you sign your applications  
that way or any future HTML-specific way, it is my personal opinion  
that signatures would be a lousy way of offering security. People would  
repeatedly be interrupted by an unpalatable choice between running an  
application in low-security mode or not being able to run it at all.  
And they would have scant evidence on which to make that choice even if  
they bothered thinking about it.

(Related: <http://mpt.phrasewise.com/2003/11/11>.)

>> ...
>>> <progressmeter value="86%">(86 %)</progressmeter>
> ...
>    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?

That could be specified if necessary. It took me only two sentences  
below.

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

Apologies: I was thinking of my alternative <datepicker> syntax.  
<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-July/ 
000875.html> There as here, it would be hard for authors to test that  
they'd done the fallback correctly, so they'd be more likely not to  
bother even when they should.

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

I had never encountered any other spelling. Thanks.

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

Invalid: you're missing alt=, which should contain the value in  
parseable format otherwise it'll be inaccessible. Well done for  
requiring a clarification of "in the contents", though: "in the  
contents (including any alternate text of child elements)". (Example  
#4792 of why alt= shouldn't have been an attribute in the first place.)

> <gage>14 x 1/100</gage>

Fails the laugh test.

> <gage>Points (Max. 100): 14</gage>

That wouldn't work, but it'd be immediately obvious that it wasn't  
going to work as soon as the author viewed the page.

> <gage>14 Percentile</gage>

Ditto. (And all the uses of "percentile" I've ever seen have been too  
important to hide inside a gauge in the first place, e.g. ranking of  
schools where people get fussed about the last percentage point.)

> <gage>[*******                                    ]</gage>

Inaccessible. (Wow, I had no idea my syntax was going to be so good at  
encouraging accessible markup.)

>    Why waste time creating rules for a parser to address all this when  
> we can stick in one attribute to solve this.
> ...

For reliable backward compatibility.

-- 
Matthew Thomas
http://mpt.net.nz/

Received on Thursday, 23 September 2004 05:37:36 UTC