A bold proposal by Heydon to make the process of styling on the web less painful and more scalable. I think it’s got legs, but do we really need another three-letter initialism?
We waste far too much time writing and maintaining styles with JavaScript, and I think it’s time for a change. Which is why it’s my pleasure to announce an emerging web standard called CSS.
This is really good breakdown of what’s different about CSS (compared to other languages).
These differences may feel foreign, but it’s these differences that make CSS so powerful. And it’s my suspicion that developers who embrace these things, and have fully internalized them, tend to be far more proficient in CSS.
A really deep dive into display: contents from Ire.
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.
Always mark-up first. Regardless of what the kids are doing these days, I stick by my guns and start with mark-up first. A fun experiment (maybe not for you, but definitely for me) is to see how your site reads on Lynx. It does serve as a good gauge of whether the content on the site is structured properly or not.
Ana goes into exhaustive detail on all the differences in the shadow DOM and styling of input type="range" across browsers.
I’m totally fine with browsers providing different styling for complex UI elements like this, but I wish they’d at least provide a consistent internal structure and therefore a consistent way of over-riding the default styles. Maybe then people wouldn’t be so quick to abandon native elements like this in favour building their own UI components from scratch—the kind of over-engineering that inevitably ends up being under-engineered.
These experiments with transitioning variable font styles on hover might be silly, but I can see the potential for some beautiful interaction design.
Great advice on keeping your hyperlinks accessible.
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?
Yes! I’ve wanted this forever!
A really interesting proposal from Lea that would allow CSS authors to make full use of selectors but without increasing specificity. Great thoughts in the comments too.
Lin gives a deep dive into Firefox’s new CSS engine specifically, but this is also an excellent primer on how browsers handle CSS in general: parsing, styling, layout, painting, compositing, and rendering.
Monica explains how Shadow DOM could be the perfect answer for scoping CSS:
We didn’t have style encapsulation, so we started naming things “the right way” with BEM, so that we didn’t accidentally stomp over each other’s styles. We wanted to be able to author CSS from inside a JavaScript component, so we started using CSS-in-JS. We needed all these tools, because “the platform” (read: the browsers that be) wasn’t there, and building these tools showed that there was a need to move forward. For style encapsulation, Shadow DOM is the platform moving forward.
Although, in a way, Shadow DOM is also another flavour of CSS-in-JS:
Before you complain that using a Shadow DOM and Web Components means that it absolutely requires JavaScript: this is true.
Geek humour is no laughing matter, as Chris demonstrates here with his thorough dissection of that coffee mug.
CSS is weird. It’s unlike any other code, and that makes a lot of programmers uncomfortable. But used wisely it can, in fact, be awesome.
It’s not often I say this, but read the comments.
This is an excellent proposal from Emil. If we can apply display: contents to fieldsets, then we would finally have a way of undoing the byzantine browser styles that have hindered adoption of this element. This proposal also ensures backwards compatibility so there’d be no breakage of older sites:
The legacy appearance of fieldsets probably needs to be preserved for compatibility reasons. But
display: contentsis not supported in any old browsers, and is most likely used on exactly zero sites using the legacy look of fieldsets.
Whaddya say, browser makers?
My argument is relatively simple: creating a comprehensive styling mechanism for building complex user interfaces is startlingly hard, and every alternative to CSS is much worse. Like, it’s not even close.
Stylish and accessible checkboxes and radio buttons accompanied by an explanation of the CSS involved.
No images were harmed in the making of these form controls.
Neither matters all that much and you can use every method on the same project without the universe imploding.
Some interesting approaches in the comments too.