Whats Good Sitepointers!
I have a full width div that purposfully breaks its fixed width container. Inside of it I want a responsive image that grows/shrinks to the full width of its container.
Independently, the divs work fine by themselves, and the image is responsive by itself. But when I add the image to the full width div, I get a horizontal scroll bar when using large images.
I’m not sure about the logic of having a child element larger than its parent, it’s over complicating things.
Why not just make a class for the content that has a max-width: 400px and leave your full width div with its natural default behaviour?
So the container is actually a flex box and the content divs are actually several blocks of content laid out in both one and two column grids, occasionally broken up visually with full width images that stretch beyond the container for aesthetics. The container was also providing the outside gutters for the content blocks and centering the overall layout. Both of your approaches work quite well !, but to implement I’ll have to specify and keep track of additional properties for the content blocks.
Thanks so much for your responses, they are highly appreciated!
Thought about it a bit more and it can’t be done without guessing at some magic numbers to account for scrollbar width which would result in incorrect placement when the vertical scrollbar was not triggered anyway.
I commented on this 3 years ago that including the scrollbar in the vh unit was a very poor choice and makes it more or less useless unless you have hidden scrollbars on html and body. If they’d implemented vh to not include scrollbars then you could have just made scrollbars visible and all would be well. The reverse isn’t true unfortunately.
Looks like the only viable solution is to have separate containers as already mention by Sam and coothead.
In case you were interested in the magic number solution you could do this.
That will account for most browser scrollbar widths but of course on browsers that don’t have a scrollbar (like those on the mac that appear overlaid on top of the content when scrolling) then you will get a slight gap at the left and right edges of the div. The same applies when there is no vertical scrollbar on the viewport also. Other than the above there seems to be no other solution for this.
Thanks PaulOB for your detailed explanation! Unfortunately, this is going to likely be the cause of extensive site-wide changes, but at least now I know exactly what’s going on and can determine how to move forward. Again, I really appreciate the full explanation and I’m going to go take a look at your previous thread on the topic!.
I entirely agree but sometimes when you make (or are forced to make) changes to an existing site then you have to work within the structures of that site or basically start again. You can never really plan for everything in advance otherwise you’d have spaghetti to start with. Of course sometimes you just have to bite the bullet and get on with it.
If your whole existing site is in a parent container of fixed/responsive width (as is the OPs) then the only option is to break that page up into multiple containers so that the full width elements are children of the body. At times like this the simplicity of the vw calc hack (if it had worked) would have been nice in that it accomplishes the layout required without changing mark up at all and is basically one line of css.
It’s such a shame that the vw unit didn’t simply refer to the viewport layout space available rather than stupidly including the scrollbar width.