Component ellipses style not applied correctly

[sampullman]

The text-overflow style isn't applied as expected to text components, since there is a wrapper div around the content and text-overflow style isn't inherited by the child div.

One solution could be to manually apply the style to the child in the renderer.

It also may be useful to add specific UI for the text-overflow style, but that can be handled in a separate issue.

Tasks

• Apply text-overflow correctly
• Consider automatically adding overflow: hidden; white-space: nowrap; when text-overflow: ellipsis is set
• Consider how to set a maximum number of lines for text, and show ellipsis once exceeded

[sampullman]

@ClaireMao1996 Does this explain the problem correctly?

[ClaireMao1996]

Yeah!

Do we have a way to set a maximum number of lines for text display and at the same time show ... if it exceeds?

For example:

[sampullman]

I'll have to look into it. I think this is a useful and somewhat common feature, so it's worth prioritizing soon.

[abemscac]

Hi @sampullman

While implementing this feature, I wonder if it make sense to introduce another layer of abstraction between the underlying CSS code and UI?

For example, if we want to use -webkit-line-clamp to customize how many lines of text should be shown before ellipses is applied, we also have to add display: -webkit-box; and -webkit-box-orient: vertical; to the target component. Currently we do this by automatically add those "accompanying properties" when certain actions are done (i.e., setting gradient background color through toolbar), which makes sense for developers, but might be confusing to non-developer, generic users. These accompanying properties may not make sense on a component anymore if any one of them changes to another value.

For normal users, the editor would probably be easier to use if they just see a list of comprehensive options to choose from; e.g., "Maximum lines of text: unlimited | by height | specific numbers", and we hide the CSS implementation underneath so that users don't have to deal with it themselves. Properties like the src of an <img> tag could also benefit from this abstraction, but that requires a huge refactor. What do you think? 😬

[sampullman]

Yes, overall I think it's a good idea, but I don't want to totally hide the underlying CSS. Along the same lines, I've been considering better editor UI for known inputs (like href and src), as well as how to best support grid.

One problem is how to handle removing the extra CSS values (like -webkit-box and -webkit-box-orient), if the value is cleared in the UI. In this case we can probably assume all the related CSS values should be removed, but there might be some situations where that's not ideal. The only way to be sure would be a way to track "grouped" properties in the site data, but I don't think that's worth the extra effort and big refactor.

[abemscac]

I see, no problem! I'll try to implement this feature under the current design, thank you!