RE: javascript and URLs

We can't leave the authors completely out of the loop.  The authors need to
understand that they can't trust "in new window" to always be there, just as
they can't trust the font or  color to be "just so."  But we also can't expect
them to "just say no" to window spawning.

But one reason that the UA group [as I understand it] put this in as something
where the user controls an option is that the multitude of open windows is a
benefit for some users just as much as it is a hazard for others.  So there is
no market for a content definition that presumes the pages will always only
replace one another in a single linear thread.  But there is a reasonably
severe hazard created by a user space that lets the author spawn new processes
without any by-your-leave from the operator of the browse session if that
operator (the user) is in a situation where multiple concurrent open processes
come at a high cost.  And there are user situations where that is true.

To make the content equally adapted to single-threaded or fork-spawning
patterns of use, we have to capture the relationships among the panes in a way
that transcends the particular pattern of concurrency or serialization in a
given walk through the material.  This is new ground we need to plough.  The
replacement for HTML 4 Frames in XHTML 2.0 should do a better job of this. 
Will you help us figure out how it should work?

New windows and Framesets are much the same logical problem except for
cascaded
vs. tiled panels.

Al

At 01:26 PM 2001-03-16 -0800, Matt May wrote:
>On Fri, 16 Mar 2001, Wendy A Chisholm wrote:
>
>> I agree that this is a user agent issue.  It's already implemented in
Opera 
>> (4.x+), although it sometimes seems to hang with a document.open(). You
are 
>> able to configure if you want new windows created or not.  This works for 
>> both new windows created with javascript (refer to example 4 at [1]) and 
>> new windows created with target="new" on an HTML A element (refer to the 
>> link "Savannah Area Convention and Visitors Bureau Website" at [2]).
>
>Making it a user-agent issue does not resolve it on the designer's end. If
>someone were to decide to convey meaningful information via pop-up window,
>their site could be completely broken by requiring it of user agents.
>Also, those who aren't paying attention to browser features appearing in
>some future version are likely to create unusable/inaccessible sites if
>it's not spelled out for them. As I said before, if it's an issue, it's
>got to be both with WCAG and UAAG: once to alleviate the symptoms, and
>once to cure the disease.
>
>I'll reiterate that the major browser vendors are not likely to take
>kindly to a requirement such as this, as both Microsoft and AOL are media
>companies, and their content organizations either use pop-ups currently or
>are expected to do so to satisfy advertisers. You can't expect the foxes
>to guard the henhouse, and as a result, it's incumbent on us to provide
>rules which are at worst redundant, and more likely the only line of
>defense.
>
>-
>m
>

Received on Friday, 16 March 2001 17:42:59 UTC