New window - exact size...

Discussion in 'HTML' started by Domestos, Jun 28, 2005.

  1. Domestos

    Domestos Guest

    Hi all,

    I need to open a HTML/PHP window with the dimensions 300x300 after clicking
    an image on the source page. How on earth do I do this - I have searched
    around the web and found various muck that hasn't helped me much...

    Ideally I would like the window to appear without the menus and icons...

    Thanks
    Andy Mak
    Domestos, Jun 28, 2005
    #1
    1. Advertising

  2. Domestos wrote:
    > Hi all,
    >
    > I need to open a HTML/PHP window with the dimensions 300x300 after clicking
    > an image on the source page. How on earth do I do this - I have searched
    > around the web and found various muck that hasn't helped me much...
    >
    > Ideally I would like the window to appear without the menus and icons...

    Use a "make new window" script with js.
    e.g.
    Between the <head>
    <script type="text/js">
    var newWindow
    function makeNewWindow() {
    newWindow =
    window.open("url","sub","toolbar=no,location=no,resizable=no,status=no,scrollbars=no,menubar=no,personalbar=no,widht=300px,height=300px")
    }
    </script>

    Some on the source file
    <a href="url_image" onClick="makeNewWindow1();return false"><img
    src"url_thumbnail"></a>
    --
    Edwin van der Vaart
    http://www.semi-conductor.nl/ Links to Semiconductors sites
    http://www.evandervaart.nl/ Under construction
    Edwin van der Vaart, Jun 28, 2005
    #2
    1. Advertising

  3. Edwin van der Vaart a écrit :
    > Domestos wrote:
    >
    >> Hi all,
    >>
    >> I need to open a HTML/PHP window with the dimensions 300x300 after
    >> clicking
    >> an image on the source page. How on earth do I do this - I have searched
    >> around the web and found various muck that hasn't helped me much...
    >>
    >> Ideally I would like the window to appear without the menus and icons...

    >
    > Use a "make new window" script with js.
    > e.g.
    > Between the <head>
    > <script type="text/js">


    It should be

    <script type="text/javascript">

    > var newWindow


    It's better to set the global variable to null and not to undefined.

    var newWindow = null;

    > function makeNewWindow() {
    > newWindow =
    > window.open("url","sub","toolbar=no,location=no,resizable=no,status=no,scrollbars=no,menubar=no,personalbar=no,widht=300px,height=300px")
    >


    If the windowFeatures string list is not empty, then there is no need to
    set all these features to no. Also, width is mispelled and width and
    height values as given will be ignored since px is not parsed by
    browsers. So the result (window dimensions) will be unknown in browsers
    here. Since you've specifically made that window non-resizable and
    non-scrollable, you're possibly going to create unaccessible and
    unusable windows most of the time for users.
    It's always best to set resizable to yes and scrollbars to yes: if your
    code has problems, whatever they are, the created window will always be
    usable and accessible.
    Your code also ignore margin set on root elements for secondary windows.
    It's 15px 10px for MSIE users. So here, even if your windowFeatures
    string list code was to be correct, at least 30px of the image would be
    clipped in MSIE.

    Finally, your code is not reusable: it will only work for the url_image.
    It will not work if javascript is disabled either since target is not
    defined but is in the function.
    Also, if the window is already opened, when clicking the link, the
    already opened window will not be brought up back on top and that is the
    nr 1 usability problem for users with sites opening new windows.

    The example
    http://developer-test.mozilla.org/en/docs/window.open#Best_practices
    solve all these issues.

    > }
    > </script>
    >
    > Some on the source file
    > <a href="url_image" onClick="makeNewWindow1();return false"><img
    > src"url_thumbnail"></a>



    Gérard
    --
    remove blah to email me
    =?ISO-8859-1?Q?G=E9rard_Talbot?=, Jun 28, 2005
    #3
  4. On 28/06/2005 23:24, Gérard Talbot wrote:

    [snip]

    > It's better to set the global variable to null and not to undefined.


    I fail to see why. The variable will type-convert to boolean false in
    just the same way, and the code that you cite doesn't attempt to make
    any distinction between two values.

    The rest I agree with, though if we're talking best practices, the code
    suggested by Mozilla should also test to make sure that the open and
    focus methods exist before calling them in case a user is using a proxy
    or third-party pop-up blocker that effectively deletes or fakes the
    former, thus making the latter non-existent.

    [snip]

    Mike

    --
    Michael Winter
    Replace ".invalid" with ".uk" to reply by e-mail.
    Michael Winter, Jun 28, 2005
    #4
  5. Michael Winter wrote :
    > On 28/06/2005 23:24, Gérard Talbot wrote:
    >
    > [snip]
    >
    >> It's better to set the global variable to null and not to undefined.

    >
    >
    > I fail to see why. The variable will type-convert to boolean false in
    > just the same way, and the code that you cite doesn't attempt to make
    > any distinction between two values.
    >


    It's better to initialize the variable to null rather to undefined as
    later parts of the code test for/compare the reference to null and not
    to undefinded. You avoid the browser to type convert that. It's no biggie.

    > The rest I agree with, though if we're talking best practices, the code
    > suggested by Mozilla should also test to make sure that the open and
    > focus methods exist before calling them


    There is no browser that supports window.open() that does not support
    window.focus().

    in case a user is using a proxy
    > or third-party pop-up blocker that effectively deletes or fakes the
    > former, thus making the latter non-existent.
    >
    > [snip]
    >
    > Mike
    >



    I'm not saying you're wrong about what you say up here about open being
    faked: I just do not know about that particular issue.
    [...After deeper thinking...] If open() is faked, then
    WindowObjectReference will be null and the WindowObjectReference.focus()
    will create a js error.

    Gérard
    --
    remove blah to email me
    =?ISO-8859-1?Q?G=E9rard_Talbot?=, Jun 29, 2005
    #5
  6. On 29/06/2005 00:14, Gérard Talbot wrote:

    [snip]

    > It's better to initialize the variable to null rather to undefined as
    > later parts of the code test for/compare the reference to null and not
    > to undefinded.


    That comparison is equivalent. I should have pre-empted that in my
    previous post - my apologies. See section 11.9.3 - The Abstract Equality
    Comparison Algorithm[1] in ECMA-262 3rd Ed., specifically steps 1, 14,
    and 15.

    [snip]

    > There is no browser that supports window.open() that does not support
    > window.focus().


    The issue isn't browser support as such, but that of pop-up blockers
    (which is why I mentioned them). However, your statement is quite a
    wide-ranging one that is difficult to substantiate either way.

    [snip]

    > If open() is faked, then WindowObjectReference will be null and the
    > WindowObjectReference.focus() will create a js error.


    Not necessarily. It is known that there are pop-up blockers which
    produce code that returns non-null values from overridden open methods.
    These resulting objects are usually made to appear like a global
    (window) object, and may in fact be synonymous with the global object
    for the current browser/tab instance, but not always. As I said, if
    we're talking best practice then code should prepare itself for these
    possibilities.

    If you're really interested, read through the archive of
    comp.lang.javascript on the subject of pop-up blockers.

    Mike


    [1] The Abstract Equality Comparison Algorithm

    The comparison x == y, where x and y are values, produces
    true or false. Such a comparison is performed as follows:

    1. If Type(x) is different from Type(y), go to step 14.
    ...
    14. If x is null and y is undefined, return true.
    15. If x is undefined and y is null, return true.

    --
    Michael Winter
    Replace ".invalid" with ".uk" to reply by e-mail.
    Michael Winter, Jun 29, 2005
    #6
  7. Domestos

    John Dunlop Guest

    text/javascript

    Gérard Talbot wrote:

    > Edwin van der Vaart a écrit :
    >
    > > <script type="text/js">

    >
    > It should be
    >
    > <script type="text/javascript">


    What makes you say that?

    --
    Jock
    John Dunlop, Jun 29, 2005
    #7
  8. Re: text/javascript

    On 29/06/2005 22:00, John Dunlop wrote:

    > Gérard Talbot wrote:
    >
    >> Edwin van der Vaart a écrit :
    >>
    >>> <script type="text/js">

    >>
    >> It should be
    >>
    >> <script type="text/javascript">


    In truth, there is no correct MIME type as none have been officially
    registered. However, there are two widely recognised values:
    text/javascript and application/x-javascript. I prefer the former, but
    Apache, for example, uses the latter by default. I'm not sure which is
    the most appropriate (in terms of application versus text).

    > What makes you say that?


    Well try using the first with a very simple script:

    <script type="text/js">
    alert('Media type acceptable');
    </script>

    I doubt you'll find it working in any browser as they correctly reject a
    script type that they don't understand. You'll have more luck with the
    two I mention above (though IE rejects the application type).

    Mike

    --
    Michael Winter
    Replace ".invalid" with ".uk" to reply by e-mail.
    Michael Winter, Jun 29, 2005
    #8
  9. Re: text/javascript

    Michael Winter <> wrote:

    >>>> <script type="text/js">
    >>>
    >>> It should be
    >>>
    >>> <script type="text/javascript">

    >
    > In truth, there is no correct MIME type as none have been
    > officially registered.


    I read this just today: <http://www1.ietf.org/mail-archive/web/ietf-
    announce/current/msg01349.html>

    --
    David Håsäther
    David Håsäther, Jun 29, 2005
    #9
  10. Domestos

    John Dunlop Guest

    Re: text/javascript

    Michael Winter wrote:

    [about <text/javascript>]

    > there is no correct MIME type as none have been officially registered.


    Yes, right, though I wouldn't be bringing notions of
    'correctness' into it!

    > However, there are two widely recognised values: text/javascript and
    > application/x-javascript.


    The first violates MIME, and the second is a private value.

    The link David gave - I hadn't read it until today either -
    suggests <application/javascript> will shortly be registered.

    > I'm not sure which is the most appropriate (in terms of application versus
    > text).


    Bjöern's draft, if it makes it, would render <text/javascript>
    OBSOLETE, 'no longer believed appropriate for use'. Tallyho!

    --
    Jock
    John Dunlop, Jun 30, 2005
    #10
  11. Re: text/javascript

    On 30/06/2005 01:49, John Dunlop wrote:

    [snip]

    > The link David gave - I hadn't read it until today either -
    > suggests <application/javascript> will shortly be registered.


    [snip]

    > Bjöern's draft, if it makes it, would render <text/javascript>
    > OBSOLETE, 'no longer believed appropriate for use'. Tallyho!


    It doesn't really make a difference either way. Using a type other than
    text/javascript is likely to leave a script unexecuted, so the
    introduction of application/javascript (and others) won't mean anything
    for quite some time.

    I must say I'm confused though (and I don't expect you to answer this):
    ECMA standardised ECMAScript in 1997. Both JScript, JavaScript, and
    others have since been implementations of that language. Considering
    such widespread use, why on Earth has it taken so long to register a
    MIME type? Particularly as one has been required for use in HTML since
    HTML 4.0 (or thereabouts), and has been around for about as long. It
    would have been significant then, but it is far too late now.

    Mike

    --
    Michael Winter
    Replace ".invalid" with ".uk" to reply by e-mail.
    Michael Winter, Jun 30, 2005
    #11
  12. Domestos

    Ian Rastall Guest

    Re: text/javascript

    On Thu, 30 Jun 2005 01:35:01 GMT, Michael Winter
    <> wrote:

    >It doesn't really make a difference either way. Using a type other than
    >text/javascript is likely to leave a script unexecuted


    That's my take on the issue ... unless we're discussing what should
    be, rather than what is.

    Granted, I've never tried using text/js. Perhaps the browser would
    just default to JavaScript, since that's likely what it'll do without
    a MIME type of any kind.

    Ian
    --
    Was it not a comedy, a strange and stupid
    matter, this repetition, this running around
    in a fateful circle? (Hermann Hesse)
    http://www.bookstacks.org/
    Ian Rastall, Jun 30, 2005
    #12
  13. Re: text/javascript

    On 30/06/2005 02:51, Ian Rastall wrote:

    > On Thu, 30 Jun 2005 01:35:01 GMT, Michael Winter
    > <> wrote:
    >
    >> It doesn't really make a difference either way. Using a type other
    >> than text/javascript is likely to leave a script unexecuted

    >
    > That's my take on the issue ... unless we're discussing what should
    > be, rather than what is.


    I'm usually partial to those debates :D, but I suppose the only details
    I'm interested in here is why didn't this occur sooner.

    > Granted, I've never tried using text/js.


    I did. After all the text doesn't need to be extensive: a browser will
    either do something or it won't, and neither Firefox nor IE did.

    > Perhaps the browser would just default to JavaScript, since that's
    > likely what it'll do without a MIME type of any kind.


    That couldn't be allowed, though. There's no rule saying that
    ECMAScript-derivatives are the only scripting languages permissible on
    the Web. After all, IE also implements VBScript. So, to simply ignore
    the type attribute when specified could result in attempts to execute a
    script that truly isn't understood.

    Mike

    --
    Michael Winter
    Replace ".invalid" with ".uk" to reply by e-mail.
    Michael Winter, Jun 30, 2005
    #13
  14. Domestos

    Ian Rastall Guest

    Re: text/javascript

    On Thu, 30 Jun 2005 02:06:09 GMT, Michael Winter
    <> wrote:

    >to simply ignore the type attribute when specified could
    >result in attempts to execute a script that truly isn't understood.


    True. I'm thinking of the behavior of browsers when nothing is
    specified at all. But I'm a bit over my head in this discussion, truth
    be told. :) This is getting into the realm of IETF and W3C stuff!

    Ian
    --
    Was it not a comedy, a strange and stupid
    matter, this repetition, this running around
    in a fateful circle? (Hermann Hesse)
    http://www.bookstacks.org/
    Ian Rastall, Jun 30, 2005
    #14
  15. Domestos

    John Dunlop Guest

    Re: text/javascript

    Michael Winter wrote:

    > Using a type other than text/javascript is likely to leave a script
    > unexecuted, so the introduction of application/javascript (and others)
    > won't mean anything for quite some time.


    I can see one workaround - and that's just what it is, mind
    you, a *workaround* - though it's far from ideal. Write a
    custom DTD in which the <type> attribute of SCRIPT is
    optional. Then you can send your javascript files with the
    MIME type <application/javascript> and have them executed by
    at least some browsers. Two points to note, however: (1) you
    have to use external scripts (which is No Bad Thing, I hear
    you say), and (2) you can't call your document HTML4.01.

    --
    Jock
    John Dunlop, Jun 30, 2005
    #15
  16. Re: text/javascript

    On 30/06/2005 08:44, John Dunlop wrote:

    > I can see one workaround [for unrecognised types:] Write a custom DTD
    > in which the <type> attribute of SCRIPT is optional.


    I don't really see that working, though. Browsers don't actually read
    the DTD, so they're unlikely to care whether you want the type attribute
    to be treated optionally. Moreover, and as I said to Ian, an omitted
    type attribute is different from a specified, but unrecognised, MIME
    type value. The former could permit a reasonable guess (some ECMAScript
    derivative), but the latter must cause a script to be ignored.

    > Then you can send your javascript files with the MIME type
    > <application/javascript> and have them executed by at least some
    > browsers.


    Care to name any? :)

    I could be wrong of course, and I would have no problem with that, but
    as I see it these registrations are less than useless for the time being.

    Mike

    --
    Michael Winter
    Replace ".invalid" with ".uk" to reply by e-mail.
    Michael Winter, Jun 30, 2005
    #16
  17. Re: text/javascript

    Michael Winter wrote:
    > On 30/06/2005 08:44, John Dunlop wrote:

    <snip>
    >> Then you can send your javascript files with the MIME
    >> type <application/javascript> and have them executed
    >> by at least some browsers.

    >
    > Care to name any? :)
    >
    > I could be wrong of course, and I would have no problem
    > with that, but as I see it these registrations are less
    > than useless for the time being.


    There are two very distinct aspects to this. The HTTP headers that
    accompany an external JS file, and the TYPE attribute as required by
    HTML in a SCRIPT element's opening tag.

    Some time ago, in response to having the absence of any official MIME
    type for javascript pointed out to me, I did some experiments sending JS
    files to browsers with MIME types that varied from the totally
    fictitious, through the utterly inappropriate, to the wrong but not too
    unexpected (text/html, text/plain and the like). And I could not find a
    browser that would not happily swallow and execute the script file
    regardless of the MIME type asserted.

    Granted I did not use any browsers as old as Netscape 3 for those test,
    and I understand that Netscape 3 did have an attitude towards the MIME
    type of external JS files (preferring application/x-javascript).

    However, in the absence of any official MIME type for javascript it is
    not surprising that browsers should appear to have a habit of disregard
    that header entirely and just treating whatever is sent as potential JS
    source code (which is also why 404 error pages asserting that they are
    text/html still get interpreted as JS and result in apparent syntax
    errors). There is little else they could reasonably do.

    As a result sending application/javascript as an HTTP header would be as
    insignificant as sending anything else, and so harmless (and, if
    officially adopted as the correct MIME type, theoretically the right
    thing to do).

    The HTML TYPE attribute of SCRIPT elements was obviously necessary if
    the W3C didn't want to tie web browsers to a single script type, but it
    was a mistake for the HTML spec to reference an official list of MIME
    types and then cite an exempt text/javascript MIME type that did not
    appear in that list. The effect was to leave text/javascript as the only
    possible TYPE value for use in HTML with javascript, but without any
    real reason for its use except that it had been provided as an example
    along side the words "Authors must supply a value for this attribute".

    The practical upshot is that if a SCRIPT element is to have a TYPE
    attribute, and be expected to treat its contents or referenced file as
    javascript, it is going to need to be TYPE="text/javascript" to work
    cross browsers (at least for the next 3 or 4 years). But then I suppose
    that if TYPE is intended to express a MIME type then an HTTP header that
    is also supposed to be a MIME type should probably assert the same (even
    if fictional) type.

    It's a mess that should have been sorted out years ago, but may now
    never be satisfactorily resolved.

    Richard.
    Richard Cornford, Jun 30, 2005
    #17
  18. Domestos

    John Dunlop Guest

    Re: text/javascript

    Michael Winter wrote:

    > On 30/06/2005 08:44, John Dunlop wrote:
    >
    > > I can see one workaround [for unrecognised types:] Write a custom DTD
    > > in which the <type> attribute of SCRIPT is optional.


    [By the way, I should've mentioned, I don't approve of my
    suggestion at all. Let it be known, I'm in no way
    recommending it!]

    > I don't really see that working, though. Browsers don't actually read
    > the DTD, so they're unlikely to care whether you want the type attribute
    > to be treated optionally.


    Well, that was really for the purposes of validation, to get
    round SCRIPT's obligatory <type> attribute.

    > Moreover, and as I said to Ian, an omitted type attribute is different
    > from a specified, but unrecognised, MIME type value.


    Yes. In my suggestion the <type> attribute is left out. The
    only place the soon-to-be MIME type features is in the HTTP
    Content-Type header.

    > The former could permit a reasonable guess (some ECMAScript
    > derivative), but the latter must cause a script to be ignored.


    So, in your words, as it falls into the former category, my
    suggestion 'could permit a reasonable guess'?


    PS, where does the spec say, other than in informative notes -
    and I'm *assuming* the note in sec. 6.7 is informative - that
    the <type> attribute takes a value of a MIME type as defined
    in RFCs2045-49? Are normative references normative if they
    occur in informative notes?

    --
    Jock
    John Dunlop, Jun 30, 2005
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. UJ
    Replies:
    2
    Views:
    7,489
    John Timney \(ASP.NET MVP\)
    Jun 27, 2005
  2. bob
    Replies:
    4
    Views:
    9,694
    nice.guy.nige
    Jun 18, 2004
  3. tshad
    Replies:
    2
    Views:
    412
    tshad
    Feb 8, 2007
  4. Wade Ward

    file of exact size

    Wade Ward, Sep 15, 2007, in forum: C Programming
    Replies:
    47
    Views:
    1,203
    Army1987
    Sep 17, 2007
  5. Replies:
    5
    Views:
    460
    christian.bau
    Feb 22, 2008
Loading...

Share This Page