Add a non-native select box: mdc-select-menu

[djensen47]

Recently the mdc-select component was regressed to only allow native select. The technical reasons are reasonable but this left the community without a reasonable looking menu-style select. The native select works but has a very inconsistent look and feel.

What I propose is two separate components for select components:

• mdc-select-menu: this would be the removed component that was based on the mdc-menu
• mdc-select-native: the native select that we have now

As others have pointed out, this change is discouraging to both current and would be users of this library. Please allow developers to decide which component is best for their use case.

Thanks for listening to my proposal.

Lastly, I can never give enough thanks to the team and contributors for building and maintaining this great library in the first place. So, thank you, again.

[acdvorak]

Thanks for filing this issue!

I added it to our issue tracker as a feature request. We would certainly like to implement this too!

It's tricky to get right on the Web, and at the moment we don't have the bandwidth for it 🙁

For now, our designers are OK with the native version, because it provides much better accessibility and UX than the previous MDCSelect implementation.

But we definitely want to build a non-native version too.

(For those who haven't seen it, #2399 explains the rationale for the current native select implementation.)

[spatialillusions]

Too bad to hear that the previous MDCSelect isn't returning in the near future. The possibility to style the select with more complex styling was really useful and could provide excellent UX, such in my unit symbol generator where I use it for providing preview images of all the options provided. Hopefully it will return in the future so that I can upgrade to a new version of MDC.

[danielweck]

First of all, thank you for MDC-Web!

I understand the rationale for favouring the native 'select' widget instead of a custom MDCMenu-based renderer. I also appreciate that the development team has limited resources and must therefore make hard choices, such as focusing its efforts on native 'select' only (i.e. complete removal of the MDCMenu alternative).

However, this breaking change from 0.33.0 to 0.34.0 (see: https://github.com/material-components/material-components-web/blob/master/CHANGELOG.md ) totally blows existing apps that make use of the old UI paradigm, which contradicts Semantic Versioning for a "minor" increment (see: https://semver.org ).

I am tempted to rollback to 0.33.0 in my project, but I would also like to keep up to date with the latest developments ... the more I postpone the inevitable upgrade, the harder it will be to update my code in the future (because of the accumulation of breaking API changes). So in the interim, I am going to (try to) put together my own MDCMenu-based "selector" component.

[djensen47]

which contradicts Semantic Versioning

In Semver, an 0.y.z release can be considered to have breaking changes, When you get to x.y.z, where x is greater than zero, then the y portion is considered non-breaker, like you mention. This confusion is why some people don't like 0.y.z releases.

---

The larger versioning problem is that this library has been promoted on material.io for almost/over a year. It's been 0.x.y for longer. Despite being a 0.x.y release, people are using it in production (like us). Personally, I think it's time for the team to start realizing this. But they're doing great work and probably know more about the end goal than we do. My fingers are crossed for a 1.0.0 release for Google I/O.

[djensen47]

Enough complaining, I have a suggestion/solution.

Would somebody like to spin the old mdc-select code into it's own repository? I suggest mdc-select-menu

Can one of the contributors help with that?

[danielweck]

Sorry for my mistake. I got a bit carried away here :) https://semver.org/#spec-item-4

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

[acdvorak]

@danielweck @djensen47 Thanks for the feedback 😃

Would it be possible to continue using version 0.33.0 of mdc-select and also use the latest version of everything else?

(BTW, if folks want to fork v0.33.0 into its own repo, I would suggest including contrib somewhere in the name (e.g., mdc-contrib-select-menu) so that it's obvious that Google doesn't officially support it. It would also help prevent collisions when people search for mdc-select.)

[Garbee]

. I also appreciate that the development team has limited resources

This made me laugh. This is a Google project with free work from the community.

On this note, let's remember that just because something is done by a major company doesn't mean it has no limits. Everything has resource limits, especially with the amount of human power capable of going into it. Do not downplay the significance that has. Projects only move forward as long as the people working on them are managing their time well and focusing on things that provide the most value.

In context to the select menu specifically, doing a non-native one has significant accessibility and performance implications. It needs to be carried out in a very thoughtful way with most cases considered since you don't have the native help on mobile to improve accessibility for multiple types of users by default.

People must do all this work. Let's not downplay the significance of that or pawn it off to "It's Google they can afford it". There are many moving parts at work on projects like this, and time and human capacity are absolutely scarce resources taken into account.

Form elements are crucial to be done super well for end users, since if they aren't the businesses relying on the components provided can end up hurting in multiple ways. It's far better the team decide to go native-priority now and allow the rest of the project to move forward. That brings the most benefits to everyone sooner instead of grinding over this for a few months to get all the accessibility figured out while other components sit without much thought since this is blocking that effort.

[djensen47]

The reasons why "This made me laugh" are not the reasons you stated but I see now how my LOL moment could have been misunderstood so I removed it (I was thinking resources as money and not time but they are both and ...oh nevermind, it wasn't actually funny; hindsight is 20/20 and all that).

Next, I do not agree with your assessment of what I think. We actually probably agree more than disagree. IMO, most of this should have been discussed elsewhere, like Twitter, or gitter, or Discord, or email.

You did make a good point about accessibility issues with a non native version but so did acdvorak.

Here's a summary of this issue/feature and it is what it is, I think it's just fine.

• It's planned and in the issue tracker. IIRC this is the issue synced with the tracker issue.
• There are other features with a higher priority so it might be a while.
• In the meantime we are free to create our own version based on 0.33 as long as it uses "contrib" somewhere in the name.

[HamedFathi]

Any good news? the native design is so ugly and far away from the Material design goal, you should have both options together.