Splittext - keep br tags

[b.strauss]

Hi, when i use the splittext plugin on a H1 element the result does not contain the BR tags i placed inside the H1. I always want to break at that text position. I don't want the plugin to inline everything. I also don't want to specify the width of the container. How do i prevent Splittext from removing the BRs?

[Carl]

Hi and welcome to the GreenSock forums,

 

SplitText should honor <br> tags as you described and as shown here:

http://codepen.io/GreenSock/pen/yYeVpL?editors=101

 

Please fork that demo and edit  the code so that it uses your code that isn't working and we will give it a look.

[b.strauss]

Hi, thanks for the feedback. In the meantime i found out the problem was that the SplitText constructor was called too early, directly after page load. Calling the constructor later, just before play() is actually called, solved the problem. I suspect the browsers css calculating/painting interfered with it.

 

Thanks anyway!

[Manu]

As a reminder for anyone landing here, I don't know if it's a bug but keep the text without space between <br> tags!

[jchensor]

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: 

See the Pen mvhak by GreenSock (@GreenSock) on CodePen

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.

[Dipscom]

Hello jchensor,

 

Welcome to the forums!

 

Firstly, I understand your reasoning but, it is better to create your own thread over reviving one that is been idle for several years. Even if it appears they deal with the same issue. Things change with time and the solutions might not apply, In this case, there has been a major update in GSAP.

 

As for your issue, do you think you are able to create a small reduced case example? I am not sure what could be going wrong in your situation. I have no experience with XSplit but if you say you do not get the issue if you put the relevant code in a browser, there isn't much room left for any other conclusion other than the issue being with how XSplit handles DOM elements.

 

I added a call to a .reverse() at the end of the sample pen you linked above at the timeline's onComplete callback but saw no issues. Presently I am unable to replicate your problem.

[jchensor]

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

[Dipscom]

It is understandable, don't worry. It's a very fine line to walk when deciding when to create a new thread and when to use other ones.

 

Usually, you should create your own mainly because it's your question and your answers. It's good to chime in on other's threads but, as a whole if each thread deals with a single question, everything is much more clear to anybody reading rather than going over pages and pages of different discussions going on different directions.

 

Also, threads that have been quiet for over a year are better off left alone. It's likely that there's new information that you will benefit if you ask a similar question rather than resurrect an old one.