RE: PopUp Windows / New Windows

> Opening new windows in no way relies on javascript, and when javascript
> is used, this can be for added benefit (such as validity to a HTML
> version without the target attribute, or more control to the user etc.)
>
> <a href="/moo"> ... </a>
>
> is equivalent to
>
> <a href="/moo" onclick="//cause moo to open in new window"> ... </a>
>
> as far as scripts being disabled, the result of activation on the link is
> the /moo resource being available to the user, the script will just
> suggest some additional behaviour, the accessibility of moo isn't
> effected because of the script (it will of course because of the new
> window, I hope the distinction is clear.)
>

True, except I also very often see:

	function openWin( windowURL, windowName, windowFeatures ) {
		return window.open( windowURL, windowName, windowFeatures ) ;
}

coupled with:

	onload="openWin('moo.html', '1',
'width=340,height=350,top=0,left=0,toolbar=0,toolbar=0,location=0,directorie
s=0,status=0,menuBar=0,scrollBars=1,resizable=0' )"

in this case, no JS, no content.


>
> I believe there are many UA's which do allow, in fact I don't know of a
> combination which doesn't under some configuration, neither should it
> prevent access to the content (if the script is appropriately authored)
>

There you go... "appropriately authored".  By experience however, this is
rarely the case.

> > * W3C Priority 2, 3.4: "Use relative rather than absolute units in
> markup language attribute values and style sheet property values."
>
> I don't see the relevance here at all, firstly it doesn't mention script
> values, and it's a side issue to the main point of opening a new window.
>

Would not fixed window sizes in JavaScript using absolute values constitute
"markup language attribute values"?  While its true that JavaScript is a
scripting language and not a mark up language, why wouldn't the spirit
requiring "flexibility" not extend to this example.  If a user needs, for
whatever reason, to enlarge a JavaScript PopUp Window, should they not be
allowed to?  Locking down window sizes seems to me to be
counter-productive...

>
> The default behaviour in UA's that I know of is for the history to be
> copied to new windows, therefore the back button will work, it has to be
> specifically disabled, so whilst yes that is something to include in
> techniques documents, I can't see that it's a reason not to use.
>

No... if I use target="_blank" to get around JavaScript the new browser
window is "on top" of the old browser window (in most current, popular
UA's).  The "new browser's" Back button will not function (take me back to
the referring page), as the targeted document is the first in it's history.
While it may be clear that for most users they will note that there is in
fact a second window open and will probably "figure it out", it flies in the
face of accessible design to make that sort of presumption.

Back to the JavaScript example, with the explosion of "anti pop-up" software
out there (Popup Killer - www.stopzilla.com, Popup Zapper -
www.versiontracker.com, BanPopup - www.oiisoft.com/BanPopup, PopUpCop -
www.popupcop.com, ...need I go on?)  Clearly many mainstream users dislike
this behaviour, as witnessed by the softwares above and others like it.  And
none of these softwares (that I'm aware of) recognize "good" popups .vs
"bad" popups.  Even User agents themselves are getting into the act: Opera
allows users to configure the browser to not open Popups, Mozilla allows the
user to disallow opening a link in a new window. I would question the wisdom
of relying on this to present ANY data via web delivery.


>
> > Using JavaScript one can sort of sniff for user agents now (and plugins
> for that matter),
>
> I have to say I don't believe they can even "sort of" let alone anything
> else.

OK, Jim, I should have stated "allege to".  See:
www.mozilla.org/docs/web-developer/sniffer/browser_type.html  (In fairness
to Mozilla.org they CLEARLY state that the document is outdated and "may no
longer represent web authoring best practice.")



JF

Received on Sunday, 15 September 2002 13:25:31 UTC