How to create a hugged text container

#1

Quick question that’s been boggling my mind for the past hour, how do I create a text container that’s hugging the text inside but also retains a set max width?

So basically I’m trying to create a chat bubble that has a text container inside of it that hugs the width of the text up to 540px wide. The problem is I can apply the “hug^540” width to the text but the text runs off to the right of the container. And if I use “1s^540” theres no value to pull for the 1s so I’m thrown a 0px wide box.

Any suggestions?

I can provide an example file if needed

Thanks guys

#2

Ryan, just want to make sure I understand your design intent before I answer:

  • The chat bubble should always hug its text child’s width
  • The text child should be the width of its text (hug) up to 540px, then it should wrap into multiple lines after that

Is that right?

How-to: Get started with Subform
#3

Yes you got it correct.

#4

@rrbarry11 @peterdarthur

Cool. So first thing is that ya’ll found a bug that we didn’t have a good test for. :slight_smile: In this example, the text set to hug^540 should indeed wrap after hitting 540px wide. We’ll get a fix in for this.

This brings up a second, related design intent issue. There are probably justifications for wanting both types of behavior:

  • Text should wrap to bounds of its container
  • Text should always be on a single line (no wrap) and be clipped by its container

I think we should probably expose an option on the text panel to specify this, with wrapping being the default. What do you think?

#5

@Ryan, I’m not sure I can think of a popular use for this behavior, unless the text is ultimately scrollable left-right in the final product. Clipped text isn’t usually a desired outcome, is it?

To me, this would be the most simple way to set hugging of a parent box and single child text:

  • Parent box set to hug_min^max.
  • Empty width on child text would trigger calculating and using the text length for that value. In such a case, space before and after the child element would only stretch in relation to each other (1s on each side would evenly distribute padding around the text box and not affect the “width” in any way) Note that setting a child’s width explicitly would override the auto-calculation of text width and the parent would hug an explicit width, as it already does currently.
  • Empty height on child text would trigger calculating and using the text height (wrapping within the parent’s max, minus any vertical “before” or “after” values for padding) for that value. Again, explicit values would also be hugged.

The issue (:cry:) comes when you have multiple text and box children within the parent. If ANY children have stretch-unit values, the stretch has no reference and neither the parent nor child is setting width, resulting in a dependency loop. So all siblings of hugged (auto-calculated width) text must have explicit widths, or bad things happen.

I feel like hugging seems obvious but easily introduces calculation issues.

#6

I agree with @peterdarthur, I cannot find a need for the single-line wrap option.

If I’m thinking correctly that can be achieved by just hugging the text child and setting a smaller width on the text container.

#7

I think the general case for no-wrapping is two-fold:

  1. Intent is that the parent should always grow to accommodate the child text string. For example, maybe you don’t want navigation tabs that accidentally wrap to two lines of text. (It clips because the tab has an explicit height, the tab gets taller and then looks out of place next to single line tabs, or the spacing around the text becomes inconsistent.)
    text_hug
    text_wrap

  2. Intent is that the text should always stick to a single line, but truncate if it exceeds the width of its parent.
    text_truncate

#1 is solvable in Subform by setting the parent to hug.

#2 isn’t doable in Subform right now. A hug parent always grows to the single-line width. A hug^max value on the text element will cause the text to wrap when it exceeds the parent width. Truncation would be possible if we added an explicit no-wrap option to the text element.

A follow-up question on this:

If the parent is set to hug and the text child is set to wrap, it still won’t wrap—because the parent is expanding to the width of the string as a single line and there’s nothing limiting the width of that line.

Is that confusing? You’ve explicitly specified “wrap,” but the text isn’t wrapping?

#8

Had to share the ironic fortune I received today at Panda Express:
20171206_153743
This baffles me. Ok, back to the discussion…

#9

I don’t find it confusing, the way I’d look at this is “hug the full text line unless you set *blank”

So in my case from the first post, I’d want my parent to "hug the full text line unless the text line width exceeds 540px then it would wrap according to controls that would have to be adding later, like if we want to hyphenate, or just push to the former word width.

#10

Hi @rrbarry11 @peterdarthur @Ryan,

I fixed this and added the relevant tests, so it’ll go out in the next release.
Thanks again for bringing it to our attention!

(TBD on control for explicit wrapping / no wrapping, that’s a separate issue for Ryan and I to design and ship later.)

#11

Whoop whoop! Can’t wait for that release, the huggin’ issue has been driving me crazy with menus and dropdowns, mainly because I thought I was setting it up wrong…

Anyways thanks for the bug fix!