I apologize if this is stuff you already know, and I'm not trying to be patronizing

Don't sweat it. I didn't mean to sound like I was lashing back.

There is no way for a web server to talk to a web client without the web client having requested something. When you click on your "Submit" button, your web client sends a request to the web server to receive some data. Now, since your CGI script is sitting on the server, all it can do is passively wait for some data to be submitted to it.

This is all correct. However, let me "reiterate" it as well, but pointing out the critical component here:

The user hit the submit button, the "page" doesn't go to the server, but the form's "data" has (not that any of this applies to the subject), and yes, the client (browser) sits and waits for data to come back. With that:

* The client is waiting for "data", so long as it meets http-compliant protocol. (I'll get back to this soon.)
* The client is not required to clear its page, its contents, or its data. It just so happens that it always does because the http data it gets back will (so far) always require that the page be cleared. Since this is NOT part of the spec (it's simply not stated), the solution can exploit this characteristic.
* The client already knows how to popup its own dialog; it's just that no one actually asks it to... except for client-side javascript. It's like having a cook in your kitchen with no phone. As long as you're in the house, you can tell the cook anything you like. If you're not there, he can't hear you.

The net sum of it all is that the client can't be told to popup a dialog, or do any of a number of things it "can" do, because it's not part of the http protocol. It just so happens that it's implemented on the client side by javascript.

IMHO, the solution to this is to articulate a minimal set of behaviors that any given client can have, where that set is a small enough common denominator that it can be implemented by any browser (phones, etc.) It is certainly the case that a popup dialog ("notice") can be included in that set. Far be it from me (or this thread) to address what the potential "full list" should be.

Waving the magic wand and assuming that such a spec were in place, we would revisit my "issue" as posted, and the solution would be something like:

print "Client:popup(text)\n\n";
[download]

Here, perl, C, or any server-side entity could pass this through the connection to the client, and the client would know what to do (because it would be http-compliant). It has the added advantage of a "guarantee" that the action would take place. (This in response to the problem that even if you did pass javascript through the channel as I'd originally wanted to, the user always had the option of turning it off, obviating the entire effort.)

Now, I have no illusions that this is going to get any attention whatsoever; and it's also not unique to shortcomings of the http protocol. People (especially the initial designers of it way back in the 80s) always said that http's original intent was never to be used in the way that it eventually did, and if they'd foreseen what happened with the growth of the net, they'd have redesigned a great deal of the protocol.

So, we have only to work with what we have. In this case, we have a bifrocated world: the web-designer has to choose between doing the majority of the "work" on the client side, or the server side. It's a huge undertaking to do one or the other, so it's not quite so simple for some larger systems that integrate with other applications/protocols, to move, even if they had a choice.

In my case, but certainly in a very large set of cases beyond mine, the situation requires the "work" be done on the server side (whereby "work", I mean that the analysis of what's input on the form cannot be done on the client). The workaround is to have a back-channel communication between the client and the server, where the "javascript", per se, could gather the form data, send it to its own listening agent on the server side (side-stepping http completely), and the agent can then do the necessary processing. In the event that a popup needs to be done, it can pass this back to the client through that side-channel, which the web-client can pick up, and do whatever it needs to do.

As you can imagine, this is a huge effort all in the name of a more appropriate and elegant UI, and I would venture to say that no one would find it worthwhile. (There's also that problem of requiring the end-user to "allow" such a back-channel communication to go on in the first place; a problem that is not socially feasible enough that such a solution could ever really be implemented and distributed.) (Of course, this was the attitude towards javascript in its early days too! :-)