Blog Comments

  1. coothead's Avatar
    Hi there molendijk,

    Have you considered those users who may have javascript disabled?

    Your site does not produce a white flash (flicker) when the user navigates.

    Unfortunately, the user is unable to navigate, as the site does not appear at all.


    coothead
  2. traq's Avatar
    Quote Originally Posted by molendijk
    if the dialog could be used to trigger some code that 'overrides' the browser's normal behavior i.e. that tells Safari, in this particular case, to abandon its normal behavior ... But creating such code seems impossible, for reasos of security.[sic]
    I hadn't checked if it was possible or not. I'd imagined it would be, but... ah well. c'est la vie.
  3. molendijk's Avatar
    Hello traq, thanks for the response.
    The general idea is that, as soon as we (as developers) know that a browser will refuse to perform a 'legal' action (such as opening a popup or a new tab after a click on a link), we write if (typeof(some_action)=='undefined'){alert("bla")}, where bla is the info needed by the user to make things (some_action) work 'as they should'.
    In our case, using a dialog box rather than an alert would only be an improvement if the dialog could be used to trigger some code that 'overrides' the browser's normal behavior i.e. that tells Safari, in this particular case, to abandon its normal behavior in favor of opening a popup or a new tab. But creating such code seems impossible, for reasos of security.
    I should add that there's no real need to anticipate on what the browser may do or refuse, since for every event we want to be accomplished we can add if (typeof(some_action)=='undefined'){alert("bla")} to our code. Most of the time, this line will be redundant (= no alert, because the action will not be classified as 'undefined' by the browser), but it never hurts.
    Arie.
  4. traq's Avatar
    Quote Originally Posted by molendijk
    Sometimes, browsers / popup blockers make mistakes and block windows or tabs although they are explicitly requested by the user.
    I think the underlying problem is that it's impossible for the browser to tell what the user's intention really was. Browsers are forced to speculate on the basis of known behaviors (both legitimate uses and scams/dishonest uses).

    -------------------

    I wonder if you could use a confirmation dialog instead of an alert, and simply ask if the user wants to open the popup...? That ought to be considered an "explicit request," right? And it would avoid the need to fiddle with settings and reload the page.
  5. molendijk's Avatar
    HERE's an elaborated version of some parts of this thread.
    Arie.
  6. molendijk's Avatar
    The demo link doesn't work anymore. Here's a new one:
    http://mesdomaines.nu/eendracht/Navi...ct3/page1.html
    ===
    Arie.
  7. molendijk's Avatar
    John, very useful, thanks!
    Arie.
  8. jscheuer1's Avatar
    I think it's invalid in some DOCTYPES, but works just fine in all of them:
    Code:
    <a href="http://www.google.com/" target="_new">New Google</a>
    BTW, even though you're using javascript: void(0) for the href, you should still return false:

    Code:
    <a href="javascript: void(0)" onclick="window.open('','_new').location.href='http://google.com'; return false;">open Google in new tab</a>
    to prevent partial unloading of the page in some browsers. Some (and not just IE) will stop processing javascript or parts of some javascript. Some will stop processing animated gif. There could be other problems. By having a link that doesn't leave the page but that doesn't return false, the browser is allowed to begin the unload process.

    Personally I prefer letting people know (see it in the status bar for browsers that do that) the link by putting it in the href:

    Code:
    <a href="http://www.google.com/" onclick="window.open('','_new').location.href=this.href; return false;">New Google</a>
    which allows you to use this.href in the onclick event, which has implications for making this a portable/assignable function/event.

    You could alternatively use another tag:

    Code:
    <span title="http://www.google.com/" onclick="window.open('','_new').location.href=this.title;">New Google</span>
    This completely eliminates any concern about the page partially unloading. The tag may be styled to look and act like a link. (cursor:pointer;text-decoration:underline; etc.)

    This also appears to work, at least in Firefox:

    Code:
    <span title="http://www.google.com/" onclick="window.open(this.title, '_new');">New Google</span>
    which tends to indicate that the a tag itself is part of the original problem you mention.
  9. webmasterws's Avatar
    thanks alot very useful player.
  10. Sarutobi sensei's Avatar
    It working for me..thax
  11. molendijk's Avatar
    Quote Originally Posted by mapleleaf
    In reading the article on iframe pixel precision, the light came on and it worked for all browser type that I am testing the web site with; namely not using the viewport variables BUT using 100% for the width and the height. WOW, alll browsers work.
    I'm glad this helped you out.
    ===
    Tot ziens, Arie.
  12. mapleleaf's Avatar
    This is my first post here in the forums and will not be my last!

    This is a great article, iframe pixel precision and it solved an issue that I had.

    In the developing of a web site and using dhtmlwindow, I wanted to use a variable for the viewport of the browsers(I am testing the web site with IE8, FF3.6.8/4.0b4,Opera 10.61, chrome 7.0, avant and Maxthon), it did not work when passing the viewport variables to the function.
    Well it did work on some but not all browser. This had me stumped and I knew the solution is a simple one; too often the simple solutions escape.
    Every page on the web site is W3C validated for xhtml1.1, CSS3, WCAGv2 AAA and section 508 BUT this really stumped me.

    I decided to register at DD having gone a multiple number of times over the years to DD for reference etc.

    In reading the article on iframe pixel precision, the light came on and it worked for all browser type that I am testing the web site with; namely not using the viewport variables BUT using 100% for the width and the height. WOW, alll browsers work.

    Here is how I use the dhtmlwindow function:

    dhtmlwindow.open("ajaxbox", "iframe", ""+a+"", ""+b+"", "width=100%,height=100%,resize=0");

    which btw does also work at the resolutions of 1024x768 and 1280x1024 that I am optimizing the web site for.

    Bedankt

    btw, I was on the beta team in the development of JavaScript by Netscape 1995-1998; becmae their JavaScript Developer's Champion in 1997; moderator for the developer and user javascriot forums AND had the 1st FAQ on JavaScript on the internet on Netscape's web site in 1997.

    tot ziens
  13. molendijk's Avatar
    It's better to post your question here.
    ===
    Arie.
  14. molendijk's Avatar
    No, it's not: this thread is not about the embeddable player, but about the chromeless player.
    ===
    Arie.
  15. molendijk's Avatar
    Quote Originally Posted by jscheuer1
    I was just using this code in an actual job. Not the chopped stuff, but the valid cross browser tag. I discovered that these highlighted parts don't really seem to be required:
    Code:
    <!--[if IE]>
    <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" style="position:absolute;left:20%; top:20%; height:80%;width:80%">
    <![endif]-->
    <!--[if !IE]><!-->
    <object type="application/x-shockwave-flash" style="position:absolute;left:20%; top:20%; height:80%;width:80%" data="http://swf.tubechop.com/tubechop.swf?vurl=rw1j0NsIIeE&amp;start=164&amp;end=199&amp;cid=28051" >
    <!--<![endif]-->
    <param name="movie" value="http://swf.tubechop.com/tubechop.swf?vurl=rw1j0NsIIeE&amp;start=164&amp;end=199&amp;cid=28051" >
    <param name="allowFullScreen" value="true" >
    <param name="wmode" value="transparent" >
    </object>
    Thanks! You seem to be right there!
    Quote Originally Posted by jscheuer1
    Oh, and another thing, I think this is a TOS violation.
    But then the whole service provided by http://tubechop.com is a violation of the TouTube TOS!(?).
    ===
    Arie.
  16. molendijk's Avatar
    I'll react to the last two comments (by jscheuer) as soon as I can. At this moment, I'm an indirect victim of the ash cloud.
    ===
    Arie.
  17. jscheuer1's Avatar
    I think this is a violation of the YouTube TOS:

    You agree not to access User Submissions (defined below) or YouTube Content through any technology or means other than the video playback pages of the Website itself, the YouTube Embeddable Player, or other explicitly authorized means YouTube may designate.

    If you use the YouTube Embeddable Player on your website, you must include a prominent link back to the YouTube website on the pages containing the Embeddable Player and you may not modify, build upon, or block any portion of the Embeddable Player in any way.
  18. jscheuer1's Avatar
    Oh, and another thing, I think this is a TOS violation. From the YouTube TOS:

    You agree not to access User Submissions (defined below) or YouTube Content through any technology or means other than the video playback pages of the Website itself, the YouTube Embeddable Player, or other explicitly authorized means YouTube may designate.

    If you use the YouTube Embeddable Player on your website, you must include a prominent link back to the YouTube website on the pages containing the Embeddable Player and you may not modify, build upon, or block any portion of the Embeddable Player in any way.
  19. jscheuer1's Avatar
    I was just using this code in an actual job. Not the chopped stuff, but the valid cross browser tag. I discovered that these highlighted parts don't really seem to be required:

    Code:
    <!--[if IE]>
    <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" style="position:absolute;left:20%; top:20%; height:80%;width:80%">
    <![endif]-->
    <!--[if !IE]><!-->
    <object type="application/x-shockwave-flash" style="position:absolute;left:20%; top:20%; height:80%;width:80%" data="http://swf.tubechop.com/tubechop.swf?vurl=rw1j0NsIIeE&amp;start=164&amp;end=199&amp;cid=28051" >
    <!--<![endif]-->
    <param name="movie" value="http://swf.tubechop.com/tubechop.swf?vurl=rw1j0NsIIeE&amp;start=164&amp;end=199&amp;cid=28051" >
    <param name="allowFullScreen" value="true" >
    <param name="wmode" value="transparent" >
    </object>
    They're for getting it to work in IE while at the same time not making others barf, right? Well without them it worked fine in IE (5.5 thru 8), Opera (10), Firefox (3), Chrome (4), and Safari (4 Win).

    Additionally, if Flash wasn't installed in IE, and you use those highlighted parts, you end up with a stray fragment of a comment, something like:

    <!--<![endif]
    showing up on the page.
  20. molendijk's Avatar
    I'm afraid I didn't explain very well what I had in mind.
    If we have something like this:
    Code:
    <head>
    <script type="text/javascript">
    function HttpRequest(url){
    var pageRequest = false //variable to hold ajax object
    /*@cc_on
    @if (@_jscript_version >= 5)
    try {
    pageRequest = new ActiveXObject("Msxml2.XMLHTTP")
    }
    catch (e){
    try {
    pageRequest = new ActiveXObject("Microsoft.XMLHTTP")
    }
    catch (e2){
    pageRequest = false
    }
    }
    @end
    @*/
    
    if (!pageRequest && typeof XMLHttpRequest != 'undefined')
    pageRequest = new XMLHttpRequest()
    
    if (pageRequest){ //if pageRequest is not false
    pageRequest.open('GET', url, false) //get page synchronously
    pageRequest.send(null)
    
    document.write(pageRequest.responseText);
    }
    }
    </script>
    
    </head>
    
    <body>
    
    <a href="javascript:void(0)" onclick = "document.getElementById('external').style.display = 'block'">external page</a> 
    
    <div id="external"  style="display:none;"><script type = "text/javascript">HttpRequest("external.html")</script></div>
    
    </body>
    then clicking on the link (faking an update of the page) gives us the text of the external page PLUS its code. So there's no need to add the script to the (main) page using the DOM.
    (In spite of this, if the external file is a HTML-menu depending partially on javascript, then it may not work well in IE if the menu contains a mixture of internal and external scripts. The workaround is to make all scripts (in the menu) external).
    We would only have to add the script to the main page if we used another inclusion method, like innerHTML or appendChild.
    ===
    Arie
Page 2 of 3 FirstFirst 123 LastLast