Ah, OK, I was thinking in terms of pixels. Perhaps a max-width set with percent works differently. Will have to try it. Thanks!
Percentage and pixels seem to behave the same. I think my confusion is between zooming text only vs the whole page. Zooming text only seems to behave exactly you describe. Zooming the whole page fits my previous description. I think I’m getting tired. Am already over my monthly zoom bogey 
Take this page, par exemple:
http://pageaffairs.com/code-archive/full-width-bands/floated-columns.html
Whether the browser is set to full zoom or zoom text only, you shouldn’t get a scroll bar at the bottom even if you zoom right in. Not in a prober browser, anyway.
“OK, I hear ya”, said the deafened man.
The example page is fluid down to almost zero width, as I imagine good fluid/responsive layouts would try to be.
Give that page a min-width in pixels (or some unit other than percent) and it will develop an h-scroll bar when the browser window is narrowed enough. It seems to me that one assigns a min-width to a page to limit the narrowness of the page for some reason; and when that is done, the browser will develop an h-scroll bar when it’s viewport is narrow enough or the zoom is big enough to trigger it. If no min-width is assigned then the fixed width boxes on the page will determine the minimum width, and when their width threshold is reached the h-scroll bar will appear.
The ideal is to eliminate fixed width items on a web page (somehow). When that ideal is achieved, no scroll bars will be triggered. It’s the target of the future.
Or so it seems tonight.
EDIT:
Until the widest box that cannot reflow is finally reached, then the h-scrollbar appears.
That’s usually where you let @media rules kick in, and drop them to a line of their own.
For content to reflow as the viewport narrows is pretty much a given, as far as I know. I was thinking about content that could not reflow when I responded to your message. I then got the impression that you were talking about how content that could not reflow might overflow the browser window without triggering an h-scrollbar, or maybe something else.
Yes, responsive layouts exist to gracefully change the layout of a page. In this discussion I was not thinking about responsive design. If you were, then I missed that transition. If I have grossly misunderstood a different point, please point me to another link.
You’ve reminded me that I need to learn a lot more about responsive layouts. I’m way behind there.
Still trying to wiggle my toes into the 21st century. 
Thank you for the discussion.
Well, don’t forget that websites in the early 90s were responsive, and then it all changed when CSS turned up. Kind of. HTML by default is fluid and responsive. It’s only the CSS layer that tends to stop that. So these days, CSS usage is being refined to reintroduce responsiveness—or adaptivity—back into web design.
Now you’re preachin’ to the choir
Hey ronpat. Thanks for the help, and sorry for the delay in replying back. I usually try to always get back to people. I just updated the site with your recommendation. I agree that aesthetics are important. It didn’t look like it affected anything, but was still worth changing I guess. It was a minor detail. No, it didn’t affect the image border. I was able to fix that on my own with some tweaking.
Thank you for the wider layout recommendation and included code. I’m not sure I want it like that. That would require updating the text in the header since it leaves a lot of empty space. There must be some errors in the html code. It rid of all the CSS. I did change the referring file back to style1. You had a different referring CSS name. However, it still didn’t fix the code for me to fully see your changes in effect.
I didn’t like the navtab, but thank you anyway. I thought the left side was too gray and had a blurred look. Looked worse than it does now. Was never able to fully fix those tabs.
Hi, eLePHANT, welcome back to the forums. How can we help you today?