If we, as a community, start to appreciate the complexity of writing CSS, perhaps we can ask for help instead of blaming the language when we’re confused or stuck. We might also stop looking down on CSS specialists.
While a handful of form controls can be easily styled by CSS, like the button element, most form controls fall into a bucket of either requiring hacky CSS or are still unable to be styled at all by CSS.
Despite form controls no longer taking a style or technical dependency on the operating system and using modern rendering technology from the browser, developers are still unable to style some of the most used form control elements such as
select. The root of this problem lies in the way the specification was originally written for form controls back in 1995.
Stephanie goes back in time to tell the history of form controls on the web, and how that history has led to our current frustrations:
The current state of working with controls on the modern web is that countless developer hours are being lost to rewriting controls from scratch, as custom elements due to a lack of flexibility in customizability and extensibility of native form controls. This is a massive gap in the web platform and has been for years. Finally, something is being done about it.
Amen!
A handy tool for getting an overview of your site’s CSS:
CSS Stats provides analytics and visualizations for your stylesheets. This information can be used to improve consistency in your design, track performance of your app, and diagnose complex areas before it snowballs out of control.
An excellent and clear explanation of specificity in CSS.
I think this a solution worthy of Solomon. In this case, the Gordian knot is the select element and its inevitable recreation in order to style it.
What if we instead deliver a native select by default and replace it with a more aesthetically pleasing one if possible? That’s where the “hybrid” select idea comes into action. It’s “hybrid” because it consists of two selects, showing the appropriate one at the right moment:
- A native select, visible and accessible by default
- A custom select, hidden until it’s safe to be interacted with a mouse
The implementation uses a genius combination of a hover media query and an adjacent sibling selector in CSS. It has been tested on a number of device/platform/browser combinations but more tests are welcome!
What I love about this solution is that it satisfies the stakeholders insisting on a custom component but doesn’t abandon all the built-in accessibility that you get from native form controls.
I never thought of combining the datalist element with input type="color"—it’s pretty cool that it just works!
I can see this coming in very handy at Codebar—pop any CSS selector in here and get a plain English explanation of what it’s doing.
This is a wonderful interactive explanation of the way CSS hierarchy works—beautiful!
Everyone wants it, but it sure seems like no one is actively working on it.
Zach traces the earliest inklings of container queries to an old blog post of Andy’s—back when he was at Clearleft—called Responsive Containers:
For fun, here’s some made-up syntax (which Jeremy has dubbed ‘selector queries’)…
- Obey the Law of Locality
- ABD: Anything But Dropdowns
- Pass the Squint Test
- Teach by example
Well, the clever CSS techniques just keep on comin’ from Trys—I’m learning so much from him!
This is a great explanation of the difference between the [lang] and :lang CSS selectors. I wouldn’t even have thought’ve the differences so this is really valuable to me.
Rachel gives us the run-down on what’s coming soon to Cascading Style Sheets near you, including an aspect-ratio unit and a matches selector (as originally proposed by Lea).
The fascinating results of Brad’s survey.
Personally, I’m not a fan of nesting. I feel it obfuscates more than helps. And it makes searching for a specific selector tricky.
That said, Danielle feels quite strongly that nesting is the way to go, so on Clearleft projects, that’s how we write Sass + BEM.
A deep, deep dive into biomicry in digital design.
Nature is our outsourced research and development department. Observing problems solved by nature can help inform how we approach problems in digital design. Nature doesn’t like arbitrary features. It finds a way to shed unnecessary elements in advancing long-term goals over vast systems.
A really deep dive into the lang attribute, and the :lang() pseudo-class (hitherto unknown to me). This is all proving really useful for a little side project I’m working on.
A deep dive into the :focus pseudo-class and why it’s important.
One thing I gained a stronger awareness of (simply from working with checkboxes) is that it’s important to progressively enhance UI components, so that a fancy custom one is able to fall back to the default browser styles and functionality. This way, a user can still access the UI if JavaScript or CSS fail.
Rebuttals to the most oft-asked requests for browsers to change the way they handle CSS.
An excellent level-headed evaluation of styling and scripting form controls, weighing up the benefits and trade-offs. The more tightly you control the appearance, the less you get to benefit from the functionality (and accessibility) that the browser gives you for free …meaning you’ve now to got to work harder to replace it.
HTML elements like check buttons, radio buttons or select options can be hard to style with CSS in a custom design. There are many workarounds for this, but are they accessible?