Here's a mystery. If I tile an image (header.gif) in SSP B6 Page Editor > Background, it shows fine on the workpage. It will not show in preview (built in, Firefox, or IE7 previews), but it ultimately shows when published to a test page. When I duplicate the process in WE, it shows fine in all senarios.

SSP B6: http://www.allianceforresponsibleenergypolicy.com/test.html

WE: http://www.allianceforresponsibleenergypolicy.com/test2.html

I can't help but wonder if it has something to do with dual mode, though I have the layout option set to single.

Any ideas?

Grasping at straws, I had something similar happen. It ended up being my firewall/virus software. It has a web pop-up blocker that keyed on file names like banner and header. Since the method used to specify the background image is different between SSP-B6 (CSS) and WE (in-line style), that may be causing it if you have a pop-up blocker enabled.

Thank you Larry.

The strange thing is that it views properly when published. I changed the name of that image 10 times and still cannot get it to work in SSP, yet it works fine as is in WE. To complicate things further, I tried another image with a different name and it worked fine in SSP (unfortunately not the image I need to test). This is the only image so far I that I am having this problem with. It's crazy!

I got pulled into another site project, so I'll have play around with it more tomorrow. Till then....

Well I figured it out. It was the filepath.

I named the file containing all the site images "Incaudo's". WE had no problem tiling an image from Documents/Webimages/Incaudo's, but SSP B6 did not like the ('). I renamed the file "Incaudos" and all is well (except for my mental health which wasn't that good to begin with).

Thanks for the clue Larry.

Jim

That's a bug Jim. The apostrophe (or single-quote) character is valid in a Window's filename so SS-Pro should not be having problems with it. At the least, it should uuencode the character to make the browser happy.

Threw me for a loop since I've never had problems with apostrophes in file names before, but the fact that WE was reading it no problem had me leaning towards SSP. Cracked it when SSP was tiling every other graphic on my drive not in that folder.

I'm still curious as to why it published and previewed off the server OK, but not local - same machine. Any thoughts?

When your page is published, images go into the /image folder so your local /Incaudo's name is not used.

I did a little investigating. There are a couple of factors coming into play.

Specifying a background image is performed with the background-image: url() CSS code; e.g.,

body {
background-image: url(./image/my-background-tile.jpg);
}

The path/file specification used inside the url() section does not require a quoted string. But a quoted string can be used without any ill effects, so CSS code of

body {
background-image: url("./image/my-background-tile.jpg");
}  

is valid.

In the browser world, strings can begin with either a double- or single-quote, so "Hello World" and 'Hello World' are interpreted the same way. You cannot mix the two; "Hello World' is invalid. Being able to use both types of string markers (delimiters) allows you to use one inside the other as regular characters instead of a string delimiter; e.g. "this is Derry's boat" or 'Have you visited the "Sandpit" today?'

When you used your background image path of

Documents/Webimages/Incaudo's  

the browser thought you were beginning a string when it saw the single-quote mark. Because the string was not properly terminated with a closing single-quote, your background image file spec was determined to be invalid, so no background image was used.

The file spec you used works in SiteSpinner/WebEngine because those two programs quote the url() specification while SS-Pro does not.

Now I get it, and this goes back to your earlier statement that SSP specifies the background image differently than previously in SS/WE.

Great way to explain this Larry. Thank you so much. I'll finish the site with WE and then test it in SSP to see if there are any more issues.

I really appreciate your help here.

Jim