That would be the one
Hence:-
Sorry Sam but Iām not a css dummy so donāt lecture me with rwd philosophy, but come with a solution.
Then Iām sure it is within your powers to work this out for yourself.
Good luck. 
1 Like
Will try that and come back later tot tell you what happened. Thank you kindly for your support so far.
It might be a good idea to validate your code before you go much further. Youāre using an xhtml doctype, but not using xhtml-style tags. Youāre also using tags such as āsectionā and āarticleā, which are only valid in HTML5. There are also some stray tags around on your page.
A good first step to debugging anything is to start with valid code.
4 Likes
You conspicuously evaded describing the behaviors that I asked about in my post #15.
I typically go with the notion that images look best if their aspect ratio is preserved, otherwise they start to look compressed or stretched out of shape. Sometimes the aspect ratio isnāt important, as in the case of repeating patterns, but your background images form an overall fixed pattern with what would seem to be a desirable aspect ratio to maintain.
You may be moderately CSS smart, but you seem to missing a geometry screw since you seem to be unable to describe how the images are to behave at different widths and with different content.
@Gandalfās approach assumes that the aspect ratios matter, as would mine. But based on your evasiveness, Iām not so sure that you have thought this through. So here is a layout for your background images in which the images abut. I have assigned fixed heights to the top two boxes although they will be treated as min-heights by default. The heights should be deleted if there is sufficient content to maintain a satisfactory heightā¦ The bottom box will fit the page to the height of the viewport (like a sticky footer might) or longer as needed. The images do NOT maintain a fixed aspect ratio, but they do not have white space between them, either (which is your big thing).
HTML page with CSS at the top, 3 images:
tulpman.zip (393.5 KB)
2 Likes
For sure I am a fool on the css hill in the first, scond or third light. Your solution Ronpat is already almost the perfect one. Yet, a gap is still there in tablet portrait and smaller media: beween the nav-box and content box. What did I forget or did I wrong in the basic css or media queries?
http://www.dickettema.eu/dk_rwd/index_test.html
Thank you kindly for the .zip file but the background image in three parts divided, must stay proportional in height and width in every screen. (Which is not the case in your given zip-example.)
(Was that the geometry screw I missed to give you?)
Forgive me for the Ronpat / Gandalf exchange or is it interchange.
Did you test the code that I sent alone or did you try to plug any of it into your exisitng code before testing it? It you tested it alone, did it have that gap? If so, under what circumstances?
How tall is that gap?
You can try applying {border-collapse:collapse} to .bigbox. Iām not optimistic that it will help, but itās worth a try.
Assuming that it will not help,
You could give .bigbox a background color that matches the images and perhaps the pixel of white space would not be noticed. (Iām assuming itās only a pixel and not the gulf of space that we saw earlier. If Iām wrong, please tell me! )
However, assuming that does not work satisfactorily either,
The remaining guaranteed fix is to reassemble the three slices into one image and assign the background image to .bigbox instead of assigning the three images to the cells. There will be no place for white space to appear. AND, considering your requirement that all 3 images must keep their aspect ratio, there is NO logical reason for them to be separate.
How are you testing the behavior of the code in the various devices? I assume you are using a software tool. May I ask which one, please? I might ask also what hardware you are using. Brand, model, O/S and versionā¦ a hight rez screen such as one of the Mac retina monitors, or what? Is the display on the monitor zoomed larger than the native resolution of the display? (commonly done these days).
The elephant in the living roomā¦ Your requirement that the images must keep a perfect aspect ratio, which in turn means that the height of the content of the header and the height of the content of the nav CANNOT change from whatever you design it to be, is unrealistic.
The images total 1120 x 872. Those are the pixel dimensions and the aspect ratio of the image. My earlier question asked how that image and its content is supposed to behave on other devices. Since you mentioned that other pages had different content, perhaps I should have asked how that āother contentā fits on their pages assuming the same background image is used on all pages. Because by using a background image with a fixed aspect ratio you definitely have less space for content on tablets and darned little space for content on smartphones especially if the user is in landscape view. If you think you can just shrink the desktop view down to smartphone size and the layout will be legible/meaningful to a user, well. thatās where the screw is loose and your concept of reality has drifting into the imaginary.
To a kid reading a comic book, it is amazing to think that Batman can stand on the ledge outside of the top floor of a skyscraper, jump upward with his powerful legs and turn a back flip and land on the roof. Good stuff! Real life, physics, just doesnāt work that way, though.
We donāt know what your content looks like for this page or any of the other pages, you havenāt revealed that, so I gave you a solution that will hold most content within the general layout that you presented. We work with what we are given, eh?
If you need the image to retain itās aspect ratio on all devices, I think you are dreaming or you site has no content to speak of.
I would like to know if the border-collapse property makes a difference, but as I said, I doubt that it will because the cause could be your testing device or something else that Iām unaware of. I only know that it works flawlessly in the latest Firefox and Chrome 49 desktop browsers.
As Winnie the Poeh could have said: āCSS is poetry and a lot of everything else.ā
A brief history:
Almost ready (a wrong assumption) with: http://www.dickettema.eu/dk_rwd/
but suspicious because I used f.i. #header{ margin-bottom: -41px}
I gave the website in in several online rwd_test sites, although the website looked as ment perfect on my desktop and laptop, acer tablet and samsung s4 phone.
A horror thus appeared before my eyes.
So I started again from the scratch to figure out what I did wrong.
(For I canāt blame CSS but only my blind spots, ahum)
And also as link given on this forum.
Of course do I know the limitations from a big screen into a mobile phone
and the necessary adaptions, I coped with already, I thought.
See also the original website, which I designed years ago, but has to be made a rwd:
http://www.dickkrijt.nl/
And please forgive me for taking so much of your time.
Isnāt it strange that an āartisticā approach since rwd necessity, seems impossible?
I do not believe that.
So do believe me truly, a gold mine design is at your hand if this probleem is solved.
Or can you show me websites, that worked around this problem, but with the same āreproductionāā¦
Yours sincerely,
Dick Ettema,
a humble webdesigner from the Netherlands.
Give me a bit more time to play with this. My thinking apparatus is sluggish tonight. 
Looking at this in Chrome and setting #nav { height:auto; } makes the gap go away, even in small screen widths.
Thank you Allan, but then the nav bar box (between the header box and content box also disappears.
Please elaborate what you mean, if you donāt mind, Iām not sure I get the golden feature(s) right.
Why is it not solved, I think @ronpat posted a good solution, donāt you?
Hi, @Erik_J. My concept and execution are good, but doesnāt fit tulpmanās plan.
He has put more thought into the end product than I realized at that time. I still donāt know if his plan will work or not, but it seems possible that it will, so itās worth a try.
Two significant points that I see are (1) that the navbar and its image are replaced by rows of menu items at 766px which lengthens the page and prevents the interruption in the graphic from being apparent, then (2) at 480px the top image is replaced with a more suitably sized version (still becomes rather small, butā¦). As far as content below the menu is concerned, there wonāt be much room for content at narrow widths, but maybe there isnāt much.
1 Like
I checked his latest iteration in post #31 and also compared the original design he mentioned.
(1) The menu items as rows is the standard mobile thing, is it not?
(2) (I should remember zoom 100% when looking!) There is also a change in the āheaderā height to 281px and a bottom margin of -170px to pull it up. I think we call that magic numbers.
Edit)
@ronpat, a better way than the height numbers would, imho, be to apply the suggestion @Gandalf gave in post #9, which he never got a respons to other than @tulpman did try it without mentioning. E.g. a top padding of 25% could fit if the height and bottom margin is removedn in that media query.
If he wants another solution than the one you posted, why not say so and explain how it should be other than just make it ārwdā?
I canāt do anything useful when guessing the conditions, like in my previous posting.
3 Likes
Take your time, Ronpat. Much appreciated.
____________ and to you allā¦
Indeed, HTML and CSS validation is of vital importante. So not to be underestimated nor to be overestimated. It serves first of all the foundation not a priori the build house on it. However 33% of all mistakes in web design are due to a missing ; { } or / in css; or due to the used - even in rwd effective - magic numbers (negative pixel or percentage values) or other work arounds.
I pray for a W3C validation that gives usable solutions and not only - often - minor flaws, which do not really have essential influence / effects on the designed site.
But for sure in five to ten years from now will be realised due to growing commercial and even artistic interest.
Do however not mark my words in this, I am a simple fool on the hill in the first, second and third light of CSS, mainly interested in put to test the utmost div_id / limitations / boundaries of web design. Or as the erudite and my almost CSS hero Ronpat could have said: āYou will never find the true solution there were the problem does show itself.ā
And truly amazed due to all the response here, out of web design compassion, for free, truly for free, with an open mind and without judgement to oneās individual perception, known or unknown. And to return to my question on this forum. Do not laugh, I had last night a weary dream, in which someone told me that I overlooked / missed the css position option.
With kind regards,
Dick Ettema alias Tulpman.
A Dutch webdesigner.
In Dunglish.
3 Likes
Ok, What is your design goal here (other than ārwdā) thatās keeping you from success so far?
To get the best help you really should share with us all aspects that leed your quest for that gold mine of yours.
Just my two
Interesting thread which I have avoided so far (too many cooks etcā¦) but I am also a little lost now as to the full requirements and indeed which pages and which gaps are currently being discussed?
In this page the dark red gap under the nav is a result of margin collapse and easily fixed by applying display:table to #box but I feel that is an erroneous gap and not the main focus of this thread which seems to be about the gray gaps appearing in the background when the sliced images are shrinking (as in the header).
The shrinking header background image is a flawed concept as the header text is an image on a sliced background and therefore never going to match up to the other sliced elements. (Also note that the header element is effectively an empty element as it has no real content and therefore really shouldnāt be a header element as such as far as semantics are concerned.) As others have mentioned the whole background would be better placed as a single background to the page container. This would of course mean removing the text from the header image background and having the text as a transparent image instead. Better still use āreal browser textā and have some useful content in the header. Iām sure a suitable font could be found that matches the existing design. In that way you can have complete control over the header and allow text to shrink and wrap if necessary.
No inference applied to you or anyone else in this thread but that statement is oft quoted by amateurs and indeed some semi-competent web designers (or graphic designers turned web designers) who do not grasp fully that the web is not print. They donāt really understand that a web page is mostly about displaying information in the best way possible and not to display a picture that they have drawn in Photoshop.
Artistic approaches do abound in RWD because in fact you have to be more artistic with your approach to cater for the variations in the devices that you need to reach. Drawing a single picture and then rigidly trying to force that single view on everyone and every device is not usually the best way forward. By all means have a concept to work against but adapt that concept to work best on the mediums where you intend it to be displayed.
Of course there is always a trade-off between what is possible and what is feasible but there should not be a limit on the artistry as such. You simply cannot have the same view on a desktop as you do have on a mobile as that would make no sense. What you can do is make it look good on all devices but not necessarily exactly the same view. 
.
Frameworks like bootstrap (which have become synonymous with RWD ) have contributed to this view that the web is boring and looks the same but again most of the users stating this do not have the ability to bend the framework to their needs an indeed use frameworks as a crutch rather than a tool. In the end the web gets filled with sites that look the same.
RWD should not limit your imagination but stretch it further than a sheet of a4 would allow.
However to get back on topic I think that @Erik_J Erik_Jās questions in the post above is a good starting point to get the thread back on track and help solve your issues moving forward.
You seem to have a good grasp of the OPās intentions Ron but Iām not quite sure I understand what the āfull planā is so I will avoid contributing any code yet and stepping on yours or Erikās experienced toes.
6 Likes