Em and Rem support

#1

Continuing the discussion from How to apply different size/padding/margin to elements at different artboard sizes:

The problem

As designers we change font sizes in small increments in a very controlled fashion based on screen size. However people are able to adjust the font size themselves due to their vision and personal preferences. Meaning designs can quickly become messy and break entirely.

A solution

Following inclusive design patterns I find myself reaching for the em and rem units regularly. This allows me to more easily manage typographic hierarchy, vertical rhythm and other layout elements for both screen size changes and user type size changes. If em and rem units can be integrated it would allow a higher level of responsive design than "media queries" typically provides. With a slider on the base font size we could also quickly see how the design can handle changes from both different screen sizes and user preferences.

Elements that change relative to base font size.

2017.02.27 Status update
#2

Woah, em and rem are important units. If I had known the tool didn't support that I probably would not have backed it.

#3

Thanks for taking the time to writeup your reasoning @Wade!

One question that immediately springs to mind for me is how the "type scope" should be defined. I would expect rem to be defined relative to the base type size of the parent artboard.

But for components (which can appear across multiple artboards), what should the rem be defined in terms of?
The artboard in which that instance is placed?
So if you want a fixed size in a component, can you not use rem / em units?

#4

In my mind your expectations are correct and I would expect the rem to be defined by the parent artboard.

#5

I think this is a tricky question.

To me, using rems across the board and just scaling a base font size is great in theory, but falls down quickly in practice. Type scales just don't work proportionally. What looks good on a 27" display doesn't necessarily work on a 4" phone at 50% (or whatever). Maybe headers scale nicely at 50%, but body text just needs to go from 16px to 14px.

So realistically, you end up setting all of these tiny overrides/exemptions for edge cases, instead of just twiddling one variable. And that's messy and difficult to manage across a lot of different screen targets.

Personally, I like to be explicit about setting my type scales and how they'll adapt to different screen sizes.

A simplistic example for the sake of illustration would be something like this SASS map:

$font-scale: (
  body-text: (
    small-screens: (
      font-size: 14,
      line-height: 1.44,
    ),
    regular-screens: (
      font-size: 14,
      line-height: 1.44,
    ),
    big-screens: (
      font-size: 14,
      line-height: 1.44,
    )
  ),
  header-text: (
    small-screens: (
      font-size: 34,
      line-height: 1.1,
    ),
    regular-screens: (
      font-size: 38,
      line-height: 1,
    ),
    big-screens: (
      font-size: 40,
      line-height: 1.1,
    )
  )
);

While I don't think writing ugly SASS maps is the best way for Subform to handle this, the idea of setting an explicit modular scale—and defining how that scale works at different screen sizes—is a more manageable approach than using relative units everywhere.

#6

Yes rem would be defined relative to the base font size of the artboard and em would be relative to the parent element cascaded right through originating from the artboard or the most recently fixed unit.

A fixed size would require another unit of measure as rem / em are relative units.

#7

This definitely requires a lot of discussion which is why I have brought it up as early as possible before I have even done much with the software.

I personally worked off the scales listed in this article for previous websites.
http://typecast.com/blog/a-more-modern-scale-for-web-typography

TL'DR

Screen Shot 2016-11-16 at 8.35.58 pm.png715x261 31.2 KB

... and so on.

To further fuel this discussion I discovered this fantastic write up of creating Fluid Typography.
https://www.smashingmagazine.com/2016/05/fluid-typography/

Here they use the em, rem & vw units. Using the vw unit on the base font and heading sizes to allow it to change according to screen size. Combined with the calc() function you can set a minimum and maximum font size (currently non-existent in css) and the rate of scale.

Relevant topics covered

  • Controlling the rate of scale
  • Maintaining ideal line length
  • Implementing modular scale
  • Maintaining vertical rhythm
  • Working with constraints

I've only just discovered this solid write up and am still wrapping my head around it. It seems that the vh and vw also mentioned here https://talk.subformapp.com/t/vw-and-vh-support-or-alternative/438 also ties into this.

#8

Thanks for writing up these thoughts, Wade! It's really helpful—this is exactly why we're excited to have this forum.

The Smashing Magazine article is interesting: I think it frames the problem well, but also highlights how brittle some of the current workarounds are. (Forced resize on calcs with viewport units, etc)

Regardless of where we end up in implementation, communicating design intent is the driving force behind Subform. So we should also look at it from the perspective of other stakeholders in the product development process.

If Subform supports this concept of fluid typography, how do we communicate the results to teammates in marketing, developers, or end-users? For websites, maybe we can export CSS that works in modern browsers. But what about prototypes? Platforms that don't have calc and viewport units? What might the documentation for fluid typography look like? How does it degrade gracefully?

#9

Another alternative for rem units would be workspace settings rather than artboard settings. Something which can follow a user across multiple projects using multiple components, based on the workspace settings.

Think of this like Photoshop's color/unit/grid/ruler/tpography preferences or Eclipse's workspace settings (tab vs indent, line wrap vs not, whitespace characters showing, code coloring, etc).

If I work for company X, then every project I make for them has to follow the standards of company X, which are defined in the workspace.

#10

That could work. Though being able to set the base font size and probably even modular scale for the headings on an artboard would also be required in some way. Larger artboard being a larger screen requireing larger fonts and vice versa. Then you could play with the base size font in the workspace and see the changes across the boards?

#11

I’m a bit disappointed that this hasn’t gone anywhere in the 13 months since it was proposed. I just got into Subform and immediately started by adding some text and bumping into the same outdated static, pixel-based line-height controls that are in Photoshop, Illustrator, Sketch, and so on. I tried using relative units (ems, %), but those aren’t supported either.

Vertically aligning text within a bounding box without adjusting the line-height (i.e., adjusting the baseline) doesn’t appear to be possible either. This means my text inside of a button sits too low, forcing me to either commit to a 1:1 line-height or fuss with the relative positioning in the box the same as I would have to in Sketch, conveying an intent that isn’t there.

Perhaps once I get the hang of the s and hug units along with the layout engine that will resolve some of the issues, but things like linked values don’t appear to be possible. This means I can’t set my button height based on the size of its content, which is how the web works by default, and is an excellent default.

#12

Hi @coreyward thanks for writing.

You can set your button height based on the size of its content — that’s what the “hug” unit is all about.
On elements, hug is the sum of the minimum sizes of all of the children.
On text, hug is calculated from the font size and number of lines.

For vertically aligning text, we defer to using the regular layout engine — so rather than making a 200 tall text box and trying to vertically position one line within that, try making a 200 tall element, then a “hug” height text, and use the vertical before/after to position.
If that doesn’t answer your question, maybe you can draw a picture so I have a better idea of what you’re trying to do?

#13

Kevin covered the hug stuff in terms of a parent box sizing based on its text content, but I’m wondering if you are looking for metric-based bounding box measurement? (i.e. the text block should position relative to it’s parent based on, say, the capheight and baseline)

I can give you a little more of our thinking around that, if that’s the case.