Determine user's default email client

[Randy Webb]

Re: Determine user's default email client

Andrew DeFaria wrote:[color=blue]
> Randy Webb wrote:
>[color=green]
>> Andrew DeFaria wrote:
>>[color=darkred]
>>> As I've said, I'm against two things in general. 1) the hiding of the
>>> recipients email address[/color]
>>
>>
>> So are most email spammers.[/color]
>
>
> Yeah, and so? Are you trying to imply that I'm a spammer? I am not.[/color]

I was not implying anything. I made a statement of my own opinion, much
as you have been doing this entire thread.
[color=blue]
> There are very legitimate reasons to want to know the contact
> information of the people you are emailing if for no other reason than
> following up.[/color]

Typically, in a larger business, there is one email address that
recieves all the email, its forwarded to people who reply to it, and
then you get the follow up. If not, then you are still stuck with the
original address which is of no use to you because you won't get the
same person twice. Telephone Tech Support is the same way.
[color=blue]
> Spam, unfortunately, is a way of life and there's not much you can do to
> stop it. Instead get something to protect yourself against spam and to
> block/filter it.[/color]

And the reason a lot of spam gets generated is email harvesting software
that searches pages for, among other things, mailto: links. I have yet
to see a spammer be able to get my email address from a contact form.

Either way, its irrelevant as mailto: always has been and is currently
*Broken*.


--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq

[Richard Cornford]

Re: Determine user's default email client

Dr John Stockton wrote:[color=blue]
> Richard Cornford posted :[color=green]
>>Mr Edgell come to this (unexpected, even in 1919) conclusion
>>through prolonged observation of the poll star. ...[/color][/color]
<snip>[color=blue]
> Polaris, the pole star, is a good half a degree away from the
> pole itself; its circular motion would be observable with the
> simplest of equipment, such as described.[/color]

The tube is described as 3/4 inch diameter by 3 foot 6 inches long. That
gives about 2 degrees of potentially observable sky. A rigorous observer
should have spotted the anomaly (at least over time) but as they say;
"There's none so blind as those that will not see", and in all things
Edgell observed only what he wanted to.

If you are interested in understanding Mr Edgell's shortcomings in this
respect you can have a look at his book. I have resurrected the web page
transcripts of it:-

<URL: http://www.litotes.demon.co.uk/dTeR/...rthRotate.html >
(about 240Kb with immages/diagrames)

Richard.

[Richard Cornford]

Re: Determine user's default email client

Andrew DeFaria wrote:[color=blue]
> Richard Cornford wrote:
> <blockquote cite="midck49hq $hgh$1$8300dec7 @news.demon.co. uk"
> type="cite">Are you really proposing that when people put a mailto
> link on a web site that their intention is no more, and no less,
> than to open an unknown piece of e-mail composing software.
> </blockquote> Exactly. What are you talking about?<br>[/color]

I am responding to your assertion that the point of putting a mailto
link in a web page is to open an e-mail client, rather than to
facilitate communication.
[color=blue]
> <blockquote cite="midck49hq $hgh$1$8300dec7 @news.demon.co. uk"
> type="cite">We know that it is more than none, but when you
> have an option to cope with 100% reliably the exact numbers
> don't matter. </blockquote> I have not found web based form
> email pages to be 100% reliable. In fact I've seen many
> times when they've failed.<br>[/color]

The general circumstances where form mail will fail, network failures,
power cuts, server failures, etc, have an equal impact on normal e-mail
traffic. But apart from those conditions we are still left with a list
of conditions under which mailto will certainly fail where normal
HTTP/HTML forms/server-side scripting will be 100% reliable.

There is always potential for the implementers of a form mail system to
screw something up and render the reliable unreliable. That is a result
of the lamentable average quality of web developers. It should not be an
excuse for never using reliable communication mechanisms.
[color=blue]
> <blockquote cite="midck49hq $hgh$1$8300dec7 @news.demon.co. uk"
> type="cite">So you don't believe that communication is the
> intended purpose (intended by the site owner, and possibly
> web developer if they are not realistic enough to see where
> it cannot work)?<br>
> </blockquote>
> The communication happens in the email client based on what
> the emailer then composes (i.e. free form).<br>[/color]

Communication requires transmission in addition to composition.
[color=blue]
> <blockquote cite="midck49hq $hgh$1$8300dec7 @news.demon.co. uk"
> type="cite"><!---->You believe that it is bad to provide the
> user with something reliable?<br></blockquote>
> I feel it's bad to limit people to what you think email is by
> reinventing email at each web page.<br>[/color]

There are no limitations imposed by facilitating reliable communication.

Richard.

[Richard Cornford]

Re: Determine user's default email client

Andrew DeFaria wrote:[color=blue]
> Richard Cornford wrote:<br>
> <blockquote cite="midck49hl $i0m$1$830fa79d @news.demon.co. uk"
> type="cite">Ass essing the relative merits of Lotus Notes is
> of no value here. It is a reality that entire companies use
> it exclusively (and their system administrators will probably
> not allow users to install their own software (licensing being
> only one reason for that). </blockquote>
> That's exactly the kinds of users I don't want as customers![/color]

If you don't want those customers that is your business (literally), but
most web authoring is done as a service to business and it is not the
web developers place to be turning away other people's business for them
(at least without explicit and informed permission).
[color=blue]
> And what sort of licensing do you think is required for
> Mozilla/Thunderbird?<br >[/color]

The point is to prevent the users from being able to install software
that would need a licence without the knowledge and permission of the
administrators. That stops them installing any software but it is the
safer policy.

<snip>[color=blue]
> <blockquote cite="midck49hl $i0m$1$830fa79d @news.demon.co. uk"
> type="cite"> <blockquote type="cite">Wha t's a coder to do?
> Rely on standards! But when you rely on standards some
> people will still complain! Argh!&lt;br&gt; <br> </blockquote>
> <!---->Relying on standards is not a practical proposition.
> </blockquote> That's an interesting statement. So then what
> is the practical proposition in your opinion?<br>[/color]

Normal cross-browser scripting gets as much from any browser as it is
capable of delivering. While the formal observance of the DOM standards
reduces IE6's capabilities to little more than form validation and image
roll-overs.
[color=blue]
> <blockquote cite="midck49hl $i0m$1$830fa79d @news.demon.co. uk
> " type="cite">In HTML terms reliably posting text (in any form)
> to a server will involve a form.<br>
> </blockquote>
> I'm not talking about reliably posting text to a server,
> I'm talking merely about sending an email. I think that
> that is where we differ.<br>[/color]

You appear to be talking about you personally sending an e-mail. But in
the context of web development the significant concept is communication.
Once reliable communication is facilitated then additional action to
accommodate individual preferences can be considered, but sacrificing
reliability for individual convenience would be negligent.

Richard.

[Andrew DeFaria]

Re: Determine user's default email client

Richard Cornford wrote:
[color=blue]
> Andrew DeFaria wrote:
>[color=green]
>> Richard Cornford wrote:
>> <blockquote cite="midck49hq $hgh$1$8300dec7 @news.demon.co. uk"
>> type="cite">Are you really proposing that when people put a mailto
>> link on a web site that their intention is no more, and no less,
>> than to open an unknown piece of e-mail composing software.
>> </blockquote> Exactly. What are you talking about?<br>[/color]
>
> I am responding to your assertion that the point of putting a mailto
> link in a web page is to open an e-mail client, rather than to
> facilitate communication.[/color]

You're being obtuse! You put a mailto link in a web page to open an
e-mail client to facilitate communication and you know that!
[color=blue][color=green]
>> <blockquote cite="midck49hq $hgh$1$8300dec7 @news.demon.co. uk"
>> type="cite">We know that it is more than none, but when you
>> have an option to cope with 100% reliably the exact numbers
>> don't matter. </blockquote> I have not found web based form
>> email pages to be 100% reliable. In fact I've seen many
>> times when they've failed.<br>[/color]
>
> The general circumstances where form mail will fail, network failures,
> power cuts, server failures, etc, have an equal impact on normal
> e-mail traffic. But apart from those conditions we are still left with
> a list of conditions under which mailto will certainly fail where
> normal HTTP/HTML forms/server-side scripting will be 100% reliable.[/color]

As you have a list of conditions under which a form based email will
fail where a mailto will succeed. What's your point?
[color=blue]
> There is always potential for the implementers of a form mail system
> to screw something up and render the reliable unreliable.[/color]

Observed actually
[color=blue]
> That is a result of the lamentable average quality of web developers.
> It should not be an excuse for never using reliable communication
> mechanisms.[/color]

And you can have the web server fail or run out of space whereas the
mail server is churning out and in emails. There are many possibilities,
none of which you've considered.
[color=blue][color=green]
>> <blockquote cite="midck49hq $hgh$1$8300dec7 @news.demon.co. uk"
>> type="cite">So you don't believe that communication is the
>> intended purpose (intended by the site owner, and possibly
>> web developer if they are not realistic enough to see where
>> it cannot work)?<br>
>> </blockquote>
>> The communication happens in the email client based on what
>> the emailer then composes (i.e. free form).<br>[/color]
>
> Communication requires transmission in addition to composition.[/color]

Obviously. Again, what's your point? I'm assuming that the person can
indeed send email. You're assuming the person can indeed browse.
[color=blue][color=green]
>> <blockquote cite="midck49hq $hgh$1$8300dec7 @news.demon.co. uk"
>> type="cite"><!---->You believe that it is bad to provide the
>> user with something reliable?<br></blockquote>
>> I feel it's bad to limit people to what you think email is by
>> reinventing email at each web page.<br>[/color]
>
> There are no limitations imposed by facilitating reliable communication.[/color]

Sure there is! Open up your mind a little bit!

--
Buy a Pentium 586/90 so you can reboot faster.

[Richard Cornford]

Re: Determine user's default email client

Andrew DeFaria wrote:[color=blue]
> Richard Cornford wrote:[color=green]
>> Andrew DeFaria wrote:[color=darkred]
>>> Richard Cornford wrote:[/color]
>> I am responding to your assertion that the point of putting
>> a mailto link in a web page is to open an e-mail client,
>> rather than to facilitate communication.[/color]
>
> You're being obtuse! You put a mailto link in a web page to
> open an e-mail client to facilitate communication and you
> know that![/color]

I am not being obtuse, I am looking at the design requirement before
considering the mechanisms by which it might best be achieved. The
design requirement is to facilitate communication; achieving that is the
goal of any implementation, and preferably doing so reliably.
[color=blue][color=green][color=darkred]
>>> <blockquote cite="midck49hq $hgh$1$8300dec7 @news.demon.co. uk"
>>> type="cite">We know that it is more than none, but when you
>>> have an option to cope with 100% reliably the exact numbers
>>> don't matter. </blockquote> I have not found web based form
>>> email pages to be 100% reliable. In fact I've seen many
>>> times when they've failed.<br>[/color]
>>
>> The general circumstances where form mail will fail,
>> network failures, power cuts, server failures, etc, have
>> an equal impact on normal e-mail traffic.[/color][/color]
^^ ^^^^^ ^^^^^^ ^^ ^^^^^^ ^^^^^^ ^^^^^^^[color=blue][color=green]
>> But apart from those conditions we are still left with a
>> list of conditions under which mailto will certainly fail
>> where normal HTTP/HTML forms/server-side scripting will
>> be 100% reliable.[/color]
>
> As you have a list of conditions under which a form based
> email will fail where a mailto will succeed. What's your point?[/color]

Where is such a list?
[color=blue][color=green]
>> There is always potential for the implementers of a form mail
>> system to screw something up and render the reliable unreliable.[/color]
>
> Observed actually
>[color=green]
>> That is a result of the lamentable average quality of web
>> developers. It should not be an excuse for never using
>> reliable communication mechanisms.[/color]
>
> And you can have the web server fail or run out of space
> whereas the mail server is churning out and in emails. There
> are many possibilities, none of which you've considered.[/color]

There are no types of application server failure that mail servers are
not equally susceptible to.

<snip>[color=blue]
> Obviously. Again, what's your point? I'm assuming that the
> person can indeed send email. You're assuming the person
> can indeed browse.[/color]

You assumption is known not to hold for all client-side systems, while
whenever an individual has accessed a web-page with either a mailto link
or a mail form over the internet the ability to browse has been
demonstrated.
[color=blue][color=green][color=darkred]
>>> <blockquote cite="midck49hq $hgh$1$8300dec7 @news.demon.co. uk"
>>> type="cite"><!---->You believe that it is bad to provide
>>> the user with something reliable?<br></blockquote>
>>> I feel it's bad to limit people to what you think email is
>>> by reinventing email at each web page.<br>[/color]
>>
>> There are no limitations imposed by facilitating reliable
>> communication.[/color]
>
> Sure there is! Open up your mind a little bit![/color]

Open my mind to what exactly? You have proposed no limitations imposed
by the use of an e-mail form on a web page, and I don't see how you
could because the existence of a form, and the server-side code to back
it up, does not preclude either the possibility of short-circuiting the
submission of the mail into a background post using XML HTTP Request
objects (where supported) or the provision of a mailto link in addition.
Layering alternatives over a reliable foundation is not restricted by
anything but the capabilities of the client, and certainly not by the
existence of the reliable foundation.

Richard.

[Randy Webb]

Re: Determine user's default email client

Andrew DeFaria wrote:
[color=blue]
> Richard Cornford wrote:
>[color=green]
>> Andrew DeFaria wrote:
>>[color=darkred]
>>> Richard Cornford wrote:
>>> <blockquote cite="midck49hq $hgh$1$8300dec7 @news.demon.co. uk"
>>> type="cite">Are you really proposing that when people put a mailto
>>> link on a web site that their intention is no more, and no less,
>>> than to open an unknown piece of e-mail composing software.
>>> </blockquote> Exactly. What are you talking about?<br>[/color]
>>
>>
>> I am responding to your assertion that the point of putting a mailto
>> link in a web page is to open an e-mail client, rather than to
>> facilitate communication.[/color]
>
>
> You're being obtuse! You put a mailto link in a web page to open an
> e-mail client to facilitate communication and you know that![/color]

No, its put there in the *hopes* that it opens an email client (if it
even exists on the system). The same is not true of a form as there is
nothing to open.
[color=blue][color=green][color=darkred]
>>> <blockquote cite="midck49hq $hgh$1$8300dec7 @news.demon.co. uk"
>>> type="cite">We know that it is more than none, but when you
>>> have an option to cope with 100% reliably the exact numbers
>>> don't matter. </blockquote> I have not found web based form
>>> email pages to be 100% reliable. In fact I've seen many
>>> times when they've failed.<br>[/color]
>>
>>
>> The general circumstances where form mail will fail, network failures,
>> power cuts, server failures, etc, have an equal impact on normal
>> e-mail traffic. But apart from those conditions we are still left with
>> a list of conditions under which mailto will certainly fail where
>> normal HTTP/HTML forms/server-side scripting will be 100% reliable.[/color]
>
>
> As you have a list of conditions under which a form based email will
> fail where a mailto will succeed. What's your point?[/color]

No, he listed things that will cause either or both to fail. The same
list is inclusive of forms, but not to mailto: as there are more things
that can fail with mailto: than with forms. Perhaps you should re-read
what he said and pay attention to the part that says "an equal impact on
normal e-mail traffic".
[color=blue][color=green]
>> There is always potential for the implementers of a form mail system
>> to screw something up and render the reliable unreliable.[/color]
>
>
> Observed actually[/color]

Not near as many times as I have observed a mailto: link not working
properly.
[color=blue][color=green]
>> That is a result of the lamentable average quality of web developers.
>> It should not be an excuse for never using reliable communication
>> mechanisms.[/color]
>
>
> And you can have the web server fail or run out of space whereas the
> mail server is churning out and in emails. There are many possibilities,
> none of which you've considered.[/color]

Yes, he even listed them. As there is no need to save the emails on the
server, thats a non-issue. If the server is set up properly to handle
it, then the email is not "saved", it is forwarded (emailed) to an
inbox. Whereas it becomes part of the normal email system. The
difference (which you refuse to admit) is the reliablity of the
mechanism used to get the information into the email system.
[color=blue][color=green][color=darkred]
>>> <blockquote cite="midck49hq $hgh$1$8300dec7 @news.demon.co. uk"
>>> type="cite">So you don't believe that communication is the
>>> intended purpose (intended by the site owner, and possibly
>>> web developer if they are not realistic enough to see where
>>> it cannot work)?<br>
>>> </blockquote>
>>> The communication happens in the email client based on what
>>> the emailer then composes (i.e. free form).<br>[/color]
>>
>>
>> Communication requires transmission in addition to composition.[/color]
>
>
> Obviously. Again, what's your point? I'm assuming that the person can
> indeed send email. You're assuming the person can indeed browse.[/color]

And one method is more reliable than the other. You just refuse to "open
your mind" (your own words) and realize it.
[color=blue][color=green][color=darkred]
>>> <blockquote cite="midck49hq $hgh$1$8300dec7 @news.demon.co. uk"
>>> type="cite"><!---->You believe that it is bad to provide the
>>> user with something reliable?<br></blockquote>
>>> I feel it's bad to limit people to what you think email is by
>>> reinventing email at each web page.<br>[/color]
>>
>>
>> There are no limitations imposed by facilitating reliable communication.[/color]
>
>
> Sure there is! Open up your mind a little bit![/color]

Ummm, what limitations are imposed by facilitating reliable communication?



--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq
Answer:It destroys the order of the conversation
Question: Why?
Answer: Top-Posting.
Question: Whats the most annoying thing on Usenet?

[Andrew DeFaria]

Re: Determine user's default email client

Richard Cornford wrote:
[color=blue]
> Andrew DeFaria wrote:
>[color=green]
>> Richard Cornford wrote:
>>[color=darkred]
>>> Andrew DeFaria wrote:
>>>
>>>> Richard Cornford wrote:
>>>
>>> I am responding to your assertion that the point of putting a mailto
>>> link in a web page is to open an e-mail client, rather than to
>>> facilitate communication.[/color]
>>
>> You're being obtuse! You put a mailto link in a web page to open an
>> e-mail client to facilitate communication and you know that![/color]
>
> I am not being obtuse, I am looking at the design requirement before
> considering the mechanisms by which it might best be achieved. The
> design requirement is to facilitate communication; achieving that is
> the goal of any implementation, and preferably doing so reliably.[/color]

And as I've told you countless times now, mailto links facilitate
communications just fine for me and millions of others. I've also
pointed out that your web based form email also has failure points.
[color=blue][color=green][color=darkred]
>>>> <blockquote cite="midck49hq $hgh$1$8300dec7 @news.demon.co. uk"
>>>> type="cite">We know that it is more than none, but when you have an
>>>> option to cope with 100% reliably the exact numbers
>>>> don't matter. </blockquote> I have not found web based form email
>>>> pages to be 100% reliable. In fact I've seen many times when
>>>> they've failed.<br>
>>>
>>> The general circumstances where form mail will fail, network
>>> failures, power cuts, server failures, etc, have an equal impact on
>>> normal e-mail traffic.[/color]
>>[/color]
> ^^ ^^^^^ ^^^^^^ ^^ ^^^^^^ ^^^^^^ ^^^^^^^
>[color=green][color=darkred]
>>> But apart from those conditions we are still left with a list of
>>> conditions under which mailto will certainly fail where normal
>>> HTTP/HTML forms/server-side scripting will be 100% reliable.[/color]
>>
>> As you have a list of conditions under which a form based email will
>> fail where a mailto will succeed. What's your point?[/color]
>
> Where is such a list?[/color]

I'm not sure. I thought you had it! :-)

But seriously you're pointing out failure points for mailto links which
is your list. I'm saying there are failure points for web based email
too, which would be my list.
[color=blue][color=green][color=darkred]
>>> There is always potential for the implementers of a form mail system
>>> to screw something up and render the reliable unreliable.[/color]
>>
>> Observed actually
>>[color=darkred]
>>> That is a result of the lamentable average quality of web
>>> developers. It should not be an excuse for never using reliable
>>> communication mechanisms.[/color]
>>
>> And you can have the web server fail or run out of space whereas the
>> mail server is churning out and in emails. There are many
>> possibilities, none of which you've considered.[/color]
>
> There are no types of application server failure that mail servers are
> not equally susceptible to.[/color]

Yes that is unless the web server is on host A and it's trashed while
the email server is on host B which is working just fine. And there are
many other ways that even if the two services are coexisting on the same
system where one is down and the other is still providing service.
[color=blue]
> <snip>
>[color=green]
>> Obviously. Again, what's your point? I'm assuming that the person can
>> indeed send email. You're assuming the person can indeed browse.[/color]
>
> You assumption is known not to hold for all client-side systems, while
> whenever an individual has accessed a web-page with either a mailto
> link or a mail form over the internet the ability to browse has been
> demonstrated.[/color]

Not necessarily the case. Some browsers don't even support forms
(ancient I agree but true nonetheless). Also many other browsers have
problems navigating through proprietary only web sites, for example.
Finally it is possible that a person has configured his email client but
lacks a browser, yet the email he just received has a link that he
cannot browse to! Again there many forms of failures.
[color=blue][color=green][color=darkred]
>>>> <blockquote cite="midck49hq $hgh$1$8300dec7 @news.demon.co. uk"
>>>> type="cite"><!---->You believe that it is bad to provide the user
>>>> with something reliable?<br></blockquote> I feel it's bad to limit
>>>> people to what you think email is by reinventing email at each web
>>>> page.<br>
>>>
>>> There are no limitations imposed by facilitating reliable communication.[/color]
>>
>> Sure there is! Open up your mind a little bit![/color]
>
> Open my mind to what exactly?[/color]

To the fact that you ain't got 100% reliability either.
[color=blue]
> You have proposed no limitations imposed by the use of an e-mail form
> on a web page, and I don't see how you could because the existence of
> a form, and the server-side code to back it up, does not preclude
> either the possibility of short-circuiting the submission of the mail
> into a background post using XML HTTP Request objects (where supported)[/color]

Or using an bona fide email client (again, where supported! ;-) )
[color=blue]
> or the provision of a mailto link in addition.[/color]

In addition is cool. We've already established that.
[color=blue]
> Layering alternatives over a reliable foundation is not restricted by
> anything but the capabilities of the client, and certainly not by the
> existence of the reliable foundation.[/color]


--
SENILE.COM found . . . Out Of Memory . . .

[Andrew DeFaria]

Re: Determine user's default email client

Randy Webb wrote:
[color=blue][color=green]
>> You're being obtuse! You put a mailto link in a web page to open an
>> e-mail client to facilitate communication and you know that![/color]
>
> No, its put there in the *hopes* that it opens an email client (if it
> even exists on the system). The same is not true of a form as there is
> nothing to open.[/color]

Likewise you are hoping that the browser can indeed navigate your site
and support forms.
[color=blue][color=green]
>> As you have a list of conditions under which a form based email will
>> fail where a mailto will succeed. What's your point?[/color]
>
> No, he listed things that will cause either or both to fail. The same
> list is inclusive of forms, but not to mailto: as there are more
> things that can fail with mailto: than with forms. Perhaps you should
> re-read what he said and pay attention to the part that says "an equal
> impact on normal e-mail traffic".[/color]

Again, the web server can be on host A and have filled disks whereas the
mail server can be on host B and have tons of space.
[color=blue]
> Yes, he even listed them. As there is no need to save the emails on
> the server, thats a non-issue. If the server is set up properly to
> handle it, then the email is not "saved", it is forwarded (emailed) to
> an inbox.[/color]

And in the meantime it hangs out in mqueue and often has other people's
mbox's on them that tend to grow without bound.
[color=blue]
> Whereas it becomes part of the normal email system. The difference
> (which you refuse to admit) is the reliablity of the mechanism used to
> get the information into the email system.[/color]

All I'm saying is that failures can happen in both methods and neither
is 100%.
[color=blue][color=green]
>> Obviously. Again, what's your point? I'm assuming that the person can
>> indeed send email. You're assuming the person can indeed browse.[/color]
>
> And one method is more reliable than the other. You just refuse to
> "open your mind" (your own words) and realize it.[/color]

I haven't seen any data to support that point. I've had far more
failures with web sites and their email forms than I've ever had with my
email client. YMMV, however, mine hasn't!
[color=blue][color=green][color=darkred]
>>> There are no limitations imposed by facilitating reliable
>>> communication.[/color]
>>
>> Sure there is! Open up your mind a little bit![/color]
>
> Ummm, what limitations are imposed by facilitating reliable
> communication?[/color]

His assumption is that it's 100% reliable and that's not true.

--
One out of every three Americans is suffering from some form of mental
illness. Think of two of your best friends. If they are OK, then it must
be you.

[Michael Winter]

Re: Determine user's default email client

On Wed, 13 Oct 2004 18:38:03 -0700, Andrew DeFaria <Andrew@DeFaria .com>
wrote:

[snip]
[color=blue]
> Likewise you are hoping that the browser can indeed navigate your site
> and support forms.[/color]

WTF? How do you propose that a mailto: link would be of more use here then?

This is why I find this thread so annoying. You aren't arguing on the same
grounds. This debate is based upon communication initiated from a web
page. Anything else is irrelevant, and your point is a prime example of
that.

Personally, I think this thread should end. If it ever had a purpose, it's
certainly lost it now.

[snip]
[color=blue]
> All I'm saying is that failures can happen in both methods and neither
> is 100%.[/color]

And who said otherwise? Of course both methods can fail, but the majority
of those failures - server errors, power cuts, etc - are beyond the
control of both the developer and the user. However, what the developer
can control is how communication is initiated.

The problem with mailto:, and the whole basis of the debate in this
thread, is that it makes an unreasonable assumption about the user's
configuration; that they have a default mail client associated with the
browser. A form does not make any assumptions. It is entirely reasonable
to expect a browser to support forms as they have been part of the HTML
Specification for years.

There is no reason why a mailto: link cannot appear on a page, but it
should not be solely relied upon for communication. Why is that so
difficult to accept?

[snip]

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[Andrew DeFaria]

Re: Determine user's default email client

Michael Winter wrote:
[color=blue]
> On Wed, 13 Oct 2004 18:38:03 -0700, Andrew DeFaria
> <Andrew@DeFaria .com> wrote:
> [snip]
>[color=green]
>> Likewise you are hoping that the browser can indeed navigate your
>> site and support forms.[/color]
>
> WTF? How do you propose that a mailto: link would be of more use here
> then?[/color]

I never proposed that. I'm simply pointing out that there are situations
where your scenarios fails too. I agree that if you can't navigate the
site then you can't navigate the site. However there are sites that are
not navigatable by one browser, say Mozilla, because the developer chose
a form approach along with some proprietary features of a particular
browser, say IE, and that user is then impeded from being able to email
(i.e. communicate) whereas his browser of choice (Mozilla) has an email
client that works fine and a mailto link instead of the proprietary IE
only web based form (not that Mozilla can't handle forms too rather the
parts used in the form are say Active X controls or some other IE only
dohicky) would have worked just fine. IOW this is a situation that fails
your "forms are 100% reliable" assertion. And I've actually had quite a
few instances where this was the case for me.
[color=blue]
> This is why I find this thread so annoying. You aren't arguing on the
> same grounds. This debate is based upon communication initiated from
> a web page. Anything else is irrelevant, and your point is a prime
> example of that.[/color]

You apparently do not understand my point.
[color=blue]
> Personally, I think this thread should end. If it ever had a purpose,
> it's certainly lost it now.[/color]

The power to end this thread for you personally was within your grasp
from the beginning. If you do not wish to discuss this then simply stop.
[color=blue]
> [snip]
>[color=green]
>> All I'm saying is that failures can happen in both methods and
>> neither is 100%.[/color]
>
> And who said otherwise? Of course both methods can fail, but the
> majority of those failures - server errors, power cuts, etc - are
> beyond the control of both the developer and the user. However, what
> the developer can control is how communication is initiated.[/color]

It was you would asserted form email is 100% reliable. I'm just refuting
that statement.
[color=blue]
> The problem with mailto:, and the whole basis of the debate in this
> thread, is that it makes an unreasonable assumption about the user's
> configuration; that they have a default mail client associated with
> the browser. A form does not make any assumptions. It is entirely
> reasonable to expect a browser to support forms as they have been
> part of the HTML Specification for years.[/color]

The problem with web based email forms is that they too make several
assumptions. They assume that the browser supports forms (probably a
pretty safe assumption) and that the web server, email server, etc are
all functioning. They also assume they have not put up other impedemints
for the user to huddle including browser differences and proprietary
controls.
[color=blue]
> There is no reason why a mailto: link cannot appear on a page, but it
> should not be solely relied upon for communication. Why is that so
> difficult to accept?[/color]

I agree that there is no reason why a mailto: link cannot appear. In
fact many sites have them for contacting support, sales, web masters,
etc. I do not recall in the problem definition that we are relying
_solely _on a mailto link. Who said that?
--
Artificial Intelligence usually beats real stupidity.

[Michael Winter]

Re: Determine user's default email client

On Thu, 14 Oct 2004 08:37:56 -0700, Andrew DeFaria <Andrew@DeFaria .com>
wrote:
[color=blue]
> Michael Winter wrote:
>[color=green]
>> On Wed, 13 Oct 2004 18:38:03 -0700, Andrew DeFaria
>> <Andrew@DeFaria .com> wrote:
>> [snip]
>>[color=darkred]
>>> Likewise you are hoping that the browser can indeed navigate your site
>>> and support forms.[/color]
>>
>> WTF? How do you propose that a mailto: link would be of more use here
>> then?[/color]
>
> I never proposed that.[/color]

I never said you did. It was a rhetorical question, implying that both
would be equally useless.
[color=blue]
> I'm simply pointing out that there are situations where your scenarios
> fails too.[/color]

I know there are. Did you read my post properly? From what you've written
here, and later, I have reason to doubt that.
[color=blue]
> I agree that if you can't navigate the site then you can't navigate the
> site. However there are sites that are not navigatable by one browser,
> say Mozilla, because the developer chose a form approach along with some
> proprietary features of a particular browser, say IE, [...][/color]

If a developer makes something as simple as a form submission proprietary,
then that developer is a moron. This "argument" would fall under the "what
the developer can control" catagory I mentioned.

[snip]
[color=blue][color=green]
>> This debate is based upon communication initiated from a web page.
>> Anything else is irrelevant, and your point is a prime example of that.[/color]
>
> You apparently do not understand my point.[/color]

No. I can't say I've witnessed you make a point, thus far (except things
I've already stated).

[snip]
[color=blue][color=green]
>> And who said otherwise? Of course both methods can fail, but the
>> majority of those failures - server errors, power cuts, etc - are
>> beyond the control of both the developer and the user. However, what
>> the developer can control is how communication is initiated.[/color]
>
> It was you would asserted form email is 100% reliable. I'm just refuting
> that statement.[/color]

When did I say that? Read the paragraph you just quoted. I said both
methods can fail, but some things are more reliable than others.
[color=blue]
> The problem with web based email forms is that they too make several
> assumptions. They assume that the browser supports forms (probably a
> pretty safe assumption)[/color]

I already stated that.
[color=blue]
> and that the web server, email server, etc are all functioning.[/color]

No-one has control over that. A mailto: link would fail if my mail server
was dead, too. I already know this and stated it (I'd count it as a server
error).
[color=blue]
> They also assume they have not put up other impedemints for the user to
> huddle including browser differences and proprietary controls.[/color]

As I said: a developer that would do this is an idiot. I know there are
plenty of them around, but that is no reason to decry a method because of
moronic implementation, when the method itself is sound.

[snip]
[color=blue]
> I do not recall in the problem definition that we are relying _solely
> _on a mailto link. Who said that?[/color]

It's implicit. It is the reason why the "solid advice" that Randy was
referring to at the start of this thread exists. People do rely solely
upon mailto:, and when it fails, communication doesn't occur. I haven't
seen the subject diverge, so if that hasn't been the basis of your
argument, then what on Earth are you talking about? Perhaps if that is
understood, this thread can, indeed, end.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[Dr John Stockton]

Re: Determine user's default email client

JRS: In article <d265b$416dd7e6 $c09cfcf$32585@ msgid.meganewss ervers.com[color=blue]
>, dated Wed, 13 Oct 2004 18:38:03, seen in news:comp.lang. javascript,[/color]
Andrew DeFaria <Andrew@DeFaria .com> posted :
[color=blue]
>One out of every three Americans is suffering from some form of mental
>illness. Think of two of your best friends. If they are OK, then it must
>be you.[/color]

Yet more false logic. 95% of the world population does not directly
have that problem - though it may well question the accuracy of "One out
of every three".

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demo n.co.uk/> - FAQish topics, acronyms, & links.
For news:borland.*, use their server newsgroups.borl and.com ; but first read
Guidelines <URL:http://www.borland.com/newsgroups/guide.html> ff. with care.

[Andrew DeFaria]

Re: Determine user's default email client

Michael Winter wrote:
[color=blue]
> If a developer makes something as simple as a form submission
> proprietary, then that developer is a moron. This "argument" would
> fall under the "what the developer can control" catagory I mentioned.[/color]

That's all fine and good however you do realize that the world is full
of morons...
[color=blue][color=green][color=darkred]
>>> This debate is based upon communication initiated from a web page.
>>> Anything else is irrelevant, and your point is a prime example of that.[/color]
>>
>> You apparently do not understand my point.[/color]
>
> No. I can't say I've witnessed you make a point, thus far (except
> things I've already stated).[/color]

Well if you can't understand it then there is nothing more that I can do.
[color=blue][color=green][color=darkred]
>>> And who said otherwise? Of course both methods can fail, but the
>>> majority of those failures - server errors, power cuts, etc - are
>>> beyond the control of both the developer and the user. However,
>>> what the developer can control is how communication is initiated.[/color]
>>
>> It was you would asserted form email is 100% reliable. I'm just
>> refuting that statement.[/color]
>
> When did I say that? Read the paragraph you just quoted. I said both
> methods can fail, but some things are more reliable than others.[/color]

I thought it was you that stated that form based email is 100% reliable.
If so then sorry. In any event each method can and does fail and each
method has it's pluses and minuses.
[color=blue][color=green]
>> The problem with web based email forms is that they too make several
>> assumptions. They assume that the browser supports forms (probably a
>> pretty safe assumption)[/color]
>
> I already stated that.
>[color=green]
>> and that the web server, email server, etc are all functioning.[/color]
>
> No-one has control over that. A mailto: link would fail if my mail
> server was dead, too. I already know this and stated it (I'd count it
> as a server error).[/color]

Yes and that's part of my point. You don't have control over whether or
not the end user has configured his email client so that mailto would
succeed. Similarly you (often - some do) don't have control over whether
or not the mail server is up or the web sever is up. So then we are
arguing whether it is more common that a mailto link will fail or that a
web email form will fail. And with that I think we can simply agree to
disagree.
[color=blue][color=green]
>> They also assume they have not put up other impedemints for the user
>> to huddle including browser differences and proprietary controls.[/color]
>
> As I said: a developer that would do this is an idiot. I know there
> are plenty of them around, but that is no reason to decry a method
> because of moronic implementation, when the method itself is sound.[/color]

My decrying of web base email systems was already enumerated.
Reliability was not high on the list for me. But as has been said before
the solution is simple - provide both!
[color=blue][color=green]
>> I do not recall in the problem definition that we are relying
>> _solely _on a mailto link. Who said that?[/color]
>
> It's implicit.[/color]

No it was not at all implicit!
[color=blue]
> It is the reason why the "solid advice" that Randy was referring to
> at the start of this thread exists. People do rely solely upon
> mailto:, and when it fails, communication doesn't occur. I haven't
> seen the subject diverge, so if that hasn't been the basis of your
> argument, then what on Earth are you talking about? Perhaps if that
> is understood, this thread can, indeed, end.[/color]

The thread can easily end from your perspective at any time by merely
ignoring it.

--
I got a new shadow. I had to get rid of the other one -- it wasn't doing
what I was doing.

[Andrew DeFaria]

Re: Determine user's default email client

Dr John Stockton wrote:
[color=blue]
> JRS: In article <d265b$416dd7e6 $c09cfcf$32585@ msgid.meganewss ervers.com
>[color=green]
>> , dated Wed, 13 Oct 2004 18:38:03, seen in news:comp.lang. javascript,[/color]
>
> Andrew DeFaria <Andrew@DeFaria .com> posted :
>[color=green]
>> One out of every three Americans is suffering from some form of
>> mental illness. Think of two of your best friends. If they are OK,
>> then it must be you.[/color]
>
> Yet more false logic. 95% of the world population does not directly
> have that problem - though it may well question the accuracy of "One
> out of every three".[/color]

A couple of points there doc:

1. It's a tagline! Intended to be funny!
2. Explaining or analyzing jokes just proves that you didn't "get it".
3. It did say Americans did it not?
4. America is not 95% of the world population!
5. If you have further questions see #1

Geeze...

--
All women are idiots... and I married their queen.