HTML lets you create the structure of a website.
CSS lets you make the website look nice.
JavaScript lets you change HTML and CSS. Because it lets you change HTML and CSS, it can do tons of things.
A deep dive info focus styles with this conclusion:
The default focus ring works. There are problems with it, but it can be good enough, especially if you can’t dedicate time and energy to create a custom focus ring.
Some very smart ideas in here for resetting default browser styles, like only resetting lists that have classes applied to them:
ul[class],
ol[class] {
padding: 0;
}
I select only lists that do have a
classattribute because if a plain ol’<ul>or<ol>gets used, I want it to look like a list. A lot of resets, including my previous ones, aggressively remove that.
The transcript of Andy’s talk from this year’s State Of The Browser conference.
I don’t think using scale as an excuse for over-engineering stuff—especially CSS—is acceptable, even for huge teams that work on huge products.
Greg has done a lot of research into developer frustrations with customising form controls.
My current thinking in this space, and I know some folks will find this controversial, but I think we should completely standardize in-page form controls with no limitations on their styling capabilities. What do I mean by in-page controls? I am referring to any form control or component that is rendered within the content process. This standardization would include the sub-parts and their related states and how these are exposed (probably through CSS psuedo classes or HTML attributes). This will enable the shadow-dom to be encapsulated while providing web developers with a consistent experience to adjust to match their brand and needs of their site/application.
What you see really is what you get. I like this style!
Well, the clever CSS techniques just keep on comin’ from Trys—I’m learning so much from him!
A few common gotchas when using BEM, and how to deal with them.
This is such a great excercise for teaching the separation of structure and presentation—I could imagine using something like this at Codebar.
This is such excellent advice for anyone starting out in front-end development:
- Get comfortable with the naked internet (sorry, not THAT naked internet)
- Build yourself some nice little one-column websites
- Learn about layout
- Make it work on phones
- Make it dynamic
(I would just love it if Meagan were posting this on her own incredibly beautiful website rather than on Ev’s blog.)
Bringing gradients back, baby!
This is going to be a handy reference to keep on hand whenever you want a button to actually look like a button.
This is a really interesting approach that isn’t quite a CSS reset or a normalisation. Instead, it’s an experiment to reimagine what a default browser stylesheet would be like if it were created today, without concerns about backwards compatibility:
Applies basic styling to form elements and controls, getting you started with custom styling. We want to find the balance between providing a base for implementing a custom design, and allowing OS-level control over how form inputs work (like how a number pad works on iOS).
Provides a very lightweight starter file, with generic visual styling that you will want to replace. This isn’t as robust or opinionated as a starter-theme or framework. We’ve leaned toward specifying less, so you have less to override. (We haven’t defined any font families, for example.)
You can contribute by adding issues.
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.
Jonathan shares his notes on that great flexbox container queries article from Heydon that I linked to.
Er …I think Heydon might’ve cracked it. And by “it”, I mean container queries.
This is some seriously clever thinking involving CSS custom properties, calc, and flexbox. The end result is a component that can respond to its container …and nary a media query in sight!
It’s getting exhausting spending so much of my time defending one of the three pillars of the web: CSS. It should sit equal with HTML and JavaScript to produce accessible, progressively enhanced websites and web apps that help everyone achieve what they need to achieve.
Another good reason to use the currentColor value in SVGs.
Chris Ferdinandi has a good rule of thumb:
If something I want to do with JavaScript can be done with CSS instead, use CSS.
Makes sense, given their differing error-handling models:
A JavaScript error can bring all of the JS on a page to screeching halt. Mistype a CSS property or miss a semicolon? The browser just skips the property and moves on. Use an unsupported feature? Same thing.
But he also cautions against going too far with CSS. Anything to do with state should be done with JavaScript:
If the item requires interaction from the user, use JavaScript (things like hovering, focusing, clicking, etc.).
‘Sfunny; I remember when we got pseudo-classes, I wrote a somewhat tongue-in-cheek post called :hover Considered Harmful:
Presentation and behaviour… the twain have met, the waters are muddied, the issues are confused.
Rachel does some research to find out why people use CSS frameworks like Bootstrap—it can’t just be about grids, right?
It turns out there are plenty of reasons that people give for using frameworks—whether it’s CSS or JavaScript—but Rachel shares some of my misgivings on this:
In our race to get our site built quickly, our desire to make things as good as possible for ourselves as the designers and developers of the site, do we forget who we are doing this for? Do the decisions made by the framework developer match up with the needs of the users of the site you are building?
Not for the first time, I’m reminded of Rachel’s excellent post from a few years ago: Stop solving problems you don’t yet have.
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).