Newgrounds.com &mdash; Everything, By Everyone.

Member since: May. 8, 2003
Offline.

Forum Stats: Member; Level 10; Blank Slate

Efficient modal dialogs 2008-05-28 11:21:24 Reply

Recently, I've been trying to look up how to build modal dialogs for web browsers. For those that don't know, Lightbox is an example of a modal dialog. However. Lightbox only works with images. What I need is something that can work with entire HTML pages, flash, etc. Kind of like what Newgrounds itself uses.

However, as I look up resources for building, I notice one thing about virtually every modal dialog web app out there: They nearly all use prototype.js. Normally, I wouldn't mind this but prototype.js is a hefty file and can add to a lot of bandwidth usage depending on how well your site does.

Therefore, I am trying to find examples of modal dialogs for browsers that do NOT use prototype.js, yet are capable of working with HTML pages and Flash, and yet would be organized in such a way that I do not need to have lines upon lines of code on each page just to make it work: instead, I would need only... well, to do what Lightbox does. I include the files onto the page, then just have my links be designed to access the code in these files.

I will admit, I've found a few interesting ways to go about it, but they either had a great deal of overhead or they were designed completely different from what I sought.

Along with all this, I am trying to determine what is the best method for programming the pages themselves: Should I put the content on separate pages and have it when the link is clicked, it then has to load the page? Or should I put the content on the page where the link is, instead having it all load at once and just hiding it until the user clicks on the link? I'm thinking the first option is better in terms of bandwidth management, but I then need to ensure the user knows the content is loading when they click the link...

http://ajaxian.com/archives/announcing-a jax-libraries-api-speed-up-your-ajax-app s-with-googles-infrastructure

Member since: Jul. 23, 2004
Offline.

Forum Stats: Member; Level 16; Blank Slate

Response to Efficient modal dialogs 2008-05-28 11:37:34 Reply

Well, the size of the prototype.js is really a non-issue, since it's cached.

"My software never has bugs. It just develops random features. " - Unknown

[ FluxBB developer | Quickmarks 0.5.1 | Strings & Ints - my blog ]

authorblues

authorblues

Member since: Jun. 21, 2005
Offline.

Forum Stats: Member; Level 12; Blank Slate

Response to Efficient modal dialogs 2008-05-28 11:47:04 Reply

At 5/28/08 11:37 AM, elbekko wrote: Well, the size of the prototype.js is really a non-issue, since it's cached.

Member since: Jul. 23, 2004
Offline.

Forum Stats: Member; Level 16; Blank Slate

Response to Efficient modal dialogs 2008-05-28 12:49:56 Reply

Interesting. Pretty much what Yahoo! does for YUI, but then for alot more frameworks.

"My software never has bugs. It just develops random features. " - Unknown

[ FluxBB developer | Quickmarks 0.5.1 | Strings & Ints - my blog ]

Member since: May. 8, 2003
Offline.

Forum Stats: Member; Level 10; Blank Slate

Response to Efficient modal dialogs 2008-05-29 11:40:32 Reply

I'm trying to make the coding as efficient as I possibly can, thus why I'd like to avoid using prototype.js if I can.

I've been trying to look up how Newgrounds has their modal dialogs done (Since they used them when you want to watch any Flash), as their set-up looks to do what I would need.

Member since: Aug. 14, 2006
Offline.

Forum Stats: Member; Level 05; Blank Slate

Response to Efficient modal dialogs 2008-05-29 13:36:48 Reply

At 5/29/08 11:40 AM, Skye-McCloud wrote: I'm trying to make the coding as efficient as I possibly can, thus why I'd like to avoid using prototype.js if I can.

I've been trying to look up how Newgrounds has their modal dialogs done (Since they used them when you want to watch any Flash), as their set-up looks to do what I would need.

Assuming you avoid using strings javascript is plenty fast enough (for some fucktarded reason regular expressions are faster than string operations... wtf at that). Programming time is expensive. Processor time is dirt cheap and it's not you who's paying the bill.

Frameworks and APIs not only make it easier to code quickly, it makes it easier to code better. Yes, there is overhead but you generally get code that is much easier to maintain and is less prone to errors (assuming you're not using a bad API or Framework).

Anyway, the quickest, easiest method I can think of to show a modal box would be to simply have a fixed positioned model box in the html, with some css to hide it and some javascript to turn off the show/hide css.

Big, BIG downside is that it doesn't work in internet explorer 6 as it doesn't support statically positioned html elements. Of course since it's not going to work in IE 6 anyway, you can safely use pngs with an alpha layer to make a transparent background.

For your interest though, here's some code for the method I described:

<html>
<head>
<style>
html, body{
  width:100%;
  height:100%;
  margin:0px;
}
#overlay{
  display:none;
  position:static;
  top:0px;
  left:0px;
  width:100%;
  height:100%;
  background-image:url('transpng.png');
  z-index:2;
}
div.inner{
  background-color:#000000;
  color:#ffffff;
  width:100px;
  height:100px;
  margin:auto;
}
</style>
<script type="text/javascript">
  function show()
  {
    var overlay = document.getElementById('overlay');
    overlay.style.display = "block";
  }
</script>
</head>
<body>
<div id="overlay">
  <div class="inner">
    Rawr!
  </div>
</div>
<div>
  Hello World
  <br />
  <input type="button" onclick="show()" value="show" />
</div>
</body>
</html>

Only tested in firefox 3 and definitely won't work in IE 6.

Sufficiently advanced incompetence is indistinguishable from malice.

Member since: Aug. 14, 2006
Offline.

Forum Stats: Member; Level 05; Blank Slate

Response to Efficient modal dialogs 2008-05-29 13:40:04 Reply

Dammit, I'm sure I changed the static to fixed... Sorry for double post.

<html>
<head>
<style>
html, body{
  width:100%;
  height:100%;
  margin:0px;
}
#overlay{
  display:none;
  position:fixed;
  top:0px;
  left:0px;
  width:100%;
  height:100%;
  background-image:url('transpng.png');
  z-index:2;
}
div.inner{
  background-color:#000000;
  color:#ffffff;
  width:100px;
  height:100px;
  margin:auto;
}
</style>
<script type="text/javascript">
  function show()
  {
    var overlay = document.getElementById('overlay');
    overlay.style.display = "block";
  }
</script>
</head>
<body>
<div id="overlay">
  <div class="inner">
    Rawr!
  </div>
</div>
<div>
  Hello World
  <br />
  <input type="button" onclick="show()" value="show" />
</div>
</body>
</html>

Anyway as I was saying; stick to APIs/frameworks. Optimising is a noble goal but this isn't the place to do it.

Sufficiently advanced incompetence is indistinguishable from malice.

Member since: May. 8, 2003
Offline.

Forum Stats: Member; Level 10; Blank Slate

Response to Efficient modal dialogs 2008-05-29 15:10:36 Reply

Thanks Bonel. That should get me a jumpstart, at the least.

And while programming time IS expensive, in the end I'm going to work the same amount of time and get paid the same amount. Might as well try to be top-notch because of it.

Member since: May. 8, 2003
Offline.

Forum Stats: Member; Level 10; Blank Slate

Response to Efficient modal dialogs 2008-05-30 14:18:26 Reply

Ok, so I had managed to build what I needed, thanks to what examples I could find on the net and here. Just when I thought I was done, though, my employer asked me to have the code be set up so that when the user clicked outside of the modal dialog it would close. This way, the user wouldn't be required to hit a close button or such. I'm not sure if this is even possible, though, so I figured I'd come back here and ask around.

Member since: Jul. 23, 2004
Offline.

Forum Stats: Member; Level 16; Blank Slate

Response to Efficient modal dialogs 2008-05-30 15:47:14 Reply

You could have a bubbling event handler on both the dialog and the main page. Then you keep track if the dialog's handler is triggered, and if not, close it.

"My software never has bugs. It just develops random features. " - Unknown

[ FluxBB developer | Quickmarks 0.5.1 | Strings & Ints - my blog ]

plasmaz

plasmaz

Member since: Feb. 13, 2007
Offline.

Forum Stats: Member; Level 09; Blank Slate

Response to Efficient modal dialogs 2008-05-30 22:52:58 Reply

You may also want to check out JQuery (http://jquery.com) and its plugin called SimpleModal (http://www.ericmmartin.com/projects/sim plemodal)

Here are some of the demos http://www.ericmmartin.com/simplemodal

- Michael McMullen
Wii Messages: http://www.wii-messages.com

Member since: Aug. 14, 2006
Offline.

Forum Stats: Member; Level 05; Blank Slate

Response to Efficient modal dialogs 2008-05-31 07:40:41 Reply

At 5/30/08 10:52 PM, plasmaz wrote: You may also want to check out JQuery (http://jquery.com) and its plugin called SimpleModal (http://www.ericmmartin.com/projects/sim plemodal)

Here are some of the demos http://www.ericmmartin.com/simplemodal

*slaps head*

Sufficiently advanced incompetence is indistinguishable from malice.

Member since: May. 8, 2003
Offline.

Forum Stats: Member; Level 10; Blank Slate

Response to Efficient modal dialogs 2008-06-02 12:45:48 Reply

At 5/30/08 03:47 PM, elbekko wrote: You could have a bubbling event handler on both the dialog and the main page. Then you keep track if the dialog's handler is triggered, and if not, close it.

Wouldn't this not work if I have Flash contained on the dialog, or would clicks in a Flash app not even be read by the code? Sorry, I'm a bit of a noob when it comes to using Flash in web design.

Member since: Aug. 14, 2006
Offline.

Forum Stats: Member; Level 05; Blank Slate

Response to Efficient modal dialogs 2008-06-02 13:38:19 Reply

At 6/2/08 12:45 PM, Skye-McCloud wrote:
At 5/30/08 03:47 PM, elbekko wrote: You could have a bubbling event handler on both the dialog and the main page. Then you keep track if the dialog's handler is triggered, and if not, close it.
Wouldn't this not work if I have Flash contained on the dialog, or would clicks in a Flash app not even be read by the code? Sorry, I'm a bit of a noob when it comes to using Flash in web design.

Yes, although someone pointed out that setting the wmode property might work in another post. I myself have only ever used it to get around some problems with z-indexes, so I can't really verify it.

If that doesn't work just write a function in flash to call the javascript function and attach it to a mouse listener. It's far less complicated than it sounds:

//Actionscript code
var listener = new Object();
Mouse.addListener( listener );
listener.onClick = function()
{
  getURL( "javascript: your_javascript_function( 'arguements' )", "_self );
}

That'll fire whenever you click inside the flash. There's a better way to call Javascript functions from flash than with getURL, but I can't recall it.

Sufficiently advanced incompetence is indistinguishable from malice.

Member since: Aug. 14, 2006
Offline.

Forum Stats: Member; Level 05; Blank Slate

Response to Efficient modal dialogs 2008-06-02 13:42:11 Reply

At 6/2/08 01:38 PM, BoneIdol wrote: var listener = new Object();
Mouse.addListener( listener );
listener.onClick = function()
{
getURL( "javascript: your_javascript_function( 'arguements' )", "_self );
}

Dammit, onPress... you'd think with javascript and actionscript both following EMCA standard, they'd use the same damned event names.

var listener = new Object();
Mouse.addListener( listener );
listener.onPress = function()
{
  getURL( "javascript: your_javascript_function( 'arguements' )", "_self" );
}

Sufficiently advanced incompetence is indistinguishable from malice.

Member since: May. 8, 2003
Offline.

Forum Stats: Member; Level 10; Blank Slate

Response to Efficient modal dialogs 2008-06-02 13:45:37 Reply

At 6/2/08 01:38 PM, BoneIdol wrote:
At 6/2/08 12:45 PM, Skye-McCloud wrote:
At 5/30/08 03:47 PM, elbekko wrote: You could have a bubbling event handler on both the dialog and the main page. Then you keep track if the dialog's handler is triggered, and if not, close it.
Wouldn't this not work if I have Flash contained on the dialog, or would clicks in a Flash app not even be read by the code? Sorry, I'm a bit of a noob when it comes to using Flash in web design.
Yes, although someone pointed out that setting the wmode property might work in another post. I myself have only ever used it to get around some problems with z-indexes, so I can't really verify it.

If that doesn't work just write a function in flash to call the javascript function and attach it to a mouse listener. It's far less complicated than it sounds:

//Actionscript code
var listener = new Object();
Mouse.addListener( listener );
listener.onClick = function()
{
getURL( "javascript: your_javascript_function( 'arguements' )", "_self );
}

That'll fire whenever you click inside the flash. There's a better way to call Javascript functions from flash than with getURL, but I can't recall it.

Problem with that is I won't always be able to code the Flash files. Sometimes yes, sometimes no. I can't exactly guarantee this would be contained in the Flash code.

Would it not be easier if I was to try to make use of the onBlur event for JS? The modal dialog I'm using makes use of an iframe, so if I was to ensure focus was set to it when the dialog was loaded, could I not then have it execute my code to close the dialog when the user simply clicks outside of the iframe? Or will that not work?

Member since: Aug. 14, 2006
Offline.

Forum Stats: Member; Level 05; Blank Slate

Response to Efficient modal dialogs 2008-06-02 13:55:53 Reply

At 6/2/08 01:45 PM, Skye-McCloud wrote:
At 6/2/08 01:38 PM, BoneIdol wrote:
At 6/2/08 12:45 PM, Skye-McCloud wrote:
At 5/30/08 03:47 PM, elbekko wrote: You could have a bubbling event handler on both the dialog and the main page. Then you keep track if the dialog's handler is triggered, and if not, close it.
Wouldn't this not work if I have Flash contained on the dialog, or would clicks in a Flash app not even be read by the code? Sorry, I'm a bit of a noob when it comes to using Flash in web design.
Yes, although someone pointed out that setting the wmode property might work in another post. I myself have only ever used it to get around some problems with z-indexes, so I can't really verify it.

If that doesn't work just write a function in flash to call the javascript function and attach it to a mouse listener. It's far less complicated than it sounds:

//Actionscript code
var listener = new Object();
Mouse.addListener( listener );
listener.onClick = function()
{
getURL( "javascript: your_javascript_function( 'arguements' )", "_self );
}

That'll fire whenever you click inside the flash. There's a better way to call Javascript functions from flash than with getURL, but I can't recall it.
Problem with that is I won't always be able to code the Flash files. Sometimes yes, sometimes no. I can't exactly guarantee this would be contained in the Flash code.

Would it not be easier if I was to try to make use of the onBlur event for JS? The modal dialog I'm using makes use of an iframe, so if I was to ensure focus was set to it when the dialog was loaded, could I not then have it execute my code to close the dialog when the user simply clicks outside of the iframe? Or will that not work?

To be honest, I'm not sure. The main irritant I can see is that if you press tab it'll get executed. Can't hurt to give it a try though, but give wmode a go first (It's an object/embed property wmode="transparent"). It usually makes flash behave itself and start socialising with the web browser properly.

There are a few things to look out for though; first it uses more resources, second it makes the flash transparent (which is sort of the point of it) and third it seems to fuck up keyboard encodings in firefox (see here).

Sufficiently advanced incompetence is indistinguishable from malice.

Member since: Jul. 23, 2004
Offline.

Forum Stats: Member; Level 16; Blank Slate

Response to Efficient modal dialogs 2008-06-02 14:11:05 Reply

Stop with the fucking useless quotes already. It's getting annoying.

"My software never has bugs. It just develops random features. " - Unknown

[ FluxBB developer | Quickmarks 0.5.1 | Strings & Ints - my blog ]