Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Hi, stupid popup question

Reply
Thread Tools

Hi, stupid popup question

 
 
Richard Cornford
Guest
Posts: n/a
 
      11-13-2003
"Michael Winter" <M.Winter@[no-spam]blueyonder.co.uk> wrote in message
news:2nBsb.2432$(E-Mail Removed)...
<snip>
>Your point is well taken. I'm sheltered from the features
>of most browsers out there. They've proved far too unstable
>on my system in the past. I loved Opera, but it crashed -
>sometimes taking the kernel with it - regularly. I've got
>enough problems with stability as it is at the moment, I
>don't need more possible causes.


Opera 6 (and 5 more so) was a bit flaky (especially when incautiously
scripted) but Opera 7 is proving quite robust. And it is surprising how
many ways there are of crashing IE 6 with JavaScript, and taking the OS
with it.

> A few counter points:
>
>1) You can't place windows off-screen. Scripts have to be
>signed to do that (unless that restriction was removed after
>1.3 - I haven't finished reading up on DOM and the later JS
>versions yet), and the OPs won't be.


Theoretically true, though there have been browsers that have allowed
windows to be opened off screen. That is usually considered a security
flaw and fixed in later versions.

However, some of the multi-monitor systems have the OS report the screen
dimensions to the browser as the smallest rectangle that will encompass
all of the monitor screens used. So if the monitors are not identical
sizes configured as either a block or a strip then there are void areas
that will not be displayed on (or practically accessible from) and of
the monitors. A fairly common configuration of a 24 inch monitor with a
17 inch monitor to the right would have an inaccessible area above the
17 inch monitor making the desktop height up to that of the 24 inch
monitor. From the point of view of the browsers that region is part of
the desktop and an attempt to centre a new browser window is likely to
place the upper right of the new window in that area, making the close,
minimise and maximise buttons and par to the content inaccessible (until
the window is moved). Move on to five or six monitors configured in an L
shape and it is entirely possible for the new window to be completely
out of site.

>2) As you say, positioning is meaningless for tabbed
>browsers. They will ignore such positioning statements,
>so it won't matter. The user just won't see quite what
>the author intended.


The existence of tabbed browsers does bring into question the validity
of designing sites to use multiple windows. Most of the justifications
for such a design vanish completely on such a browser (and they do
include browsers based entirely on IE).

>3) The browsers create the screen object. It would be
>logical to assume that an MDI browser would report the
>dimensions of the MDI window, and not that of the entire
>monitor.


That depends, if it is called the "screen" object it might be reasonably
be argued that what it should report should be related to the screen and
not something else. Making the screen object report the MDI interface
viewport dimensions might help authors who insisted on trying to centre
windows, but not that much as they never seem to bother to check if the
results of ((screen.availWidth - browser.width)/2) is negative, and the
MDI interface viewpoint does not constrain the windows it contains so
that information is not necessarily an appropriate basis for the
positing decisions either.

>In my opinion, I see no point in reporting the
>existence of pixels you can't use. Whether the browser
>developers see it that way is of course, another matter and
>one that is a waste of time debating (good to note, though).


The bottom line is that the screen objects of various browsers report
information that is inaccurate, irrelevant and inapplicable. As a
result, the general advice is to never do anything that necessitates an
interest in the screen dimensions. Avoiding the inaccuracy and
inapplicability of the information by never asking the question.

As with all things related to browser scripting, there are plenty of
people who would rather ignore the issues than learn how to cope with
the consequences, but that just means that they are willing to make
themselves look incompetent whenever their scripts encounter any of the
'slightly diverging from the norm' conditions.

Richard.


 
Reply With Quote
 
 
 
 
DU
Guest
Posts: n/a
 
      11-13-2003
Michael Winter wrote:

> "Richard Cornford" wrote on 13/11/2003:
>
>
>>"Michael Winter" <M.Winter@[no-spam]blueyonder.co.uk> wrote in

>
> message
>
>>news:hOzsb.2299$(E-Mail Removed)...
>><snip>
>>
>>>... . I'm frankly at a loss for what would cause your
>>>window to maximize like that. ...

>>
>><snip>
>>
>>My suspicion is that Shaun is using cut-and-paste scripts without
>>understanding what they do or how they work and has included a

>
> script
>
>>with a call to window.resizeTo (or resizeBy) that is expanding the
>>window. It certainly isn't something that I would expect to happen
>>without some sort of instruction to do so. (Then again it might be

>
> some
>
>>sort of ill-conceived free web host inserted script.)
>>
>>
>>>As for centring, that's fairly simple. Check the 'screen'
>>>object. It's properties include the user's monitor dimensions,
>>>amongst other things. Of course, until your maximizing problem
>>>is fixed, centring is useless.

>>
>>Centring windows is not as simple as just reading the screen

>
> dimensions
>
>>and positioning the window accordingly. Apart from being a

>
> meaningless
>
>>action in a tabbed browser, problems occur with, say, the MDI

>
> interface
>
>>on Opera, where screen dimensions reflect the desktop but window
>>positing instructions are relative to the outer window of the

>
> interface,
>
>>meaning that an attempt to position a window based on the screen
>>dimensions stands a very realistic chance of resulting in a window

>
> that
>
>>is entirely out of site. Multi-monitor displays are another

>
> stumbling
>
>>block as positioning based on screen dimension may result in the

>
> window
>
>>being opened across the screen boundaries, partly out of the

>
> displayable
>
>>desktop area and/or on a different monitor to the browser window,

>
> where
>
>>it may go unnoticed.
>>
>>Unfortunately, without any mechanism for determining the type of
>>multi-monitor display (if any) being used, whether the browser is

>
> MDI or
>
>>tabbed, or any combination of these, the only reliable approach to
>>positioning windows is to make no specification at all. In response

>
> most
>
>>browsers will open a new window over the existing window, the one

>
> place
>
>>that you can be fairly certain that it will be apparent and fully
>>visible to the user (subject to scriptable window opening being

>
> allowed
>
>>at all).

>
>
> Your point is well taken. I'm sheltered from the features of most
> browsers out there. They've proved far too unstable on my system in
> the past. I loved Opera, but it crashed - sometimes taking the kernel
> with it - regularly. I've got enough problems with stability as it is
> at the moment, I don't need more possible causes.
>
> A few counter points:
>
> 1) You can't place windows off-screen.


Yes you can with MSIE 5+. No you can not in Mozilla-based browsers and
NS 4 as you rightly point out that scripts must be signed to do that...
although there are a few bugs which still needs to be fixed regarding
this issue:

Bug 176342: windows opened using innerHeight/Width can open partially
offscreen
http://bugzilla.mozilla.org/show_bug.cgi?id=176342

Bug 118717: Never let sites position windows outside the screen
http://bugzilla.mozilla.org/show_bug.cgi?id=118717

Bug 183633: screenX/left and screenY/top of popups are not corrected
accordingly when sizes are not specified
http://bugzilla.mozilla.org/show_bug.cgi?id=183633
http://bugzilla.mozilla.org/attachme...63&action=view

Scripts have to be signed to
> do that (unless that restriction was removed after 1.3 - I haven't
> finished reading up on DOM and the later JS versions yet), and the OPs
> won't be.
> 2) As you say, positioning is meaningless for tabbed browsers. They
> will ignore such positioning statements, so it won't matter. The user
> just won't see quite what the author intended.


But we are talking about new windows here, no?

> 3) The browsers create the screen object. It would be logical to
> assume that an MDI browser would report the dimensions of the MDI
> window, and not that of the entire monitor. In my opinion, I see no
> point in reporting the existence of pixels you can't use.


Correct. I agree. That's why Opera needs to implement a property of the
window object for this. Something like
window.MDIviewportWidth
window.MDIviewportHeight

DU

Whether the
> browser developers see it that way is of course, another matter and
> one that is a waste of time debating (good to note, though).
>
> Mike
>


 
Reply With Quote
 
 
 
 
Lasse Reichstein Nielsen
Guest
Posts: n/a
 
      11-13-2003
DU <(E-Mail Removed)> writes:

> Correct. I agree. That's why Opera needs to implement a property of
> the window object for this. Something like


> window.MDIviewportWidth
> window.MDIviewportHeight


Why not use screen.availHeight and screen.availWidth for that. The
MDI viewport *is* the available size for windows. (I have suggested
it to them, but maybe it is too big a change).

/L
--
Lasse Reichstein Nielsen - http://www.velocityreviews.com/forums/(E-Mail Removed)
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
 
Reply With Quote
 
DU
Guest
Posts: n/a
 
      11-13-2003
Richard Cornford wrote:

> "Michael Winter" <M.Winter@[no-spam]blueyonder.co.uk> wrote in message
> news:hOzsb.2299$(E-Mail Removed)...
> <snip>
>
>>... . I'm frankly at a loss for what would cause your
>>window to maximize like that. ...

>
> <snip>
>
> My suspicion is that Shaun is using cut-and-paste scripts without
> understanding what they do or how they work and has included a script
> with a call to window.resizeTo (or resizeBy) that is expanding the
> window. It certainly isn't something that I would expect to happen
> without some sort of instruction to do so. (Then again it might be some
> sort of ill-conceived free web host inserted script.)
>
>
>>As for centring, that's fairly simple. Check the 'screen'
>>object. It's properties include the user's monitor dimensions,
>>amongst other things. Of course, until your maximizing problem
>>is fixed, centring is useless.

>
>
> Centring windows is not as simple as just reading the screen dimensions
> and positioning the window accordingly. Apart from being a meaningless
> action in a tabbed browser,


Browsers with tab capability still can open a new instance of the
browser window; a new window (child window, secondary window) is still a
new window in such browsers (e.g.: Mozilla, Opera 7).

problems occur with, say, the MDI interface
> on Opera, where screen dimensions reflect the desktop but window
> positing instructions are relative to the outer window of the interface,
> meaning that an attempt to position a window based on the screen
> dimensions stands a very realistic chance of resulting in a window that
> is entirely out of site.


Yep! Opera 7 is a good example of this.

Multi-monitor displays are another stumbling
> block as positioning based on screen dimension may result in the window
> being opened across the screen boundaries, partly out of the displayable
> desktop area and/or on a different monitor to the browser window, where
> it may go unnoticed.
>
> Unfortunately, without any mechanism for determining the type of
> multi-monitor display (if any) being used, whether the browser is MDI or
> tabbed, or any combination of these, the only reliable approach to
> positioning windows is to make no specification at all. In response most
> browsers will open a new window over the existing window,


In case of a
<a href="path/filename.html" target="ANewSecondaryWindow"
title="Clicking this link will open in a new window or will reuse an
already opened one">See my garden</a>
the new window left and top coordinates will be offset 15px to the right
and to the bottom from the opener (if non-maximized) in both
Mozilla-based browsers and MSIE 5+. The idea is that this helps users
notice taht a new window has "emerged" on top of the opener. Such 15px
offset is an usability aid.

the one place
> that you can be fairly certain that it will be apparent and fully
> visible to the user (subject to scriptable window opening being allowed
> at all).
>
> Richard.
>
>


When a window.open call is done without any specifics to position (left,
top, screenX, screenY are not defined), then new window coordinates will
be those of the last non-maximized window which were stored by the os
(persistent data). So new windows do not have random positions or sizes.

DU

 
Reply With Quote
 
DU
Guest
Posts: n/a
 
      11-13-2003
Lasse Reichstein Nielsen wrote:

> DU <(E-Mail Removed)> writes:
>
>
>>Correct. I agree. That's why Opera needs to implement a property of
>>the window object for this. Something like

>
>
>>window.MDIviewportWidth
>>window.MDIviewportHeight

>
>
> Why not use screen.availHeight and screen.availWidth for that. The
> MDI viewport *is* the available size for windows. (I have suggested
> it to them, but maybe it is too big a change).
>
> /L



screen.availHeight and screen.availWidth refer to different areas: they
refer to the available workarea for applications on the screen. I.e. the
whole user screen minus semi-permanent os-dependent applications like
windows taskbar, MS-Office quick launch bar, MS-magnifier and any
os-dependent 3rd party applications (winbar, membar,etc.).

Just see for yourself, make sure you're in MDI with O7:
File/Preferences...Alt+P/Windows/Windows handling/Prefer pages inside window

http://www10.brinkster.com/doctorunc...WindowsO7.html

DU

 
Reply With Quote
 
Warren Sarle
Guest
Posts: n/a
 
      11-13-2003

In article <bousf5$kvq$1$(E-Mail Removed)>
(Re: Hi, stupid popup question),
"Richard Cornford" <(E-Mail Removed)> writes:
> ...
> The bottom line is that the screen objects of various browsers report
> information that is inaccurate, irrelevant and inapplicable. As a
> result, the general advice is to never do anything that necessitates an
> interest in the screen dimensions. Avoiding the inaccuracy and
> inapplicability of the information by never asking the question.


I have a web photo gallery that lets users choose any of three
image sizes to view. By default, you get small images (suitable
for an 800x600 external browser window size). I've been looking
through a Javascript book to see if there might be a way to make
an educated guess about what image size would be best to display.
But this may be a hopeless endeavor, judging from what Richard
says. Would anyone care to offer an opinion as to whether I should
stick with the small images by default or try to do something
more clever?

--

Warren S. Sarle SAS Institute Inc. The opinions expressed here
(E-Mail Removed) SAS Campus Drive are mine and not necessarily
(919) 677-8000 Cary, NC 27513, USA those of SAS Institute.
 
Reply With Quote
 
DU
Guest
Posts: n/a
 
      11-13-2003
Richard Cornford wrote:

> "Michael Winter" <M.Winter@[no-spam]blueyonder.co.uk> wrote in message
> news:2nBsb.2432$(E-Mail Removed)...
> <snip>
>
>>Your point is well taken. I'm sheltered from the features
>>of most browsers out there. They've proved far too unstable
>>on my system in the past. I loved Opera, but it crashed -
>>sometimes taking the kernel with it - regularly. I've got
>>enough problems with stability as it is at the moment, I
>>don't need more possible causes.

>
>
> Opera 6 (and 5 more so) was a bit flaky (especially when incautiously
> scripted) but Opera 7 is proving quite robust. And it is surprising how
> many ways there are of crashing IE 6 with JavaScript, and taking the OS
> with it.
>
>
>>A few counter points:
>>
>>1) You can't place windows off-screen. Scripts have to be
>>signed to do that (unless that restriction was removed after
>>1.3 - I haven't finished reading up on DOM and the later JS
>>versions yet), and the OPs won't be.

>
>
> Theoretically true, though there have been browsers that have allowed
> windows to be opened off screen. That is usually considered a security
> flaw


not in MSIE 5+

and fixed in later versions.
>


I wonder which browsers you're talking about. Mozilla still has not
fixed 3 bugs regarding this.

> However, some of the multi-monitor systems have the OS report the screen
> dimensions to the browser as the smallest rectangle that will encompass
> all of the monitor screens used. So if the monitors are not identical
> sizes configured as either a block or a strip then there are void areas
> that will not be displayed on (or practically accessible from) and of
> the monitors. A fairly common configuration of a 24 inch monitor with a
> 17 inch monitor to the right would have an inaccessible area above the
> 17 inch monitor making the desktop height up to that of the 24 inch
> monitor. From the point of view of the browsers that region is part of
> the desktop and an attempt to centre a new browser window is likely to
> place the upper right of the new window in that area, making the close,
> minimise and maximise buttons and par to the content inaccessible (until
> the window is moved). Move on to five or six monitors configured in an L
> shape and it is entirely possible for the new window to be completely
> out of site.
>
>
>>2) As you say, positioning is meaningless for tabbed
>>browsers. They will ignore such positioning statements,
>>so it won't matter. The user just won't see quite what
>>the author intended.

>
>
> The existence of tabbed browsers does bring into question the validity
> of designing sites to use multiple windows. Most of the justifications
> for such a design vanish completely on such a browser (and they do
> include browsers based entirely on IE).
>


I don't agree. There are cases where having 2 browser window is more
suitable than having 2 browser tabs. I can have 2 browser instances, 2
browser windows side by side. How can you view 2 browser tab side by side?

>
>>3) The browsers create the screen object. It would be
>>logical to assume that an MDI browser would report the
>>dimensions of the MDI window, and not that of the entire
>>monitor.

>
>
> That depends, if it is called the "screen" object it might be reasonably
> be argued that what it should report should be related to the screen and
> not something else. Making the screen object report the MDI interface
> viewport dimensions might help authors who insisted on trying to centre
> windows, but not that much as they never seem to bother to check if the
> results of ((screen.availWidth - browser.width)/2) is negative, and the
> MDI interface viewpoint does not constrain the windows it contains so
> that information is not necessarily an appropriate basis for the
> positing decisions either.
>
>
>>In my opinion, I see no point in reporting the
>>existence of pixels you can't use. Whether the browser
>>developers see it that way is of course, another matter and
>>one that is a waste of time debating (good to note, though).

>
>
> The bottom line is that the screen objects of various browsers report
> information that is inaccurate, irrelevant and inapplicable.


I don't agree on the inaccurate point. I think overall they report
accurate info but there are compatibility difficulties: window.screenX,
window.screenY have no equivalent in MSIE. I.e.:
window.screenY in Mozilla != window.screenTop in MSIE
window.screenY in Opera 7 != window.screenY in Mozilla

I agree that the relevance of such info is quite debatable or at least
largely over-evaluated.

As a
> result, the general advice is to never do anything that necessitates an
> interest in the screen dimensions. Avoiding the inaccuracy and
> inapplicability of the information by never asking the question.
>
> As with all things related to browser scripting, there are plenty of
> people who would rather ignore the issues than learn how to cope with
> the consequences, but that just means that they are willing to make
> themselves look incompetent whenever their scripts encounter any of the
> 'slightly diverging from the norm' conditions.
>
> Richard.
>
>



I deeply believe that amateur website developers over-excessively focus
on issues that they can control and that they believe can bring some
value to their site. Positioning a popup fits perfectly into their
controlling mind. At the same time, they will gladly remove window
resizability, scrollbars (thinking they are not needed but not
considering many usability issues like increasing font size),
statusbar,etc.. and they will feel powerful at controlling the website.
It's sort of a macho-power-trip attitude.

They totally miss the point that these windows are (should be) at the
disposal of users. They over-concentrate on issues and matters which
should matter a lot less than content and suitable design.

DU

 
Reply With Quote
 
Lasse Reichstein Nielsen
Guest
Posts: n/a
 
      11-13-2003
DU <(E-Mail Removed)> writes:

> screen.availHeight and screen.availWidth refer to different areas:
> they refer to the available workarea for applications on the
> screen.


I know that is what it *does*. However, in an MDI client, I don't
think that is what it *should* do.

The "available" area should be the area that is available to the page,
e.g., for creating and placing new windows. That area is exactly the
viewport of an MDI application.

/L
--
Lasse Reichstein Nielsen - (E-Mail Removed)
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      11-14-2003
"DU" <(E-Mail Removed)> wrote in message
news:bp11to$9gp$(E-Mail Removed)...
<snip>
>not in MSIE 5+
>
>>and fixed in later versions.

>
>I wonder which browsers you're talking about. Mozilla
>still has not fixed 3 bugs regarding this.


I wasn't thinking of any particular browsers, I know that there are
still plenty about that don't mind if a script attempts to position a
window off screen but I didn't want to disagree with Michael on the
point that they really shouldn't. As we were discussing centring windows
on the screen (presumably with the intention that they be visible) I was
more interested in demonstrating that a script with that intention might
still place a new window out of site and not be in a position to know
that it had done so, rather than getting into whether a script could
deliberately put a new window where it couldn't be seen.

<snip>
>>The existence of tabbed browsers does bring into question the
>>validity of designing sites to use multiple windows. Most of
>>the justifications for such a design vanish completely on such
>>a browser (and they do include browsers based entirely on IE).

>
>I don't agree. There are cases where having 2 browser window is
>more suitable than having 2 browser tabs. I can have 2 browser
>instances, 2 browser windows side by side. How can you view 2
>browser tab side by side?


You cannot view two browser tabs side by side. But that is what I was
getting at. If a design suggests that it would be suitable to have two
windows side by side but it is not possible to know with certainty that
two windows will be the outcome on the client then rather than worrying
about the best way of attempting to open windows (and inevitably
accepting that it is just not going to happen reliably) it might be
better to re-consider that design and attempt to come up with something
that would be meaningful in any browser.

As I see it, a design that want's to open a second window has to take
into account the possibility that the second window does not open (or is
immediately closed by an external pop-up blocker, detect those condition
and falling back), navigates within the current window and opens in a
tab instead of a distinct window, in addition to the desired outcome of
opening in a new window. So a design that suggests the opening of a new
window implies the need to cope with at least three distinct UI styles
and to come up with a script that can detect, and sensibly respond to,
the failure of the window.open call due to pop-up blockers, etc.
(something that, so far, has never been demonstrated to be possible).

If opening a new window implies an exponential increase in UI complexity
and necessitates a script that has never been written (and I, for one,
believe to be impossible) then maybe it would be more effective to
abandon multi-window designs and instead see how much can be achieved
within a single browser window.

<snip>
>>The bottom line is that the screen objects of various
>>browsers report information that is inaccurate, irrelevant
>>and inapplicable.


>I don't agree on the inaccurate point. I think overall they report
>accurate info but there are compatibility difficulties: window.screenX,
>window.screenY have no equivalent in MSIE. I.e.:
>window.screenY in Mozilla != window.screenTop in MSIE
>window.screenY in Opera 7 != window.screenY in Mozilla


On the accuracy point I was thinking of screen objects that report the
same values for avail/Width/Height as the values they report for
width/height (on, say, IceBrowser 5 and Opera versions < 7.02).

>I agree that the relevance of such info is quite debatable
>or at least largely over-evaluated.
>
>>As a result, the general advice is to never do anything
>>that necessitates an interest in the screen dimensions.
>>Avoiding the inaccuracy and inapplicability of the
>>information by never asking the question.
>>

<snip>
>I deeply believe that amateur website developers over-excessively
>focus on issues that they can control and that they believe can
>bring some value to their site. Positioning a popup fits perfectly
>into their controlling mind. At the same time, they will gladly
>remove window resizability, scrollbars (thinking they are not
>needed but not considering many usability issues like increasing
>font size), statusbar,etc.. and they will feel powerful at
>controlling the website. It's sort of a macho-power-trip attitude.


(A definition of amateur that seems to include quite a number of people
who are trying to make a living from web site development) I would tend
to leave the "macho-power-trip" judgement until after the individual has
had a chance to react to having the issues pointed out. At least some of
these attitudes seem to be down to attitudes gained in unrelated areas.
Graphic designers trained for (and experienced with) designing for paper
and print. Programmers used to coding for consistent and predictable
environments where they expect to actively control the UI. Coming to
terms with working in a medium as fluid as a web page and programming
for an environment as inconsistent as web browser DOMs is not going to
happen over night.

>They totally miss the point that these windows are (should be)
>at the disposal of users. They over-concentrate on issues and
>matters which should matter a lot less than content and suitable
>design.


Yes, there is a lot of concentration on the wrong issues. To my mind
worrying about the positioning, sizing, re-sizing, etc. of new windows
or communicating between them once they exist are all issues that come
after the issues around opening windows with scripts, and especially
detecting and coping with the failure of the attempt. Until a reliable
strategy exists to address that issue everything that follows is of no
more than academic interest.

Richard.


 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      11-14-2003
"Lasse Reichstein Nielsen" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>>screen.availHeight and screen.availWidth refer to different
>>areas: they refer to the available workarea for applications
>>on the screen.

>
>I know that is what it *does*.


At least since they fixed it late last year (about 7.02).

>However, in an MDI client,
>I don't think that is what it *should* do.
>
>The "available" area should be the area that is available to
>the page, e.g., for creating and placing new windows. That
>area is exactly the viewport of an MDI application.


But the MDI interface does not constrain its inner window size (when not
maximised) and the MDI window is freely re-sizeable. Neither of which
are a problem as such but centring windows based on the MDI window size
would still be problematic because people never check to see if
((screen.availWidth - newWindowWidth)/2) is negative, which it often
would be when the MDI window is small, and negative values are treated
as if they are positive so the centred window would still be offset down
and right, maybe to the pint of being out of site in a small MDI window.
Which is exactly the same situation is exists now.

Another problem is the people who use screen size to redirect to a page
"tailored" to the screen size, a small MDI window might be redirected to
PDA or smaller desktop content when the user would prefer to re-size the
MDI window to suite larger content, or with less considerate scripts the
site might attempt to reject the browser because it thought the screen
was too small.

Of course fluid page design removes the necessity for the scripts that
impose the second problem, but abandoning efforts to position new
windows renders the values reported by the screen object irrelevant
anyway.

There has got to be a reasonable argument for an object called "screen"
to provide information related to the screen. It just might be necessary
for script authors to recognise that the screen is not really relevant
to them.

Richard.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
stupid, STUPID question! rincewind HTML 25 05-08-2009 01:07 PM
stupid question...waiting for a stupid answer Brandon McCombs Java 4 08-28-2006 06:57 PM
Stupid question. Please, only stupid responders. If you're not sureif you're stupid, you probably aren't. =?ISO-8859-1?Q?R=F4g=EAr?= Computer Support 6 07-18-2005 05:11 AM
stupid stupid stupid kpg MCSE 17 11-26-2004 02:59 PM
Main > Popup > Popup > Close popup AND new URL in main? Jens Peter Hansen Javascript 7 06-19-2004 08:56 PM



Advertisments