Aryeh! You have made an ad-hominem attack: shame on you! I mention the
Microsoft use cases only to save space. There are similar cases in the
Linux and Macintosh realms. Judge an idea by its merits, not by its
source (even if that source is as disreputable as I certainly am).
You are correct that short duration time outs are, often, a terrible
idea ... but the standard should not hobble the developer. Terrible
ideas are a matter of opinion; my ideas are always grand and glorious,
never terrible ... just ask me ... for I never lie and am always right.
...and consider this: just how would you handle the case in which the
WWWeb page says:
There is an approaching storm!
Do you wish to close the dykes?
No (let everybody drown)
Yes (if you don't answer in an hour, this will be the default)
To say that the WWWeb should not be used for this is in itself a
terrible idea for you know that it will be used in this manner and
neither of us can prevent such stupidities.
By-the-Way - I advocate no change to alerts and such ... the above can
be implemented with setTimeout without any changes to existing browsers.
Best (and please understand my admonitions to be accompanied by
affection and great respect)!
BdG/WeBMartians
===
On 2011-03-01 19:46, Aryeh Gregor wrote:
On Mon, Feb 28, 2011 at 7:42 PM, Ian Hickson<[email protected]> wrote:
Well we can't remove support for them from browsers, since millions of
pages use them. Conformance checkers can't really complain about usage of
those APIs, since they can't easily check JavaScript runtime compliance.
So what would deprecating them mean?
We could define script APIs, or features of them, as deprecated if
browsers were willing to log some kind of notice to their error
consoles when the feature is used. They all have error consoles with
different reporting levels already, so it shouldn't be a pain for them
to implement. They can have the deprecation warnings off by default
so they don't clutter the output. At least Firefox already does this
for some things, like document.getSelection() (although that message
will probably go away in a future release).
Of course, this would only be useful if we had a good alternative to
recommend. "Don't use alert(), use some giant JavaScript library
instead" is unlikely to be a very helpful message. But it would be
nice for some of the crazier or more horrible APIs, if they have saner
replacements.
On Tue, Mar 1, 2011 at 9:12 AM, WeBMartians<[email protected]> wrote:
For comment 3, simply reference the use cases for Microsoft's AfxMsgBox,
::MessageBox and its derivatives. The time out is a well-received idea.
Timeouts on dialogs are typically a terrible idea, and we shouldn't
encourage them. They mean that if the user wasn't paying attention --
which could just mean they were looking at another tab, in browsers
with tab-modal dialogs -- they never see the dialog. This is only
useful in the case where the dialog is so useless you don't actually
care if the user doesn't see it, in which case, why show it? In
practice, authors often add timeouts to things that they expect the
user to see, leaving the user confused if they don't wind up seeing
it. IIRC, one of the nice little improvements I made to MediaWiki a
few years ago was removing the last of the timed redirects from it.
OS APIs are much more enthusiastic about permitting programmers to
shoot themselves in the foot than web APIs. Microsoft specifically
also cares much more about developers and less about users, because
they depend on developers to write Windows-only apps and maintain
Microsoft's lock-in, while users are forced to buy Windows anyway.
Browsers, on the other hand, care very strongly about users, because
users can easily switch to another browser at any time, while
developers (authors) don't help or hurt them much as long as they
write cross-browser code. So for multiple reasons, the fact that
Windows supports something doesn't mean we should. You need to give
actual specific use-cases, not just cite the fact that the feature
exists in Windows.
