Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...

Vic Emond

ShockinglyGreen
  • Posts

    7
  • Joined

  • Last visited

About Vic Emond

  • Birthday 06/02/1970

Profile Information

  • Gender
    Male
  • Location
    Chicago, IL

Recent Profile Visitors

1,848 profile views

Vic Emond's Achievements

  1. Phew...I didn't misspell that property. You had me worried that it was going to be a dumb mistake (although it might be some other dumb mistake). I am using this to create the draggable gallery: oGallery = Draggable.create( $('.slider div.wrapper'), { type: 'left', edgeResistance: .75, bounds: $('div.slider'), lockAxis: true, dragClickables: true, allowNativeTouchScrolling: true, throwProps: true, snap: { left: function(nEndValue){ return Math.round(nEndValue / nGalleryWidth) * nGalleryWidth } } } ); And you can see it in place on my dev site here: http://maw.netingredients.com. On mobile (at least on my iPhone running the latest iOS), the slightest deviation from swiping left to right on the gallery causes the native vertical scrolling to happen. So, in turn, swiping the gallery left or right can be difficult or a little wonky. I was hoping to get this to perform more like how the Instagram app works, for example. You can scroll up and down just fine, even if there are posts with multiple photos that allow you to swipe between them left to right. And when you are swiping left to right, there isn't any conflict with scrolling up and down. I realize that is an app and there is tighter control over event handling, but I was hoping I could make some improvements over what I've currently got. If you need more of a simplified test case to help me identify a solution, I'd be happy to throw one together. Thanks!
  2. I'm dealing with the same issue. Setting allowNativeTouchScroll to false on my draggable doesn't seem to work on the latest iOS. And I just tried your Draggable beta, but it doesn't seem to have changed anything on my end. Would love a solution for this! Thanks!
  3. If I apply an alpha tween: TweenMax.to($('.myElementWithTextShadow'), 0.5, {css:{autoAlpha:1}}); ...to text that has a text-shadow/filter:dropshadow - in IE9 - I see a black background behind the element as it fades in. It goes away once the tween has completed. Any thoughts on this?
  4. Wouldn't the "Tween.from" also potentially produce a flicker of the visible image until the Javascript kicks in? Anyhow, thanks for uploading a new version of the CSSPlugin! This will help me out a ton. Your immediate response and support are second to none. Much appreciated.
  5. I am getting the following error when I try TweenMax.killAll(): ReferenceError: Can't find variable: TweenMax.min.js:16 I'd give more specifics about the exact situation, but it's pretty basic and I would think that function's requirements and results are pretty straight-forward. I've got a bunch of tweens either running or queued up via delays (not delayed calls). Anyone else experiencing this?
  6. I am trying to show DOM elements in an animation that are initially hidden. I've tried initially setting their "display" to "none" in my CSS file, but then realized that the autoAlpha doesn't affect that property. Rather it sets the "visibility" to "hidden" (when going from 1 to 0 opacity - at least that's all the docs specify). So I tried setting the elements "visibility" to "hidden" in my CSS file instead. This certainly produces the intended initial layout, but my tween still doesn't fade my elements in. They just immediately appear at the end of the tween, rather than a smooth fade from 0 opacity up to 1. The only way I can get my tween to do what I want it to, is to laboriously set my opacity in my CSS like this: zoom: 1; filter: alpha(opacity=0); opacity: 0; ...so that I cover all of my browsers. And I don't want to set opacity in my JS, because there is/can always be that initial flicker when you see the object on the page prior to Javascript kicking in and hiding it. Plus, that seems awful inefficient as well. Using the autoAlpha method SHOULD be smart enough to set the opacity to 0, THEN set my "display" to "block" or "visibility" to "visible", THEN do the tween from 0 to 1. This would be most like the equivalent method in the AS version, wouldn't it? I realize that then heading back from 1 to 0, using that same method, would leave the question of whether or not to set the "display" back to "none" or the "visibility" back to "hidden" - but maybe there could be some flag set or something. Dunno. Am I missing something here? Or is there a better way to handle this?
×