Still no text wrap?

#1

I haven’t touched Subform for a month or so. Now need to work with a few responsive layouts and felt like a good idea to pick it up again. Trying to remember basic things like how do I create a component, how do I add text, all good so far :slight_smile:

… until I needed to create wrapping text. Kinda bummed that it’s not implemented. I could really use wrapping for some labels in this thing I’m doing. Is there any workaround or such available for wrapping? One really ugly one I can think of is create multiple states of a component, each with a different number of text subcomponents, and manually edit the text in each of them. That’s terrible though :slight_smile: is there any better way at this time?

#2

Hi @jaanus, Thanks for raising this issue.
You can wrap text in Subform, but you need to set the width explicitly on the box before the text will wrap.
If you leave the width blank, then the layout engine will automatically grow the box to be the size of the text (and thus the text will never wrap).

These two screenshots from Subform bb1f015 may help explain things:

Screenshot 2017-02-06 15.19.55.png706x161 17.8 KB

If you are wrapping the text, then you will need to also provide a height value.

Let me know if you have any other questions!

#3

Cool, thanks. Yes, I now see it works when I set an explicit width and height to the text element, cool.

I guess this means there is currently no way to make it smartly wrap based on the dimensions of the containing element (e.g if the parent width decreases, the text would start to wrap into multiple lines, and increase its height accordingly). Fair enough.

#4

Yeah, doing this well is a hard problem.
You need to choose smart line breaks, which requires hyphenation, which requires knowledge of the text language (since hyphens only make sense at phonetic boundaries, not between arbitrary characters).

At some point we may implement Knuth/Plass for decent linebreaking, but that's likely a ways off.
Doing text really well also may be a bit misleading in that we provide power in Subform that is not available on native platforms.
AKA, your developers will get very upset with you if you demand that text break/hyphenate on the web the same way it does within Subform =P

2017.05.30 Status update
#5

Is this smart hyphenation really a hard requirement for building layouts with Subform? I can totally see how localized smart hyphenation is hard. I am not convinced it is necessary. Maybe if people lay out whole pages with copy, it would be. I work a lot less with content copy and a lot more with things like forms and labels. Having a wrapped form label to be hyphenated seems to be unnecessary, I’d rather rework my label so it doesn’t need to be hyphenated to be sensibly wrapped.

CJK is yet another case. No hyphenation but other rules for wrapping.

Yeah… good luck with all of that :slight_smile: as a designer where I am today, I’d much rather take some more simplistic auto-wrapping now and better/complex thing later, rather than doing it fully correctly right away and thus waiting for the first version for a longer time. I don’t have a good definition of what tradeoffs the simpler version should make though.

#6

How would the difficulty of this change if it was scoped to whole word wrap only (no hyphenation?)

#7

This touches on the issue of Subform/platform mismatch I alluded to in my first reply.
If we encourage people to twiddle with the label width so that Subform breaks the words where they want, they may get the impression that this is how the words will break on the actual platform (iOS, Android, web, etc.).
But that's not something we can guarantee.

Arguably, if you are placing labels in a design and have a tight space, it's better for you to explicitly break the label into separate boxes that you layout yourself than to rely on the "auto word wrap" decisions of a single text box, which will differ according to platform, exact font, etc.

Agreed --- we don't want the perfect to be the enemy of the good here.

Is the simplistic auto-wrapping that currently exists in Subform good enough for your use case, or do you need some other functionality?

#8

The one thing I am currently lacking is auto-wrapping with variable width. Imagine a simple edge-to-edge one-column layout with a bunch of components below one another. Some of these components contain variable amounts of text. On wider screens, a string might fit on one line, while on narrower ones it might get wrapped to several lines. I would like to specify a layout for text component "16px margin on both right and left, and width is variable". The exact wrapping boundaries/cutoffs/thresholds are then not so important as just getting a general feel for how it flows with the same text being on one or several lines on screens with various sizes.

I can’t do the above with the current requirement that I have to specify an explicit width to a text component.

#9

You can do this using a percentage width on the child with padding values on the parent:

Screenshot 2017-02-09 12.47.44.png705x317 30.2 KB

I've attached the Subform file to this post.
Note that these layout semantics will change in the next release, but you will still be able to do this.

Of course, both now and in the next release you will still need to set an explicit height on the text box.

Does this help with what you're trying to do?

percentage_width_text.subform (1.4 KB)

#10

Thanks. Yes, this works for basic wrapping.

#11

There is so much room for improving how UI tools handle text.

  • Controlled character length for automatically truncating and applying ellipsis
  • Wrapping, but l limiting that wrap with truncating (ie. only allowing 3 lines)
  • Text resizing instead of wrapping

On a whole text responding dynamically in the same way that it does in a browser, or in the way that images, and vectors resize in groups within our UI program of choice.

#12

Agree, Brian.

The bad news is that getting this stuff right is really hard. :slight_smile: (And again, this is why most tools are really lousy at type)

Even in print, typography is complex. Add in all the stuff that digital introduces—dynamic wrapping that works with layout, truncation, rendering differences, responsive/fluid type, etc—and the complexity just grows.

At some point, I'm sure we'll write a deep-dive article on this stuff, but I'll throw this out again: Vincent De Oliveira's excellent post on CSS / browser rendering of font metrics and line height is a small window into the hellscape of digital type.

And if you really want to get into it, follow along as the CSS working group spends years working on a standard for type that can align to a baseline grid!

#13

@Ryan Very true. But I know that from a developer standpoint that on the web we can pretty much automate truncating, line wrap limitations, adapt font sizes based on width / height, etc.

I want design tools to have access to the same visualization options. I'd say the most difficult thing is providing enough flexibility to allow a designer enough control, but still being able to have it be a function of text. Meaning do you build in a bunch of options, or have it be more programmatic? Or somewhere in-between?

#14

Definitely. But one of the complexities of this domain is that the web renders type differently than say, how Core Text handles it. We want Subform to be platform agnostic, with the goal of helping designers communicate their design intent to developers in a way that can be implemented.

That means a few things, tactically:

  • We're not just throwing in Chrome's rendering/layout engine and calling it a day. We've written our own layout engine, which means we have to implement type handling ourselves.
  • We can potentially implement type functionality that the web/CSS doesn't do natively. (As mentioned previously, baseline grids are an example of that. They're still just a CSS working group proposal.)
  • Different platforms might render the same metrics (e.g. line-height) in different ways. How do we choose which one to do? Should we offer them all and let the designer decide?
  • CSS' type rendering is quite often not fully understood by designers. (Again, De Oliveira's post is an awesome primer on this) If the goal is to help designers prescribe and preserve their intent, we should expose the decisions that need to be made and illustrate how things are rendering and why.

Meaning do you build in a bunch of options, or have it be more programmatic? Or somewhere in-between?

Yeah, it's a good question. We're not trying to build an IDE or an uncanny valley prototyping tool. With the advanced type stuff, I think we'll start simple, work iteratively, and get feedback from designers along the way. As a guiding principle, we care less about interactivity than intent.