I'm pulling my hair out over this. I have a webpage where I'd like to have a fixed position div on the left (the parrot & translater) follow the page as it scrolls down.
http://www.cartoonizemypet.com/new/help/
I managed to follow this tut http://jqueryfordesigners.com/fixed-floating-elements/ and get what I thought was a perfect effect! Then I tried viewing it on my phone.... As soon as I zoomed in the blasted div moved over the text! :( You can see the affect on a regular browser by shrinking the browser window and scrolling to the right.
Does anyone know a way to prevent the parrot from moving horizontally? I've been searching high and low for a solution but it's starting to seem impossible.
Here's the relevant CSS
#content {
padding-top:20px;
padding-bottom:713px; /* Height of the footer element */
width:888px;
margin-left:auto;
margin-right:auto;
position:relative;
}
#help-col1 {
left:0;
width:218px;
position:absolute;
height:500px;
}
#parrot-box {
position:absolute;
top:0;
margin-top: 20px;
}
#parrot-box.fixed {
position:fixed;
top:0;
}
#help-col2 {
width:634px;
float:right;
}
Feel free to check out the page source (http://www.cartoonizemypet.com/new/help/) to see the SCRIPT and HTML. Any help would be MUCH appreciated.
When the parrot gets the 'fixed' class, The parrot (inside #help-col1) has a 'left' value of 0. This means he's always going to be attached to the left side of the page... no matter what the dimensions of the window are, and how it scrolls.
What you're asking for is for him to behave like a fixed positioned element when the user scrolls vertically, but not horizontally. As far as I know, this isn't possible. Fixed is fixed... x and y.
However, there are some solutions (like this one) that talk about using javascript to get over this problem. The theory here is that a little javascript can listen to when the page has been horizontally scrolled and if it has, nudge the parrot back into place accordingly.
Personally, I'd look into using css media queries to make a mobile specific layout. You can assign specific CSS for the mobile version of the site, so hopefully the user doesn't need to zoom (or horizontally scroll) at all =)
Good luck!
JS scroll event listener has been suggested, but all implementations relying on it are systematically laggy. I reckon you would have better luck using media queries to determine whether or not fixed positioning is appropriate (i.e. OK if the window/device is wide enough, or substitute with an alternative behaviour if not).
You could actually leave the parrot at the top for narrow screens and preserve some real estate as well as address older mobile Safari versions' inability to correctly interpret position:fixed. You could certainly implement out a more refined approach, but this should be a good starting point - to try it out, execute the following script on your page (just in the console is fine):
$('head').append('<style type="text/css">#parrot-box.fixed {position:absolute;}</style><style type="text/css" media="screen and (min-width: 982px)">#parrot-box.fixed {position:fixed !important;}</style>');
First it overrides the original #parrot-box.fixed declaration, and then applies your floated styling to whenever the window is at least 982px wide (your page wrapper width).
Not to worry everyone, my husband figured out an alternative way of making this work! :)
Rather than moving the parrot with the page; I'm going to have multiple versions of the parrot inside the answer divs. That way when a user clicks on an answer it pops open and the parrot appears beside it.
Not how I originally had it planned out, but I think I can make this new way look even better!
Thanks for the help at any rate! :)
Related
I have a simple JSFiddle of a single floating header here:
http://jsfiddle.net/zT9KQ/
Basically, this uses translate3d to kick in the GPU and hardware accelerate the floating header so that it may be drawn more smoothly. The header jitters in the latest Safari but gets drawn perfectly fine in the latest Chrome, FF and Opera. The actual code that is being affected by this (the code that spurred this question) is code I've written that cannot be shared publicly but works in a similar manner where fixed positioning is, unfortunately, not a valid solution.
I have tried:
Setting the backface-visibility CSS property to none.
Setting the perspective CSS property to 1000.
Playing with requestAnimationFrame during the animation logic.
Throttling the scroll event callback.
Setting the translateZ transform to something higher than 0px.
But none of this has worked (or at least - it seems reasonable to assume the GPU has kicked in but the jittering persists). I noticed that two questions are already open that are identical this one I'm raising but no one has answered them:
Jitter in Sticky Header in Safari
Implementing fixed position in javascript causes jitter in Safari when scrolling
Is this a known bug? Is there a performance hole I'm not sealing up?
EDIT
I have been receiving a lot of questions as to why position: fixed is not a valid option. To directly reply to Antony's comment on the question itself:
I'm not emulating/reinventing position: fixed. If you look at the top-voted answer (as of this comment), you will see that this seems to be a Safari issue. The reason position: fixed is undesirable in this case is because the code in question must be able to support multiple floating headers that sit below each other and have a "container" range where there may be infinitely nested containers. Using fixed positioning not only makes the code more complicated in the case where these floating headers live in a container that horizontally scrolls but also makes the component more brittle overall (calculating offsets when the widget needs to sit within another container somewhere else on the page). So, semantically, absolute positioning fits my needs better than fixed.
SECOND EDIT
Upon thinking about what Antony had been telling me (that I may be reinventing the wheel), and after hearing about -wekbit-sticky from user3716477, I would like to update the question to show what I'm trying to do. You can see how my code behaves in every browser other than Safari here:
http://cl.ly/3y1i3C473G2G
I have learned:
You cannot rely on the scroll or really any scroll-like events (such as mousewheel) since they are asynchronous in nature. I submitted a bug to Apple detailing what was happening and they closed the bug for this reason.
There is no real way to do what I want as of now - to have multiple floating headers that stack and replace each other. I guess I'll have to wait for something like -webkit-sticky to come out.
I should include all relevant information in SO questions from here on out. :-P
Thanks for playing guys! Here's the exact response I received from Apple:
Apple Developer Relations09-Jun-2014 01:16 PM
Engineering has determined that there are no plans to address this
based on the following:
Code is using scroll events, which are asynchronous.
We are now closing this bug report.
If you have questions regarding the resolution of this issue, please
update your bug report with that information.
Please be sure to regularly check new Apple releases for any updates
that might affect this issue.
Since there is an apparent delay between scrolling with the trackpad and the scroll event firing, you can attach the handler to an additional mousewheel event to smoothen things up.
$scrollContainer.on('scroll mousewheel', function () {
// reinvent the wheel here
});
You can see in this demo here that jittering is far less likely to occur when you scroll with the trackpad. In the demo, I have invoked the handler on load to eliminate the flash when you first scroll on Safari. There may still be some occasional jitter, but if you want to minimize that, you can go the resource intensive way of using setInterval and requestAnimationFrame.
This might fix the problem for now, but as I have said before, this emulation approach is not ideal and you are very likely to run into more trouble down the road.
It appears to be a bug with Safari scrolling. If you drag the scrollbar manually (don't use the trackpad gesture to scroll), then there is no jittering.
Chrome (and other browsers) handle scrolling differently which is why this bug is only present on Safari. You might want to submit a bug report to Apple.
How about a little restructuring, like this:
http://jsfiddle.net/me2loveit2/zT9KQ/6/
html:
<div>
<h1>Header</h1>
<div class="container">
<div class="content"></div>
</div>
</div>
CSS:
.container {
height: 300px;
position: relative;
overflow-y:scroll;
}
.content {
height:1000px;
}
h1 {
position: relative;
top:0px;
left:0px;
margin: 0;
width: 100%;
background: black;
color: white;
}
If you are using something similar to the jiddle code you have to check if browser is safari and then make it a different way like:
$(function () {
var $header = $('h1'),
$container = $('.container'),
$scrollContainer = $('.scroll-container'),
scrollContainerOffset = $scrollContainer.offset().top;
$scrollContainer.on('scroll', function () {
var top = Math.max(0, $container.offset().top * -1 + scrollContainerOffset);
$header.css('top', top + 'px');
});
});
Even when it isn't the way you want your problem to be solved, it might be a workaround that may help...
Scroll events are sent asynchronously in various browsers; you should not rely on them to do things like this.
The best solution would be to use position:-webkit-sticky; top: 0;
You could try and disable all and any javascript-ish scroll handling and just simply remove
position: relative; from the .container.
Afterwards just add h1{ top:0; } and it will happily stick to the .scroll-container.
Excerpt from CSS absolute positioning:
Position it at a specified position relative to its closest positioned ancestor...
To explain - your absolute H1 will look up the tree for the first ancestor element which defines a "position" property and inherit it as a 0,0 reference point.
It could be a WTF at first, but this behaviour is a powerhouse once you tame it.
EDIT: Related to the original jsFiddle, I made some more property removals:
http://jsfiddle.net/253Ss/
^ .container wrapper could be removed as well, since it is no more neccessary in a technical sense.
I'm working with Visual Studio, ASP.net, HTML, CSS, C# (for the code behind), ADO.net and Javascript/Jquery.
I'm trying to make a web page with some div block and I want that the block never exceed the browser. Do you know : how to add a height size for div even if I change the resolution of my window?
PS: I'm French so, please, don't be matter about my mistake.
Without further clarification of your senario, one method is to do the following:
HTML
<div id="test">
My div
</div>
CSS
html, body {height:100%;margin:0;padding:0}
#test {width:100%; height: 100%;position:absolute;}
Setting height to 100% usually works. NOTE: Sometimes padding may push you beyond the browser.
I've encountered screen resolution problem before and this solved my problem.
If you want your website to dynamically changing whenever your screen resolution change you can use % in your css to all your page, containers, wrappers etc. so that it will adjust on any screen resolution. (problem: This destroys your web design whenever the screen resolution is big)
The best solution I find so far and I think other professional websites also is doing is to make your width static or fixed and just let your page get on the center. This will preserve the design you made on your page and everything will stay and looks as it is.
In your CSS just add this line on your page ,containers, wrappers etc. margin:0 auto;
and your site will be centered to any screen resolution. For more examples and to read more about it check this reference How to Center a Website With CSS. If you want to test different screen resolutions without changing your actual screen resolution you could try it here. Hope this helps :)
I'm working on a jQuery lightbox type plugin that needs to function for mobile devices and desktops. I'm having a problem with the full screen overlay effect. From my research, it seems that the standard solution for this is to use position: fixed or background-attachment: fixed to accomplish the overlay effect. Of course, mobile devices don't support fixed positioning, and so I'm trying to find another way.
Right now, I'm attaching a function to $( window ).on( 'resize' ) to get the new dimensions of the window and set the overlay to them. The problem I'm seeing is that this is triggering flickering scroll bars that make the whole thing really jumpy when I size the window down. You can see the effect here: (http://jsfiddle.net/dominic_p/ZqLCx/3/ or http://3strandsmarketing.com/lightbox.php).
Any idea how I can solve this? The code is still in heavy development so it's kind of a mess, but I tried to highlight what I think the 2 problem areas are in the jsFiddle with a comment that says "THE PROBLEM: START".
UPDATE:
I had a brilliant idea to just change the positioning to fixed for desktop browsers and still rely on my resizing scripts for mobile browsers. It seems to have helped a lot, but there is still some significant flicker when the browser window starts to get small (especially when shrinking it vertically). Also, when using position: fixed on Android 4 there is suddenly a large white gap on the side of the screen that I can horizontally scroll to in portrait mode only. Anyone have an idea of how to resolve either problem?
The solution for the flicker problem seems to be to set the overflow-x (or just overflow if you prefer) property for the <body> element to hidden. For curiosity's sake, it actually wasn't the overlay layer, but the lightbox contents that were causing the flicker.
I'm still struggling with the white gap that shows up on Android, but that's a separate problem, so I'm posting this as the solution.
I built a new .Net website which will fit nicely on 1200px width resolution.
The problem is that some of my users will browse this website with 1024px width.
Is there a way to fix this problem quick without changing all the design of the page? For example, to put some javascript that will do the trick.
Please keep in mind that the top banner of my site is 1200px wide, and I don't need to support less then 1024px resolution.
Thanks a lot.
It all depends on how 'properly' your web site was designed. You might need to change a few widths for the main containers (hopefully divs) and the whole content will reflow nicely.
However, if your website contains fixed widths for individual elements, or if there are some images / background images with fixed width, then you will have to amend them as well.
Relatively / absolutely positioned elements will need to by amended as well.
There is no silver bullet 'make my page look nice in smaller resolution', if that's what you're looking for.
I would use javascript. I'd check user's width with document.width, then use jQuery's css() element to change what's needed.
If you really don't need to support users with horizontal resolutions less than 1200px, then why not just let them have the horizontal scrollbars?
Wrap the whole structure of the site in a (div) container that has a min-width: 1200px and be done with it.
Otherwise, if you can't stomach some users having horizontal scrollbars and you really want to maintain the beauty of the site, then you really need to get out of your way and re-design the site in a way that it gracefully degrades in lower resolutions. It definitely is not easy but it can be beautiful.
Here's an article from alistapart that discusses the techniques involved.
You can use the following CSS:
min-width:600px;
max-width:2000px;
this code will set the webpage to all resolutions between 600px to 2000px.
I feel like GMail is an excellent example of best practices in action, but I'm looking for a more theoretical code-based approach. CSS? JavaScript? jQuery? Let's hear it.
Most web application use proper document layout and CSS to make the flow work itself out naturally when the user resizes the browser window, without executing any script at all. This is exactly what the CSS properties display, position, float, clear, etc. are for.
Depends on what you have to do on window resize...
Usually most applications and websites use browser resize event for changing layout or increasing/decreasing font size when user changes browser window size.
Check this article out...
you could do something like this.
The idea is you make a large wrapper (#main,the lightest one) and you place 2 divs inside:#left and #right.
left is a fixed width div width:200px and floats left float:left.
right is liquid so no width, but to prevent #left from overlapping you give #right a margin of the width of #left -> margin:0 0 0 200px.
To prevent #right from being to small you give it a minimum width min-width:400px. Now when you resize the window #right will resize along until #right gets at 400px then the scrollbars will be visible