mat-hint type descender and uppercase accents are cropped in mat-form-field

[SchnWalter]

Bug, feature request, or proposal:

Bug

What is the expected behavior?

All alphabet letters should be readable.

What is the current behavior?

The lower case letters that have descenders (g, j, p, q and y) should not be cropped in mat-hint

What are the steps to reproduce?

• Go to https://material.angular.io/components/input/overview#changing-when-error-messages-are-shown
• Take a look at the example, the y from the "Errors appear instantly!" hint is cropped at the button, this would be more obvious if you open your dev-tools and add a g in there (the curved descender goes away)

What is the use-case or motivation for changing an existing behavior?

Text readability.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

Probably a very recent build, the package-lock.json from the material.angular.io repo points to a commit.

Is there anything else we should know?

1. I've tested only on openSUSE Linux.

2. The Material Design specification doesn't say much about the "Helper text": https://material.io/guidelines/components/text-fields.html#text-fields-layout

3. The .mat-form-field line-height is inherited by .mat-hint. The problem goes away if you add .mat-hint { line-height: initial; }, but this solution doesn't seem right, probably, the line-height on the .mat-form-field should not be that small: 1.125

[mmalerba]

Can I ask what browser/OS you're seeing this on? It seems to work fine for me on Chrome + Linux.

Also as a temporary workaround, the line-height can be adjusted via the typography config: https://material.angular.io/guide/typography

[SchnWalter]

I'm on openSUSE Leap 42.3.

I've just tested all my browsers and I can see this issue in most of them:

• Firefox 52.6.0 (64-bit) for openSUSE Leap - Extended Support Release
• Firefox Nightly 57.0a1 (2017-09-16) (64-bit) - pre-Quantum
• Firefox Nightly 60.0a1 (2018-02-15) (64-bit)
• Chromium 64.0.3282.167 (openSUSE Build) (64-bit)
• Google Chrome 64.0.3282.167 (Official Build) (64-bit)
• Google Chrome 65.0.3325.73 (Official Build) beta (64-bit)
• Opera 49.0.2725.64 (64-bit)
• Opera 51.0.2830.34 (64-bit)

Firefox, Firefox Nightly, Chromium and Google Chrome (stable) have some extensions installed, but they shouldn't really cause this issue (and fonts are not blocked):

• EFF HTTPS Everywhere
• EFF Privacy Badger
• uBlock Origin
• Adblock Plus
• and some sort of User Agent switcher

But I don't see this issue in:

• Tor Browser 7.5 (based on Mozilla Firefox 52.6.0) (64-bit) It is configured to block requests to Google domains, which includes fonts.google.com, so no "Robotto" font.

[mmalerba]

Interesting, I tested Chrome & Firefox on Debian and Chrome, Firefox, and Safari on OS X. All seem fine, I wonder if maybe its specific to openSUSE?

Also here's another workaround that should have less side effects for the rest of your app (won't affect the sizing of any elements):

.mat-form-field .mat-form-field-subscript-wrapper {
  overflow: visible;
}

[SchnWalter]

I've also seen this on a different laptop with openSUSE Leap 42.2 and several browsers, including the latest, unstable version of chrome:

• Google Chrome 66.0.3346.8 (Official Build) dev (64-bit)

And you are right, I've tested on a fresh install of Debian 9 (stretch) and everything seems fine, but the font doesn't look excactly like the one from openSUSE. I'll do some more research, it might be just the way fonts are rendered.

I've checked the x-height and it seems to be the same (7 pixels), but the ascenders and the descenders are different; with 2 pixels on Debian and 3 pixels on openSUSE, so the total is 11px on Debian and 13px on openSUSE, it might be a problem with the font itself or some rounding errors. I'll test other fonts, maybe Noto, to see what I can find.

[mmalerba]

According to the spec we probably should actually be using Noto:

Noto is the standard typeface for all languages on Chrome and Android for all languages not covered by Roboto.

Would be great if that solved the problem

[SchnWalter]

I didn't get to do some more testing, but it just occurred to me that I should check if uppercase letters with accents are properly displayed. It looks like the accents are cropped even on Debian 9 (stretch):

This issue is an even bigger issue that I initially thought: Ă, Â, Á, É, Í, Î, Ó, Ú, Ü, Ñ, g, j, p, q and y all have issues in various cases. Maybe that overflow: hidden should go away, I wonder why it was added in the first place.

And we definitely need to check the specification regarding the line-height, 1.125 seems very small.

[mmalerba]

Ah ok, I do see the problem with the accent letters. I can also see it on the label and the input text in addition to the hint, so I think the right thing to do is bump up the line-height then, maybe 1.25?

[SchnWalter]

A line-height of 1.25 fixes the issues on openSUSE and Debian

EDIT: I've just checked elementaryOS and I saw that accents and descenders are cropped with a line-height of 1.125, but everything is OK with 1.25.

[SchnWalter]

I've talked to someone about the way fonts are rendered and I found out that it's not the browser that renders the font, but the operating system. And looking over the web I found this 7 part blog post:

https://blog.typekit.com/2010/10/05/type-rendering-on-the-web/ Type rendering on the web Each operating system contains a text rendering engine — sometimes multiple engines from which to choose. And each browser controls which of those rendering engines is used. So on the same OS, two browsers can produce text with very different appearances because they use different rendering engines. On top of that, often the rendering engines differ between different versions of the OS and different versions of the browser. Additionally, default font-smoothing settings vary by OS and OS version, and can be overridden by users’ browser preferences.

(and it looks like an interesting read)

[mmalerba]

This is apparently affecting most Googlers now that we use Debian, we may need to make the change to 1.25 line-height even though 1.125 is sufficient for the newer version of the font.

[ImranAhmed]

I'm seeing similar too.

I'm on Win 10 and Chrome.

@angular/material: "^5.2.1" @angular/core: "^5.2.1",

[FoxelFox]

Same on Windows 10 + Firefox @angular/material: "^6.0.0" @angular/core: "^6.0.0"

[rutgervd]

Still having this issue: Mac 10.13.6 + Chrome 69 @angular/material: "6.4.7" @angular/core: "6.1.7"

[mmalerba]

This was caused by an old version of the Roboto font that shipped with Debian, it has since been updated

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity. Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}