That’s a dangerous situation given all the different devices he’d need this to work on.
His call though.
Eh, not technically scrollbars but the user would have to sideways scroll (talking mobile here.)
And I guess if someone zoomed the text only there would be a lot of overlap or overflow hidden happening.
Sounds like a dangerous situation indeed.
Thanks, Ryan.
I used a friend’s site to test with my mobile. We’ll have to wait for the OP to make it publically accessible so it can be more broadly tested.
<off topic>
EDIT: I answered a post before it had been posted… very interesting. Where’s Sherlock when we need him?
</off topic>
1 Like
I have a browserstack.com account so I can be of service with testing various other devices.
I’d just need the URL.
Works in my phone with just Chrome and Opera and in my laptop with Mozilla and Chrome (check it out) I’m not too concerned about mobiles anyway, as with the current height both menu and box are fairly accessible if used horizontally.
When I said: “let the bottom part of my website to adapt to its correspondent (bottom) part of the viewport”, I was thinking about a some more css-ish intervention. Of course giving up the current fixed box backgroung image and replacing it with a similar css.
I won’t be able to convert the current layout, you explained far too well why in post 96. What is left is to experimenting before giving in and move on.
I am already brooding about a new, possibly similar, layout in whose regard, apologizing, I will once again cite its discussion hoping some of you may contribute. 
Would you be kind enough to restate that in plain English? As you can tell, I am totally devoid of ESP genes. In fact, when I was a child, my mother tried to give me away but no one would adopt a child who couldn’t read his mother’s mind. What can I say? I don’t interpret ambiguously stated or unspoken wishes at all.
You are slightly mistaken. I am still trying to put the pieces together and understand exactly what you want. Still trying…
Best of luck.
1 Like
Apologize for reducing what I had in mind to the nonsensical term “css-ish intervention”. Indeed I don’t even know if it would even be possible using css.
What I should have said instead is: “making the box’s height responsive to changes in screen resolution (and zooming)”.
Just to not to be ambiguous, by box I mean what wraps and hide the content generating the second scrollbar.
Sorry for confusing you with all those requests. I am trying to figuring out a compromise without having to give up the box and the second scrollbar. I’m therefore experimenting different approaches. I should have noticed you more clearly every time I changed course of action.
Then with <meta name="viewport" content="height=780, initial-scale=1"> the adaptation happens by means of scaling. That was exactly what I asked. It appear not to be cross-browser though.
Now (by a css-ish divine intervention 
), I am wondering if something can be done to the box itself to make it stretch or contract according to the viewport.
We’re getting there 
I’m running out of options.
Anything unclear please say so.
Take out the “initial-scale=1” and try again with just
<meta name="viewport" content="height=780">
It makes a difference.
This was the correct code to start with and should be the one to use, but you said that it is not cross-browser friendly.
Please reinstate the code shown above and tell exactly in which devices it does not work as desired and describe how it does not work… (the bottom is cut off of the landscape orientation, etc). And at the risk of asking you to repeat yourself, please remind me how you are testing these devices. Software simulator or the real things?
If you change the height or width of the outer box, then the way the graphics fit in the page is affected. Either the graphics will have to be allowed to be cut off at narrow widths or distort so both dimensions can be filled. Making the graphics repeatable or changing the look somwhat is the other option which has already been mentioned several times and would be used if the dimensions of the box were allowed to change.
At the risk of repeating myself too many times, your page could work satisfactorily if you did not restrict the height to 780px and allowed the browser to generate scrollbars instead of the container on the page. Beyond allowing the page to behave like a “normal” page that scrolls vertically if needed, I don’t understand what you imagine CSS or JS might be able to do. I’m still not seeing what you are imagining.
Do I understand correctly that you want the fixed height of the site to remain fixed (780px)? You do not want to allow the browser to generate its own vertical scrollbars? You DO want to continue using your internal scrollbars? And you want the site to fit into any device left-edge to right-edge if in portrait view and top to bottom if in landscape view? If so, that is what the code above does in the Note 3 and that is as far as I can go. Someone else will have to work with you now.
Reinstated. This time none of the browsers in my laptop is showing any difference (they visualize it normally at 100% of zooming) even trying erasing possible cookies.
As for mobiles Opera and Chrome working Firefox and Dolphin not ( these last two visualize it cropping the white width-wise and generating the scroll). I am testing everything on real devices.
You understood everything perfectly. It appears not to be cross-browser friendly though and I will keep doing everything you might have in mind about it.
Now. This is the container’s css:
div.box{width:1100px;height:500px;
background: url(../images/1.png) no-repeat top center;
padding:1px 0;font-size:10px}
div.box-inner{height: 420px;overflow:auto;
margin:20px 15px 0;padding-right:2px;
}
Let’s assume I decided to make it work normally (which I repeat, I will probably do if no solution will be achieved). I would have still to change the container background image (1.png), both bottom-right fruit picture and top-left light reflection would be warped being the height modified. Or either substitute that image with some css gradient or whatever. Are you with me on this? Does it even make sense?
As I have said (I might be wrong or miss something, maybe other tricks or solutions I don know may prevent it) the graphic, meaning principally the image 1.png would have to be changed regardless of the container be eliminated or not.
Now said that. Not considering the graphic, does exist a way to make the container’s height responsive to screen resolution, zooming and - I would add - viewport changes? Changes in zoom and viewport happen after pageload therefore they would have to be corrected through js, I believe, like the menu real-time function.
It should behave as current websites essentially, but not modifing the width (just the height) as the tables layout has to remain fixed.
Can you see it know?
Let’s see… ideal requirements:
(1) The width of the page should be fixed at 1100px (1112px actually but same idea - fixed width).
(2) The height of the page should adapt to the height of the viewport instead of being fixed at 780px. For this, you must modify the content background image for each page so the page will look good as the height changes. Yes?
(3) The header and navigation menu should not change.
(4) On the home page, the 3 column table layout should not change except as mentioned in item 2 above (which IS a big deal) and except as needed to improve the way content fits within each column (such changes should be minimally noticable).
(5) In a mobile device, the page should not trigger browser scrollbars unless zoomed larger (virtual viewport increased). The on-page (inner) vertical scrollbar should be the method of scrolling the content section of the page.
If I have overlooked any “ifs”, “buts”, “is it possibles”, or “maybes”, please add them to this list NOW.
NOTES:
The word “responsive” is normally applied to designs that use media queries to change the layout of items on a page so the content can adapt to different viewport widths. Your page is not a candidate to be “responsive”. If I replace your use of the word “responsive” with an appropriate form of the word “adaptive”, then most of your descriptions begin to make sense.
I don’t know as much about mobile devices as I thought I did, so we will need additional help making your page viewable on small devices. I say “we” because I want to learn more. The results on my android device are inconsistent - sometimes as desired, sometimes not - so my recommendations based on my local tests can’t be trusted.
If you are looking for an “easy CSS” solution, there isn’t likely to be one as long as fixed graphics are your mainstay. Making these fixed graphics extendable requires segmented images, possibly a few compromises and more code. When I worked on your menu, the examples that I sent did not contain the green background image, they used a green background and an inset white box shadow to achieve a similar look. All CSS.
You have added some CSS in the body of your home page. CSS in the body of a page has NEVER been valid. It needs to be moved into the head of the page or (better) moved to a stylesheet.
You change the doctype from XHTML transitional to HTML(5). Along with changing a doctype comes a need to change some code. The transitional doctype accepted as valid a number of HTML attributes that have long been obsolete. You need to clean up your code by replacing these attributes with CSS. 140+ validation errors is 'errendous .
You would still be wise to do the work to upgrade your jQuery to 1.11. Fix the misbehaving (outdated) scripts.
Your friend: http://jigsaw.w3.org/css-validator/
Corrected in what way? What problem would need to be corrected?
I believe that is pretty much all. But yes, I think I will add somethings.
Imagine we manage to accomplish everything - the container is adapting to the page etcetc. How about then we make sure, as soon as the user starts scrolling, that the header disappears (means it gets scrolled away) and the conteiner enlarges occupying the space the header was on?
With that, just the menu and the container will be left. The user spends those few seconds looking at the header, after that, it will become of secondary importance. Again I have no idea it be feasible, indeed it might just be the craziest of all
Yes, “adaptive” would be the word.
Same opinion about devices’ browsers (same story might even be valid for lap/desktops).
I will make sure to fix all the CSS as behoved. The one in the index in the tests folder is there for my convenience.
I will try to correct possible deprecated code, it will still be difficult for me as I don’t yet know which and which not. Same with jQuery.
I was thinking about the actual responsive layouts as they adapt to every change of wieport. Is that achieved by js?
That’s done with CSS. The CSS detects the size of the viewport and changes the layout so it fits within the viewport. No Zooming. The layout of the pages are changed so they fit within the viewport. In that way, the text will appear its normal size and images or can be predictably resized with CSS if needed.
I think you may be confusing/mixing the Zooming of the virtual window in mobile devices with responsiveness. They are completely different and quite unrelated actions. A mobile device does not report a different device width and height when a page is zoomed. As far as the web is concerned, the size and dimensions of the mobile device do not change except for landscape or portrait views if the device reports them (which it should). A responsively designed web page may change the layout if coded to fit the view. Device zooming is not part of the equation. CSS scaling often is.
1 Like
If you have Firefox and the HTML Validator plug-in, which I believe you do, they will dutifully point out each and every one to you. They nag very politely
Sorry, I should have specified. No, I was thinking about zooming on lap/desktops browsers which I believed was different but that maybe is also based on mobiles’ algorithms as well.
Could you post a URL to a site that behaves the way you would like your site to behave? If not, can you create a series of pseudo-screenshots (using Photoshop, GIMP, etc.) that depict your wishes/questions?
You talk about zooming a fixed width site on desktops and laptops and I don’t understand why there should be a reason to do this. If your content is rendered at a “normal” size, what’s to zoom larger or smaller on a desktop or laptop? And one doesn’t generally shift the orientation of either of those devices. The width of the browser window, maybe, but not the monitor. If zoomed lager than the browser window, the browser window sprouts scrollbars or if zoomed smaller than the browser window, the rendered page just becomes smaller.
If you are talking about a site that is designed to be responsive, then the layout of the content shifts to accommodate different browser window widths. If that is to happen, the page cannot be a fixed width layout.
No site I know works this way.
If the site wuold have such feature right now the container would behave as this:
Then once started scrolling down:
If you had a 32’’ monitor you might feel the need of using the zoom. The site will be ‘adaptive’ in height but not in width. Other than that your logic in anassailable.