Jump to content
GreenSock

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

ryanpwaldon

Members
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

4 Newbie

About ryanpwaldon

  • Rank
    Newbie

Recent Profile Visitors

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

  1. Thanks Jack, good solution!
  2. Hi everyone, I'm having an issue aligning an element (a car) to a path (a road). I've provided a simplified example (the SVG is large, although, I thought it was best to include the entire thing for context). I'm using the align property with the target path as the value, although it doesn't seem to be working – the car appears a few hundred px away from the target path. (I'm probably missing something simple) Would greatly appreciate any help. Ryan
  3. Thanks for the quick responses! No worries, I was in a bit of a rush at the time and I left quite a lot out. I've made a reduced version on codepen, although unfortunately I could not replicate the issue (this seems to work fine in Safari). Nevertheless, I've attached the pen below for reference. Despite of this, I have been able to replicate the issue by uploading my entire build to codepen. You'll see this works fine in most browsers, although the carets are not removed after being typed in Safari due to the explanation in my prior comment. I completely understand that this will be hard to debug, although if you want to check it out I've attached it below. For reference, the typewriter is called on lines 68, and 83-86; and the typewriter functions can be found between lines 107-116. In all honesty, a work around should be fairly straight forward, I was just thinking it would be nice if I could make my code a little bit more lean (I now understand it's not the greatest idea to do it this way). Also, thanks for the suggestions Jonathan! This will be part of a dynamic banner (with dynamic text) that will have to wrap, and account for line breaks, hence why I went for a custom solution.
  4. Hi guys, I'm running into an issue on Safari with a function I've created that uses the _next, and _prev properties on a tween object. Here's the code: const copy = new SplitText('.copy-' + i, {type:'chars, words', charsClass:'chars'}) tl.staggerTo(copy.chars, staggerDuration, {onStart: caretForward, onStartParams: ['{self}']}, staggerDuration, label) function caretForward(tween) { if (tween._prev) { TweenMax.set(tween._prev.target, { borderRight: 'none' }) // this removes the caret for the previous character // tween._prev is always null when called in Safari } TweenMax.set(tween.target, { autoAlpha: 1, borderRight: borderStyle }) // this adds the caret for the current character if (tween._next === null) { // tween._next is also always null when called in Safari blink(tween.target) } } I'm creating a typewriter effect whereby the caret is created (by adding a borderRight to the character) in the onStart callback, and subsequently removed using the _prev property in the following tween. This works in every browser (including IE), however the _prev property seems to be always 'null' in Safari. Does anyone have any ideas on what could be causing this? Any help would be greatly appreciated! Thanks, Ryan
  5. Thanks for the advice, Jack! Glad to say I figured out a solution this morning. I used font face observer (https://github.com/bramstein/fontfaceobserver) which is a library that allows you to fire a callback once particular fonts have been loaded (and it probably does some other things). Web font loader is an alternative to this, although it's a heavier library (and as mentioned above, I couldn't get this working anyway). Still a bit puzzled as I use split text all the time and haven't come across this issue before. Anyway, this looks to be a pretty solid solution should anyone else happen to come across this
  6. Hey guys, Hoping someone can help me out. My Problem: Split text is being applied before my font has actually rendered in the browser which results in abnormally large letter spacing. My assumption is the fallback font is being used for the split text calculation prior to my imported fonts being rendered in the browser (thus, when my fonts are rendered, they're not formatted correctly). I'm 90% sure this is the cause of my issue, although let me know me if otherwise! The issue occurs about 50% of the time (the other 50% renders as expected) and at the moment it's only happening on IOS Safari / Chrome (so far from what I've tested) which makes it hard to debug. I've also tested and found this problem occurs more frequently when my font loads slower than usual. The problematic font is loaded from AWS, although I've also had the same problem loading fonts from Google. I've seen questions regarding this issue thrown around a few times, although I couldn't seem to find a robust / official solution (mostly hacks or the use of the Webfontloader (https://github.com/typekit/webfontloader) which looks great, but I can't seem to get working). Here's an example of what I'm seeing: Good: Bad: Has anyone got this figured out? Thanks guys! Ryan
×