What are more such things which you love about CSS but only learned about recently? Can greatly benefit CSS dinosaurs like me who know CSS but haven't really kept up on the recent developments.
I wrote about them here https://blog.logrocket.com/min-max-clamp-css-functions/ - there are some real embarrassments in that article (probably due to me being busy with other things at the time of writing, and being outside my comfort zone [dealing with design]) - example silly statement: "these functions can accept anything that is a number or a calculable value, like the length of a variable, as an input." length of a variable? WTF did I write that for!?!
I could also probably have saved my time because the day after I finished writing it I found this post https://ishadeed.com/article/css-min-max-clamp/ which makes a lot of the same points, less verbosely, and better, with much nicer looking examples because I guess this guy has a design sense.
on edit: I mean I am just jealous of the examples he made, I sweated trying to make something up to show the power of the functions and explain their use and I don't think I did a good job of it, didactically, and his examples were really good. Probably he sweated to, but they look effortless.
Edit: just noticed the articles you linked have nice examples of combining the two (should've read first), and it makes perfect sense since min-width/min-height deal with how elements grow to fit their contents, while something like `width: clamp(...)` would be declaring the width instead.
Without these functions people probably have more media queries with min-width min-height max-width max-height, with them maybe one or two without media queries is needed.
People are finding all sorts of fun things to do with it: https://web.dev/one-line-layouts/ and https://moderncss.dev/3-popular-website-heroes-created-with-...
.foo-component {
--size: 20px;
width: --size;
height: --size;
@media (hover: none) {
--size: 40px;
}
}The reason to use `hover`, instead of `pointer` like a sibling comment mentioned, is for accessibility purposes:
> For accessibility reasons, even on devices that do support hovering, the UA may give a value of hover: none to this media query, to opt into layouts that work well without hovering.
I view this not as "unreliable for detecting touch screen laptops" but reliably detecting touch screens.
What you are saying here is the opposite of the comment that I'm replying to, and is the opposite of the W3 spec. Are you sure? micromacrofoot correctly said:
> touch devices with a dedicated mouse can be detected as no-hover devices
"no-hover devices" are AKA touch input devices, and will therefore satisfy the query `hover: none`. The spec says as such:
For example, on a touch screen device that can also be controlled by an optional mouse, the `hover` media feature should match `hover: none`, as the primary pointing device (the touch screen) does not allow the user to hover.
However, despite this, the optional mouse does allow users to hover. Authors should therefore be careful not to assume that the ':hover' pseudo class will never match on a device where 'hover:none' is true, but they should design layouts that do not depend on hovering to be fully usable.
> A laptop that has a mouse and a touch-screen will in some cases NOT be detected as a touch screen
You see the "NOT" in all capitals? "NOT be detected as a touch screen".
I said:
> A laptop that has a mouse and a touch-screen will in some cases NOT be detected as a touch screen.
That is the same thing, is it not?
Which is the same thing as you quoted from the spec.
> For example, on a touch screen device that can also be controlled by an optional mouse, the `hover` media feature should match `hover: none`, as the primary pointing device (the touch screen) does not allow the user to hover.
Right, so such devices will be detected as "NOT a touch screen".
I feel like I'm agreeing with the spec and agreeing with micromacrofoot, but you are for some reason still reading it in reverse.
If you detect something with both touch and a mouse as "NOT touch", and then deliver a UI optimized for "NOT touch", this is NOT "erring on the side of keeping things usable for touch input".
But this is now a super boring conversation! If this super boring pedantic explication doesn't get us anywhere else, nothing will, I give up!
> Right, so such devices will be detected as "NOT a touch screen".
`hover: none` means it's a touch screen.
The idea being that the device shouldn't expect hover inputs. Hence "touch devices with a dedicated mouse can be detected as no-hover devices"
Paraphrased, the bit of the spec I quoted says "even if a touch laptop has a mouse, `hover: none` will still match". Here's a quick fiddle to show: https://jsfiddle.net/b2f69uya/
Ultimately: if you have a touch control as a device's primary input, there's a guarantee that `hover: none` will be satisfied.
https://davidwalsh.name/pointer-media-query
Which has values for coarse (finger) and fine (mouse, tablet, etc)
Great to be aware of what might come, but.. it's not an option if it's literally just proposed.
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Scroll_...
Container queries are a game changer, although not fully ready across browsers yet.
CSS variables have been around for a while now, but still considered fairly new. CSS nesting is also around the corner. When you combine these two things, you can start considering to drop CSS preprocessors like SCSS.
CSS layers is brand new and may be useful when working with design language systems.
And as an unimportant but fun last one: you can now address colors outside the RGB color space.