I have seen the document and know ' links defined by entityRanges ' and ' bold style defined by inlineStyleRanges'.
But the ' bold style ' also can be seen as a entity which type is bold and data is font-weight: bold; ?
So what is difference between entity and inlineStyle? Why don't just use entity for everything?
Inline styles are meant to only really decorate (i.e., style) the content in that range as-is. It has properties such as being an ordered set (e.g., BOLD, ITALIC) to control rendering.
Entities can render anything regardless of the content that it is applied to, and has the additional MUTABLE, IMMUTABLE, SEGMENTED properties.
@guitardave24 Thanks for your reply.
I decide to use MUTABLE entity with data bold to replace inline style bold, because it's will more friendly to our java engineer to understand. It's OK?
The key here is to think of entities as _metadata_, not as style.
Consider an imagined styled Facebook comment: "Hey Isaac, are you _sure_ you want to commit that change?"
Here, my name is a Facebook tag. There is metadata associated with my Facebook identity, and a decorator can render it as bold (or a link, like on actual facebook.com). That's an entity. In contrast, the italic text afterward doesn't have any metadata -- it's just styled text.
You _can_ use an entity to represent styles, since in essence style information is also just metadata on a text range. IMO, though, you'll end up duplicating built-in functionality.
@hellendag got it, thanks.
Most helpful comment
The key here is to think of entities as _metadata_, not as style.
Consider an imagined styled Facebook comment: "Hey Isaac, are you _sure_ you want to commit that change?"
Here, my name is a Facebook tag. There is metadata associated with my Facebook identity, and a decorator can render it as bold (or a link, like on actual facebook.com). That's an entity. In contrast, the italic text afterward doesn't have any metadata -- it's just styled text.
You _can_ use an entity to represent styles, since in essence style information is also just metadata on a text range. IMO, though, you'll end up duplicating built-in functionality.