Does anybody have any current CSS to remove the search bar from a choice component? It’s such a poor experience on mobile devices because the search bar gets focus immediately and automatically pops up the keyboard covering have the screen. In my case, there is no need for the search option.
I do have some CSS that’s been working for quite a while, but now I have a problem because I want to add a new choice component using the radio button style, and my current CSS causes all radio choices to be hidden.
So now I’m looking for a different solution. Removing my current CSS is now leading to user complaints because the choice search bar is showing again and slows data entry because the keyboard keeps popping up unsolicited.
The users don’t need or want the choice search. I just want it gone. I’ll accept anything that works globally or with specified class names. Doesn’t matter to me. I found a couple of threads that had different solutions, but I was not having any luck getting them to work. The threads were about a year old, so now I’m wondering if there are any more modern solutions that people have.
1 Like
I might have something that works. Any thoughts on these? I’m not great at CSS.
label:has(input[placeholder*="Search"]) {
display: none !important;
}
or
label:has(input[aria-label*="Search"]) {
display: none !important;
}
or, this which I maybe like better
label:has(input[role*="searchbox"]) {
display: none !important;
}
3 Likes
I’m surprised that the search bar only appears when using the dropdown style and not with the radio style. I’m not sure if the following code actually works on the radio style:
#app-modal-root > [aria-label="Select options"] > div {
display: none;
}
or
#app-modal-root > div > div {
display: none;
}
4 Likes
Thank you! Both of those options seem to work as well. They remove the search from the dropdown style choice components while keeping the radio options visible on radio style choice components. The first one looks to be a little more specific to the search box, so I’d probably choose that over the second option.
I wonder how well these work with different languages, especially the ones that look at placeholder and aria-label? I assume Glide translates placeholder to different languages, but do they translate aria-label as well? I think that’s why I was leaning towards my third option of looking at ‘role’ assuming it’s a value that is never translated to a different language.
3 Likes
Oops, my mistake — I misunderstood earlier.
It turns out you already had a preferred option.
Your analysis is correct, and your choice makes sense as long as it works reliably.
Attributes that appear in the UI (like placeholders or aria-labels) indeed carry the risk of being translated, so avoiding them is the safer approach.
4 Likes
I appreciate your input. If there’s anybody I trust with CSS, it’s you.
6 Likes
@Jeff_Hager I assume you went for this one (more reliable than the others)?
I went with that one because I’m assuming Role is more of a back end code variable, so less likely to be influenced by language translations and other factors that would cause it to change. Just feels like something that would remain consistent. Of course it’s all assumptions.
1 Like
Jeff, since search elements appear in many components, it’s safer to include #app-modal-root so the selector only targets the modal and nothing else. The div here is the wrapper that contains the entire search block, so hiding it removes the whole search section:
#app-modal-root [role="dialog"] > div {
display: none;
}
If you need it more specific, you can add your own class.
Also, there’s no need to add * or !important—those can easily become bad precedent and cause issues later.
3 Likes
I made the change and it’s working so far. Thanks again!
3 Likes
As a side note, it’s nice to see such conversations happen here in the community forum rather than in Slack.
4 Likes