overlibmws : Messages : 1106-1136 of 1492

I'm referred here by Overlib support group.

There is an AJAX plugin but I can't find any documentations about it. So
please bear with me.

Here is what I want to do.  I like to display an image thumbnail on the
web and show the real big-sized image by clicking on it. I think this
concept falls into AJAX. Can someone here shed any light on how to do
it? Thanks in advance,

Michael

#1107

From: "Foteos Macrides" <fote@...>
Date: Sun Mar 2, 2008 12:59 am
Subject: Re: [OLmws] How can I use AJAX in overlibmws? Thanks,

oldgreeky

http://www.macridesweb.com/oltest/AJAX.html

Michael,

The support document for AJAX in general, and for use of the OLgetAJAX or OLpostAJAX functions via the ajaxcontentmws.js support script, is:

Note that if you already are using AJAX via an equivalent function in one of the popular libraries for AJAX, e.g., prototype or mootools, you can continue using that with overlibmws popups, as also is discussed in the above support document.

Also note that in addition to the Command Reference for overlibmws, a large number of support documents including the above can be accessed via:

http://www.macridesweb.com/oltest/

Note as well that you do not need to use AJAX to achieve your objective of not fetching the full-sized image specified via an img tag in the lead argument of your overlib function call during initial loading of the document. The thumbnail will be fetched for direct display within your document while the document is being loaded, but unless you use javascript pre-loading code (see below) the full-sized image will not be fetched from your server until the first time (if ever) that the user clicks on the thumbnail (and then for any subsequent invocations of that popup, the cached, local copy of the full-sized image will be used).

Be sure to indicate both the width and height of the full-sized image in the img tag so that the popup will be properly sized before the image has been fetched, rather than requiring any re-draw of the popup after the image has been received and its height and width can be read by the browser from the image's own header section. You similarly would be wise to indicate the height and width for your thumbnail(s), to avoid any need for redraws of the document in conjunction with its initial loading.

Since you are using the onclick event to invoke the popup with the full-sized image, you might wish also to include markup for invoking a descriptive popup via the onmouseover event, as discussed in the Getting Started:

http://www.macridesweb.com/oltest/STARTED.html

support document. Also, be sure to structure your onclick attribute value so that it returns false, to ensure a complete fetch and loading of the full-sized image, as explained in the:

http://www.macridesweb.com/oltest/ONCLICK.html

support document.

Normally, one includes pre-loading javascript code for images which will appear only in popups, as discussed and illustrated in the:

http://www.macridesweb.com/oltest/STICKY.html

support document. For your presumably quite large, full-sized images, one would put a script block with the pre-loading code at the bottom of your document's body section, rather than including it in a script block in the document's head section as is done for the small images in that support document, so that the fetching of those full-size images will not commence until all other fetches associated with loading the document have been initiated (modern browsers issue and maintain up to 6 simultaneous requests to the server when the document is loading, but even so, it's a good idea to make sure requests for very large images which are used only in popups will be issued last). All of the modern browsers start displaying the document before it has been fully loaded, and before images associated with pre-loading code have actually be fetched. The overlibmws library in turn is structured such that its popups can be invoked as soon as the associated portions of the document are displayed, without need for the document to have as yet been fully loaded or for any of the images associated with pre-loading code to have been fetched. So most people do include such pre-loading code, so that the images are likely to be in local cache and thus displayed promptly upon invocations -- including the first invocation -- of popups which contain images. There is, however, a "wasted bandwidth" cost for pre-loading images which are never shown because the user did not invoke the associated popups, so if you are using a hosting service whose monthly bandwidth allotment is on the smallish side, that's a factor in deciding whether to use pre-loading for your full-sized images.

Once you've set up all that, you'll likely next want to know how to give users the option to print your DHTML popups with those images. That's explained in the:

http://www.macridesweb.com/oltest/PRINT.html

support document set. And be sure to check out Manon's beautiful examples:

http://www.purplespirit.com/overlib/ol_print.htm

of thumbnail image galleries.

Fote

----- Original Message -----

From: dogshasha

To: overlibmws@yahoogroups.com

Sent: Saturday, March 01, 2008 3:21 PM

Subject: [OLmws] How can I use AJAX in overlibmws? Thanks,

I'm referred here by Overlib support group.

There is an AJAX plugin but I can't find any documentations about it. So please bear with me.

Here is what I want to do. I like to display an image thumbnail on the web and show the real big-sized image by clicking on it. I think this concept falls into AJAX. Can someone here shed any light on how to do it? Thanks in advance,

Michael

#1108

From: "dave_rado" <dave.rado@...>
Date: Sun Mar 2, 2008 11:54 am
Subject: Re: [OLmws] Problem with shadows not resizing on Ctrl+

dave_rado

Hi Fote

--- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@...> wrote:
>
> Dave,
>
> IE7 and Opera are doing the zooms properly, and so for them the
shadow stays properly scaled relative to the popup.  Firefox has fixed
its zooms for its version 3.0 so that the shadows will scale properly
for it as well.  I don't know what the situation is with Safari, but I
doubt it will let itself remain the browser with bum
(non-standards-compliant) zooms.  :<)
>
> Fote
> --
>
>   ----- Original Message -----
>   When you press Ctrl+ in Firefox or Safari, the overlib pop-up
>   increases in height, but the shadow doesn't resize with it, giving
>   a very odd effect.

This discussion has been preying on my mind lately, and although I
respect the fact that overlibmws is your app not mine, and that it is
already the proverbial bees kness, I would urge you to reconsider this.

For one thing, there are still a lot more IE6 users than IE7 users
(see http://tinyurl.com/56kp). Even in IE7, a minority of users may
choose to use View + "Text Size" rather than View + Zoom, because of
the fact that graphics can lose quality when one zooms in. Most Mac
users use Safari and as you say, Safari doesn't yet support zooms. So
for all these reasons it would be really great if the shadow could
increase in height when the pop-up box does, even when increasing the
text size as opposed to zooming, although if it would be a really
major project to fix it I appreciate why you may not think it can be
justified.

Also, I realise that you have forgotten far more about css than I will
ever learn about it, so I imagine you must have considered the
following idea already and had to reject it, but I'm curious about why
Stu Nichol's method at http://www.cssplay.co.uk/menu/shadow2.html
wouldn't solve this problem? It seems to work even in IE 5.0 when I
try it (according to browsershots.org).

Dave

Reply | Messages in this Topic (5)

#1110

From: "Foteos Macrides" <fote@...>
Date: Sun Mar 2, 2008 7:25 pm
Subject: Re: [OLmws] Problem with shadows not resizing on Ctrl+

oldgreeky

Dave,

That CSS is for always visible HTML markup using CSS with position:relative; and your inference that it might be easy to come up with an equivalent, general workaround for browsers which still have bugs that affect the shadow in DHTML popups upon changes in text size via Ctril +/-/0 or View>Text Size is like inferring that because oranges are sweet one might use some similar procedure to make lemons stop being sour. In fact, I'm not aware of any DHTML popup library that includes a workaround for the current and/or older versions of the otherwise supported browsers which have that problem. I'm not saying it can't be done, but a truly general workaround is non-trivial, and despite the usage statistics you cite, for browsers (or older versions) with the problem, it occurs only when the resizing is done while a STICKY popups is being displayed, and the problem will not be present when that or other popups subsequently are invoke. That is, it in fact should be a rare event, which for the most part will be going way in the next releases of the browsers which presently have the problem, and so generating a workaround should be evaluated in relation to avoiding code bloat.

IE7 (but not Firefox through v2.0.0.12; nor Safari for any version; nor Opera but it doesn't have the problem; haven't checked IE6) issues a resize event when it does that resize. So you can use this simple workaround for IE7 (which needs it for View>Text but not Ctrl +/-/0):

In your body start tag add:

onresize="myCheckShadow();"

and in a script block in your head section or in your imported .js file for setting up overlibmws add:

function myCheckShadow() {
if (OLloaded && OLgateOK &&

OLshowingsticky && OLshadowPI && o3_shadow)

OLdispShadow();
}

Please let us know if it also works for IE6;

Fote

----- Original Message -----

From: dave_rado

To: overlibmws@yahoogroups.com

Sent: Sunday, March 02, 2008 6:54 AM

Subject: Re: [OLmws] Problem with shadows not resizing on Ctrl+

Hi Fote

This discussion has been preying on my mind lately, and although I respect the fact that overlibmws is your app not mine, and that it is already the proverbial bees kness, I would urge you to reconsider this.

For one thing, there are still a lot more IE6 users than IE7 users (see http://tinyurl.com/56kp). Even in IE7, a minority of users may choose to use View + "Text Size" rather than View + Zoom, because of the fact that graphics can lose quality when one zooms in. Most Mac users use Safari and as you say, Safari doesn't yet support zooms. So for all these reasons it would be really great if the shadow could increase in height when the pop-up box does, even when increasing the text size as opposed to zooming, although if it would be a really major project to fix it I appreciate why you may not think it can be justified.

Also, I realise that you have forgotten far more about css than I will ever learn about it, so I imagine you must have considered the following idea already and had to reject it, but I'm curious about why Stu Nichol's method at http://www.cssplay.co.uk/menu/shadow2.html wouldn't solve this problem? It seems to work even in IE 5.0 when I
try it (according to browsershots.org).

Dave

--- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@...> wrote:

Dave,

IE7 and Opera are doing the zooms properly, and so for them the shadow stays properly scaled relative to the popup. Firefox has fixed its zooms for its version 3.0 so that the shadows will scale properly for it as well. I don't know what the situation is with Safari, but I doubt it will let itself remain the browser with bum (non-standards-compliant) zooms. :<)

Fote

----- Original Message -----
When you press Ctrl+ in Firefox or Safari, the overlib pop-up increases in height, but the shadow doesn't resize with it, giving a very odd effect.

Reply | Messages in this Topic (5)

#1111

From: "dogshasha" <dogshasha@...>
Date: Sun Mar 2, 2008 7:25 pm
Subject: Re: [OLmws] How can I use AJAX in overlibmws? Thanks,

dogshasha

Hi Fote, Thank you so much for explaining it in such details. One more
question, if I'm using overlib to display some simple text, images with
some caption,  nothing fancy, can I switch to overlibmws without having
to change my code? Thanks,

Best Regards,

Michael
--- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@...> wrote:
>
> Michael,
>
> The support document for AJAX in general, and for use of the OLgetAJAX
or OLpostAJAX functions via the ajaxcontentmws.js support script, is:
>
> http://www.macridesweb.com/oltest/AJAX.html
>
> Note that if you already are using AJAX via an equivalent function in
one of the popular libraries for AJAX, e.g., prototype or mootools, you
can continue using that with overlibmws popups, as also is discussed in
the above support document.
>
> Also note that in addition to the Command Reference for overlibmws, a
large number of support documents including the above can be accessed
via:
>
> http://www.macridesweb.com/oltest/
>
> Note as well that you do not need to use AJAX to achieve your
objective of not fetching the full-sized image specified via an img tag
in the lead argument of your overlib function call during initial
loading of the document.  The thumbnail will be fetched for direct
display within your document while the document is being loaded, but
unless you use javascript pre-loading code (see below) the full-sized
image will not be fetched from your server until the first time (if
ever) that the user clicks on the thumbnail (and then for any subsequent
invocations of that popup, the cached, local copy of the full-sized
image will be used).
>
> Be sure to indicate both the width and height of the full-sized image
in the img tag so that the popup will be properly sized before the image
has been fetched, rather than requiring any re-draw of the popup after
the image has been received and its height and width can be read by the
browser from the image's own header section.  You similarly would be
wise to indicate the height and width for your thumbnail(s), to avoid
any need for redraws of the document in conjunction with its initial
loading.
>
> Since you are using the onclick event to invoke the popup with the
full-sized image, you might wish also to include markup for invoking a
descriptive popup via the onmouseover event, as discussed in the Getting
Started:
>
> http://www.macridesweb.com/oltest/STARTED.html
>
> support document.  Also, be sure to structure your onclick attribute
value so that it returns false, to ensure a complete fetch and loading
of the full-sized image, as explained in the:
>
> http://www.macridesweb.com/oltest/ONCLICK.html
>
> support document.
>
> Normally, one includes pre-loading javascript code for images which
will appear only in popups, as discussed and illustrated in the:
>
> http://www.macridesweb.com/oltest/STICKY.html
>
> support document.  For your presumably quite large, full-sized images,
one would put a script block with the pre-loading code at the bottom of
your document's body section, rather than including it in a script block
in the document's head section as is done for the small images in that
support document, so that the fetching of those full-size images will
not commence until all other fetches associated with loading the
document have been initiated (modern browsers issue and maintain up to 6
simultaneous requests to the server when the document is loading, but
even so, it's a good idea to make sure requests for very large images
which are used only in popups will be issued last).  All of the modern
browsers start displaying the document before it has been fully loaded,
and before images associated with pre-loading code have actually be
fetched.  The overlibmws library in turn is structured such that its
popups can be invoked as soon as the associated portions of the document
are displayed, without need for the document to have as yet been fully
loaded or for any of the images associated with pre-loading code to have
been fetched.  So most people do include such pre-loading code, so that
the images are likely to be in local cache and thus displayed promptly
upon invocations -- including the first invocation -- of popups which
contain images.  There is, however, a "wasted bandwidth" cost for
pre-loading images which are never shown because the user did not invoke
the associated popups, so if you are using a hosting service whose
monthly bandwidth allotment is on the smallish side, that's a factor in
deciding whether to use pre-loading for your full-sized images.
>
> Once you've set up all that, you'll likely next want to know how to
give users the option to print your DHTML popups with those images.
That's explained in the:
>
> http://www.macridesweb.com/oltest/PRINT.html
>
> support document set.  And be sure to check out Manon's beautiful
examples:
>
> http://www.purplespirit.com/overlib/ol_print.htm
>
> of thumbnail image galleries.
>
> Fote
> --
>
>   ----- Original Message -----
>   From: dogshasha
>   To: overlibmws@yahoogroups.com
>   Sent: Saturday, March 01, 2008 3:21 PM
>   Subject: [OLmws] How can I use AJAX in overlibmws? Thanks,
>
>
>   I'm referred here by Overlib support group.
>
>   There is an AJAX plugin but I can't find any documentations about
it. So please bear with me.
>
>   Here is what I want to do.  I like to display an image thumbnail on
the web and show the real big-sized image by clicking on it. I think
this concept falls into AJAX. Can someone here shed any light on how to
do it? Thanks in advance,
>
>   Michael
>

#1112

From: "dave_rado" <dave.rado@...>
Date: Sun Mar 2, 2008 8:27 pm
Subject: Re: [OLmws] Problem with shadows not resizing on Ctrl+

dave_rado

Hi Fote

--- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@...> wrote:

> I'm not aware of any DHTML popup library that includes a workaround
for the current and/or older versions of the otherwise supported
browsers which have that problem.

Okay, thanks for considering it anyway.

> ... it occurs only when the resizing is done while a STICKY popups
is being displayed, and the problem will not be present when that or
other popups subsequently are invoke. That is, it in fact should be a
rare event.

Whoops, sorry, I hadn't noticed that the doesn't manifest after the
resizing has been done! In that case I agree it's not a significant
problem at all - sorry to have brought it up again.

> IE7 (but not Firefox through v2.0.0.12; nor Safari for any version;
nor Opera but it doesn't have the problem; haven't checked IE6) issues
a resize event when it does that resize.

Given that the problem only manifests if the pop-up is visible while
the resizing is being done, and given that in IE7, you have to use the
menu to invoke Text Size command (i.e. there's no shortcut for it in
IE7, I think the chances of a user ever encountering the problem in
IE7 are tiny. In IE6 it's more likely to be encountered but I can't
test it in IE6 - the only means I have of testing old browsers is by
getting screen captures of my web pages using browsershots.org, which
doesn't allow me to test things like changing the text size on the fly.

But many thanks for coming up for the IE workaround, and my profuse
apologies for not having noticed that the problem doesn't manifest if
you resize before displaying the pop-up.

Dave

Reply | Messages in this Topic (5)

#1113

From: "Foteos Macrides" <fote@...>
Date: Sun Mar 2, 2008 8:32 pm
Subject: Re: [OLmws] How can I use AJAX in overlibmws? Thanks,

oldgreeky

Michael,

I abandoned the Bosrup version of overlib and continued on my own with overlibmws way back in 2002. At this point there is almost no overlap in the actual code for the two versions, but the most commonly used command names for the basic commands in the core module for the two versions (overlibmws.js versus overlib.js) are for the most part the same. So if you are just getting started and only using the core module, you should be able to switch which one you import and not have any problem. If you had been using one of the commands whose names differ (say, FOO), you'll get an error message that FOO is undefined, in which case you can post what that name is, and I can tell you what to use for overlibmws.

But the Bosrup version similarly does not fetch the image for the img tag in the lead argument before the user invokes the popup unless you've added code for pre-loading that image, so you need not switch versions for that reason alone.

Fote

----- Original Message -----

From: dogshasha

To: overlibmws@yahoogroups.com

Sent: Sunday, March 02, 2008 2:25 PM

Subject: Re: [OLmws] How can I use AJAX in overlibmws? Thanks,

Hi Fote, Thank you so much for explaining it in such details. One more question, if I'm using overlib to display some simple text, images with some caption, nothing fancy, can I switch to overlibmws without having to change my code? Thanks,

Best Regards,

Michael

#1114

From: "dave_rado" <dave.rado@...>
Date: Fri Mar 7, 2008 11:29 pm
Subject: IE not displaying overlib pop-up's borders

dave_rado

Hi Fote

I've just noticed that since I started using css to define the overlib
borders, IE7 isn't displaying the borders, although all other browsers
are (Firefox, Opera, Safari, etc.). See my mock-up at
http://tinyurl.com/37w382. The OverlibStyles.css file is at
http://tinyurl.com/2twesz; and the OverlibPageDefaults.js file is at
http://tinyurl.com/3amngh. Can you see what I'm doing wrong, or at
least, what I need to change to get the borders to display in IE?

Dave

Reply | Messages in this Topic (3)

#1115

From: "dave_rado" <dave.rado@...>
Date: Fri Mar 7, 2008 11:52 pm
Subject: Problem with red caption

dave_rado

Hi again Fote

On my personal website I'm using a red gradient background for the
caption (as opposed to the grey (Safari-like) one I'm using for the
other site I'm developing), and I've hit a snag. I want to have a grey
border for most of the pop-up, but the grey border above the caption
looks odd against the red gradient - so I'd like that top border to be
red (or no border there at all), but the other borders to still be
grey. Is that possible? See my mockup at http://tinyurl.com/2mtany;
the OverlibStyles.css file for this mock-up is at
http://tinyurl.com/3yg9ga; the OverlibPageDefaults.js file is at
http://tinyurl.com/2o3eln; and the gradient background image is at
http://tinyurl.com/2nkyy8.

Dave

#1116

From: "dave_rado" <dave.rado@...>
Date: Sat Mar 8, 2008 12:01 am
Subject: Re: [OLmws] Thank You Fote

dave_rado

--- In overlibmws@yahoogroups.com, Ben Johansen <benj@...> wrote:
>
> I'm with terry excellent product

Me too, and excellent support!

Dave

#1117

From: "Foteos Macrides" <fote@...>
Date: Sat Mar 8, 2008 1:00 am
Subject: Re: [OLmws] IE not displaying overlib pop-up's borders

oldgreeky

Dave,

We've discussed this before. The problem stems from your use of a generic td rule in your MainStyles.css file. You've added BGCLASS,"MyOLOutsideTableClass" in your OverlibPageDefaults.js file to help deal with that but didn't do it properly. Also add BORDER,0 to your defaults, and in your OverlibStyles.css file use:

.MyOLOutsideTableClass {background-color:b6b6b6; border:1px solid #b6b6b6;}

assuming you want a 1px outer border. Otherwise, increase that in the border rule to whatever you do want.

Fote

----- Original Message -----

From: dave_rado

To: overlibmws@yahoogroups.com

Sent: Friday, March 07, 2008 6:29 PM

Subject: [OLmws] IE not displaying overlib pop-up's borders

Hi Fote

I've just noticed that since I started using css to define the overlib borders, IE7 isn't displaying the borders, although all other browsers are (Firefox, Opera, Safari, etc.). See my mock-up at http://tinyurl.com/37w382. The OverlibStyles.css file is at http://tinyurl.com/2twesz; and the OverlibPageDefaults.js file is at
http://tinyurl.com/3amngh. Can you see what I'm doing wrong, or at least, what I need to change to get the borders to display in IE?

Dave

Reply | Messages in this Topic (3)

#1118

From: "Foteos Macrides" <fote@...>
Date: Sat Mar 8, 2008 1:12 am
Subject: Re: [OLmws] Problem with red caption

oldgreeky

Dave,

Fix up you BGCLASS rules as in the preceding reply, and instead of using that border rule for a uniform grey border, use a border-foo rule set to have outer borders on whatever sides you'd like and with whatever set of colors you'd like.

Fote

----- Original Message -----

From: dave_rado

To: overlibmws@yahoogroups.com

Sent: Friday, March 07, 2008 6:52 PM

Subject: [OLmws] Problem with red caption

Hi again Fote

On my personal website I'm using a red gradient background for the caption (as opposed to the grey (Safari-like) one I'm using for the other site I'm developing), and I've hit a snag. I want to have a grey border for most of the pop-up, but the grey border above the caption looks odd against the red gradient - so I'd like that top border to be red (or no border there at all), but the other borders to still be grey. Is that possible? See my mockup at http://tinyurl.com/2mtany; the OverlibStyles.css file for this mock-up is at http://tinyurl.com/3yg9ga; the OverlibPageDefaults.js file is at
http://tinyurl.com/2o3eln; and the gradient background image is at http://tinyurl.com/2nkyy8.

Dave

#1119

From: "dave_rado" <dave.rado@...>
Date: Sat Mar 8, 2008 10:39 am
Subject: Re: [OLmws] IE not displaying overlib pop-up's borders

dave_rado

Hi Fote

--- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@...> wrote:

> We've discussed this before ...  You've added
BGCLASS,"MyOLOutsideTableClass" in your OverlibPageDefaults.js file to
help deal with that but didn't do it properly.

Please make allowances for my relative lack of technical expertise. I
thought I had followed your previous instructions, and was beguiled by
the fact that it displayed as I wanted it to in Firefox ..

> Also add BORDER,0 to your defaults, and in your OverlibStyles.css
file use:
>
> .MyOLOutsideTableClass {background-color:b6b6b6; border:1px solid
#b6b6b6;}

That works great, many thanks.

Dave

Reply | Messages in this Topic (3)

#1120

From: "dave_rado" <dave.rado@...>
Date: Sat Mar 8, 2008 10:42 am
Subject: Re: [OLmws] Problem with red caption

dave_rado

Hi Fote

--- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@...> wrote:

> Fix up you BGCLASS rules as in the preceding reply, and instead of
using that border rule for a uniform grey border, use a border-foo
rule set to have outer borders on whatever sides you'd like and with
whatever set of colors you'd like.

The problem with that is that I then get a red top border on pop-ups
that have no caption, whereas I want those to have a grey top border.

Is it possible to have a grey top border for pop-ups that have no
caption, but a red top border for those that do have a caption?

Dave

#1121

From: "Foteos Macrides" <fote@...>
Date: Sat Mar 8, 2008 3:58 pm
Subject: Re: [OLmws] Problem with red caption

oldgreeky

http://www.macridesweb.com/oltest/commandRef.html

Dave,

In previous discussions you had wanted to include a border line between your captions and main text area. With your current (rather longish) class names for the default classes and their rules for a grey border, you would do that by adding:

table.MyOLCaptionBoxClass {border-bottom: 1px solid #b6b6b6;}

Beyond that, you seem to have locked yourself into a restrictive mind-set of conceptualizing your default classes as the only ones you can use. The defaults which differ from the distribution defaults (which for the class commands is a parameter with the null string, so that no class-based rules are used) should be assigned via an OLpageDefaults function call. For your class commands, you would specify the most commonly used classes as their parameters, so you need not include those class commands overtly in the overlib function calls which use them.

But you also should contemplate the power of the overlib function's command structure, and learn to make use of it.

Let's pretend that you had followed my previous suggestion to use short class names which reflect their corresponding class commands, as is done in the support documents at http://www.macridesweb.com/oltest/ Your current MyOLfooBoxClass rule sets with grey borders might instead have been olbgGrey and olcgGrey (of course, you could instead append color strings to your current class names and make them yet longer).

What is most commonly done in popups with captions is to use border colors which are the same as or complementary to the caption background color (which for some reason, probably derived from your initial trial and error, you are making transparent -- equivalent to making it the background color of the rule set for that pop-up's BGCLASS command instead of setting it via the CGCLASS command, itself). So for the popups with captions using a red gradient background you could have additional olbgRed and olcgRed classes who's rules replaced the #b6b6b6 with #dd0000 (or some other, darkish red color spec). If you have not made those defaults, you would include BGCLASS,'olbgRed' and CGCLASS,'olcgRed' in the overlib function calls for popups which should use them. Plus you could use SHADOWCOLOR, '#dd0000' (or other shade of red) to make your semi-transparent shadow's color complementary as well.

If you really want to have popups with an outer border line on the sides and bottom, but not the top, of the popups, then create an olbgFoo (or MyOLOutsideBoxClassFoo) rule set which includes the appropriate border-foo rules, and use that for the default of overtly included BGCLASS command.

Basically, all of the presently 79 core commands, and up to 55 additional commands available via the plug-in modules, are being used in your overlib function calls, either with the defaults specified in the Command Reference:

or the defaults specified via your OLpageDefaults function call, or via the parameters or toggle settings specified overtly in the overlib function call.

Fote

----- Original Message -----

From: dave_rado

To: overlibmws@yahoogroups.com

Sent: Saturday, March 08, 2008 5:42 AM

Subject: Re: [OLmws] Problem with red caption

Hi Fote

--- In overlibmws@yahoogroups.com, Foteos Macrides wrote:

Fix up you BGCLASS rules as in the preceding reply, and instead of using that border rule for a uniform grey border, use a border-foo rule set to have outer borders on whatever sides you'd like and with whatever set of colors you'd like.

The problem with that is that I then get a red top border on pop-ups that have no caption, whereas I want those to have a grey top border.

Is it possible to have a grey top border for pop-ups that have no caption, but a red top border for those that do have a caption?

Dave

#1122

From: "dave_rado" <dave.rado@...>
Date: Sat Mar 8, 2008 10:29 pm
Subject: Re: [OLmws] Problem with red caption

dave_rado

Hi Fote

--- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@...> wrote:

> In previous discussions you had wanted to include a border line
between your captions and main text area.  With your current (rather
longish) class names for the default classes and their rules for a
grey border, you would do that by adding:
>
> table.MyOLCaptionBoxClass {border-bottom: 1px solid #b6b6b6;}
>
> Beyond that, you seem to have locked yourself into a restrictive
mind-set of conceptualizing your default classes as the only ones you
can use.  The defaults which differ from the distribution defaults
(which for the class commands is a parameter with the null string, so
that no class-based rules are used) should be assigned via an
OLpageDefaults function call.  For your class commands, you would
specify the most commonly used classes as their parameters, so you
need not include those class commands overtly in the overlib function
calls which use them.
>
> But you also should contemplate the power of the overlib function's
command structure, and learn to make use of it.
>
> Let's pretend that you had followed my previous suggestion to use
short class names which reflect their corresponding class commands, as
is done in the support documents at http://www.macridesweb.com/oltest/
  Your current MyOLfooBoxClass rule sets with grey borders might
instead have been olbgGrey and olcgGrey (of course, you could instead
append color strings to your current class names and make them yet
longer).
>
> What is most commonly done in popups with captions is to use border
colors which are the same as or complementary to the caption
background color (which for some reason, probably derived from your
initial trial and error, you are making transparent -- equivalent to
making it the background color of the rule set for that pop-up's
BGCLASS command instead of setting it via the CGCLASS command,
itself).  So for the popups with captions using a red gradient
background you could have additional olbgRed and olcgRed classes who's
rules replaced the #b6b6b6 with #dd0000 (or some other, darkish red
color spec).  If you have not made those defaults, you would include
BGCLASS,'olbgRed' and CGCLASS,'olcgRed' in the overlib function calls
for popups which should use them.  Plus you could use SHADOWCOLOR,
'#dd0000' (or other shade of red) to make your semi-transparent
shadow's color complementary as well.


That works great, many thanks.

The reason I use longish class names is that I find it much easier to
remember what they are if I do - I forget (for instance) that CGClass
means the class for the overlib caption box, but I don't forget what
MyOLCaptionBoxClass means.

The reason I had set the background to transparent was that I had
originally planned to give the caption box round corners, which I
assumed would require a transparent background colour. But I agree
there's no need to specify any background colour as it stands.

One more question: is it possible to specify a left and right border
colour for the main box (below the caption) but a different colour for
the left and right border of the caption? I tried giving my css class
that is mapped to FGCLASS a left and right border but the borders
appeared in the wrong place because of the padding.

Dave

#1123

From: "Foteos Macrides" <fote@...>
Date: Sat Mar 8, 2008 11:30 pm
Subject: Re: [OLmws] Problem with red caption

oldgreeky

Dave,

A BGCLASS,'bgfoo' command causes class="bgfoo" to be placed in the table start tab of the outer table, with no class specified for its td cell. In contrast, the CGCLASS,'cgfoo' and FGCLASS,'fgfoo' commands cause class='cgfoo' and class='fgfoo' to be placed in both the table start tag and td start tag of their respective tables. You can use the latter tables instead of the outer table to create border line and color patterns such as you are seeking by specifying BORDER,0 and not including border or border-foo rules for the outer table, and instead using them for the inner tables. But in the latter case you must do it in a way which associates those rules only with the table start tag(s). That is why for the border line between the caption and main content tables I indicated that you should use:

table.MyOLCaptionBoxClass {border-bottom: 1px solid #b6b6b6;}

You can elaborate the border rules in that, plus use:

table.MyOLMainBoxClass {border...}

(using those long but for you, memorable, class names :<).

Fote

----- Original Message -----

From: dave_rado

To: overlibmws@yahoogroups.com

Sent: Saturday, March 08, 2008 5:29 PM

Subject: Re: [OLmws] Problem with red caption

[snip]
One more question: is it possible to specify a left and right border colour for the main box (below the caption) but a different colour for the left and right border of the caption? I tried giving my css class that is mapped to FGCLASS a left and right border but the borders appeared in the wrong place because of the padding.

Dave

#1124

From: "Foteos Macrides" <fote@...>
Date: Sun Mar 9, 2008 2:31 pm
Subject: Re: [OLmws] Problem with red caption

oldgreeky

http://www.macridesweb.com/oltest/commandRef.html#cascading-style-sheets

Dave,

Not specifying background-color in the rule set for CGCLASS leaves it transparent (so you don't need to include such a rule overtly if that's what you want). If you were using images to create round corners so you'd also have them with IE, you would want that transparency, as well as omitting a background-color rule and thus leaving it transparent in the rule set for BGCLASS so you don't end up seeing that background instead of seeing through to the document at the transparent, round corners of the images. But you don't want those transparencies when using CSS to create round corners, as in the examples I had provided. You let the CSS, itself, create transparency outside of the round corners and use the specified background-color everywhere else in the CAPTION.

In that CSS-based round corners case, and for square CAPTION corners as you are presently using, including a CGCLASS command overrides the default or overtly specified CGCOLOR command for setting the background color for the CAPTION, and that is why you should include a background-color rule, as discussed in the CSS section:

of the Command Reference. What you want in the case were you are using a red gradient background image is also to specify a red background color, which normally would not be seen, but would keep the popup looking OK if there is a delay or failure in fetching the image.

Fote

----- Original Message -----

From: dave_rado

To: overlibmws@yahoogroups.com

Sent: Saturday, March 08, 2008 6:29 PM

Subject: Re: [OLmws] Problem with red caption

[snip]
The reason I had set the background to transparent was that I had originally planned to give the caption box round corners, which I assumed would require a transparent background colour. But I agree there's no need to specify any background colour as it stands.

[snip]

#1125

From: "dave_rado" <dave.rado@...>
Date: Sun Mar 9, 2008 10:31 pm
Subject: Re: [OLmws] Problem with red caption

dave_rado

Hi Fote

--- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@...> wrote:

> ... That is why for the border line between the caption and main
content tables I indicated that you should use:
>
> table.MyOLCaptionBoxClass {border-bottom: 1px solid #b6b6b6;}
>
> You can elaborate the border rules in that, plus use:
>
> table.MyOLMainBoxClass {border...}

That works great, and my red-captioned pop-ups now look as I want them
to, many thanks.


> (using those long but for you, memorable, class names  :<).

Sorry!

Dave

#1126

From: "dave_rado" <dave.rado@...>
Date: Sun Mar 9, 2008 10:45 pm
Subject: Re: [OLmws] Problem with red caption

dave_rado

Hi Fote

--- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@...> wrote:

> ... What you want in the case were you are using a red gradient
background image is also to specify a red background color, which
normally would not be seen, but would keep the popup looking OK if
there is a delay or failure in fetching the image.

Good point, which made me check what the Close Alt text for the close
image would look like if there were a problem loading the exit.gif
image, and it didn't look good; so I tried resuscitating the style I
used to use for Close text before I started using a close image, as
follows:

span.MyOLCloseFontClass {font-family: Arial, Helvetica, sans-serif;
font-size: 11px; color: #ffffdf; margin-top: 0; margin-bottom: 0}

But it had the unfortunate side-effect, which I don't understand, of
increasing the height of the caption box by 1px, and of moving the
close button upwards, so that it was no longer vertically centred in
the caption box - even though the font size I've specified for the
Close text of 11px is the same as that used by MyOLCaptionFontClass,
and even though I've specified zero top and bottom margins (which I
only did after I noticed the problem, but it made no difference).
Adding "padding: 0" to the above class makes no difference either. Any
idea what's causing this problem and how to fix it?

Dave

#1127

From: "dave_rado" <dave.rado@...>
Date: Sun Mar 9, 2008 10:54 pm
Subject: Re: [OLmws] Problem with red caption

dave_rado

Further to my previous post, I've just realised that this problem only
occurs when I include margin-right: 2px in the definition for
span.MyOLCloseFontClass. I added this so that the Close Alt text
wouldn't butt up against the right edge of the caption box, but it has
the weird side effect described below.

So simply having the following in my css file:
span.MyOLCloseFontClass {margin-right: 2px}

Increases the height of the caption box by 1px and also moves the
exit.gif image upwards so that it is no longer vertically centred in
the caption box.

Apologies for my previous incomplete summary of the problem, but do
you have any idea what could be causing this problem and how to fix it?

Dave

--- In overlibmws@yahoogroups.com, "dave_rado" <dave.rado@...> wrote:

> Good point, which made me check what the Close Alt text for the close
> image would look like if there were a problem loading the exit.gif
> image, and it didn't look good; so I tried resuscitating the style I
> used to use for Close text before I started using a close image, as
> follows:
>
> span.MyOLCloseFontClass {font-family: Arial, Helvetica, sans-serif;
> font-size: 11px; color: #ffffdf; margin-top: 0; margin-bottom: 0}
>
> But it had the unfortunate side-effect, which I don't understand, of
> increasing the height of the caption box by 1px, and of moving the
> close button upwards, so that it was no longer vertically centred in
> the caption box - even though the font size I've specified for the
> Close text of 11px is the same as that used by MyOLCaptionFontClass,
> and even though I've specified zero top and bottom margins (which I
> only did after I noticed the problem, but it made no difference).
> Adding "padding: 0" to the above class makes no difference either. Any
> idea what's causing this problem and how to fix it?
>
> Dave
>

#1128

From: "Foteos Macrides" <fote@...>
Date: Mon Mar 10, 2008 5:31 am
Subject: Re: [OLmws] Problem with red caption

oldgreeky

http://tech.groups.yahoo.com/group/overlibmws/message/1077

Dave,

So other people can follow this discussion, you are using the workaround described in:

and your span rule problem involves the same issues which apply to the:

.olclo {...}

a.olclo:hover {...}

rules for the close link when using CLOSEFONTCLASS,'olclo' in a number of support document examples, e.g., in:

http://www.macridesweb.com/oltest/STICKY.html

An anchor is an inline element. A span is a generic inline element, in contrast to a div which is a generic block element. Block elements have at least one line break forced (if not already present) above and below their content so that they can work with rules for the CSS box model. In contrast, inline elements "go with the flow" of any surrounding text (without forced line breaks) and accept only "non-box" CSS rules such as those for font families, sizes, weights and colors.

The margin rules are for the CSS box model, and thus can be used only for block elements. Your use of margin-right for a span is invalid, causing browsers to invoke some kind of error handling, which can differ across different browsers and can depend on which DOCTYPE your document is using. The "problem" you are describing is actually some browser's error handling, which is probably to treat the span as if it had a display:block rule (in effect, making it a div) so that it can act on your margin-right rule, but also thereby eliminating the "go with the flow" alignment, which actually is wanted above all else and is why the anchor was replaced by a span rather than div for the workaround.

What you really want there is padding-right, which is the space between the content of the element and the right border. Try using that plus vertical-align:middle and see if it works out better. If you still get the 1px increase in height, live with it and add display:block to make the CSS fully valid.

Fote

----- Original Message -----

From: dave_rado

To: overlibmws@yahoogroups.com

Sent: Sunday, March 09, 2008 6:54 PM

Subject: Re: [OLmws] Problem with red caption

Further to my previous post, I've just realised that this problem only occurs when I include margin-right: 2px in the definition for:

span.MyOLCloseFontClass

I added this so that the Close Alt text wouldn't butt up against the right edge of the caption box, but it has the weird side effect described below.

So simply having the following in my css file:

span.MyOLCloseFontClass {margin-right: 2px}

Increases the height of the caption box by 1px and also moves the exit.gif image upwards so that it is no longer vertically centred in the caption box.

Apologies for my previous incomplete summary of the problem, but do you have any idea what could be causing this problem and how to fix it?

Dave

#1129

From: "dave_rado" <dave.rado@...>
Date: Mon Mar 10, 2008 9:36 pm
Subject: Re: [OLmws] Problem with red caption

dave_rado

Hi Fote

--- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@...> wrote:

> What you really want there is padding-right, which is the space
between the content of the element and the right border. Try using
that plus vertical-align:middle and see if it works out better.  If
you still get the 1px increase in height, live with it and add
display:block to make the CSS fully valid.

That works great, thanks Fote. I don't get the 1px increase but have
added the display: block rule anyway, for good practice's sake.

Also, I found that whereas I wanted the close button only 2px from the
right-hand edge of the caption, I wanted the close text to be slightly
further from the edge, so I change the Alt text for the exit.gif
graphic to "Close ", and now everything looks as I want it to.

Many thanks again for all your help.

Dave

#1130

From: "Foteos Macrides" <fote@...>
Date: Mon Mar 10, 2008 11:17 pm
Subject: Re: [OLmws] Problem with red caption

oldgreeky

Dave,

We're not underlining the Close link text, so you can do the equivalent of increasing padding-right by appending non-breaking space entities. But otherwise, the underlining would extend to include the apparent spaces and look strange.

Fote

----- Original Message -----

From: dave_rado

To: overlibmws@yahoogroups.com

Sent: Monday, March 10, 2008 5:36 PM

Subject: Re: [OLmws] Problem with red caption

Hi Fote

--- Foteos Macrides wrote:

What you really want there is padding-right, which is the space between the content of the element and the right border. Try using that plus vertical-align:middle and see if it works out better. If you still get the 1px increase in height, live with it and add display:block to make the CSS fully valid.

That works great, thanks Fote. I don't get the 1px increase but have added the display: block rule anyway, for good practice's sake.

Also, I found that whereas I wanted the close button only 2px from the right-hand edge of the caption, I wanted the close text to be slightly further from the edge, so I change the Alt text for the exit.gif graphic to "Close ", and now everything looks as I want it to.

Many thanks again for all your help.

Dave

#1131

From: "dave_rado" <dave.rado@...>
Date: Mon Mar 10, 2008 11:44 pm
Subject: Re: [OLmws] Problem with red caption

dave_rado

Hi fote

--- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@...> wrote:

> We're not underlining the Close link text, so you can do the
equivalent of increasing padding-right by appending non-breaking space
entities.  But otherwise, the underlining would extend to include the
apparent spaces and look strange.

Good point - in case I should ever wish to underline the close text,
is there a better way of achieving my object of having more padding
for the close text than for the exit.gif image? I couldn't think of
any way other than using a no break space.

Dave

#1132

From: "Foteos Macrides" <fote@...>
Date: Tue Mar 11, 2008 2:23 am
Subject: Re: [OLmws] Problem with red caption

oldgreeky

Dave,

When you specify the red gradient image via CSS as a background via the rule set for the CGCLASS command, if there is a problem with fetching the image then the browsers will stay silent about that and simply let the background color display, which is why you should define that to a shade of red.

If you are using a string, e.g. 'Close' as the parameter for the CLOSETEXT command in conjunction with a CLOSECLASS command and want more than 2px of padding-right, then you should specify more than 2px in the rule set for the CLOSECLASS command.

If, instead, your CLOSETEXT parameter is the variable name closeimg which has been defined to an img element, and you do want 2px, then that's what you should specify. That image is in the foreground, not the background, and a transmission failure will cause browsers to implement their "broken image" routine. Browsers differ in whether their routine respects the image width and height specified in the img tag. IE and Opera do, and there is not enough room in the designated space for the string 'Close' let alone that string plus any non-breaking spaces, so all you'll get is an empty box around the space where the image would have been if the fetch had been successful. Firefox doesn't, and will display your alt text including substitution of spaces for any non-breaking space entities, but your font rules in the CLOSECLASS rule set will not be applied to it (as you seem to think based on the comment in your OverlibStyles.css file), and I'm not aware of CSS which can make the padding-right value conditional on an image transmission error (though there might be some trick for doing that). Safari for Windows creates a close link the size specified for the image, but does not show anything to indicate its presence (hopefully because it's still beta, and hopefully Safari for Mac behaves more fully like IE and Opera, or like Firefox, though I haven't tried it with Safari for Mac).

Fote

----- Original Message -----

From: dave_rado

To: overlibmws@yahoogroups.com

Sent: Monday, March 10, 2008 7:44 PM

Subject: Re: [OLmws] Problem with red caption

Hi fote

Foteos Macrides wrote:

We're not underlining the Close link text, so you can do the equivalent of increasing padding-right by appending non-breaking space entities. But otherwise, the underlining would extend to include the apparent spaces and look strange.

Good point - in case I should ever wish to underline the close text, is there a better way of achieving my object of having more padding for the close text than for the exit.gif image? I couldn't think of any way other than using a no break space.

Dave

#1133

From: MikZ <lord.mikz@...>
Date: Sat Mar 22, 2008 1:38 pm
Subject: Problem with Opera 9.5 dialy builds and with document.all

lord.mikz@...

Hi,
i found a problem. overlibmvs dont work in opera dialy builds because
document.all is set to false... if i turn user javascript and set
document.all to true it works .. or if i set Mask as Internet Explorer in
page settings. Can you fix that browser recognition?

#1134

From: "Foteos Macrides" <fote@...>
Date: Sat Mar 22, 2008 6:09 pm
Subject: Re: [OLmws] Problem with Opera 9.5 dialy builds and with document.all

oldgreeky

http://www.macridesweb.com/oltest/

I updated the overlibmws.zip distribution at:

with tweaks for recognition of Opera 9.5b+ and for the AJAX support with Firefox 3.0b+.

Fote

----- Original Message -----

From: MikZ

To: overlibmws@yahoogroups.com

Sent: Saturday, March 22, 2008 9:38 AM

Subject: [OLmws] Problem with Opera 9.5 dialy builds and with document.all

Hi,
i found a problem. overlibmvs dont work in opera dialy builds because document.all is set to false... if i turn user javascript and set document.all to true it works .. or if i set Mask as Internet Explorer in page settings. Can you fix that browser recognition?

#1135

From: "TrippleEx" <tripple-ex@...>
Date: Fri Mar 23, 2007 1:57 pm
Subject: Poup with iframe content, caption, but witout close link

mrspock75

Hello,

how can i disable the „Close Link“ ?

So, I would like, that the Popup close self, when the Mousepointer Offsite the Hyperlink.

How can i do it ?

Sorry my English is not so good L

Best regards

�zg�r

#1136

From: "Foteos Macrides" <fote@...>
Date: Sun Mar 23, 2008 3:16 pm
Subject: Re: [OLmws] Poup with iframe content, caption, but witout close link

oldgreeky

http://www.macridesweb.com/oltest/IFRAME.html

�zg�r,

A popup includes a Close link in the caption only if you include the STICKY command in the overlib function call. If you do want the popup to be sticky, you can prevent the caption from including a Close link by also including the NOCLOSE command in the overlib call. If you do that, the popup will close if the user hovers over the popup and then moves the mouse off of the popup. You also might wish to include a TIMEOUT command so that the popup closes on its own if the user does not hover over it. The timeout is cancelled if the user does hover over the popup, so that it will not close until the user subsequently moves the mouse off of it (or clicks on a link in the popup content set up to load another document in the parent window).

If what you actually want is for the popup to close when the user moves the mouse off of a hyperlink which invoked the popup via the link's onmouseover or onclick event, then do not include the STICKY command in the overlib call, and include onmouseout="nd();" in the link. A popup can have a caption via the CAPTION command and iframe content via the iframecontentmws.js support script without being sticky (though it usually is sticky so that the user can access links in the iframe content). If it is not sticky, you also would not include the SCROLL or DRAGGABLE commands which are used in the examples of sticky popups with iframe content:

If this is still unclear to you, it would be helpful for you to post a URL for a test document which shows us exactly how you are invoking your popup with iframe content and caption, so that we can indicate more specifically what changes you need to make.

Fote

----- Original Message -----

From: TrippleEx

To: overlibmws@yahoogroups.com

Sent: Friday, March 23, 2007 9:57 AM

Subject: [OLmws] Poup with iframe content, caption, but witout close link

Hello,

how can i disable the �Close Link� ?

So, I would like, that the Popup close self, when the Mousepointer Offsite the Hyperlink.

How can i do it ?

Sorry my English is not so good L

Best regards

�zg�r