Jump to content
Search Community

Silverback IS

Business
  • Posts

    21
  • Joined

  • Last visited

About Silverback IS

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Silverback IS's Achievements

  1. Is it necessary to add this style if pin spacers are turned off? It does create some issues listening to window scroll events. So on a mobile app using VueJS or something, if you load a page which has no scrolling, then switch to a page which does, then scroll trigger plugin wouldn't work. Basically I have built this https://www.ambertutton.co.uk/ The background you see on the text pages (contact and about) is pinned always and part of the layout. So on mobile devices it is always 100% viewport height and visible. If I load the contact page first, it usually will not scroll on a user's screen. So the style is added to the body. But then I switch to a gallery page, and no gallery images will animate in because we listen for window scroll events which no longer fire.. my nav bar is also listening for window scroll events which no longer fire. Interesting... I have just set the body overflow to visible and forced it with !important for now.
  2. Thanks I think the switching to 'fixed' positioning will cause some snapping on mobiles with the URL bar visibility changes. So I will probably have to look at wrapping the scroll container too. Thanks for such prompt help! I'll have a play.
  3. Very useful thanks - I was adding a class to try and set the fixed positioning once I was done. This seems neat. Another thing I found since posting was to put the whole animation in a fixed container. That may have other issues too though.
  4. Hi, I as wondering if there is a best practice for keeping a target pinned to the screen after the end point of the animation instead of it scrolling off the screen again. Thanks in advance!
  5. Sorry, you are correct, I didn't mean to confuse the situation! It is another potential solution to the main problem that a user can get completely stuck, and would provide a way they could scroll out of the draggable area to pinch and zoom. Easiest to demonstrate on CodePen: https://codepen.io/silverbackis/pen/VKNZZN So with the draggable area larger than the container, it'd be great if AutoScroll could be set to scroll the body when it reaches the edge of the container. I hope this helps to clarify, but I'm happy to start a new topic if this is not the best place to suggest this as an alternative way of preventing a user getting stuck. Sorry for my delayed reply as well!
  6. What about the idea of scrolling the next scrollable parent (perhaps defined by the user) instead of bouncing if already at the container boundary? If enabled it could default to scrolling the body if enabled? Similar to a scrollable div in iOS with -webkit-overflow-scrolling:touch applied
  7. Fair enough, thanks Jack I'll go down the route of disabling pinch zooms through JS if possible.
  8. Or alternatively...you could have a setting so that when you reach the boundary the touch move behaviour could scroll another element (by default the body perhaps). Kind of like how iOS scrollable elements work. You can scroll to the end, you get a bounce, but when the bouncing stops, if you then try and scroll down, the next parent element which is scrollable will start scrolling. That way at least you could get out of the area where you cannot pinch-zoom. (Wouldn't work for Google Maps, but I don't know if anyone is using draggable for an infinite sized canvas)
  9. It's almost as if Apple have done something silly by not allowing developers to easily prevent zooming on mobile layouts It does seem like it may not be possible if the first touch has to have default behaviours prevented. The only thing I could think is allowing a user to only zoom if both touches are simultaneous. Also perhaps delaying the preventDefault() function by 200-300ms to see if there's a second touch but I'm not sure if that'd work either.
  10. Jonathan: The behaviour is easily replicated on any draggable element in all existing demos. The difference is that the draggable element in our site is a large area. But essentially what I need to work out if I can do is perform native zooming with the touches starting on the draggable element. You can't zoom in or out when touching the draggable element, but if I zoom in on the page then scroll into a large area where the draggable element fills the screen, a user wouldn't then be able to zoom out or scroll away. Jack: Thank you very much - I imagine it'd be a task and perhaps not possible, but thought it was worth asking the question. Thank you for your response. My other option is to disable pinch zooming using javascript which I think will be OK if there isn't another workaround. Thanks both! Sorry for my delayed reply.
  11. I don't have a CodePen url as I don't think it's necessary to explain the issue but you'll be able to see what I mean on our website www.britishwebsites.co.uk With a large draggable area, now that ios10 does not allow a developer to easily override the ability to pinch and zoom, it becomes necessary that the pinch-zoom functionality on a draggable area works. If you zoom into a large draggable area (our big map/island) you can not then zoom out again. You would have to zoom in on another part of the website then scroll into the map view, but it is possible to get completely stuck. Are there any plans to make it so the draggable plugin can allow multiple touches to perform the default behaviour (i.e. zooming)? I know I can disable pinch zooming through javascript still, but I suppose it is a good thing to allow users to zoom in on websites which is why Apple have decided to ignore user-scalable=no now.
  12. If it helps anyone else I've also found out that if you have a link surrounding an SVG shape/polygon, adding touchstart/touchend events to the shape or the link seems to result in the link having to be clicked many times on Chrome for Android. As a result, I will have to use those events and detect the distance moved manually to trigger a click like event. Probably a browser bug.
  13. After stripping out the draggable plugin until the links were working again, I've built it back up and realise the solution by OSUBlake is great and fixes the issue - thank you! Firstly, I had read that the xlink namespace was deprecated, but by not using the namespace, link links surrounding the SVG shapes were not clickable even without initialising the draggable plugin. So I got the links working again without draggable then the fun began. Without the 'allowEventDefault' value being true, not even the onClick event on Draggable will fire. By setting it to true, I can get the onClick from Draggable and the click event on the link themselves. I've only enabled that for Android mobile devices so far ( very useful mobile detection scripts here https://github.com/kaimallea/isMobile ). I have more testing to do on Explorer/Edge but thanks for helping get to this stage!
  14. I've just tried that which didn't work unfortunately - but thank you for the help. I imagine it is to do with how I've structured my HTML and the way I'm positioning the SVG shapes with a link surrounding them. Even though in the inspector I can hover over the links and they appear to be there and in the correct place I have a feeling it's got something to do with it. I'm setting up a test page on my site where I can continue to play step-by-step with what works and what doesn't. I don't know at what point it stopped working but it may have even been a browser update or something. If I take draggable off completely, those links don't appear to be clickable on the android devices. I can see now from experience that Android Chrome is very odd with how it handles touch/click events. I'll be back on here when I figure it out
  15. Thanks very much for this, it's been very helpful - it's revealed there must be something else interfering some how. The onClick handler on draggable has the same behaviour issue where the triggerElement needs to be tapped multiple times to trigger the event. I can see the CodePen works well though so it cannot be an issue with Greensock. Allowing the default event doesn't make a difference either. It is strange because once I manage to trigger that event, without dragging the area the click event triggers without an issue, as soon as I drag the element again, I have to tap lots of times. I'll keep plugging away at it. Thanks again!
×
×
  • Create New...