I have a site that has a shadow version all around it except for where the logo is, it stretches outside of the div… I want to have that in front of everything, but I want to use the same image just sized differently, so my first instinct was to use the bg element, but I’m having difficulty making the whole thing show (basically an empty div) I’m happy to follow best practices and such and wonder if i’d be better off just using an image.
The working version of the site is up here so you can see what i mean… i want an image on top of the box border just to smooth out that shadow just where the logo is… right now there’s two logo divs which are obviously incorrect because i’ve been mucking about with the code…
Do you have an image of what you are trying to accomplish? the layout is so horribly broken here between scrollbars and misplaced elements I’ll be damned if I can figure what you are even trying to do…
… and your text explanation wasn’t helping.
Though I suspect you are dealing with one of those ‘pretty picture in photoshop has nothing to do with building a website’ moments. The 170k background image being a dead giveaway on that (all by itself being larger than I’d build an entire page on a site).
Though I’m wondering if all you need to do is change those overflow:auto’s to overflow:hidden… taking a peek at the code…
You seem to have WAY more container DIV’s there than necessary… I would suggest removing #bg, #logo (that’s H1’s job), #main, #header, and the DIV on #menu and just put that on the UL directly. Since you are already using a giant fixed image as the background, I’d probably also say screw it and pre-composite that shadow on the background (aka make it just one image). Then all you have to worry about is the body repeat and the footer.
Wait, I’m not even seeing a image for the shadow - are you messing around with the “not ready for use on production websites” CSS3 shadows or something?
Ooh, yup.
-webkit-box-shadow: 0px 0px 8px #555;
-moz-box-shadow: 0px 0px 8px #555;
box-shadow: 0px 0px 8px #555;
Do it in the image, you’re already at monstrous filesize status, might as well make those do all your grunt-work rather than waste your time on something not ready for deployment on real world websites and not even out of draft. There’s a reason even the lead of the HTML 5 project says it won’t be real world deployable until 2022.
Or even just delete the overflow:scroll completely for the logo… as it gives the same result as setting it to hidden.
Hmm, what I see is also broken enough that I’m not entirely sure what the goal is, BUT
know that MOST people doing layouts like these don’t actually lay stuff like ink splatters on top of stuff and then other boxes on top of that. It only LOOKS that way, but what the other sites do is have a few different images on several different elements, carefully positioned to LOOK like it’s one giant ink splatter.
And then the blueish area with text isn’t actually sitting on top of the ink stain. Instead, it’s just sitting on the page in place with its own part of the background, including the imitation opacity box.
#bg could just be the body and hold the centered background ink image.
*edit I just saw another thread where someone said take the bg image off the body, but I don’t see why we’d make an element just to hold a bg image if the body can do it… perfectly legal and no bugs…
#wrapper would have all the splat that sits on white and since it’s fixed width, it can also have the shadows. (edit someone else would have to have the shadows repeated down…)
If the #menu just has a red background, it can be one regular box and it’ll cover up any splat.
Look VERY, VERY closely. there’s a gradient image on body, the monstrous splatter .jpg is on top of it - hence the extra DIV.
Almost missed that myself.
Aaaaah. Hm.
Problem is, we would ideally want the outer bounds of splatter to act like a body image… not cause a scrollbar.
It isn’t though - it’s all those wierd inner DIV doing so.
Though I would consider making it force a scrollbar height-wise and setting a min-height on the inner content.
Basically instead of having #bg wrap everything, make it a sandbag beforehand, fixed height, with a negative bottom margin to ride the content up over it.
Anything to prevent an extra layer of nesting 
Oh, so a <div id=“bg”></div>? Hm, yeah, I’d go for that.
By scrollbar though I meant, a horizontal one starting from the furthest left edge of the splat image. Whereas ideally the horizontal scrollbar would appear if anything was less wide than the whitish content-area (#wrapper).
ok sorry about that everyone. what i uploaded was just testing to see what would happen with overflow:scroll on the divs… IE whether it would show the background. not meant to look like that. hopefully everyone had a bit of fun trying to figure out what the hell i was talking about and denouncing my subpar skillz. I just reread the first post, and yeah, I don’t know what I was talking about
the reason for the extra div is indeed the gradient that shows up if your screen is wide enough for it to show… all the bg images are the same one just showing different parts of it, which overall made a smaller filesize than cutting it up into different bits but allowed me to position things better and use the border shadow. i had not realized border shadow was 12 years away from being usable since i’ve been seeing it around a lot and thought it would be useful here.
I was trying to make the #logo div hover over the logo area and cover up the shadow just in that area… it may be, though, that trying to make a div ‘hover’ above the logo area to hide the shadow is impractical. I thought making the background image the same image and positioning it with css but setting the z-index above the div with the border would block it off, but I wasn’t able to get it to actually show.
i had not realized border shadow was 12 years away from being usable since i’ve been seeing it around a lot and thought it would be useful here.
Well, there are things I’ve used knowing only a few browsers show it, and it’s ok: it doesn’t break if someone else can’t show them.
I think background shadows are something not really a necessity, so it woulnd’t be wrong of you to use CSS rather than images. IE users will simply never see them in this century. I dunno if that’s a bad thing either. IE doesn’t have rounded border-radius and that’s never stopped me from using it.
Whereas I refuse to use specifications not even out of draft on production websites - because I remember the last time we did that… It was called IE 5 and we’re still paying for the broken box model confusion today.
Don’t forget IE6, where Microsoft implimented ideas before they were finished and we are left with the mess ;).
You’re thinking 5.5 - IE6 was the bugfix since it added the trigger to remove the broken box model when a doctype is present and pays attention to margin:0 auto;
Apart from that there are few if any real differences in rendering and/or working CSS properties between 5.5 and 6. That’s why 99% of the time all you have to do to make a page that works in 6 end up working in 5.5 is use text-align to center elements instead of margin and never declare padding & border the same time as width and/or height.
Oh, and IE 5.x’s table font-size based off browser instead of inheriting off body. Important to know if you are using tables with %/em fonts.
Though it’s WHY I will not use in draft specifications in building websites. PERIOD. Jumping the gun with CSS3 and HTML5 before they are solidified is just shooting yourself in the foot the EXACT SAME WAY web developers did using the ‘in draft’ properties implemented in IE 5.x - it’s cute to play with to see what we might be able to use SOME DAY, but have no place in a production website.
Besides, it’s bad enough having to declare -moz twice just to get a WORKING inline-block without further compounding the problem by having to declare every border property three times with -moz and -webkit… **** that.
Whereas I refuse to use specifications not even out of draft on production websites - because I remember the last time we did that… It was called IE 5 and we’re still paying for the broken box model confusion today.
I was really thinking more like, scroll- bar colours that don’t appear in most browsers… don’t hurt anything as far as not showing up in most browsers. Box model, something entirely different.
Besides, it’s bad enough having to declare -moz twice just to get a WORKING inline-block without further compounding the problem by having to declare every border property three times with -moz and -webkit… **** that.
The inline-block hack is a must, like * html, unless you just want to leave FF2 and K-Meleon out of your supported browser list (which is reasonable, tho I’m still trying to support them, at least until K-Meleon moves up to the new engine… if they ever do).
The border-radius bloat though, I think is a matter of choice. At worst, it’s ignored. If you’re not -moz, you don’t look at it. That sounds more than reasonable. And if the specs change (the reason only Opera’s bothered to implement the regular border-radius), well, we’ll just have to accept any consequences if we need to change code. It’s something I’m putting in some of my company’s websites because I like the way it looks, don’t mind deleting it later if necessary, and not being handed off to some client. If that were the case, no, I wouldn’t play with them. Play is play, it’s fun, and if you know you’re going to be on that production website later then it’s cool.
It’s not like it’s hard to have vi look for -moz and -webkit and dd those lines or anything.
You CAN, it’s just that you will have to update the values via a hack (backslash) or some other. I only started CSS 4 years ago so I had the pleasure of not having to deal with IE5 for long (I did IE5.5 for a few months)