If i add a green div of a certain height to my page then scroll-bars are added, as expected. When i remove the div the scroll-bars disappear in all browsers but remain in IE and a white void takes the place of the div, somehow the div height is not recalculated correctly after the removal.
Please see this fiddle for a live demo, you will see that it works in all browsers except in IE.
http://jsfiddle.net/nzbrg/16/
The problem seems to be resolved when removing the overflow:scroll for html tag rule, unfortunately this is not an option.
I tested this in latest versions of IE, Chrome and FF and Opera.
Why is this happening and how can i force IE to display the correct height after the dom insertion ?
Note that when you resize the window the white void space disappears immediately, so i just need a way for this to happen without actually re-sizing the window.
It seems that when IE renders a height at 100%, if it grows it will stay the largest size as that is now it's new 100%. To make it shrink again, instead of giving it a height, you need to give it a min-height - change your html and body css to
body, html {min-height:100%;}
this should make your wrapper resize after the green block is removed:
http://jsfiddle.net/nzbrg/6
EDIT
The only way I have found to make ie re-render the page is to set the overflow property on the html:
$('html').css('overflow', 'auto');
http://jsfiddle.net/nzbrg/13/
Add $('body').css('height', 0);
http://jsfiddle.net/nzbrg/4/
I fixed this problem by animating the dom insertion and removal ( needs to be both ) with jQuery, this solution only works because i can use an animation off course.
I don't think this will work if you turn of animation
I would love to find a better solution, but currently this is going to be it. It looks better with the animation anyway so it's win-win ( for me at least ) :)
see here:
http://jsfiddle.net/nzbrg/15/
$("#spacer").slideDown();
$("#spacer").slideUp();
Sneaky Update:
If you disable animation with $.fx.off = true; then it seems to work to. Might have something to do with the way that the animation fumble with the styles to hide and show the div instead of just plain removing it.
Strange because i did also try to hide the element before removing it but was unsuccessful.
Anyway i'm sticking with the animations.
Related
I am developing a mobile web app, and I'm a bit confuse with something :
I have one div called UpperDiv with a z-index of 50 and under that div, there is an other one, called UnderDiv with z-index 0.
The problem is, when I "tap" on UpperDiv, it activates the :active pseudo-class on an element (where I clicked) of my UnderDiv. What should I do to disable this ?
----------------------------- EDITED --------------------------------
It finally works !!!!
I forgot to mention that I'm using a transition to open/close my UpperDiv.
So when opening I'm using :
$('#myDiv').css('-webkit-transform', 'translate3d(200px, 0px, 0px)').bind('webkitTransitionEnd', function(){
$('.underDiv').css('pointer-events', 'none');
});
And when I close :
$('#myDiv').css('-webkit-transform', 'translate3d(0px, 0px, 0px)').bind('webkitTransitionEnd', function(){
$('.underDiv').css('pointer-events', 'auto');
});
It works fine for me, if it can help someone else...
If this is on Android, it will be similar to this question
Is there a workaround for the Android browser bug with CSS-Position and clickable areas?
It is a bug in Android browser (and only there) that comes around when you change the DOM of the page along with some z-index stacking. The layers below will be target for mouse clicks even if something is stacked on top of it.
There are some workarounds on the above question which might work for you.
I read about using an empty flash movie with z-index 20 between the two divs.
Here's another question, which might have the answer
Android Webkit: Absolutely positioned elements don't respect z-index
on the issue page at google there is a workaround by some developer.
https://code.google.com/p/android/issues/detail?id=6721#c26
The problem is: If you change the CSS of an HTML element (e.g. display), the Android browser does not keep track of the UI changes the same way it would do it, if the DOM was changed. The change and the UI active areas are not synchronised correctly by only changing CSS. They would be by changing DOM.
So if you display the hight z-index layer with changes in the CSS, do change the DOM of that layer accordingly. This includes some gibberish in some data- attributes.
Comment https://code.google.com/p/android/issues/detail?id=6721#c55 may have a solutions, too
i am using the autoresize plugin which increases the height as users type in stuff. It works great on FF/Chrome, but the behavior is messed up on IE (see screenshots below).
Essentially, the textbox, when resized, does not push the rest of the buttons down, which is weird, given that nothing on the page is absolute positioned.
I suspect the button and span on the right are in a relatively positioned container? I've encountered the same problem recently with positioned elements and expanding/collapsing siblings. Still searching for a proper solution, but removing the positioning can be a temp fix.
Nasty little bug, this one.
As illustrated in Android ticket 6721, the Android browser seems to not respect z-index when absolutely positioned elements are laid over the top of <a> or <input> tags.
I am desperate for any sort of workaround. Has anybody conquered this one before?
Thanks in advance!
This problem is probably related to controls and their being special for the browser. While looking at your problem (in chromium) I found a related problem that when you press the tab key you will still be able to focus the input elements. You probably don't want this either (regardless of bleedthrough). The solution is surprisingly simple, you write your script to add the disabled attribute to all input/button/etc. elements that are overlayed. A disabled input will not be able to receive focus (by keyboard or otherwise), and clicking it should be impossible.
As this also disables silly keyboard circumnavigation it is not even a workaround, but a better design that also works with keyboard based navigation as expected.
To answer the question properly it's important to read the bug page. The problem is not about visibility of the input below, but its "clickability".
I can't test it, but these are possible workarounds:
0 Forget absolute positioning and just put two divs there and toggle visibility.
If this doesn't satisfy You...
1 try setting CSS position to absolute or relative for all a and input tags (Yup, this might force You to rewrite CSS to keep the layout, but isn't it worth it?)
2 make a <a>-tag container:
<div style="z-index:100 etc."><a style="width: 100%; height:100%; z-index:101">
stuff here
</a></div>
This will need some more CSS to make the content look ok. But I expect something like this would solve the problem.
if 1 and 2 aren't helping try them both at once ;)
3 if it still happens You might want to check in details what happens when You click. Bind click and mousedown events to: link on top, container on top, input in the bottom and log them. If You get any of those events for the top link You can try and stop the bubbling at some moment or prevent the event on the input in the bottom.
This would be difficult, but I can help a bit. jQuery would be quite necessary.
Past fixes for this issue for IE include, but are probably not limited to the following list. These may help solve the problem in Android for you.
Put an iframe behind the absolute content. The iframe may obscure those elements for you
When you display your absolute content, hide all of the problem elements with JavaScript
Define the div's in the opposite order
Point number 1 is deemed the most reliable fix for IE, but may not be the nicest fix for you.
Add this to the CSS of every element that creates a problem:
-webkit-backface-visibility: hidden;
Simulate INPUT and A with DIVs.
[PSEUDO JQUERY CODE]
<div href="http://google.com" rel="a">Link</div>
<div class="field">
<div></div>
<input type="text" style="display: none" />
</div>
<script>
$('div[rel=a]).click(function() {
location.href = $(this).attr('href');
});
$('.field > div').click(function() {
$(this).hide();
$('.field > input').show();
});
$('.field > input').blur(function() {
$(this).hide();
$('.field > div').html($(this).val()).show();
});
</script>
IE has this same problem and the solution there is to make sure that every element that is involved in the positioning and even their containers have a z-index applied to them. Basically if you add a z-index to 1 element in the dom then IE gets understands its z position but doesn't understand its z position relative to what its next to and/or over.
container - z-index 0
child (on top container) - z-index 1
child 2 (above all) - z-index 999
Of course this is all based on stupid IE but its worth a try in android also.
Second Try :)
I am not familiar with the android browser at all, but I hope to maybe lead you down a path to solve your issue. Superfish is a javascript menu that has implemented a solution for z-index menu items when they drop down over select boxes in browsers. BgIframe is the js that they use to achieve this. Your answer may lie there, hopefully.
http://users.tpg.com.au/j_birch/plugins/superfish/#sample2
Put the under html in a div and set the display:none using javascript, so then the under content is gone, instead of being clickable and modal.
if you want to solve this problem, first of all you must add z-index to parent wrapper and clearly add z-index to your other elements, solution is that all elements will have a zero point for anderstanding z-index property correctly
I have a web page that has content which extends past the right edge of the browser window. I set overflow-x: hidden on <body> to turn off the bottom scrollbar, but I can still scroll horizontally with the trackpad, which is not what I want.
Is there any way to prevent the browser from scrolling horizontally?
As a side note: Safari 4.0.4 only scrolls horizontally sometimes, and the scrolling feels "sticky" and "jumpy," whereas Firefox always smoothly scrolls horizontally.
you could try to set in CSS:
html{
overflow-x: hidden;
}
instead of use body selector.
I tried that and works in firefox.
I think the real question is, why do you have your content overflowing out of the intended size of the page? Is this content that you don't want users to actually see? In that case, put it in a div somewhere and set it's display to none. That would avoid the overflow issue entirely.
If there is a legit reason you want it to overflow the container, then set the size of the container explicitly, then the overflow-x to hidden. I haven't tested it, but that should prevent the current behavior. If not, try using a div, rather than the body tag. The browsers may be acting strangely because it's working on the body tag itself.
I would go into Chrome and open the developer tools on a desktop. Remove the overflow-x property. Then proceed to delete each parent element on your page. When you see that the horizontal scroll bar disappears, you know you have found your problem. Then dive into that element. My bet is you have a width of 100% and than a margin put onto it. Remove the margin if that is the case.
If all else fails, you could use Javascript to constantly force the browser to scroll to the left using window.scrollTo(xpos, ypos). For xpos you'll want to use 0 and ypos you'll want to get the user's current scroll position assuming you want to allow vertical scrolling.
You could put your function call either in the window.onscroll event handler, or in a javascript interval that runs every 100 ms or so. Up to you. If you need code examples just ask.
This would be better to understand if you had an example.
is this a long url or something with no whitespaces? Do you have white-space:nowrap; set on the element?
If you have a container with a defined size (one that fits in the viewport), the text should adhere correctly, (unless it's a long line with no spaces)
Old discussion, but it could be of use to people looking for the right answer !
Set "overflow:hidden" on the parent div of the element that is wider than the browser window (not html or body as you would normaly do), that will stop the scroll with de pad or the arrows pad...
I have some divs with just a width, height, and border. I am using:
$(".the_divs").bind("mousemove",function(ms){
do_stuff(this);
});
My divs do not have any background css set (so you can see what is behind them). However, ie6 only fires the mousemove event when the mouse is over the border of the div. So, if you quickly move the mouse into the div (past the border), it never gets fired.
If I set the background to a color this problem is fixed.
I tried the following with no luck:
background: none transparent;
I think I could put another div inside and set the width to 100% or something, but I'm looking for the easiest solution as this is part of a bigger project.
Thanks
I think I've found a hack/fix. On my ie6 only css sheet, I set the background of these divs to a transparent gif. It seems to work.
You can avoid having a transparent GIF background by simply using an invalid image URL, for example:
background-image: url(#);
this sounds like a css issue with ie 6. I would recommend trying
display:block
also, setting the width and height of the div is probably a good idea too. here's a great resource to understanding and fixing a lot of the weird shit that ie6 does:
http://satzansatz.de/cssd/onhavinglayout.html