[RFC] When to start adopting new CSS features, browser support

[siriwatknp]

What's the problem? 🤔

CSS is one of the core logic that powers Material UI and Joy UI and it is evolving over time. New CSS features, e.g. flexbox gap, can reduce the complexity of the code and solve existing issues. However, we've never talked about when to start using them.

This RFC aims to create a discussion to bring clarity to the community.

What are the requirements? ❓

1. The support percentage (Global) from caniuse.
2. The specific issue that the new feature will solve.
3. A proof of concept

Proposed solution ⌛️

Final solution: TBD

---

I think the adoption can be split into 2 phases (if possible) by using caniuse as an indicator:

1. At 90%, create an opt-in version (could be a new prop, or a new component):
   • prop example, <Stack useFlexGap> will switch the implementation from margin to gap which can be enabled from the theme default props to affect all instances of the Stack.
   • component example, <Unstable_CssGrid > that implements CSS Grid feature as an alternative to the existing Grid.
2. At 94% (~1-2yrs from 90%), make the API stable based on the feature.
   • In the case of the Stack, the gap can be the default implementation because it covers every use case of the margin
   • For components, e.g. CssGrid, make it a stable version but remains Grid component because they might be used in different scenarios.

Resources and benchmarks 🔗

No response

[siriwatknp]

Some of the CSS new features that have the potential to be adopted:

• https://caniuse.com/?search=aspect-ratio
• https://caniuse.com/?search=flexbox-gap
• https://caniuse.com/?search=inset
• https://caniuse.com/?search=logical%20properties
• https://caniuse.com/?search=%3Awhere
• https://caniuse.com/?search=%3Ahas
• https://w3c.github.io/csswg-drafts/css-transforms-2/#individual-transforms

[michaldudak]

As discussed in the meeting, we can generalize this RFC to consider browser support in general. Also, we can decide if/when to remove the browser-specific hacks and workarounds in code.

Here's the list of such workarounds I've found so far (I'll keep it updated as I stumble upon anything else):

• touch action support detection in useSlider:

  material-ui/packages/mui-base/src/SliderUnstyled/useSlider.ts

  Lines 159 to 179 in a7a2901

  	// TODO: remove support for Safari < 13.
  	// https://caniuse.com/#search=touch-action
  	//
  	// Safari, on iOS, supports touch action since v13.
  	// Over 80% of the iOS phones are compatible
  	// in August 2020.
  	// Utilizing the CSS.supports method to check if touch-action is supported.
  	// Since CSS.supports is supported on all but Edge@12 and IE and touch-action
  	// is supported on both Edge@12 and IE if CSS.supports is not available that means that
  	// touch-action will be supported
  	let cachedSupportsTouchActionNone: any;
  	function doesSupportTouchActionNone() {
  	if (cachedSupportsTouchActionNone === undefined) {
  	if (typeof CSS !== 'undefined' && typeof CSS.supports === 'function') {
  	cachedSupportsTouchActionNone = CSS.supports('touch-action', 'none');
  	} else {
  	cachedSupportsTouchActionNone = true;
  	}
  	}
  	return cachedSupportsTouchActionNone;
  	}

• useIsFocusVisible hook (used by many components): https://github.com/mui/material-ui/blob/a7a2901744bb2c9b0e3e76da7c067253dfe12aba/packages/mui-utils/src/useIsFocusVisible.ts
• non-standard key codes in useSnackbar (Esc):

  material-ui/packages/mui-base/src/SnackbarUnstyled/useSnackbar.ts

  Line 40 in a7a2901

  if (nativeEvent.key === 'Escape' || nativeEvent.key === 'Esc') {

• IE specific support in FocusTrap:

  material-ui/packages/mui-base/src/FocusTrap/FocusTrap.js

  Lines 180 to 189 in a7a2901

  	// In IE11 it is possible for document.activeElement to be null resulting
  	// in nodeToRestore.current being null.
  	// Not all elements in IE11 have a focus method.
  	// Once IE11 support is dropped the focus() call can be unconditional.
  	if (nodeToRestore.current && nodeToRestore.current.focus) {
  	ignoreNextEnforceFocus.current = true;
  	nodeToRestore.current.focus();
  	}
  	nodeToRestore.current = null;

• Handling focus on disabled elements in useInput:

  material-ui/packages/mui-base/src/InputUnstyled/useInput.ts

  Lines 97 to 102 in a7a2901

  	// Fix a bug with IE11 where the focus/blur events are triggered
  	// while the component is disabled.
  	if (formControlContext?.disabled) {
  	event.stopPropagation();
  	return;
  	}

[oliviertassinari]

I think the adoption can be split into 2 phases

I would only have two comments on the proposal:

1. It sounds great. It could even be done sooner based on the results in https://stateofcss.com/. For example, 50% of people saying I have used it sounds good enough to justify the importance of providing an early API:

https://2021.stateofcss.com/en-US/features/layout/#flexbox_gap

2. I think that this rule can be used, at a minimum as the policy on how we update https://github.com/mui/material-ui/blob/master/.browserslistrc / https://mui.com/material-ui/getting-started/supported-platforms/#browser between major versions of MUI Core. I have just added a proposal of removing Safari 12 and Safari 13 support in [discussion] Preparing v6 #30660 based on [docs] Add gap property documentation for Flexbox #35104.

---

I think there is the question of whether should we freeze the browser versions support for a given major version or have something dynamic? An example https://ant.design/docs/react/introduce#Environment-Support

Historically, I have always seen library to freeze the browser version support, e.g. with Node.js dependencies, or https://nextjs.org/docs/basic-features/supported-browsers-features but maybe it's not longer relevant in this new era of browsers that updates continuously.

[oliviertassinari]

https://twitter.com/threepointone/status/1597636986176610304