4 ms·

While this might be useful in certain cases, don't get your hopes up: i18n will break your carefully laid out equal width layout. E.g. many german terms will be

by corty 6y ago

While this might be useful in certain cases, don't get your hopes up: i18n will break your carefully laid out equal width layout. E.g. many german terms will be longer than the english equivalent, causing all the same problems, just even more annoying because you as an english-speaking developer won't notice until it hits your foreign users. Give up on pixel-perfect design or give up on i18n. You cannot have both (or rather you cannot afford a redesign for each new translation).

LukeShu 6y ago
I think you're missing the point. i18n is just a change in the static content, which is mentioned in the article, but is pretty quickly dismissed: > While this feature allows for some creative layering in static typesetting, it is decidedly spectacular for interface design, where things tend to quickly go awry with only small changes. As an example, changing the weight of a single menu item on hover usually results in an erratic twitching dance of the whole menu as it tries to adjust for the change. > this feature is nothing but a nice gimmick in static typesetting, The point is that when the font attributes change dynamically when using the interface; like hovering over a button makes the text bold. If that dynamic during-interaction change changes the size, it might make everything else move around too, which would be bad. The problem being addressed isn't so much being able to get the page to look just so, but being able to make it not jitter around while you interact with it. Here's the animation from the article that I'd use to get the point across (top is a non-uniwidth font, bottom is a uniwidth font): https://miro.medium.com/max/1400/1*eUu31P1t6Ez6xwD56BQJaw.gif https://miro.medium.com/max/1400/1*eUu31P1t6Ez6xwD56BQJaw.gi...
- asiachick 6y ago
  I think you missed the point of the OP? Let's try it https://jsfiddle.net/7ysgdpf2/ https://jsfiddle.net/7ysgdpf2/ Failed for Arabic, Sanskrit, Telugu. I'm only guessing those languages are not easily writable with fixed size units
  - jfk13 6y ago
    Whether it'll work or not for the various non-Latin scripts will depend what fallback fonts the browser happens to pick, so people's results will vary. Your jsfiddle also fails even for English in most browsers, because you didn't load both regular and bold weights of Recursive. As a result, you get a browser-generated synthetic bold effect, which varies between browsers and in most cases (but not Chrome, IIRC) will alter the width. (To fix that aspect, you need something like "family=Recursive:wght@400;700" in your Google Fonts link.)
  - leephillips 6y ago
    The jsfiddle shows it working perfectly in my browser.
    - asiachick 6y ago
      This is what I see https://pasteboard.co/JM3MBN4.png https://pasteboard.co/JM3MBN4.png For it to have worked each pair of lines should be the same width. They are not. Tested on MacOS 11.1 Safari, Firefox, Chrome and Windows 10, Firefox, Chrome. All failed.
      - leephillips 6y ago
        Interesting. It renders in a width-invariant way on my machine (chromium on Ubuntu).
  - FreeFull 6y ago
    In this case, the problem is that the Recursive font doesn't actually contain the Arabic and Japanese characters, so the browser is falling back to another font. If you use a uniwidth font that actually contains all the characters, this should work.
kevincox 6y ago
This is true for static layouts. However I think the compelling use case is when the font weight changes dynamically such as on hover or focus. In this case it can be useful to avoid having the layout shift (especially on hover where the shift risks moving the hover target and creating an unwinnable game of cat and mouse).
IggleSniggle 6y ago
It becomes _even more important_ for i18n. When you’ve worked out your maximum character width for each element across all languages you support, every pixel counts. Knowing that applying bold is not going to cause a reflow in one of the languages you’re not currently working with is a huge boon.

by corty 6y ago

LukeShu 6y ago

I think you're missing the point. i18n is just a change in the static content, which is mentioned in the article, but is pretty quickly dismissed: > While this feature allows for some creative layering in static typesetting, it is decidedly spectacular for interface design, where things tend to quickly go awry with only small changes. As an example, changing the weight of a single menu item on hover usually results in an erratic twitching dance of the whole menu as it tries to adjust for the change. > this feature is nothing but a nice gimmick in static typesetting, The point is that when the font attributes change dynamically when using the interface; like hovering over a button makes the text bold. If that dynamic during-interaction change changes the size, it might make everything else move around too, which would be bad. The problem being addressed isn't so much being able to get the page to look just so, but being able to make it not jitter around while you interact with it. Here's the animation from the article that I'd use to get the point across (top is a non-uniwidth font, bottom is a uniwidth font): https://miro.medium.com/max/1400/1*eUu31P1t6Ez6xwD56BQJaw.gif https://miro.medium.com/max/1400/1*eUu31P1t6Ez6xwD56BQJaw.gi...

asiachick 6y ago
I think you missed the point of the OP? Let's try it https://jsfiddle.net/7ysgdpf2/ https://jsfiddle.net/7ysgdpf2/ Failed for Arabic, Sanskrit, Telugu. I'm only guessing those languages are not easily writable with fixed size units
- jfk13 6y ago
  Whether it'll work or not for the various non-Latin scripts will depend what fallback fonts the browser happens to pick, so people's results will vary. Your jsfiddle also fails even for English in most browsers, because you didn't load both regular and bold weights of Recursive. As a result, you get a browser-generated synthetic bold effect, which varies between browsers and in most cases (but not Chrome, IIRC) will alter the width. (To fix that aspect, you need something like "family=Recursive:wght@400;700" in your Google Fonts link.)
- leephillips 6y ago
  The jsfiddle shows it working perfectly in my browser.
  - asiachick 6y ago
    This is what I see https://pasteboard.co/JM3MBN4.png https://pasteboard.co/JM3MBN4.png For it to have worked each pair of lines should be the same width. They are not. Tested on MacOS 11.1 Safari, Firefox, Chrome and Windows 10, Firefox, Chrome. All failed.
    - leephillips 6y ago
      Interesting. It renders in a width-invariant way on my machine (chromium on Ubuntu).
- FreeFull 6y ago
  In this case, the problem is that the Recursive font doesn't actually contain the Arabic and Japanese characters, so the browser is falling back to another font. If you use a uniwidth font that actually contains all the characters, this should work.

kevincox 6y ago

This is true for static layouts. However I think the compelling use case is when the font weight changes dynamically such as on hover or focus. In this case it can be useful to avoid having the layout shift (especially on hover where the shift risks moving the hover target and creating an unwinnable game of cat and mouse).

IggleSniggle 6y ago

It becomes _even more important_ for i18n. When you’ve worked out your maximum character width for each element across all languages you support, every pixel counts. Knowing that applying bold is not going to cause a reflow in one of the languages you’re not currently working with is a huge boon.