Blog Comments

  1. Beverleyh's Avatar
    Well those are certainly much easier than playing "draggy" with the browser window

    Just to help out those who might not see where to get to the responsive view in Firefox;

    - press ALT (in Windows) to display the menu bar if you don't already have it
    - Tools >> Developer >> Resonsive Design View

    OR, press CTRL+Shift+M

    Its funny you posted this when you did Arie - I just was just working on making my Fast Edit website responsive/adaptive and it was very useful to see all the screen widths alongside each other using the Matt Kersley tool:

    Thanks for sharing
    Updated 09-30-2013 at 06:16 PM by Beverleyh
  2. molendijk's Avatar
    Talking about Responsive Web Design:
    you can test your site here.
  3. molendijk's Avatar
    Hi Coothead,
    Thanks for your comment.
    I must say I don't care much about users who have javascript disabled. And for valid reasons.
    Less than 2% of users have javascript turned off, some say it's less tha 0.5%.
    Can we use jquery without javascript enabled? No
    How about e-banking with javascript disabled? Not possible.
    Have you tried DynamicDrive with javascript disabled? Disaster.
    It's not without reason that Firefox 23 has removed the option to disable JavaScript from the Options pane and if you had JavaScript turned off, it has been turned back on.
    It's not without reason that Chrome tells you that turning off javascript is not recommended (when you change settings).
    So if you want my site to appear, don't disable javascript (you can't drive a car without an engine, can you?).
    Updated 09-04-2013 at 11:07 PM by molendijk
  4. 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.

  5. 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.
  6. 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.
  7. 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.
  8. molendijk's Avatar
    HERE's an elaborated version of some parts of this thread.
  9. molendijk's Avatar
    The demo link doesn't work anymore. Here's a new one:
  10. molendijk's Avatar
    John, very useful, thanks!
  11. jscheuer1's Avatar
    I think it's invalid in some DOCTYPES, but works just fine in all of them:
    <a href="" target="_new">New Google</a>
    BTW, even though you're using javascript: void(0) for the href, you should still return false:

    <a href="javascript: void(0)" onclick="'','_new').location.href=''; 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:

    <a href="" onclick="'','_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:

    <span title="" onclick="'','_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:

    <span title="" onclick=", '_new');">New Google</span>
    which tends to indicate that the a tag itself is part of the original problem you mention.
  12. webmasterws's Avatar
    thanks alot very useful player.
  13. Sarutobi sensei's Avatar
    It working for me..thax
  14. 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.
  15. 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:"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.


    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
  16. molendijk's Avatar
    It's better to post your question here.
  17. molendijk's Avatar
    No, it's not: this thread is not about the embeddable player, but about the chromeless player.
  18. 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:
    <!--[if IE]>
    <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" style="position:absolute;left:20%; top:20%; height:80%;width:80%">
    <!--[if !IE]><!-->
    <object type="application/x-shockwave-flash" style="position:absolute;left:20%; top:20%; height:80%;width:80%" data=";start=164&amp;end=199&amp;cid=28051" >
    <param name="movie" value=";start=164&amp;end=199&amp;cid=28051" >
    <param name="allowFullScreen" value="true" >
    <param name="wmode" value="transparent" >
    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 is a violation of the TouTube TOS!(?).
  19. 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.
  20. 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.
Page 2 of 4 FirstFirst 1234 LastLast