Skip to content
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

<select> with form-control have background color as :read-only #33860

Closed
DannyFeliz opened this issue May 6, 2021 · 10 comments · Fixed by #33961
Closed

<select> with form-control have background color as :read-only #33860

DannyFeliz opened this issue May 6, 2021 · 10 comments · Fixed by #33961
Labels
Projects

Comments

@DannyFeliz
Copy link

DannyFeliz commented May 6, 2021

OS: Windows 10 Pro
Browser: Chrome 90
Bootstrap version: 5.0.0
How to reproduce

After update from the beta to the stable version of bootstrap I'm experiencing this issue where the select and the options have a gray background instead of white.

image

It's marking the select as readonly
image

@mdo
Copy link
Member

mdo commented May 6, 2021

@ffoodd Perhaps something is off with the :read-only selector? We didn't have this with [readonly] as far as I know.

Fwiw though, from the comments in #33642, <select>s should use .form-select and not .form-control.

@alpadev
Copy link
Contributor

alpadev commented May 7, 2021

Yeah we shouldn't have used :read-only as a replacement for [readonly. [readonly] explicitely matches against the html attribute, but :read-only works frankly different.

The specification defines it like this (albeit a little counter-intuitive) :

The :read-write pseudo-class must match any element falling into one of the following categories, which for the purposes of Selectors are thus considered user-alterable: [SELECTORS]

  • input elements to which the readonly attribute applies, and that are mutable (i.e. that do not have the readonly attribute specified and that are not disabled)
  • textarea elements that do not have a readonly attribute, and that are not disabled
  • elements that are editing hosts or editable and are neither input elements nor textarea elements

The :read-only pseudo-class must match all other HTML elements.

@alecpl
Copy link
Contributor

alecpl commented May 7, 2021

Looks like selects are :read-only because they cannot be edited, indeed. On the other hand the documentation says selects should use .form-select.

So, maybe we should just acknowledge that using .form-control on a select has no sense. The same as it does not work on checkboxes. The same as it does not make sense to use readonly attribute on a select.

Of course, you can just revert the change as well.

@coharishreddy
Copy link
Contributor

[readonly] has side effects when readonly attribute is used inappropriately on any HTML element which doesn't support it. We can Reset :read-only styles applied to selects which has from-control class
select.form-control:read-only { background-color: initial; border-color: initial; }

@alpadev
Copy link
Contributor

alpadev commented May 7, 2021

Maybe I wasn't clear with what I said earlier. My proposal is not, not to use :read-only in general. But simply substituting [readonly] with :read-only isn't the correct approach IMO, as it has a different meaning.

According to the spec :read-only also applies to disabled inputs which makes combining it with :disabled sort of unnecessary. But they have been left in the code https://github.com/twbs/bootstrap/pull/33642/files.

Another issue with :read-only is that browsers implement it differently. Take Firefox for example, they implement the spec as it was defined.

So that's how the file inputs look now:
image

@alecpl
Copy link
Contributor

alecpl commented May 7, 2021

Oh, I missed the file input issue. This actually might be the biggest reason to not use :read-only.

@ffoodd
Copy link
Member

ffoodd commented May 12, 2021

Agreed, I mentionned the difference between the two selectors in the PR but didn't think it'd match selects and file inputs.

I'd be in favor of reverting this PR — otherwise we need to be more restrictive with the pseudo-class to avoid clashes with select and file input, and I don't think it worth it.

@mdo
Copy link
Member

mdo commented May 12, 2021

Let's revert @ffoodd :)

@lacutah
Copy link
Contributor

lacutah commented May 13, 2021

Notes from the field to consider - (in Firefox), this also causes problems with custom (read third-party) composite controls as they also use the .form-control class for integration / consistency, and because they're not input elements suddenly all appeared disabled.

@mdo mdo added the v5 label May 13, 2021
@mdo mdo added this to Inbox in v5.0.1 via automation May 13, 2021
v5.0.1 automation moved this from Inbox to Done May 13, 2021
@scayze
Copy link

scayze commented May 16, 2021

The very same issue also happens when using form-control with buttons
image
As opposed to with select, with buttons i cannot substitute form-control with something alike form-select, without it causing layout issues

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
v5.0.1
  
Done
Development

Successfully merging a pull request may close this issue.

9 participants