"Markus Ernst" <derernst@NO#SP#AMgmx.ch> wrote in message
news:3f***********************@news.easynet.ch...
<snip>
My proposal is not a solution for the actual problem.
I could quote that line in this response and say nothing more on the
subject. Indeed, properly attributed, that line is good enough for a
comic signature.
It is just a workaround for some cases:
Case 1: UA is not Internet Explorer. There is no problem, as
a new window will be empty.
That pre-supposes that the Ctrl-n behaviour is unique to IE browsers.
The OP only suggests that Mozilla does not follow IE, but given 20 odd
Gecko implementations with diverse Uis I doubt that Mozilla's behaviour
is even consistent among Gecko browsers. There is certainly no guarantee
that IE is the only browser that can open a new window showing the
current page, in fact browsers often actively re-produce the behaviour
of IE (especially if designed to run on the Windows OS).
But while the browser may not be IE, and may not clone the current page
into a new window, that browser is still to be exposed to the code and
so the call to window.open. Not all browsers (including pocket IE) can
open new windows, many non-IE browsers include settings that restrict
the opening of new windows and many browsers are used in conjunction
with pop-up blocking software of one type or another. And, of course,
any of those non-IE browsers may have JavaScript disabled or just not
implemented.
Case 2: UA is Internet Explorer, and Javascript turned on. Here
the solution I proposed works as it creates a new session.
Even on (desktop) IE the call to window.open may not result in a new
window and can even result in the navigation of the current (nameless)
window to the URL provided as a parameter to the window.open call. (The
action of various types of pop-up blocker)
<snip>Case 3: UA is Internet Explorer, and Javascript turned off.
Here you have 2 possibilities:
a) You open the applicaton with window.open() as I proposed
to prevent non-Javascript users from opening it at all.
Along with the users of JavaScript incapable browsers, other browsers
with JavaScript disabled, browsers that cannot open new windows and a
proportion of browsers (including JavaScript enabled IE) operating on
conjunction with pop-up blockers.
As JavaScript incapable/disabled browsers may include browsers designed
(or configured) for use by various disabled groups there may even be
legal implications of this action if it is done in a commercial context
under some jurisdictions.
This is ok if Javascript is crucial in other parts of your
application, too -
This is the "bad design justifies worse design" argument again. There
are more web sites and applications that are JavaScript dependent than
there are web sites and applications that *need* to be JavaScript
dependent, by a very large margin. JavaScript dependence more often than
not is a direct result of inadequacies in the developer.
for example select boxes with Javascript-created dynamic
option field sets or whatever.
If you mean the case where the content of a second(+) select box is
populated based on the selection in a first then there are 4 patterns of
authoring such a system that do not create a dependence on JavaScript.
Most of them do not result in a good UI in the absence of JavaScript but
at least the result is always usable. Otherwise, server-side scripting
is completely capable of, and suited to, dynamically generating the
option elements of an HTML select element.
Of course you have to tell your users to activate Javascript,
Some users just will not be able to do that.
and some will be angry about you.
And if you don't needlessly introduce a JavaScript dependence you will
not anger anyone (at least for that reason) and there is no need to
explain, or apologise for, anything.
b) You provide a way to open the application without Javascript
(<a href="myapp.jsp" target="[session id]"> will do the same
as the window.open() I proposed).
That is actually much better than your window.open proposal. It will
still be subject to the action of some pop-up blockers (though you may
reduce that a bit more by explaining that the link will attempt to open
a new window). And it will still result in navigation within the current
(nameless) window on browsers that cannot open new windows and browsers
subject to the actions of content inserting/re-writing proxies
configured to remove TARGET attributes (a standard filter in
Proximatron, for example).
So a very small part of users will have the cloned session problem,
If that is acceptable then there was never really a problem in the first
pace as by and large users will not clone there current browser instance
into a new window so it was only ever a problem that might be
experienced by a small minority.
as I think most people who have installed Internet
Explorer don't care about disabling Javascript.
You could even hide the whole thing from non-IE browsers by
using the 3b) solution by doing a serverside browser sniff
and write the target attribute only to IE browsers.
Server side browser sniffing is about as reliable as using a random
number generator and biasing the results with your favourite
(meaningless) browser usage statistics. You loose all credibility by
even suggesting it.
So all popup blocker and broken back button issues will
not occur on non-IE browsers.
Assuming that you are not proposing excluding non-(desktop)IE browsers,
you are back to assuming that IE's Ctrl-n behaviour is unique to IE (or
at least, given the server-side browser sniffing proposal, unique to
browsers that habitually (or are currently configured to) send UA
headers that are indistinguishable form IE browsers).
Maybe my proposal introduces more problems that I don't see,
then I am very interested to know about them.
Given a combination of an HTML UA capable of communicating via HTTP to a
server running any server-side scripting technology you have a system
that can work for 100% of visitors 100% of the time (all other things,
telephone networks, electricity supplies, etc, being equal). So from a
starting point that is as close to completely reliable as anything
involving electrical and mechanical systems can be it is the design
decisions of humans that undermine that reliability.
Returning to the dependent select element example above, it is fairly
common for there to be a requirement for a users selection at an early
stage in a process to define and limit there choices at a later stage.
That could be implemented as a wizard style interface using only HTML
forms and server-side scripts, or it could be implemented with multiple
dependent select elements on one page. The former does not detract from
the intrinsic reliability that the system started with, the latter
could. But in the latter case there is also the decision about how to
implement the dependent select elements, they will need JavaScript in
order to "work" but they do not need to be unusable in the absence of
JavaScript and that design decision is going to significantly impact on
the reliability of the whole system. Rendering it unusable for between
2 and 80% of potential visitors (depending on which JavaScript
unavailability statistics you believe. Obviously that range of figures
merle reflects the fundamental meaninglessness of statistics relating to
browsers in general).
The decision to put the select elements on the same page might be based
on usability, or appearance, or just an ignorance of the consequences,
and the decision to implement it in a JavaScript dependent way might be
based on the relative cost of employing a developer who understands how
to properly employ JavaScript as opposed to one who merle knows how to
write the code but doesn't know how to design the code for the internet.
Then again it might not have been a decision at all, just the
consequence of assigning the task to someone who didn't know any better.
But the consequences are still an otherwise avoidable loss of
reliability on the whole system.
If a client (who is unlikely to be in a position to make informed
decisions about implementations for themselves) was told that a
percentage of their potential visitors (or worse, customers) where now
being turned away for no better reason than the inability, or
unwillingness, of a developer to design their implementation in a way
that does not detract from the intrinsic reliability of the system then
the client would probably want find a better developer. Of course the
developer is in a position to bamboozle the client into believing that
whatever was implemented is as good as it can be, and that its
shortcomings are unavoidable or intrinsic to the system, or just not
significant. Throwing spurious statistics and guesstimates about "normal
user behaviour" about and talking of "target" audiences and such like.
If a site cannot be visited and used by any and all potential visitors
(or customers) then that is directly the result of (bad) design
decisions and could have been avoided.
Richard.
