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.
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.
This simulation says that you are willing to make some compromises in your images.
The image of the plant is missing from the content’s background image. I know this is just a simulation, but why don’t you make the leap and create the background image in such a way that it can be extended as tall as needed to accommodate the content. There are several ways of doing it, some easier than others. Think about the mechanics/geometry involved and try some things.
Noted also, the internal scrollbar is missing. The browser’s scrollbar is showing. Another willing compromise?
I think you need to convert your full website for mobile as well as responsive, computable to each browser, devices & gadgets for a good traffic.
Do not consider the details of those screenshots. Consentrate about the behaviour (I describe in post 127). The internal scrollbar will have to be present.
Written in post 124.
The container background image (1.png) will have to be substituted altoghether, I believe, with anything not subsceptible to unidirectional variations (proportion being broken by the only height changed). I haven’t had time to go into such “segmented images” you were mentioning, yet.
Yes, if I, as well as the plant, would eliminate the top-left light reflection the container backgroung could enlarge in any direction.
It is not the point though. I think it would be more interesting/challenging trying to develop my idea.
Yes, I should do that. Looking for to…
I would be very grateful if you would explain why the internal vertical scrollbar is essential to the layout. I want to be sure that I understand what it contributes. I can understand personal aesthetics, but I wonder if there isn’t more to the concept than just the scrollbar. For example, your simulations both suggest that the bottom of the background image is visible while the content is being scrolled, which in turn means that the social media icons are always visible in what is probably a fixed footer. Is that part of the requirement/expectation. If that is its purpose, it’s a false premise. Or is the footer supposed to be able to rise above the bottom of the browser window if the content is short (I think not, but need to ask)? What would not be satisfactory about abandoning the internal scrollbar and relying on an external scrollbar?
Please use unambiguous descriptive language, repeat specific nouns instead of using ambiguous pronouns, etc. I am easily confused
Please take a look at the way the top of the page behaves on this web site. I believe this is the way you would like the banner and horizontal menu at the top of your page to behave.
Hiding the header on scroll requires a pinch of JS. should not be a problem. But do notice that the page uses external scrollbars, not internal.
I took this on as a challenge, a learning experience. There is a difference between “challenging” and “impossible”, though, and I’m not so sure that I recognize your requirements clearly enough to identify the distinctions.
IF the page can be designed to behave as you envision, it may end up working only in the most modern browsers, no IE8. Is that OK?
Just to be clear, this is a fixed width site. Only the height will change, not the width.
Which is? (Key to the layout. Priority ONE. Must be technically possible.)
Why not?! Jokes aside, what is your impression when you see the content being scrolled within a container? And that is it! It is just another way to make the page behave.
The container (outer div) currently having as background the blue image (1.png) has to be always visible, in other words it does not have to be scrolled away.
In my simulation it (the container) is “visible” in the first screenshot along with the menu and the header. This combination has to happen just when each page is loaded.
The moment in which the user decide to see more, feeling the need to scroll the content inside the container (the container has been visible along with the other two elements afore mentioned within the viewport, as the first screenshot suggests, the user doesn’t likely know the page’s behaviour, (s)he just start scrolling, the cursor being anywhere in the page), that moment, some magic css intervention has to happen, attention now:
The moment the scrolling has been initiated the css is supposed to enlarge the outer div (increase its height, as the second screenshot suggests) enough to:
- conceal the heather
- leave the menu visible
- leave the copyright line (bottom) declaration visible
The footer (and social media icons) you seem being concerned about is part of the outer div - and therefore it stays within the container - and has to be visible along with the container.
I don’t think rise the footer above the bottom (diminish the height of the outer div/ container) would look nice. So you guessed right.
Again it would mean choosing something else.
I thought already about that course of action. It would be nice and easier. It is not, however, what I meant.
Again I apologize for the lack of clarity in my explanations (hope the last one will do) but yes I am curious myself of knowing if my idea is feasible or not.
That it’s going to be a right pain accessing it by keyboard.
Scrolling websites? What do you think about this?
I think there’s already a topic discussing that site, and we shouldn’t hijack dRyW’s topic to discuss it here.
Well, I don’t want to make mine that extreme. It is a cool one though.
In what way is it not what you meant? I probably have missed a detail that is important to you.
You asked me to have a look at that page. I answered: it is not what I meant. Sorry, I wanted to say “the menù in my website doesn’t have to behave the way it behaves on your suggested webpage.”
IF indeed. I don’t know it yet. I don’t know either how many compromises will be requiered to be done. Isn’t it a bit too early to talk about it?
Way more importantly, was my explanation clear enogh? Can you better understand the meaning of those two screenshot now?? Have you got, even just remotely, my point?
Not at all. One needs a clear vision with specifications to code a page properly.
You seem to be in the wishful thinking stage, which is fine, except that you keep changing (or otherwise ambiguously describing) the picture. I ask for a specific, you give a vague generality or seem to change something that you previously said. I can’t code your page based on vague impressions and generalities.
I think I’ve done all that I can. In fairness to both of us, it’s time for someone else to take my place in this thread.
I must infer your question be of vital importantce. My apologizes for not answer it right away.
“Working only in the most modern browsers, no IE8” you ask. Well, IE8 seems losing groung nowadays. I would be more curious to see my idea working even though not IE8 friendly or if in the end too outlandish to be used. Would you have preferred me to say “No, IE8 is required. Without it let’s forget about what has been discussed in these last 60 post” (which problably matter little seen as vague and fickle it has been), because if so you should have asked it 60 post ago
It means my explanation didn’t make any difference.
Well, your help has been enormously appretiated notwithstanding.
For anyone which hasn’t been as influenced as poor ronpat has by my continue changes, have a look to the screenshots on post 132 ( type126 in the quick searcher on the bottom-right of the page) and what I wrote in post 138 (131 on the searcher). I believe (I hope) you might get something out of it