Water overrides input display property about water.css

[joplomacedo]

This would be a perfect place to use the new :where selector. Something like:

input:where(:not([type='checkbox']):not([type='radio'])) { ... }

:where() and whatever is included inside the :where() are ignored in the specificity calculation. So effectively that line above would have the same specificity as just input

The bad news is that it's still only supported in safari and firefox's dev browsers.

[kylejrp]

I think this is a necessary evil of water.css. The closest I can get to lowering the specificity is:

input:not([type='checkbox']):not([type='radio']),
select {
  display: block;
}

or

input,
select {
  display: block;
}

input[type='checkbox'],
input[type='radio']{
    display: inherit;
}

Both of these still have a higher specificity than .hidden because they're targeting both input and [type=...]. I've seen other frameworks fix this by using a .check and/or .radio class... but we're a classless framework!

If anyone has a suggestion on how to fix this, I'd love to see a pull request for it! Low specificity isn't an explicit goal of water.css, but it would help with our compatibility with other css.

---

@frontendmonster, I hate suggesting the use of !important, but a utility class feels like an okay place to use it:

• http://www.davidfusilier.com/writing/specificity-and-utility-classes
• https://css-tricks.com/when-using-important-is-the-right-choice/#article-header-id-0
• https://stackoverflow.com/a/3706876

Changing the .hidden class to use display: none !important feels okay here and would solve the specificity issue while we think about thinks on our end.

[ASafaeirad]

Thanks for your fast response,
I opened #82, that can fix the issue.
Maybe that's a cheat, but i don't think so that makes problem in water.css use-cases.

[kcclemo]

Not sure if this might be too specific, or have any other implications but, what if you excluded inputs that contain classes or ids? This allows the water.css styles to be a baseline, but, then immediately overridden if a class or id is provided.
input:not([type='checkbox']):not([type='radio']):not([class=]):not([id=])

What I don't like about this is that if I am adding an ID or Class for the purpose of using JavaScript and not style, then I've stripped the water.css styles unnecessarily.

[rubissima]

I've been looking into this, because it's just the kind of nerdery that I enjoy. Or at least love to hate.

I experimented with something I found here: https://csswizardry.com/2014/07/hacks-for-dealing-with-specificity/, which was new to me: if you double the class name, you get double the specificity. So .hidden.hidden is twice as specific as .hidden, .hidden.hidden.hidden is 3x the specificity, etc.

Incidentally, I inspected this very page to test it, and found no less than five !importants in the css attached to a single element. Two of them were in a media query and cancelled out two other ones. This, I believe, is the danger of !important.