Material-components-web: [MDCSelect] 4.0.0 removed the hidden form element
Bug report
According to the new mdc-select specification we no longer have a hidden input element to capture the selected value.
When using the mdc-select on a submit form - how is the selected value intended to be captured?
cintaccs
All 7 comments
relates to #4799
cintaccs
on 6 Nov 2019
@bonniezhou : the problem I have is that I don't know whether it was intended to remove the hidden input element under the mdc-select or it will pop back in again (which I think it should) in a future build.
there are 2 scenarios for grabbing the selected value - with or without an underlying model for the selected value.
Scenario 1: With an underlying model the mdc-select listener that you provide will handle the value update - which is fine and works. GOOD!
Scenario 2: is a mdc-select component implemented on a submit form or without an underlying data-model. In this case we either:
A: need to write the value somewhere using your provided listener (or use a queryselect to grab the selected item from the list elements (which is no problem either)). But where to write the value?
B: not writing the selected value anywhere - in which case it will not be picked up by a submit button and not delivered as part of a form submit. NOT GOOD.
In my code I can handle both cases - but it would be nice to know whether the INPUT hidden will suddenly pop back up again in the specification? or whether I can consistently assume that it will not suddenly appear with the value (which would then be redundant to any custom solutions made?
cintaccs
on 7 Nov 2019
I have written an alternative solution using MDCText, MDCMenu and MDCList components. Because I use the MDCText - I now again have a form element for submitting. It uses type ahead and actually allows more characters to match an entry than the native SELECT - and your MDCLIST keyboard handling at least for the single select navigation is as good as native ever was. I got lost in foundations, foundation_, defaultfoundation (I therefore use querySelectors instead) so it is not following the component skeletons well enough for pushing as a suggestion for a general solution - however it integrates well with the other components.
I think for mobile use (or any responsive size "phone size" - the menu surfaced list as a modal dialogue list will be a consistent and material designed solution for selecting items. That should work too as the focus moves from the MDCText to the menu surface at enter or keydown.
One thing that I did see as a benefit is that by creating the menu surface at "activation" time instead of at design time in the HTML in location - I avoid having z-index issues with the parent element siblings (which I think you might have with MDCSelect (at least I had some issues with the select list menu not being the top z-indexed layer with 4.0 implementation).
(z-index issues is avoided by inserting the menu surface at the end of body as in the pre-4.0 implementation - I have included a remove menu HTML in the closing action - and it seems to be solid and work).
cintaccs
on 14 Nov 2019
Would you mind sharing some code? I can't understand, why submit form support has been deliberately removed and am currently stuck with this issue too :frowning_face:
sclausen
on 2 Jan 2020
sorry for the delay, the hidden input element seems to have been overlooked during a refactor. Created #5428.
bonniezhou
on 8 Jan 2020
@bonniezhou this comment stated that it has been removed on purpose.
sclausen
on 9 Jan 2020
@sclausen That comment explains removal of support for native <select>, not the removal of the hidden <input> element
bonniezhou
on 9 Jan 2020
Related issues
7iomka
路
3Comments
16rajumane
路
3Comments
traviskaufman
路
3Comments
m-alzam
路
3Comments
cintaccs
路
3Comments
Most helpful comment
I have written an alternative solution using MDCText, MDCMenu and MDCList components. Because I use the MDCText - I now again have a form element for submitting. It uses type ahead and actually allows more characters to match an entry than the native SELECT - and your MDCLIST keyboard handling at least for the single select navigation is as good as native ever was. I got lost in foundations, foundation_, defaultfoundation (I therefore use querySelectors instead) so it is not following the component skeletons well enough for pushing as a suggestion for a general solution - however it integrates well with the other components.
I think for mobile use (or any responsive size "phone size" - the menu surfaced list as a modal dialogue list will be a consistent and material designed solution for selecting items. That should work too as the focus moves from the MDCText to the menu surface at enter or keydown.
One thing that I did see as a benefit is that by creating the menu surface at "activation" time instead of at design time in the HTML in location - I avoid having z-index issues with the parent element siblings (which I think you might have with MDCSelect (at least I had some issues with the select list menu not being the top z-indexed layer with 4.0 implementation).
(z-index issues is avoided by inserting the menu surface at the end of body as in the pre-4.0 implementation - I have included a remove menu HTML in the closing action - and it seems to be solid and work).