[whatwg] Status bars and progress indicators

[James Graham]

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

I entirely agree with mpt here; advocating signing as a means of  
security is unlikely to be effective. As far as I know, all signing  
allows is that people can identify who provided an application. This  
does not provide sufficient information to allow a random end user to  
decide whether the application is to be trusted. Since the default  
behaviour of most users is to trust untrustworthy things (until  
recently, email attachments were probably the primary means of  
spreading viruses) it is clear that merely being asked if they trust a  
particular entity does not protect the user from malicious webpages.

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

The simplest definition would be to use the DOM3-defined textContent  
[1] of the <gauge> node as the string to be parsed. Having said that, I  
tend to think that authors would prefer the flexibility of having an  
attribute rather than using the contents to determine the gauge level  
that should be displayed. Experience suggests that given the choice  
between an accessible approach that doesn't meet some obscure need they  
believe they have and bad markup, authors will choose bad markup every  
time.

[1]  
http://www.w3.org/TR/2002/WD-DOM-Level-3-Core-20020409/core.html#Node3- 
textContent