Use rem instead of px units

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

In order to get fully fluent responsive experiences in the MUI components I setup all “sizing properties” to apply em unit if naked number is used as a value for them.

Current Behavior 😯

1. I passed my custom settings to defaultUnit plugin in JSS with accordance to documentation
2. Then I feed StylesProvider with such customized preset:
3. Theme option for htmlFontSize I set to 10.
4. And my reset CSS has

As a result, some of the properties in the default theme (which are originally implemented with unitless values) are becoming oversized. Exemplary original styles implementation chunk of code:

This is happening because the implicit output unit (while using numbers only) for “sizes like properties” e.g. padding, margin is preassumed as px.

So when I have margin: 16 it becomes 16em in my scenario. Which produces 160px overblown margins, paddings, and so on in the default theme. Like for example: This enforces a lot of tedious override procedures in the theme, like:

Expected Behavior 🤔

For the originally set unitless values in the default theme I would expect one of scenario (starting from most appreciated):

1. The values are recalculated to the respective defaultUnit settings in the JSS. So when I set defaultUnit to em for some CSS properties, the original implementation should recalculate all the unitless values based on htmlFontSize property in theme. Something like:

if (customDefaultUnit === 'em') unitlessProps.map(prop => (prop / theme.htmlFontSize);

It’s a pseudo code to get the basic concept. This scenario would create full responsive (proportional sizing) across all the styling in the default theme. 2. Default unitless props are becoming hardcoded to pixel-units in case if defaultUnit plugin is changed. This would make some theme props output as pixel-sized, which would create an inconsistent sizing pattern. But at least it would not break the theme while customizing the defaultUnit JSS preset. 3. Make the unitless concept of theming out of the theming, and make everything pixel-based. Very grim scenario but at least consistent and not brittle.

Steps to Reproduce 🕹

I hope the above explanation is enough. I will provide a working example if necessary.

Context 🔦

CSS theme that uses only proportional sizing (em, rem %) in order to get the best responsive UI experiences and simplify the process of customizing styles.

Currently, part of the API support this task like font sizing but some of the props (as described above) produce fixed pixel values which output as an inconsistent theme (some values are em and some px). This enforces many tedious overrides in theme in order to get proper responsive “fluid” results.

I don’t know if this type of issue “the Bug” (I guess it is something between the Bug and request to Change functionality) applies to the described scenario. So please amend accordingly. I might, of course, miss some documentation and do things just wrong. So please direct in the better implementation suggestions.

Your Environment 🌎

Tech	Version
Material-UI	v4.9.14
React	v16.13.1
Browser	[“last 1 version”, “> 0.5%”, “not dead”]
TypeScript	v3.8.3

[mifrej]

Most browsers today have the base font-size set to 16px. Respecting that (which would make the most sense) we can utilize the remCalc helper to then use for all the sizing values in styles.

So exemplary I took the Button component and went through the styles to adapt it.

diff --git a/packages/material-ui/src/Button/Button.js b/packages/material-ui/src/Button/Button.js
index fe392b926..d514a0910 100644
--- a/packages/material-ui/src/Button/Button.js
+++ b/packages/material-ui/src/Button/Button.js
@@ -6,13 +6,17 @@ import { fade } from '../styles/colorManipulator';
 import ButtonBase from '../ButtonBase';
 import capitalize from '../utils/capitalize';

-export const styles = (theme) => ({
+export const styles = (theme) => {
+  /*
+    @base should be taken from `htmlFontSize` if treated as root rem font-size
+  */
+  const remCalc = (size, base = 16) => `${size / base}rem`;
+  return {
   /* Styles applied to the root element. */
   root: {
     ...theme.typography.button,
     boxSizing: 'border-box',
-    minWidth: 64,
-    padding: '6px 16px',
+    padding: `${remCalc(6)} ${remCalc(16)}`,
     borderRadius: theme.shape.borderRadius,
     color: theme.palette.text.primary,
     transition: theme.transitions.create(['background-color', 'box-shadow', 'border'], {
@@ -42,7 +46,7 @@ export const styles = (theme) => ({
   },
   /* Styles applied to the root element if `variant="text"`. */
   text: {
-    padding: '6px 8px',
+    padding: `${remCalc(6)} ${remCalc(8)}`,
   },
   /* Styles applied to the root element if `variant="text"` and `color="primary"`. */
   textPrimary: {
@@ -68,8 +72,8 @@ export const styles = (theme) => ({
   },
   /* Styles applied to the root element if `variant="outlined"`. */
   outlined: {
-    padding: '5px 15px',
-    border: `1px solid ${
+    padding: `${remCalc(5)} ${remCalc(15)}`,
+    border: `1px solid ${ // for border width px are ok most of the time as we most likely don't want to scale borders (exception)
       theme.palette.type === 'light' ? 'rgba(0, 0, 0, 0.23)' : 'rgba(255, 255, 255, 0.23)'
     }`,
     '&$disabled': {
@@ -224,10 +228,10 @@ export const styles = (theme) => ({
   /* Styles applied to the startIcon element if supplied. */

I didn’t use the existing theme helper pxToRem as it has some coef factor I don’t get, but I guess we could keep such helper in theme and propagate htmlFontSize prop as the base argument for all sizes in styles.

These adaptations would need to be applied throughout all existing components and then used for future ones.

When now I look at it it wouldn’t be actually that painful to do. Would it?

[tkodev]

I think rem should not be the default value for spacings, margins, widths, etc, because of a few things:

• accessibility users often have their font size set differently than the default 14-16 px, this is NOT the same as page zoom and we shouldn’t treat it as such. https://medium.com/@sascha.wolff/dont-use-rem-em-for-paddings-margins-and-more-94e19026b000
• using material ui to build injected dom elements, such as browser extensions will tie these element’s visuals to the page’s default font size. This is not ideal. While they can use things like shadow-dom, it’s not always something that’s possible, depending on the application.