-
Notifications
You must be signed in to change notification settings - Fork 617
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
optgroup does not work when some options are nested and some are not #615
Comments
Hello @mtriff, can you take a look at this bug eventually please ? 😭 |
I have started to look into this, but didn't get very far yet. I do have a failing cypress test though, if anyone wants to support: https://github.com/voidus/Choices/tree/fix-mixed-optgroups Next step: Find the relevant place in the code |
Okay I've oriented myself a bit in the code and found an approach. Right now, afaict, the parts that process the options deal with either TBH, I was expecting the change on the branch to already have an effect, but it doesn't look like it. @mtriff would you be generally open to merge something like this? Otherwise we should probably discuss potential approaches. (Tagging you because you seem to be maintaining the repo) |
Closes Choices-js#615. This pushes the conversion of OPTION/OPTGROUP elements to Choice objects into the WrappedSelect class and unifies the code paths a little between groups-present and groups-not-present. Some work towards possibly fixing Choices-js#615
Closes Choices-js#615. This pushes the conversion of OPTION/OPTGROUP elements to Choice objects into the WrappedSelect class and unifies the code paths a little between groups-present and groups-not-present. Some work towards possibly fixing Choices-js#615
Yeah folks I think I got it. 🕺 |
Visiting https://whitehall-admin.publishing.service.gov.uk/government/admin/editions There is an "All organisations" dropdown, an "All types" documents dropdown, etc. These options are represented by an `<optgroup>` with a single `<option>` inside, that option having a blank `""` value. In v11+ of Choices.js, that's no longer allowed - presumably since this change: Choices-js/Choices#615 The option is now silently dropped from rendering. From a quick look, it seems any option with a blank value is dropped. We need to investigate what changes are needed on our end to have Choices.js render the "All *" options - made a bit tricky by the multiple layers of helpers etc that sit between the options list array and what actually gets passed to Choices.js.
Visiting https://whitehall-admin.publishing.service.gov.uk/government/admin/editions There is an "All organisations" dropdown, an "All types" documents dropdown, etc. These options are represented by an `<optgroup>` with a single `<option>` inside, that option having a blank `""` value. In v11+ of Choices.js, that's no longer allowed - presumably since this change: Choices-js/Choices#615 The option is now silently dropped from rendering. From a quick look, it seems any option with a blank value is dropped. We need to investigate what changes are needed on our end to have Choices.js render the "All *" options - made a bit tricky by the multiple layers of helpers etc that sit between the options list array and what actually gets passed to Choices.js.
Visiting https://whitehall-admin.publishing.service.gov.uk/government/admin/editions There is an "All organisations" dropdown, an "All types" documents dropdown, etc. These options are represented by an `<optgroup>` with a single `<option>` inside, that option having a blank `""` value. In v11+ of Choices.js, that's no longer allowed - presumably since this change: Choices-js/Choices#615 The option is now silently dropped from rendering. From a quick look, it seems any option with a blank value is dropped. We need to investigate what changes are needed on our end to have Choices.js render the "All *" options - made a bit tricky by the multiple layers of helpers etc that sit between the options list array and what actually gets passed to Choices.js. The select component behaves differently depending on whether or not `grouped_options` or `options` is passed. First step will be to decide on a common data structure to pass around, and consolidate onto one `options` parameter - let the component dynamically infer whether or not an `<optgroup>` is needed.
Previous versions of Choices.js happily accepted HTML like this: ```html <optgroup label=""> <option value="">All organisations</option> </optgroup> ``` However, in v11+ of Choices.js, that's no longer allowed - presumably since this change: Choices-js/Choices#615 The option is now silently dropped from rendering. Choices.js now seems to expect such HTML to be passed outside of an `<optgroup>`, i.e. `<option value="">All organisations</option>`. NB, it is perfectly fine to mix top-level `<option>`s with `<optgroup>`s: https://www.w3.org/TR/WCAG20-TECHS/H85.html#:~:text=The%20optgroup%20element%20should%20be,desired%20intent%20when%20using%20this. This work was made a bit tricky by us having separate `options` and `grouped_options` parameters, meaning we have to maintain two separate methods, making behaviour change more difficult. I had hoped to consolidate onto one single `options` parameter and have the helper be clever enough to dynamically return options or optgroups, but in my attempt in 2b643a8 there were so many test failures that this wider rearchitecture was not worth the time.
The library used works if every
<option>
is in a<optgroup>
but has a bug when some are nested and some are not.This will work:
This will not:
Related: #253
The text was updated successfully, but these errors were encountered: