Container width not changing to accommodate text after editing in 'Escape Hatch'

[toby_burkill]

Mac OS X version: 10.12.1
Subform release: 3f2bab9

While adding text to a box and then tweaking the letter-spacing using the 'escape hatch', the text became too long and a word disappeared. When left to auto width it does not take into account the spacing from the CSS and just trims the sentence unless a width is specified. I guess this would cause issues further down to line if that was part of a component that had text variations and the width was not set to auto?

Steps to repeat:
• Select a blank artboard and press "enter" to create a new box.
• Double click the box to type into it and add at least two words
• in 'escape hatch' add letter-spacing:0.15em;

Results: words disappear

Screen recording link: https://www.dropbox.com/s/bwb98t3qh2ntby8/Typography%20width%20not%20changing%20to%20acomodate%20text.mov?dl=0

Hope this helps
Toby

[kevin]

Hi @toby_burkill

Thanks for the excellent writeup and video!

The Subform layout engine doesn't know anything about CSS rendering, which is why the box doesn't expand when you set the letter-spacing property.

Subform isn't a web IDE, and we won't be supporting every CSS property.
The escape hatch will be removed at some point, so it's best to avoid it when you are coming up with your designs.

[nickisnoble]

Honestly I'd love to see the escape hatch stay!

Along with real type controls and all the other great things you guys do in future updates, I'd really appreciate full CSS support there – it's something that I feel is really missing in my current UI design app-of-choice, Sketch.

Sometimes you just want to dive in and write a few things out, yeah? It would be lovely if it was a two way control, i.e. if I were to add border-radius: 12px; in the escape hatch, it would update the corner radius ui controls as well.

(and maybe the same vice-versa: if the user had written something in escape hatch initially, it would stay up to date if the same control was later updated through UI...).

[josh84089]

I second this. I started following this project back when it was BoxBox and in very early development. Being able to compose a UI with CSS classes with real CSS properties was a huge game changer to me and my company. Perhaps I misread the intention of this tool, but if this is not the case I struggle to see what differentiates it from all the other similar design tools.

[Ryan]

@josh84089 (and others): If CSS properties/compatibility are a driving factor, curious as to why using a WYSIWYG tool like Webflow isn't the right fit?

[Benzo]

I agree with the point @Ryan is making here. Subform is not trying to be a web development tool and contrary to Sketch (and similar static UI design tools) it is trying to solve the problem that Designers currently face in their workflows, the ability to create flexible design systems to streamline the process of designing for multiple screen sizes.

Although the current version of Subform is using the CSS escape hatch to allow setting rules/behaviors for components in ways that are not currently possible through Subform's tools/UI, needing this escape hatch in the final product would mean that the application's UI is flawed.

Personally, I would not mind having the option of having something like the escape hatch for power users as long as keeping such a feature would not impede the development and vision of Subform.

[marc]

Totally agree. I never backed Subform to be an IDE, and I don't think it should be. Please get that notion out of your heads folks.

[Ryan]

Sure. Thinking about Subform might enhance productivity inside our design tools via different methods (command-line, code-like entry, etc) is great. And that may be what folks like about the current escape hatch: it can sometimes be faster to just type something out than using a graphical UI control. (I think that's what @nickisnoble is advocating above).

[nickisnoble]

Yes, speed and ease of getting it out of the brain is what I'd love, and sometimes typing is faster especially for multiple items.

To be very clear so we don't straw man this, I'm not advocating for an Integrated Development Environment or trying to start a "should designers code?" argument. Being able to write code in an app doesn't make it a developer only tool, a really great example of this is After Effects' Expressions feature.

---

A side note about this forum:

I've seen in a number of places, across threads, people saying things along the lines of "I wouldn't have backed Subform if...", "Subform is/isn't x", "My Subform would be...". Or people showing up to essentially downvote feature requests. I think criticism is very important but I don't those are the way to do it.

@Ryan and @kevin will triage and decide what they want to build. Or they'll give us something like this.

The best thing we can do if we want a good product is to strive for clear feedback on existing things that don't work, and have constructive discussions on how new features could look and work. Not whether they should be built ever (in the grand scheme of things), when they should be added, or what the final implementation has to be... because it's not up to us!

[nickisnoble]

Because your layout engine is much better, it's not so tightly tied to one ecosystem, and it can be used for more things (than just websites!)