detecting browser

**Douglas Crockford** · Jul 20 '05, 08:48 AM

Re: detecting browser

> pls, why is this not working?[color=blue]
>
> <SCRIPT language=JavaSc ript type="text/javascript">
> var br = '<SCRIPT language=Javasc ript'
> br += 'src="js_pop.js " type="text/javascript">'
> br += '</SCRIPT>'
> var op = '<SCRIPT language=Javasc ript'
> op += 'src="js_pop-op.js" type="text/javascript">'
> op += '</SCRIPT>'
> if (navigator.user Agent.indexOf(' Opera') != -1 ) {
> document.write( op)
> } else {
> document.write( br)
> }
> //-->
> </SCRIPT>
>
> I pulled a script with an identical construction from the JS Bible:
>
> function reWrite() {
> var newContent = â€œ<HTML><HEAD> <TITLE>A New Doc</TITLE></HEAD>â€
> newContent += â€œ<BODY BGCOLOR=â€™aqua â€™><H1>This document is brand new.</H1>â€
> newContent += â€œClick the Back button to see original document.â€
> newContent += â€œ</BODY></HTML>â€
> document.write( newContent)
> }
> what's wrong with my construction?? error msg I get in IE says
> "undetermin ated string constant".. and the other weird thing is that part
> of the script appears at the very top of the page, this is what appears:
>
> " var op = "[/color]

When the browser sees

br += '</SCRIPT>'

it stupidly thinks that </SCRIPT> is the end of the script. So what the compiler
sees is

br += '

which looks like an unterminated string constant and the rest of the script is
displayed as text. The moral of that is that you must dirty up the close script
tag so that the browser will not behave so stupidly. I recommend inserting a \
before the >. Others like to put it before the slash. I think it is better to
put it before the > because that also solves a related problem with XML CDATA.

br += '</script\>';

jslint checks for this. http://www.crockford.com/javascript/lint.html

Get rid of the //-->. It is a waste of space. The latest style is to use
lowercase in the tags.

**Richard Cornford** · Jul 20 '05, 08:48 AM

Re: detecting browser

"Frances Del Rio" <fdr58@yahoo.co m> wrote in message
news:oprrnygde0 b3v73v@news.cis .dfn.de...
When a web browsers finds an opening script tag like:-
[color=blue]
> <SCRIPT language=JavaSc ript type="text/javascript">[/color]

It has to decide how much of what follows to send to the JavaScript
interpreter. It does that by looking for - </SCRIPT> - in the HTML.
[color=blue]
> var br = '<SCRIPT language=Javasc ript'
> br += 'src="js_pop.js " type="text/javascript">'[/color]

And it finds it here:-
[color=blue]
> br += '</SCRIPT>'[/color]

To use the closing HTML script tag in a JavaScript string you need to
make it look like something else. Using escape characters can be
effective - <\/script> - or </script\> -.

<snip>

Richard.

**Jim Ley** · Jul 20 '05, 08:49 AM

Re: detecting browser

On 02 Jul 2003 13:26:19 +0200, Lasse Reichstein Nielsen
<lrn@hotpop.com > wrote:
[color=blue]
>"Douglas Crockford" <nospam@laserli nk.net> writes:
>[color=green]
>> Others like to put it before the slash. I think it is better to
>> put it before the > because that also solves a related problem with XML CDATA.
>>
>> br += '</script\>';[/color]
>
>The most suprising thing is that it works. According to specification,
>what terminates the script content is the "end tag open", i.e., "</".[/color]

I think it works because of error correction in the browser, they see
the ETAGO, but because it's not followed by SCRIPT> then they know
it's not what the author intended.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

**Lasse Reichstein Nielsen** · Jul 20 '05, 08:53 AM

Re: detecting browser

Frances Del Rio <fdr58@yahoo.co m> writes:
[color=blue]
> the reason for this whole thing (which anyway was a good learning
> exercise) is that Opera starts counting the screen.availWid th at the
> left of the BROWSER WINDOW, not the entire screen, they way other
> browsers do..[/color]

They do? It would have been great, but I don't think it is so.
I get 1600 as the value of "screen.availWi dth", which is the
width of the entire screen. Since I run Opera in MDI, the entire
screen isn't "available" , and anything based on the screen size
will most likely fail.
[color=blue]
> so that if you have the left panel open (where list of
> e-mail folders, newsgroups, contacts, etc appear) this left panel
> doesn't count towards screen.availWid th in Opera...[/color]

I see no difference between having the sidebar open or not.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit. html>
'Faith without judgement merely degrades the spirit divine.'

**Frances Del Rio** · Jul 20 '05, 08:54 AM

Re: detecting browser

I also get the right valuation for screen.availWid th in Opera (in my case
1024), but still if left panel is open window shows up further to the right
than it otherwise would.. check out

404 Not Found

http://www.francesdelrio.com/hbl/index2.html

(scroll down & click where it says "testimonia ls")
(am on whatever latest version of Opera is on W98..)

I think if I found a way to center pop-ups on screen I wd run into same
problem w/Opera... thank you for yr response... Frances

On 06 Jul 2003 18:47:12 +0200, Lasse Reichstein Nielsen <lrn@hotpop.com >
wrote:
[color=blue]
> Frances Del Rio <fdr58@yahoo.co m> writes:
>[color=green]
>> the reason for this whole thing (which anyway was a good learning
>> exercise) is that Opera starts counting the screen.availWid th at the
>> left of the BROWSER WINDOW, not the entire screen, they way other
>> browsers do..[/color]
>
> They do? It would have been great, but I don't think it is so.
> I get 1600 as the value of "screen.availWi dth", which is the width of the
> entire screen. Since I run Opera in MDI, the entire
> screen isn't "available" , and anything based on the screen size
> will most likely fail.
>[color=green]
>> so that if you have the left panel open (where list of
>> e-mail folders, newsgroups, contacts, etc appear) this left panel
>> doesn't count towards screen.availWid th in Opera...[/color]
>
> I see no difference between having the sidebar open or not.
> /L[/color]

**Richard Cornford** · Jul 20 '05, 08:54 AM

Re: detecting browser

"Frances Del Rio" <fdr58@yahoo.co m> wrote in message
news:oprrw36ofa b3v73v@news.cis .dfn.de...
<snip>[color=blue]
>I think if I found a way to center pop-ups on screen I wd run
>into same problem w/Opera...[/color]
<snip>

Yes you would. Opera positions new window relative to it's workspace
area and not the screen. But there are other browsers that provide less
than accurate and useful information in screen.availWid th/Height.
Currently I often find that some script authors attempt to centre a
window in Opera results in it appearing 3/4 out of the display area,
rendering its contents unreadable; the opposite of the desired effect.

This centring a window on screen idea is fatally flawed anyway, on
multi-monitor displays the rectangle representing the desktop dimensions
may not all be displayable on the available monitors and opening a
pop-up on a neighbouring monitor will not bring it to the users
attention. While opening a pop-up so it overlaps two or more monitors
will not make it easily read.

It strikes me that the sensible place to open a new window, if you want
it to immediately come to the users attention, is over the existing
window because that it where the user is looking at the moment they
trigger the action that opens the window. As the majority of browsers
will open a new window over the existing one if not asked to put it
somewhere else it would probably more reliably place a new window where
the user could see it if no position instructions were sent to the
window.open command at all.

Of course these days there is no reason to expect a call to the
window.open function to result in a new window being opened at all so
the question of where the window would have opened becomes moot.

Richard.
--

Example JavaScript DOM listings for: Opera 7.11,
Mozilla 1.2 and ICEbrowser 5.4
<URL: http://www.litotes.demon.co.uk/dom_root.html >

**Frances Del Rio** · Jul 20 '05, 08:54 AM

Re: detecting browser

Richard Cornford wrote:[color=blue]
> "Frances Del Rio" <fdr58@yahoo.co m> wrote in message
> news:oprrw36ofa b3v73v@news.cis .dfn.de...
> <snip>
>[color=green]
>>I think if I found a way to center pop-ups on screen I wd run
>>into same problem w/Opera...[/color]
>
> <snip>
>
> Yes you would. Opera positions new window relative to it's workspace
> area and not the screen. But there are other browsers that provide less
> than accurate and useful information in screen.availWid th/Height.
> Currently I often find that some script authors attempt to centre a
> window in Opera results in it appearing 3/4 out of the display area,
> rendering its contents unreadable; the opposite of the desired effect.[/color]

Thank you. This answers Lasse's last post in this thread....
[color=blue]
> Of course these days there is no reason to expect a call to the
> window.open function to result in a new window being opened at all[/color]

excuse me????

so[color=blue]
> the question of where the window would have opened becomes moot.
>[/color]

thanks for yr response..... Frances

**Frances Del Rio** · Jul 20 '05, 08:55 AM

Re: detecting browser

Richard Cornford wrote:[color=blue]
> "Frances Del Rio" <fdr58@yahoo.co m> wrote in message
> news:bec6h8$3gs tt$1@ID-127847.news.dfn cis.de...
> <snip>
>[color=green][color=darkred]
>>>Of course these days there is no reason to expect a call to the
>>>window.ope n function to result in a new window being opened at
>>>all[/color]
>>
>>excuse me????[/color]
>
> <snip>
>
> After being unnecessarily barraged with advertising pop-up window many
> users have decided that they have had enough and have done something
> about it. They either use a browser that provides them with control over
> the opening of pop-up window or they use separate pop-up blocking
> software. (There are also an increasing number of PDA browsers which
> often cannot open new window.)[/color]

yes but wait a minute, doesn't this pop-up-blocking sw distinguish betw.
UNSOLICITED pop-ups and pop-ups that open when user clicks somewhere?
I think it's great that there is sw that blocks unsolicited pop-ups
(although to a point, there are cases when unsol. pop-ups open that are
not advertising, aren't there?) I love to use pop-ups, and know how to
do them well, have used them a lot, though not excessively; I think if
you know how to use pop-ups right you can do good UI design with them...
thank you for yr response....

**Jim Ley** · Jul 20 '05, 08:55 AM

Re: detecting browser

On Tue, 08 Jul 2003 09:57:17 -0400, Frances Del Rio <fdr58@yahoo.co m>
wrote:
[color=blue]
>yes but wait a minute, doesn't this pop-up-blocking sw distinguish betw.
>UNSOLICITED pop-ups and pop-ups that open when user clicks somewhere?[/color]

Some do, some don't...
[color=blue]
> I love to use pop-ups, and know how to
>do them well, have used them a lot, though not excessively; I think if
>you know how to use pop-ups right you can do good UI design with them...
>thank you for yr response....[/color]

I know my don't, mine just redirect the open to the same window, or do
nothing depending on config.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

**Richard Cornford** · Jul 20 '05, 08:55 AM

Re: detecting browser

"Frances Del Rio" <fdr58@yahoo.co m> wrote in message
news:beeioo$4ck jv$1@ID-127847.news.dfn cis.de...
<snip>[color=blue]
>yes but wait a minute, doesn't this pop-up-blocking sw
>distinguish betw. UNSOLICITED pop-ups and pop-ups that
>open when user clicks somewhere? I think it's great that
>there is sw that blocks unsolicited pop-ups (although to
>a point, there are cases when unsol. pop-ups open that are
>not advertising, aren't there?) I love to use pop-ups,
>and know how to do them well, have used them a lot, though
>not excessively; I think if you know how to use pop-ups
>right you can do good UI design with them...[/color]

There are several types of pop-up blocker (and browsers offering that
option) and they have user configurable settings so how any one behaves
is largely up to the user. Content inserting/re-writing proxies work be
replacing the window.open function and in my experience can be
configured to just block in-line and onload/unload window opening but
they can also prevent all window opening (though they can also force new
URLs provided for new window to open in the current window or do things
like overriding the "features" list so any new windows have the chrome
that the user desired). The content inserting proxies that I have looked
at tended to default to blocking all new windows and required user
adjustment to get them to be more tolerant.

External pop-up killers work by detecting new instances of the browsers
and do not know anything about the actions or script that is trying to
open the window. I recently read of an external pop-up blocker that
required the user to hold down the Ctrl key if they actually wanted a
new window. Of course that would require that they knew in advance that
a link was going to try to open in a new window so they could hold Ctrl
down while they clicked it. Making an external pop-up blocker tolerant
of new window seems to involve providing it with a list of sites which
it will allow to open new window (though there are a lot of variations
on how this is done, some are "smarter" and more automated than others).

Browser pop-up blocking also varies. Mozilla allows fine grained control
over window opening and window chrome, Opera is also flexible but
Konqueror 2 and ICEBrowser only offer a blanket window.open disable
option.

For someone who does not like pop-ups they are all "unsolicite d" and the
small PDA browsers that cannot open new window just cannot open new
window (as the hardware gets more capable and cheaper they will become
ever more common).

There is also tabbed browsing in an increasing number of browsers
(including embedded IEs) where a script opened pop-up might appear as a
new tab (displayed over the entire browser viewport area). That will
often make a UI that might make sense as a number of distinct window
distributed over a screen for simultaneous viewing into a very different
beast and of questionable worth.

If a web site stays within its original window it will be both reliable
and reasonably predictable (the user will often still have the option of
right clicking and opening the next page in a new window/tab if they
want anyway). Attempt to open a new window and you cannot determine the
outcome beforehand or verify what actually happened afterwards, and it
is difficult to design a UI if you cannot predict or detect the outcome
of user actions.

Richard.

detecting browser

detecting browser

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment