I'm using -webkit-overflow-scrolling:touch for native scrolling capabilities on my iPad. But I've come into quite an odd problem:
I have one div with various children. If these children are big enough to create the need for scrolling, the device properly scrolls correctly, with momentum and all. However, if this div is not big enough to require scrolling, and suddenly has elements inserted into it and now does require scrolling, you will not be able to scroll the element at all.
I hope that wasn't too incredibly confusing, but if someone could shed some light on what to do in this situation, that would be fantastic. There isn't much documentation about this property out there.
EDIT: Tried testing this a lot, and it seems now it's just a generally intermittent problem. Every 1 out of 5 times or so, scrolling just fails for my entire web app, no matter the contents.
I had the same issue and it seems like assigning the CSS class after the new DOM element is added seems to work fine:
// your code to add a div to the DOM
// the div contains a scrollable div with the content class
setTimeout(function(){
// this is using JQuery
div.find(".content").addClass("overflowScroll");
}, 1);
// CSS class
.overflowScroll {
overflow: hidden;
overflow-y: scroll;
-webkit-overflow-scrolling: touch;
}
// The HTML for the div
// I am adding a dynamic list to the content div
// which should use the overflow scroll
<div class="panel">
<div class="header">
</div>
<div class="content"></div>
</div>
Related
I am using Element's Notification component but when it is activated the dialog appears but seems to be "behind" the grey background that is also introduced. Clicking anywhere removes the grey background and allows the interaction with the dialog box but without the greyed out background that should be filtering out the noise of the normal screen. Here is a short video that shows the various states:
video
The code to put the component in as follows:
<div class="add-address" #click="showAddDialog = true">
+
</div>
</div>
<el-dialog
title="Add New Address"
:visible.sync="showAddDialog"
width="30%"
:before-close="newAddressDialogClosed">
<span>Postal Address</span>
<el-input v-model="newAddress" type="text"></el-input>
<span slot="footer" class="dialog-footer">
<el-button #click="dialogVisible = false">Cancel</el-button>
<el-button type="primary" #click="dialogVisible = false">Confirm</el-button>
</span>
</el-dialog>
I have used the inspector to poke around at the CSS but I haven't yet understood what's causing this from a CSS perspective nor a Vue/Element perspective. Any help would be appreciated.
I have further analyzed the HTML/CSS and the component appears to introduce two separate blocks in the DOM:
The lower block is the grey background which you'd expect to "blur" the page and focus attention on the modal. It, however, is in front of the dialog. Also of interest is that clicking anywhere seems to target the grey background and dismiss it but in so doing it also has a subtle effect on the placement on the dialog box as can be seen here:
Note that the z-index of the dialog box is greater than the background which intuitively makes sense to me but I'd have thought this would have put the dialog box on top. Guess that's not all there is to this.
I have hacked a work-around for now by changing the background to display: none and then adding the following HTML directly before the modal dialog in the DOM:
<div class="modal-background" v-if="showAddDialog"></div>
These seems to validate my underlying suspicion that placement within the DOM tree is important and the component's attempt to place the modal background at the very end of the DOM is somehow problematic.
I had the same issue and also found changing the z-index of the dialog had no effect. This was occurring when I had nested Element.Eleme.io elements, which appears to be the case for you also.
The z-index is not quite as simple as "higher always means on top". Elements are grouped into different stacking contexts; it is not possible for an element in a lower stacking context to appear above an element in a higher stacking context. Therefore depending on where the different elements were rendered in the DOM, they can land themselves in different stacking contexts, and are destined to remain at the same relation to one another, no matter how much the z-index has changed. (See https://philipwalton.com/articles/what-no-one-told-you-about-z-index/ for a more detailed explanation on the z-index).
Examining with Chrome dev tools, I found that the obscuring modal is not rendered in the same place as the dialog; in fact it is appended to the body, i.e. on the outer reaches of the application, which appears to be the reason they are not within the same stacking context. There is a quick fix; the dialog element has a property "modalAppendToBody". If true, the modal is rendered to the body, and if false it is rendered to the parent element of the dialog. By specifying this as false I managed to solve the issue:
<el-dialog
title="Add New Address"
:visible.sync="showAddDialog"
width="30%"
:before-close="newAddressDialogClosed
:modalAppendToBody="false">
</el-dialog>
you can use the CSS property called z-index
either any object which you want to set to back ? you just have to set z-index: -1; // or more
or you want to set any object on to the front of another ? you just have to set z-index: 1; //or more
Check the Snipet For More Info :
.a {
position: absolute;
left: 0px;
top: 0px;
z-index: -1;
}
.b {
margin-top:150px;
position: absolute;
left: 0px;
top: 0px;
z-index: 1;
}
<!DOCTYPE html>
<html>
<head>
</head>
<body>
<h1> I am on Image</h1>
<img class="a" src="http://qnimate.com/wp-content/uploads/2014/03/images2.jpg" width="100" height="140">
<br>
<br>
<br>
<br>
<h1> Image is on me</h1>
<img class="b" src="http://qnimate.com/wp-content/uploads/2014/03/images2.jpg" width="100" height="140">
</body>
</html>
I have some nested recursive functions which dynamically create collapsible with listviews that are in a side panel. I found the default 17em to be too small, especially as the nested text starts to get short. So I found the styles in the css which set it and I overrode those to use 25em. This might be a bit too much after testing on some devices. However I digress.
The thing I am here to ask is why my collapsible overflows the panel when I use data-display="overlay", when I set it to 'reveal' it looks fine. I thought it might be all my nested content, so I made a fiddle with static content here: http://jsfiddle.net/LF6UR/
<div data-role="panel" id="left-panel" data-display="overlay" data-position="left" data-position-fixed="true" data-swipe-close="true" data-dismissible="true">
and I can see it is not that, perhaps there is some other CSS property for the panel that I am not aware of. There seem to be lots of niggly little settings to get to know with this framework. Hope someone out there can help because I really think 'overlay' is better than pushing my main content area.
jQM adds a negative left and right margin to collapsibles within the collapsible set. You can override the margin like this:
.ui-collapsible-set .ui-collapsible{
margin-left: 0;
margin-right: 0;
}
Updated FIDDLE
Also, changing your collapsible set to data-inset="true" fixes the issue.
a solution without setting collapsibles to inset...which is important because I have nested collapsibles is to simply set the 'magic' .ui-panel-inner class which JQM puts in as an 'enhancement' but which makes it a bit difficult for traditional webdevelopers to know to apply styles to their controls.
.ui-panel-inner {
/*width: 25em;*/
padding: .2em 1.2em;
}
http://jsfiddle.net/magister/LF6UR/8/
The code works on Chrome and I am trying to get the code to work on ie9. It works properly with the draggable() without containment but messes up the behavior badly when containment is set to parent:
img = $("<img alt='Preview' id='preimg' src='" + data.result.url +"' />")
$('#preimage').append(img);
$('#preimage').resizable({
'aspectRatio':true,
'handles':"all",
'autoHide':true,
containment: "parent"
}).draggable({
containment: "parent"
});
The parent position is set to relative. I am using jquery 1.7.2 and jquery-ui 1.8.20
Is there any workaround?
EDIT
After much testing - I have found that the container size calculation for the div is not working correctly, I was able to get it to work with the resizable enabled but without actually resizing the div. As soon as I resize the draggable containment area reduces in size, resizing multiple times leads to this area becoming smaller until the drag option stops working.
I found that there are several bug reports with the jquery ui library about these issues - http://bugs.jqueryui.com/report/10?P=resizable
I was able to find a work around that I tested extensively and which should work in most situations. The key here is that you need to use a container div that is not floated and has position relative. If you need to use a floated/absolute div just create a div inside it and set the position to relative. For the code in the question the html looks like:
<div class="outer">
<div class="container">
<div id="preimage"></div>
</div>
</div>
and the css would be:
.outer{
position:absolute;
right:0;
}
.container{
position: relative;
}
Since you can't drag an element when you resize and vice-versa, a safer way(to avoid some of the issues) of using the javascript would be:
$('#sqoutline2').resizable({
'handles':"all",
'autoHide':false,
containment: "parent",
start:function(){$('#sqoutline2').draggable('options','disabled','true');},
stop:function(){$('#sqoutline2').draggable('options','disabled','false');}
}).draggable({containment:"parent",
start:function(){$('#sqoutline2').resizable('options','disabled','true');},
stop:function(){$('#sqoutline2').resizable('options','disabled','false');}
});
I'm building an iOS app with PhoneGap. I'm using translate3d CSS animations to create the 'flip' effect.
This works great on simpler elements...a DIV with front/back divs and maybe an extra span or two.
But when I attempt to flip a larger element...namely the entire screen, I get redraw glitches. What happens as soon as I swap the css class to start the transition, parts of the 'bottom' div pop-through the 'top' div, then the flip happens, then they pop-out again. And it's not the entire element that shows through...it's half of the element split along the axis that I'm doing the translate 3d rotation on.
Any ideas or theories as to what might be causing this? It happens the same both on the iPad as an app and on the desktop in Safari, so appears to be a webkit issue.
Could it be some CSS issues? Or is attempting to do a full-screen translate3d rotation with complex nested elements with large background images just more than Safari can handle?
UPDATE 1:
I've made progress in narrowing down the issue.
What's happening is that the elements that are 'peeking through' when I do the translate3d flip happen to be child elements that had been previously positioned via translate3d.
My 'page' structure that I want to transition with translate3d:
<div id="frontbackwrapper">
<div id="front">
</div><!--/front-->
<div id="back">
</div><!--/back-->
</div><!--/frontbackwrapper-->
This works on it's own. The front div is replaced with the back div with a card-flip effect.
The problem is that prior to doing the full page flip, I've already animated some elements within the #front div using translate3d:
<div id="frontbackwrapper">
<div id="front">
<div class="modal"></div>
</div><!--/front-->
<div id="back">
</div><!--/back-->
</div><!--/frontbackwrapper-->
Example CSS:
.modal {
width: 800px;
height: 568px;
position: absolute;
left: 112px;
z-index: 100;
-webkit-transition-duration: 1s;
-webkit-transform: translate3d(0,-618px,0); /* set off screen by default */
}
.modal.modalOn {
-webkit-transform: translate3d(0,80px,0); /* slides the div into place */
}
If--instead of using translate3d--I just reposition the div with a top style or transform the top property, I don't get the peek-through issue. Of course, that means I have to give up the slick animation or hardware acceleration, respectively.
At this point, it looks like a webkit bug. I'll keep doing some playing with it. If anyone has run into this before and found a workaround, I'm all ears!
solution! After a night of sleep, I mulled over the culprit and what to do with it. It's not necessarily the act of animating a child element with translate3d but rather the face that the element that was translated has that CSS property at the time it's parent is being animated with translate3d.
The fix is to first animate the child element, then remove the translate style all together.
The CSS structure is now:
/* default class for the start of your element */
.modal-startposition {
-webkit-transition-duration: 1s;
-webkit-transform: translate3d(0,-618px,0);
}
/* add this class via jQuery to then allow
webkit to animate the element into position */
.modal-animateposition {
-webkit-transform: translate3d(0,80px,0);
}
/* when animation is done, remove the above class
and replace it with this */
.modal-endposition {
top: 80px;
}
And some sample jQuery:
//[attach a click event to trigger and then...]
$myModal
.addClass("modal-animateposition")
.on('webkitTransitionEnd',function () {
$myModal
.removeClass('modal-startposition')
.removeClass('modal-animateposition')
.addClass('modal-endposition');
});
A little tedious, but it completely fixes the screen redrawing problem.
EDIT: Corrected a typo
DA,
I learned something from this, thanks. Also,
take note of the css attrbibutes, 'translate3d' and 'left'. Translating and positioning is a little different. Test it out, translate an element 100px in x-axis, set it's 'left' style attribute to 0px. Verify, it will be positioned at 0px on x-axis from the current translation point (starting from 100px on x-axis).
That produces mathematical errors in drag/drop and animation algorithms and easily noticed (redraw glitches, skips, position getting reset), and becomes a challenge because translate3d no longer updates the elements offsetLeft or 'left' style attribute (to prevent reflow, for optimization), so parsing the elements real left, is based on knowing if translate3d or left was being used. If you're a game developer, tracking the x,y in internal variables is the way to stay in synch with the elements position. Hope that helps out more.
I was seeing a strange phenomena when using Scriptaculous BlindDown and SlideDown effects, where they would smoothly slide, and then at the very end, they would jump an additional amount, maybe 10% of the slide distance.
I already saw the note on the BlindDown page that you have to be sure not to use padding, which I'd already done.
I was still thinking that this must be my mistake somehow, when I noticed that I see the exact same thing happening on their demo page for Toggle when clicking on either the Blind or Slide demos:
http://wiki.github.com/madrobby/scriptaculous/effect-toggle
Firefox 3.6.7, Chrome 6, and Internet Explorer 8 all display this effect on my computer.
So I was thinking about just writing it off and either living with it or cutting the effect out, when I noticed that the page for BlindDown does not display this effect:
http://wiki.github.com/madrobby/scriptaculous/effect-blinddown
So there must be a way to make this work. On my page, the jump is occurring whether I directly use BlindDown/Slide or whether I use Toggle.
Has anyone out there used these and managed to do so without this problem? Any ideas on what the secret is?
It's usually due to margin or padding.
The element you're blind-downing mustn't have any margin or padding, or should have margin:0.1% so that contained margins don't collapse through the bounds of the element either. If you do this it'll be smooth as silk.
also - ensure you've set overflow:hidden
Enjoy.
(the other place it'll fall down is if you don't define height. If you do this little incantation before you animate it'll get and set you height without bothering anything else.
elem.setStyle({position:'absolute',visiblity:'invisible'});
elem.setStyle({'height':elem.getDimensions().height+'px'});
elem.setStyle({position:'relative',visibility:'visible'}); //or position:'static'
In my experience, the jumping is just a performance issue, which is effected by the system specs, browser, and complexity of the html content you are toggling. Some browsers like safari and chrome have a pretty good javascript engine making them more efficient.
I see this is happening for you even when using chrome though? Is the html content particularly complex, or your computer overloaded with applications running?
There is definitely a little very well known secret... Have you tried wrapping your content in an extra div container? You should consider this best practice and almost a requirement specifically when using Scriptaculous effects.
For example... Say you want to slideDown or Toggle a login form - and you have::
<div id="login-panel">
<input type="text" name="username" />
<button type="submit" name="send">Login</button>
</div>
All you have to do is add an extra inner div tag::
<div id="login-panel">
<div><!-- extra div here -->
<input type="text" name="username" />
<button type="submit" name="send">Login</button>
</div><!-- close it here -->
</div>
Now when you do something like Effect.toggle("login-panel", 'slide'); the transition should be much smoother and less jumpy. It may seem a little sloppy but it almost always helps. Hope this helps you!!
Keep in mind that when Scriptaculous begins an animation, the container that is being modified will be absolutely positioned and then a record of the height will be taken, similar to what danielsherson mentions. If however the container does not exist within a relatively positioned parent container, then the dimensions of the animating container may change quite drastically. The easiest way to test this is to modify your container using firebug to set the position to absolute. What happens? Did the height change? For the best results, there should be no change in the dimensions of your animating container when switching to absolute positioning. What happens to the rest of your document, such as content moving underneath, will not matter.
The padding/margin issue is a tricky one too since there really isn't a way to prevent the margins from overlapping and creating issues. Best way I found to address this is to set your animating container to float and then use the clearfix hack on a parent container to make sure nothing overlaps.
<body style="margin: 0 auto; width: 300px; position: relative; background: black;">
<div class="parent nonanimating clearfix">
<div class="animating" style="float: left; width: 100%; background: white;">
<div class="apply-your-margins-and-padding-here">
...content...
</div>
</div>
</div>
<div class="parent nonanimating clearfix">
<div class="animating" style="float: left; width: 100%; background: white;">
<div class="apply-your-margins-and-padding-here">
...content...
</div>
</div>
</div>
</body>
Note that the classes are not functional and just for reference to my comments with the exception of clearfix, which is the float clear hack. The backgrounds and widths are only specified to give a better example of what is happening. Add whatever animation you'd like to $$('.animating')
I use this one (there are many), all though it is old and I don't even design for many of the browsers this hack supports..
.clearfix:after {
content: ".";
display: block;
clear: both;
visibility: hidden;
height: 0;
}
.clearfix {
display: inline-block;
}
/* Hides from IE-mac \*/
* html .clearfix {height: 1%;}
.clearfix {display: block;}
/* End hide from IE-mac */
I don't think it's a performance issue at all. I'm having the same issue. The ONLY way I've been able to make it not jump is to define a height for the div I'm sliding. I realize that this is NOT a good solution but it's the only one I've been able to find. I've also tried adding the additional div and it had no effect on how the Effect.toggle slide worked.
If anyone else has any more info on this, I'm all ears.
To prevent a Scriptaculous effect from jumping or jerking, remove the 'style' attribute from the element which you are applying the Effect to.
This:
<div id="mydiv" style="padding:10px;margin:10px;">
<button onClick="new Effect.BlindUp('mydiv');" />
</div>
Becomes:
<div id="mydiv">
<button onClick="new Effect.BlindUp('mydiv');" />
</div>
The styling can be placed in a enclosed div like this:
<div id="mydiv">
<div style="padding:10px;margin:10px;">
<button onClick="new Effect.BlindUp('mydiv');" />
</div>
</div>
The problem is caused by Scriptaculous reapplying the element's (mydiv) inline style declarations after the effect has been performed.
I have found success with using position: relative; on the block element using the slide/blind animation. Make sure padding/margins are placed on the child elements and not the slide block element.