RichText should have a property to ignore missing closing tags

Feature Requests Engine Features
#1

As a Roblox developer, it is currently annoying to make typewriter animations with RichText

If Roblox is able to address this issue, it would improve my development experience, because I would be able to easily make typewriter animations in my games.

Adding a feature like “continous properties” in RichText will make scripting for typewriter animaions much easier.
As of now, most of us know that we need to wrap up the RichText properties at the end with a slash (<b>Hi</b>)
With this feature implemented, we will no longer have to worry about wrapping up the properties at the end.

As of right now:

  • Normal TextLabel using RichText (Normal, Bold, then Italic)
    asd
  • Normal TextLabel not using RichText
    asd

With a property called continous properties or something :
This one has no bold wrapped up at the end.

  • TextLabel with this property enabled, using RichText (As you can see the bold bleeds over the italic)
    asd
  • TextLabel with this property enabled, not using RichText
    asd

Sorry for the unclear explanation, this was bit of a quick one.

5 Likes
RichText [TextScaled Support Added]
#2

Sorry, but this doesn’t work.

It’s impossible to get any reasonably predictable / consistent behavior by arbitrarily slicing in the middle of a rich text and expecting Roblox to patch it up for you somehow. What happens when you slice halfway through the ending tag? How does the Rich text know that it’s an ending tag and not another starting tag? Etc, etc…

The solution to this is for someone to publish a Lua library which understands how to type-writer-ify a block of RichText, not for the engine to try to make a wild guess at what you’re doing.

6 Likes
#3

Say I have a loop that iterates through every character in my “rich text” variable, and it uses a wait() for each character, but when it hits the “<” It’ll skip the wait, and iterate without the wait, until after it hits the end of the “>”.
How about that? That way the rich-text will not show any “raw-text” in the typewriter animated TextLabel.

#4

Yes, this is still possible with normal scripting. This suggestion is just very helpful in some cases.

#5

It’s still not a good solution, because it makes assumptions about what the developer wants. What if the developer isn’t trying to write a typewriter effect? In that case they probably want to know that their tags are mismatched / broken when it happens, not have the engine silently try to patch things up for them. The problem that the engine is trying to make a wild guess at your intent still exists.

What you want is a Lua module that knows how to properly sub-string a rich text, that would make it just as easy and leave no guessing to the engine:

local Typewriter = require(...)
local writer = Typewriter.new("My <b> fancy </b> string")
textBox.Text = writer:getNextString()
1 Like
#6

What I’m trying to propose is a new boolean property in the TextLabel instance. Which lets the developer choose if they’re making a typewriter effect.

But yeah, just a small quick suggestion, probably a terrible suggestion, I’ll go with it.
I’ll attempt to make a module that knows how to make richtext in a typewriter effect.

#7

Thanks for your suggestion We have been discussed this for a while internally. As @tnavarts has explained, it is very hard to make it ignore closing tags for now. While we have some plan on shipping text effects (that applies to glyphs) as a dev feature so that you do not need to worry about manipulating strings or dealing with unicode.

1 Like
#8

I understand that it’s hard to implement this feature.
This isn’t very important, since we can script it. :upside_down_face:

#9

In addition to being difficult to implement, this feature would cause more headaches than it solves.

It allows bad behavior (you can be lazy and hope the engine catches it for you), hides bugs (won’t let you know if you forgot a closing tag), and can lead to misbehaving results (engine assumes something incorrectly).

The web is full of absolutely garbage HTML because browsers tried to be lenient and “guess” at what the user meant, which leads to tangled messes and weird dependencies. We should avoid making the same mistake, especially for something that could be done properly in Lua.

5 Likes
#10

I already understand, this idea is garbage and I’m embarrassed to admit.

#11

This idea was only to specifically simplify one thing, but it’s not important.

#12

No reason to be embarrassed! You brought up an issue and provoked a discussion, and that’s always a good thing.

3 Likes
#13

Alright, I understand, thanks. :slight_smile:

2 Likes