Pixel line-height setting in iui-body considered harmful?

[tcobbs-bentley]

I just spent some time trying to track down why one of my elements became shorter after upgrading from 2.19 to 3.0, and eventually tracked it down to the line-height setting in iui-body. I can work around the problem by resetting that to normal, but it seems to me that it is a very bad idea to set that setting to a specific pixel value in iui-body, since that has such wide-ranging consequences.

In my particular case my element contains large-ish text. Because of the global body-level line-height setting of 22px, space was not made to accommodate the larger text. This body-level setting means that (unless I am misunderstanding) anyone using itwinui is forced to set line-height to some other value any time they have any text anywhere that isn't the default size, and I feel that is very bad.

Am I missing something? Is this hard-coded pixel setting providing some advantage that I'm just not seeing?

[mayank99]

after upgrading from 2.19 to 3.0

I think you're referring to itwin-core. They started using itwinui in 3.0. So there is no "change" from our side.

Is this hard-coded pixel setting providing some advantage?

Setting line-height globally is a standard CSS practice because the default browser line-height is too small. What is debatable however is the use of a hardcoded pixel value. We are currently experimenting with switching to rem units in #424, so that should help a bit. We might also try using some fluid value (e.g. line-height: calc(1em + 0.5rem)) after researching a bit more.

my element contains large-ish text

Your concern about larger text is very valid, and this is an often thought-about problem. For now, you can either extend our typography variants or override the line-height on a case-by-case basis.

[tcobbs-bentley]

Thanks. When using iModelJS 2.19, apparently itwinui-css either didn't get imported, or not in a way that would change the class of the body element to iui-body. After upgrading to iTwin 3.0 (and making necessary adjustments), my body element did have the iui-body class added to it, introducing this problem.

Based on your link, I'll be setting .iui-body and .iui-body * selectors to have line-height of calc(6px + 1em). Note: it seems like using 1em + 0.5rem is asking for trouble, since the page you linked to indicated that the amount of extra spacing should be fixed regardless of the font size. I assume that using 0.5rem would lead to extra unwanted spacing in the entire page if the user increases the default font size.

[mayank99]

When using iModelJS 2.19, apparently itwinui-css either didn't get imported

I think imodeljs 2.X simply doesn't use iTwinUI.

Based on your link, I'll be setting .iui-body and .iui-body * selectors to have line-height of calc(6px + 1em)

What value you use should be carefully considered. Our current CSS follows our current UX standard values which were specifically chosen to work well with other iTwinUI components.

I realize that your case might necessitate different values for mobile users so you are free to experiment yourself. But like I said, we are currently researching flexible typography units. If you find a value that works well for your users, please share it back with us so that we could also consider it when we update our standards.

it seems like using 1em + 0.5rem is asking for trouble [...] I assume that using 0.5rem would lead to extra unwanted spacing

I would not call it "unwanted". It's an accessibility best practice. In fact, WCAG explicitly recommends the line height to be at least 1.5 times the font size.

/cc @FlyersPh9