- From: James Graham <jg307@cam.ac.uk>
- Date: Thu, 23 Sep 2004 16:22:00 +0100
>> ... >> 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
Received on Thursday, 23 September 2004 08:22:00 UTC