Photos extend beyond the frame

[winnjewett]

Large photos seem to extend beyond the frame smugmug sets both in my photos (I've added lots of html), and in Baldy's photos (which I believe are bone stock to sm). Here are the links:

http://brilliantphoton.smugmug.com/gallery/467385/1/19044887/Large
http://baldy.smugmug.com/gallery/175301/1/6612807/Large

It's a lot more obvious in my photo, but if you look for the dashed line as an indicator, it is still apparent in baldy's photo.

-winn

[winnjewett]

Any thoughts?

[winnjewett]

Here is another example:
http://art.smugmug.com/gallery/82700/1/2874648/Large

Does anyone else have this problem?
-winn

[{JT}]

Yes, it is a problem we are aware of. I am trying to come up with a CSS fix for it (since it is a CSS problem), but am coming up dry for now. But ... even if the image was centered, you'd still have to scroll since it extends farther than the rest.

Here is another example:
http://art.smugmug.com/gallery/82700/1/2874648/Large

Does anyone else have this problem?
-winn

[Khaos]

Here is another example:
http://art.smugmug.com/gallery/82700/1/2874648/Large

Does anyone else have this problem?
-winn
I clicked and I'm not seeing the issue. I guess it's related to res? I'm at 1600x1200

[winnjewett]

Yes, it is a problem we are aware of. I am trying to come up with a CSS fix for it (since it is a CSS problem), but am coming up dry for now. But ... even if the image was centered, you'd still have to scroll since it extends farther than the rest. JT, I believe the following CSS code will fix the problem:

-winn

#header, #footer, #cobrand_footer, #feeds, #content, #singleImage, #elegant_small, #journal, #traditional, #allthumbs, #slideshow, #press_release {
width: 100%;
padding: 0;
}
#breadcrumb, #albumDescription, #comment_box, #photoTools, #caption, #fileName, #photoBy, #imageInfo, #albumNav, #albumNav_bottom {
width: 97%;
margin: 0 auto;
}
#singleImage #photos {
padding: 0 10px;
}

[Mike Lane]

JT, I believe the following CSS code will fix the problem:

-winn

#header, #footer, #cobrand_footer, #feeds, #content, #singleImage, #elegant_small, #journal, #traditional, #allthumbs, #slideshow, #press_release {
width: 100%;
padding: 0;
}
#breadcrumb, #albumDescription, #comment_box, #photoTools, #caption, #fileName, #photoBy, #imageInfo, #albumNav, #albumNav_bottom {
width: 97%;
margin: 0 auto;
}
#singleImage #photos {
padding: 0 10px;
}
The issue is that you have the following in your css:

#header, #footer, #cobrand_footer, #feeds, #content, #singleImage, #elegant_small, #journal, #traditional, #allthumbs, #slideshow, #press_release {
margin: 0px auto;
width: 750px;
padding: 5px 0px;
text-align: left;
} It's not too big of an issue but you're seeing overlap in firefox because the image is 800px on its longest side (which is landscape for this picture thus the spillage). The thing is that firefox isn't like IE. IE will resize the container whether you want it to or not (sometimes messing up your hard work terribly but mostly only when you have 2 or more columns which is not an issue here).

Good news, there is a fix. Simply use the following in your css:

/* width sepcific divs defaults */
#header, #footer, #cobrand_footer, #feeds, #content, #singleImage, #elegant_small, #journal, #traditional, #allthumbs, #slideshow, #press_release {
margin: 0px auto;
width: auto;
min-width:750px;
_width:750px;
padding: 5px 0px;
text-align: left;
}

The width:auto; part is for firefox and will stretch your container only if it needs stretching and the _width:750px; is the underscore hack for IE to make it keep doing what it's doing (which is what you want). The only other thing to do is to let firefox know that it can't keep doing the resize thing and that it needs a min-width. I just assumed 750px was what you were going for and left it in there.

[{JT}]

I know what the issue is that is causing it :) But your suggested code caused everything to stretch the width of the page in FF and Safari.

I have some other ideas I will be messing around with today, but feel free to keep the suggestions coming. So far the best solution I have is to create a new template called #singleImage_large and set it's width to be 800px; it is not ideal, but at least it would work. As for original, there is really nothing that could be done, other than opening a popup.

/* update */
I did end up getting Mike's code to work out the way it should, but I had to add 10 extra lines of code to get the other page elements to be 750px width. I still think that making a new ID #singleImage_large would be a far better solution and would make reading the CSS easier.

OR ...
I can ask if the image is larger than 750px, and if so set #singleImage to be the same width as the image. For large images this looks good. For original images, you will more than likely still have to scroll, but oh well - you should not be browsing Original images anyway :)

Good news, there is a fix. Simply use the following in your css:

/* width sepcific divs defaults */
#header, #footer, #cobrand_footer, #feeds, #content, #singleImage, #elegant_small, #journal, #traditional, #allthumbs, #slideshow, #press_release {
margin: 0px auto;
width: auto;
min-width:750px;
_width:750px;
padding: 5px 0px;
text-align: left;
}

[winnjewett]

Thanks for the css modification. I think that I still need the other tags for breadcrumb, caption, etc... and #singleImage #photos.

Without that code, those elements fill the entire width of the page.

-winn

[Mike Lane]

/* update */
I did end up getting Mike's code to work out the way it should, but I had to add 10 extra lines of code to get the other page elements to be 750px width. I still think that making a new ID #singleImage_large would be a far better solution and would make reading the CSS easier.
Speaking of solutions:D Any chance we could get a gallery style specific tag somewhere that would contain the cobranding header and footer that we created... :wink

[{JT}]

(Read my updates to the post above, I think I have the best solution.)

Mike, I already have the code working for your request (we heard you way more than once on the issue). It will be in the form of a a body class though:

<body class="journal gallery_793">
or
<body class="singleImage image_1056 keyword_fun">

I think that this is the best way for you to pick out whatever it is you want to style based on; style, gallery page, image, etc.

You could get very specific in the styling too:
body.singleImage.image_1056.gallery_793 {
color: red;
}

Speaking of solutions:D Any chance we could get a gallery style specific tag somewhere that would contain the cobranding header and footer that we created... :wink

[Mike Lane]

(Read my updates to the post above, I think I have the best solution.)

Mike, I already have the code working for your request (we heard you way more than once on the issue). It will be in the form of a a body class though:

<body class="journal gallery_793">
or
<body class="singleImage image_1056 keyword_fun">

I think that this is the best way for you to pick out whatever it is you want to style based on; style, gallery page, image, etc.

You could get very specific in the styling too:
body.singleImage.image_1056.gallery_793 {
color: red;
} Okay okay, I'll stop being a pest, sorry about that.

This brings up an interesting point and hopefully I'm not being a moron here ... buuuuut, I can't seem to find the <body> tag when I view the source on any of my smugmug pages. Am I missing something?

[winnjewett]

Okay okay, I'll stop being a pest, sorry about that.

This brings up an interesting point and hopefully I'm not being a moron here ... buuuuut, I can't seem to find the <body> tag when I view the source on any of my smugmug pages. Am I missing something?
Mike, is it possible that you put the stat counter code into the body tag, and forgot to include a <body> ?

-winn

[Mike Lane]

Mike, is it possible that you put the stat counter code into the body tag, and forgot to include a <body> ?

-winn
It is possible. I did add that in my wee early smugmug days. I thought I added that to the script box and then to the footer but I'll have to double check that.

[{JT}]

It is true that if you put something into the body section of your customizing that it will overwrite the body tag we write.

But ... there is really no need to put anything in that tag anyway, since you can use CSS and Javascript in the other sections.

It is possible. I did add that in my wee early smugmug days. I thought I added that to the script box and then to the footer but I'll have to double check that.

[Mike Lane]

It is true that if you put something into the body section of your customizing that it will overwrite the body tag we write.

But ... there is really no need to put anything in that tag anyway, since you can use CSS and Javascript in the other sections.
Learning is FUN!!!!

I'll move the script to the footer and maybe I'll see all the hard work you've done.:rolleyes

[winnjewett]

It is true that if you put something into the body section of your customizing that it will overwrite the body tag we write.

But ... there is really no need to put anything in that tag anyway, since you can use CSS and Javascript in the other sections.
JT, I use the body tag to run javascripts on page load. Is there another way to do this?

-winn

[Mike Lane]

JT, I use the body tag to run javascripts on page load. Is there another way to do this?

-winn
Just out of curiosity winn, couldn't you just put them at the top of your header?

[winnjewett]

Just out of curiosity winn, couldn't you just put them at the top of your header? I don't think so. I believe that it needs to read:
<body onload="smHacks();">

The reason for this is that at the time the browser reads the header, items that are refrenced from within the function smhacks() have not yet been loaded.

-winn

[{JT}]

Yes, in your javascript section add this:

onload = smHacks;

JT, I use the body tag to run javascripts on page load. Is there another way to do this?

-winn

[{JT}]

The body class changes are not coming until later this week ...

Learning is FUN!!!!

I'll move the script to the footer and maybe I'll see all the hard work you've done.:rolleyes

[Mike Lane]

The body class changes are not coming until later this week ... :stud Seriously, you guys are the best! I'm just excited to know it's on its way.

[{JT}]

Ok, so the upcoming BODY tag classes will now be inserted to your customize BODY tag, so no need to worry.

I don't think so. I believe that it needs to read:
<body onload="smHacks();">

The reason for this is that at the time the browser reads the header, items that are refrenced from within the function smhacks() have not yet been loaded.

-winn

[winnjewett]

Ok, so the upcoming BODY tag classes will now be inserted to your customize BODY tag, so no need to worry.
Fantastic. Thanks.