[material-ui] Remove enableColorScheme prop from CssBaseline

[o-alexandrov]

What's the problem?

There is an unused prop enableColorScheme in CssBaseline which gives an option to choose something that does not make any sense.

From #42640 (comment)

What’s the need for enableColorScheme: false?
In other words, why would anyone want the browser to show light color scheme for a dark theme?

The existence of enableColorScheme led to the introduction of an extra hanging span HTML element.

What are the requirements?

Remove enableColorScheme prop

What are our options?

In Material UI v7+, you might consider to remove the enableColorScheme prop.

Search keywords: enableColorScheme, CssBaseline

[oliviertassinari]

The prop was added to avoid breaking changes, as far as I remember.

This issue looks like point 4 of #38507 but where we also remove the prop.

[o-alexandrov]

@oliviertassinari thank you for linking the issue and specifying the point 4. Would you like to reword the 4th point there, so it says removal, instead of setting the value to true by default?

• if yes, then I’d happily suggest to close this issue as this one would become a duplicate

[siriwatknp]

I think we can remove it before the stable release of v6. It's a breaking change but I think CssBaseline is used once in a project.

[headironc]

I'll try completing this.

[chrisbellstardust]

There doesnt seem to be much documentation on actually removing props -- after starting this change I realized this isn't really just a code change and more may be needed.

• Should the existence of the prop from the css baseline component on the docs be removed?

This issue might be "fixed" faster if we just default the enableColorScheme to true and deprecate the prop?

[siriwatknp]

@DiegoAndai I have 3 options here:

1. set enableColorScheme: true by default and update the migration docs
2. replace the enableColorScheme with disableColorScheme (meaning the color-scheme is enabled by default too), then update the migration docs
3. postpone this to v7

The difference between 1 and 2 is that the latter follow our convention for using boolean flags.

Both are considered breaking changes. Should we do it or should we postpone to v7?

[DiegoAndai]

@siriwatknp I think we should move this request to be included/considered in #38507, and close this one as duplicate as @o-alexandrov suggested here.

This would effectively postpone this to v7 so we can have enough time to rework CssBaseline properly.

[DiegoAndai]

I've moved this request to point 4 in #38507. Closing as duplicate.