jchensor

You, sir, are my hero. Totally worked. Created a flex container and kept it separate from the text, and now I get the line breaks AND the self-vertical-centering. Thank you so much!

Ah, yes, I see. Okay. Removing the flex does fix the <br> tag problem. The reason for using the "flex" option was to make sure the text was always centered vertically regardless of how many lines the text is, because for my purposes I don't actually ever know how many lines that display is gonna be. Using the "flex" option was the only solution I had found that worked for me so that the text will always be vertically centered dynamically with one line, two lines, three lines, etc. Removing it makes it so that text is always at the top of the graphic in the original zip file (or the top of the css bounding box width and height). Obviously, centering the text vertically isn't your problem, though. LOL! I'll have to see if I can an alternate solution that supports both. But at least I know why this is happening with the Greensock portion! Thank you very much! - James

Holy crap I didn’t even THINK of that. I’m so so so so sorry!! That’s totally my bad! O_o Thousand apologies from my end! - James

Hello! I've recently started to use SplitText and it's very cool. However, I'm finding some odd behavior in it, and I'm wondering if I could get some help. In the attached file, if you unzip it and just load "topics.html", you'll notice that at one part, "weprocess" shows up on the screen. In the "topics.js" file found in the "js" folder, the text I have written has a "<br>" tag in between the two words. So SplitText isn't processing it normally as I have seen in all the sample Codepens. And I haven't been able to reproduce it properly in the Codepens either. Not only that, but if you uncomment the single line in the "revert" function where I call "mySplitText.revert()", the <br> is read properly after revert takes effect. (Note: I'm using Chrome to view the html file currently on a Windows X machine.) Also, the way I have the text set up is in a very defined space. But when the text gets too long to fit in there, SplitText starts to do some crazy things to the format display. All you need to do to see this is, in the "topics.js" file, comment out the first "var topicDetail" line and uncomment out the second one right under it and refresh "topics.html" in the browser. When the line is particularly long, the format gets completely dismantled. I'm not sure what it is that I'm doing that makes it all behave incorrectly. But any help would be appreciated! Thanks! Edited to add: It *probably* has to do with the fact that I am setting the html text and re-pulling it via the js file. While this seems redundant, for the purposes of what I'm trying to accomplish, this is a necessary step so I can't avoid doing this. - James

Hi, Dipscom! Thanks for the quick reply! And I just didn't want to be that guy who made a new thread for something people are like, "DUDE, use old threads!" Hahaha! But what I will do is try to reproduce this issue somewhere else other than XSplit, and if I can, I'll start a new thread so I can have all the new information available immediately! Thanks again! - James

Hello. I'm running into this problem and I just downloaded Greensock today. A lot of the examples are a little outdated, but I'm using the main example on the site as a basis: https://codepen.io/GreenSock/pen/mvhak I feel like I'm following everything to the tee. But when I run it, SplitText is not honoring my <br> tag on my string. However, I call .revert() after everything is done via "onComplete" and, after revert takes place, the <br> tag immediately becomes recognized. This is essentially my code. I create my string, set it to the "topicDetail" item of my html, make sure the opacity is fully on, then set up my animation. Again, when it runs, the <br> tag is ignored, but as soon as revert() is called, the <br> kicks in and the text snaps instantly to splitting properly. var topicDetail = "This is a test to see<br>if my Break Tag is honored."; // Set the topic detail. $('#topicdetail').html(topicDetail); // First make sure it's set to full opacity, just in case. TweenLite.set('#topicdetail', {opacity: 1}); // Set the animation for the detail text. var tl = gsap.timeline({onComplete: revert}); var mySplitText = new SplitText("#topicdetail"); var chars = mySplitText.chars; tl.from(chars, {duration: 0.5, opacity:0, scale:3, y:40, ease:Back.eastOut, stagger: 0.02}); When I replicate this on the codepen sample page from above, it works just fine. Now, I AM running the web page not via a browser, but inside XSplit, an application designed for streaming for sites like Twitch.tv. However, that shouldn't be the problem, I don't think. But you never know. Better to give all the info possible. Everything else has been running properly on XSplit thus far. Edited to add: Messing with the sample page above, revert() also causes a snap on the text above even if the only thing I change is adding "revert()" as an onComplete. That's not really the bug I'm here to tackle, but it does seem to be a bug in general that the text that gets produced doesn't match, exactly, the text after being reverted. Obviously I'm okay with not calling revert() at all if that bug remains, but I still would like my <br> to be properly processed.