Feature request: rems & ems instead of px units used or CSS variables exposed for contexts where pixels values are not critical for the representation of component?

[lozandier]

For the sake of maximizing the capabilities of the Web platform associated with typography, flexibility by components to react to different font sizes within their boundaries common in RWD flows, improved ability to establish vertical rhythm, improved accessibility, & so on, it seems to make sense to suggest Material Web components recently updated to use rem& em units instead of px units.

For the sake of perhaps dev convenience, there may be value leaving pixel values as comments or using a pxToEem function common in popular CSS frameworks such as Foundation & Bootstrap:

@mixin mdc-button__icon_ {
  @include mdc-rtl-reflexive-box(margin, right, 8px);

  display: inline-block;
  width: 18px;
  height: 18px;
  font-size: 18px;
  vertical-align: top;
}

changes to

// Base font size is 16px, the default of all major browsers material-components-web supports
@mixin mdc-button__icon_ {
  @include mdc-rtl-reflexive-box(margin, right, 0.5rem /* 8px */);

  display: inline-block;
  width: 1.125em; /* 18px*/
  height: 1.125em; /* 18px */
  font-size: 1.125rem; /* 18px */
  vertical-align: top;
}

or

// Note: Conventional pxToEm funcs accept both 1px & 1 using Sass's `type-of` or other Sass meta-programing features
@mixin mdc-button__icon_ {
  @include mdc-rtl-reflexive-box(margin, right, pxToRem(8));

  display: inline-block;
  width: pxToEm(18);
  height: pxToEm(18);
  font-size: pxToRem(18);
  vertical-align: top;
}

Alternatively, but not ideal, would be the ability to override every value currently using pixels with CSS variables such as --mwc-icon-button-height.

This seems messy and would be a pain for intermediate & advanced components that would seemingly only be alleviated once the CSS Shadow Parts Proposal lands for at least the Web Components port of the recently updated components.

With material components recently updated to be more customizable, it leaves an opportunity for this change to finally be done to conform with ideal application of font-sizes, padding, & spacing that Web platform enables better than what is enabled by pixels.

In contexts where typography-based-sizing is N/A, percentages or viewport units should ideally be used instead of pixels such as vh & vw for more out-of-the-box flexibility commonly an issue with the initial release of Material Design Components for the Web when Web creatives inevitably want to realize designs with the components in a responsive Web design manner rather than an adaptive Web Design manner indirectly enforced with the fixed units used by the styles of existing components¹ .

Scope of feature request

Impacts all components using pixel values in contexts where absolute sizing is not critical for the representation of the component

Footnote

¹: This is particularly problematic when devs won't have maintainable access to such nodes with fixed sizing at all that make up a component once advanced ports of Material Design Component for the Web use DOM APIs such as Shadow DOM that create isolation from nodes only needed for implementation details

[jimsimon]

This is extremely important for any projects that legally need to adhere to accessibility standards (i.e. apps made for educational institutions and government).

[patrickrodee]

Bumping this back up. We need this internally at least for text field.

[clshortfuse]

As long as you responsibly follow the guidelines you should be pretty okay. I had to ultimate craft my own framework because the use of px over em in certain cases.

I outlined the problems in https://github.com/material-components/material-components-web/issues/1932

Since then, I've mostly completed translating my framework to the MD2018 guidelines and everything scales nicely with custom fonts or increased base font size (based on browser/system font-sizing). You can see how text fields should size based on font with my samples here:

https://clshortfuse.github.io/materialdesignweb/textfield.html

(Just note that on my samples, I'm prioritizing no JS over smooth outlined animations. I haven't coded a smoother Javascript-based alternative.)

There are currently two unaddressed accessibility concerns that you'll eventually find when trying to with font scaling:

• In the MD2018 update, there are no text fields samples shown with larger than 16sp input field. This makes the size of labels uncertain. Based on MD2015, labels are always 12sp, even when the input is larger (like 40sp, or 34sp). It's uncertain if labels are still meant to be 12sp or 75% of the input field. (ie: 40sp input perhaps should have a 30sp label).

• Line-height is fixed on the spec. This means the spec may say 16sp for font, but 20dp for line-height. Unfortunately, if the user is scaling his font past 125% (with a base-height of 16px), that means the font will be 20px, and will bleed into the next line. I haven't found a good solution to this, other than, perhaps, use sp directly for line-height. Even so, I've kept it as is.

There's also the consideration you might have to consider what happens with word-wrapping, in case the developer doesn't account for overflowing text. Things like Tabs and Bottom Navigation can get misaligned once text gets too large. But, honestly, that's more of the developer having long text than the framework.

[lozandier]

IDK, it’s more common & appropriate to use a different typography scale for your respective app based on your primary content rather than attempting to shoehorn your app to MD2018 guidelines.

Typography & a grid based on your primary content (see this if you’re unfamiliar with the latter, why CSS grid & Flexbox is critical for ratio, content-out layout rather than generic column approaches & etc )

Accordingly, that’s why this is important to be addressed.

On Tue, Jan 8, 2019 at 8:29 AM Carlos Lopez notifications@github.com wrote:

As long as you responsibly follow the guidelines you should be pretty okay. I had to ultimate craft my own framework because the use of px over em in certain cases.

I outlined the problems in #1932 https://github.com/material-components/material-components-web/issues/1932

Since then, I've mostly completed translating my framework to the MD2018 guidelines and everything scales nicely with custom fonts or increased base font size (based on browser/system font-sizing). You can see how text fields should size based on font with my samples here:

https://clshortfuse.github.io/materialdesignweb/textfield.html

(Just note that on my samples, I'm prioritizing no JS over smooth outlined animations. I haven't coded a smoother Javascript-based alternative.)

There are currently two unaddressed accessibility concerns that you'll eventually find when trying to with font scaling:

-

In the MD2018 update, there are no text fields samples shown with larger than 16sp input field. This makes the size of labels uncertain. Based on MD2015, labels are always 12sp, even when the input is larger (like 40sp, or 34sp). It's uncertain if labels are still meant to be 12sp or 75% of the input field. (ie: 40sp input perhaps should have a 30sp label).

Line-height is fixed on the spec. This means the spec may say 16sp for font, but 20dp for line-height. Unfortunately, if the user is scaling his font past 125% (with a base-height of 16px), that means the font will be 20px, and will bleed into the next line. I haven't found a good solution to this, other than, perhaps, use sp directly for line-height. Even so, I've kept it as is.

There's also the consideration you might have to consider what happens with word-wrapping, in case the developer doesn't account for overflowing text. Things like Tabs and Bottom Navigation can get misaligned once text gets too large. But, honestly, that's more of the developer having long text than the framework.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/material-components/material-components-web/issues/2731#issuecomment-452362306, or mute the thread https://github.com/notifications/unsubscribe-auth/ABKqOD5Yja1XRLX4N_gxqLky0dULYjuWks5vBMeDgaJpZM4T67P3 .

-- Kevin Lozandier lozandier@gmail.com lozandier@gmail.com

[clshortfuse]

@lozandier The problem with resizing content based on em is that the unit meant for font-size not component scaling. Just because a user wants large fonts doesn't meant the user needs bigger components. Simply put, he/she wants larger fonts. Mixing scaling with font means you're enlarging touch targets and layouts unnecessarily.

Android has two options: Font Size and Display Size. Display Size scales everything. Font Size scales text. There equivalent measurements are sp and dp, respectively. Those translate to (x/16)rem and 1px. On browsers, rem is specified by the respective system and browser's respective base-font size. By default, it's 16px, but users may change that to 20px (125%) or 24px (150%). Zoom is what handles px and when people zoom their browser in.

In mobile usage, this is how Android and iOS font-scaling work. A 48px by 48px button doesn't need any resizing just because the user has trouble reading text specifically. For example, people suffering from diplopia or dyslexia need larger fonts, but don't need bigger targets for their fingers or expanded layouts. Those will poor eye-sight in general (glaucoma or myopia) will likely zoom in everything because everything is hard to see and would actually need larger touch targets.

My issues with the framework stem from not addressing user-defined default font-size other than just 16px, causing layouts to actually break (text fields).

On the topic of layout, the Material Design framework its suggests 4/8/12 column system, a 4dp or 8dp horizontal flow for components, and 4dp flow for typography. It's definitely not for everyone, but the components themselves should be able to scale to any width and height.

I will also note to consider that there are many, many sites that have little to no concern for allowing the user to scale font. The website you linked to is one of those examples. It pushes a forced 18px base font-size, ignoring the user's requested base font-size and forcing users to have to use browser zoom to scale. This is a violation of WCAG 2.0 requirements, specifically 1.4.4:

https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0#resize-text

[lozandier]

I’m not suggesting forcing components to use ems instead of pixels; most cases you’re talking about is more appropriate to use other relative units & have hooks (CSS variables, CSS custom parts) to customize specific to the app & context.

That’s what’s being advocated in the bug actually

On Tue, Jan 8, 2019 at 9:09 AM Carlos Lopez notifications@github.com wrote:

@lozandier https://github.com/lozandier The problem with resizing content based on em is that the unit meant for font-size not component scaling. Just because a user wants large fonts doesn't meant the user needs bigger components. Simply put, he/she wants larger fonts. Mixing scaling with font means you're enlarging touch targets and layouts unnecessarily.

Android has two options: Font Size and Display Size. Display Size scales everything. Font Size scales text. There equivalent measurements are sp and dp, respectively. Those translate to (x/16)rem and 1px. On browsers, rem is specified by the respective system and browser's respective base-font size. By default, it's 16px, but users may change that to 20px (125%) or 24px (150%). Zoom is what handles px and when people zoom their browser in.

In mobile usage, this is how Android and iOS font-scaling work. A 48px by 48px button doesn't need any resizing just because the user has trouble reading text specifically. For example, people suffering from diplopia or dyslexia need larger fonts, but don't need bigger targets for their fingers or expanded layouts. Those will poor eye-sight in general (glaucoma or myopia) will likely zoom in everything because everything is hard to see and would actually need larger touch targets.

My issues with the framework stem from not addressing user-defined default font-size other than just 16px, causing layouts to actually break (text fields).

On the topic of layout, the Material Design framework its suggests 4/8/12 column system, a 4dp or 8dp horizontal flow for components, and 4dp flow for typography. It's definitely not for everyone, but the components themselves should be able to scale to any width and height.

I will also note to consider that there are many, many sites that have little to no concern for allowing the user to scale font. The website you linked to is one of those examples. It pushes a forced 18px base font-size, ignoring the user's requested base font-size and forcing users to have to use browser zoom to scale. This is a violation of WCAG 2.0 requirements, specifically 1.4.4:

https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0#resize-text

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/material-components/material-components-web/issues/2731#issuecomment-452376769, or mute the thread https://github.com/notifications/unsubscribe-auth/ABKqOBoQMW7-eS2aTTa4iqlex9VuWCX1ks5vBNDEgaJpZM4T67P3 .

-- Kevin Lozandier lozandier@gmail.com lozandier@gmail.com

[clshortfuse]

@lozandier Ah, I wasn't sure. I've seen some people overuse em, so perhaps I was a bit presumptuous.

As for the point of:

appropriate to use a different typography scale for your respective app based on your primary content rather than attempting to shoehorn your app to MD2018 guidelines

The problem isn't so much the Material Design framework itself, but the way it's being implemented in this framework with some hard px values. You can use the framework just fine, but have to be careful with how you interpret the numbers. The guidelines are built around 16sp. It's just a matter of how you scale it, which at the moment, this framework doesn't properly based on font.

Here's an example:

This is how the framework I made displays a dialog at 200% font-size:

Here's home material-components-web does it:

You'll see the vertical padding on the second one is rather improper.

Here's why. The website example says 40dp.

While it says it's 40dp, isn't actually supposed implemented as 40dp. Yes, that's what the guideline picture says, but as I stated before, that's at 16sp base-font. It's actually 20dp from text-top. That makes it 20sp + 20dp. Implementation should be either the sum of 1.25rem + 20px if you want 20sp, or 1em + 20px to allow more dynamic font-size support.

So again, I think the MD framework is fine (except for maybe the horizontal margins), it's the just implementation that needs to be cleaned up a bit.