?
[Robin]: Let’s say you need some margin and padding utility classes. In Tailwind, for example, you’d write some HTML like this:
<div class="pt-6">...</div>This sets the padding-top CSS property to 6 in the scale. 1 is less padding than 2, etc. And this can be super handy when you don’t want to litter your CSS with margin and padding values. To be quite frank here, I think this is indeed a very useful thing (even though generally I am not entirely all aboard the utility class hype train).
However! What if we wanted to have these utility classes without using something like Tailwind? Sure, we could use Sass to generate those classes but, as Andy Ford suggests, we can write these utility classes ourselves with CSS custom properties.
First off, Andy gives an example that looks like this in HTML:
<div style="--p: 4;">...</div>I know I’m being stereotypically British when I say this but, ahem, you wot?
This is extremely weird but also very cool! It’s setting a CSS custom property inline from the HTML which I’ve never done before. In your CSS you’d set up that variable in the :root, like this perhaps:
:root {
--p: 0;
}(If all this is a bit foreign to you then I’d very much recommend our guide on CSS custom variables. I return to it an awful lot.)
And then you’d create the class that sets the padding in CSS:
[style*='--p:'] {
padding: calc(0.25rem * var(--p)) !important;
}So that’s multiplying whatever you set as the --p variable by 0.25. And when you put all that together you can use that utility class throughout your HTML, like this:
<div style="--p: 1;">0.25rem of padding</div>
<div style="--p: 2;">0.50rem of padding</div>
<div style="--p: 3;">0.75rem of padding</div>I think this is an extremely neat—although very peculiar—CSS trick. And, as Andy shows, you need to set variables and write classes for padding-right, padding-left, etc. You also need to figure out how to deal with breakpoints and media queries.
He writes:
It’s worth pointing out here that CSS variables assigned in inline styles do not leak out. They’re scoped only to the current element and don’t change the value of the variable globally. Thank goodness! The one oddity I have found so far is that DevTools (at least in Chrome, Firefox, and Safari) do not report the styles using this technique in the “Computed” styles tab.
This is such a neat example of what CSS custom properties can do. We could do the same for font-size or changing the font-family of an element, too. There are so many different things we could explore with this technique!
?
Last week, Chris wrote about Chrome’s decision to deprecate JavaScript dialogs including alert(), prompt(), and confirm() and then collected a ton of opinions from developers:
Believe it or not, I generally am a fan of Google and think they do a good job of pushing the web forward. I also think it’s appropriate to waggle fingers when I see problems and request they do better. “Better” here means way more developer and user outreach to spell out the situation, way more conversation about the potential implications and transition ideas, and way more openness to bending the course ahead.
Through this post, I bumped into Jeremy Keith’s excellent note on the matter called “Foundations” where he describes his concern for browsers that make breaking changes to the web:
[…] breaking changes don’t happen often on the web. They are—and should be—rare. If that were to change, the web would suffer massively in terms of predictability.
Secondly, the onus is not on web developers to keep track of older features in danger of being deprecated. That’s on the browser makers. I sincerely hope we’re not expected to consult a site called canistilluse.com.
On that note, Rich Harris riffed on that point in this great piece:
We can’t normalise the attitude that collateral damage is the price of progress, even if we accept the premise — which I don’t — that removing APIs like alert represents progress. For all its flaws, the web is generally agreed to be a stable platform, where investments made today will stand the test of time. A world in which websites are treated as inherently transient objects, where APIs we commonly rely on today could be cast aside as unwanted baggage by tomorrow’s spec wranglers, is a world in which the web has already lost.
?
On an entirely different and less-drama-fuelled note, here’s a fun project from John Polacek where he creates a background gradient generator in Next.js.
Just look at this nifty thing:
?
Okay, so this one is an upsetting and yet bonafide CSS trick by Dongsung Kim where he makes a color that is whiter than white.
If you check out this demo and turn down the brightness of your screen you’ll see some text that’s hidden in the background. What’s going on here?
There are hidden HDR videos playing at the corners of this page. When a HDR-capable browser encounters one, it switches to HDR mode. For some reason, CSS backdrop-filter + brightness >100% combo seems to behave like HDR—reaching beyond the user-controlled display brightness, up to the maximum HDR brightness—while the everything in between follow along. At least that’s the overall idea, but I still don’t know exactly why it works; especially why with those two CSS properties.
I feel like this problem is crying out for some poor developer to write an enormous 3,000-word interactive essay on this subject.
?
This tool by Neatnik called View Source is excellent and does exactly what it says on the tin: it lets you tap in a URL and then view the HTML source. This is particularly handy on mobile devices where browsers don’t give you the ability to check that.
Also, doh!, I just checked my personal site and immediately found a bug where I’d duplicated the <title> twice in a row.
I’m bookmarking the heck out of this site because I also just love reading the view source like this, rather than from a tiny window in DevTools. But also: ugh that double <title>
??
See that nifty hover effect up there? That’s from a post Temani Afif wrote about how to use the CSS Paint API to create an image fragmentation effect. It’s extremely neat:
The Paint API is part of the Houdini project. Yes, “Houdini” the strange term that everyone is talking about. A lot of articles already cover the theoretical aspect of it, so I won’t bother you with more. If I have to sum it up in a few words, I would simply say : it’s the future of CSS. The Paint API (and the other APIs that fall under the Houdini umbrella) allow us to extend CSS with our own functionalities. We no longer need to wait for the release of new features because we can do it ourselves!
And just look at the CSS for this thing!
img {
-webkit-mask: paint(fragmentation);
--f-o: 1;
transition:--f-o 1s;
}
img:hover {
--f-o: 0;
}This is how you apply the Paint API to an HTML element — and I’m skipping out all the JavaScript here — but if I saw CSS like this a few years ago I would have thought it’s from an alien language, not the CSS I know and love.
?
Here’s yet another nifty tool alert! SVG Gobbler is a Chrome extension that grabs all the SVGs on a webpage and lets you see them all in a grid. Here’s what it looks like when you run the extension on CSS-tricks, for example:
You can them export those SVGs and even optimize them, too! Very handy indeed.
Sponsor
Educative
Take the next step toward mastering today’s most popular and trending technologies.
Get free access to the largest hands-on catalog, from small bites to full blown coursework covering the latest in-demand technologies and skills.
Start Learning Today with a Free 7-day Trial
Sponsor
Duda
Load times have a tremendous impact on a website’s ranking. Duda’s editor automatically takes care of image optimization, browser caching, critical path CSS and embeds your fonts above the fold to deliver top-performing sites that load the fastest.
[Chris]: I enjoyed this story ultimately about RegEx from Buzz Andersen:
On March 10, 2021, many Russian Internet users suddenly found they were having trouble accessing parts of the web. Kentik, a US-based network analysis company, reported that network traffic to Rostelecom, the Russian state telecom, was down as much as 24%, and cybersecurity Twitter was abuzz with speculation about the causes.
Eventually, a Russian artist and Twitter user named Gregory Khodyrev realized what was going on: someone at Russia’s state Internet censor, Roscomnadzor, had attempted to block the Internet domain “t.co” (used by Twitter’s URL shortener), but had instead managed to cut off access to any domain containing the text pattern “t.co.” This meant that sites such as “microsoft.com,” “reddit.com,” and even Russia’s own state media outlet “rt.com” were rendered suddenly inaccessible.
There is more interesting stuff in that story about RegEx, but allow me to share my own introspective thoughts. I’m not, like, “good” at RegEx. But I can clearly remember a time in my dev career where I wouldn’t have even tried to write one or understand one. I’d just be like… this is advanced developer, almost more back-endy stuff, that I’ll never understand and that’s why I pair up with devs who do know this stuff.
I’m past those days. I’ll at least give writing a RegEx a try before asking for help, and often get it done myself. Tools like RegExr help. And I can slowly reason them out as well. Did I get smarter? I don’t think so. I just got more confident. I have a feeling now that it’s just code, and I know enough about code that I can reason it out through research and guess-and-test work. And slowly I’ll get better. I’m still not “good” at RegEx, maybe that’s a future step in my journey, but the years have bought me the confidence I needed to do the job when I need to.