CSS Tricks

From time to time at Stackoverflow, the question pops up whether there is an equivalent to the stroke-dashoffset technique for animating the SVG stroke that works for the fill attribute. But upon closer inspection, what the questions are really trying to ask is something like this: I have something that is sort of a line, but because it has varying brush widths, in SVG it is defined as the fill of a path. How can this "brush" be animated? In short: How do you animate calligraphy? A mask path covers the calligraphic brushThe basic technique for this is relatively simple: draw a second (smooth) path on top of the calligraphy so that it follows the brush line and then choose the stroke width in such a way that it covers the calligraphy everywhere. This path on top will be used as a mask fo...

Yes, this is a React component, but regardless if you care about that part or not, the "ideal image component" part could be of interest. There is a lot to consider with how we put images on web pages these days. This deals with: Placeholder space (and then flexible responsive styles after loading) Low-quality placeholder images Responsive images syntax (srcset) Image formats (e.g. using WebP when you can) Click-to-load on bad network connections Better UX for loading errors, with translatable copy That's not even all of it. So much to think about with poor little <img>. I enjoyed Alejandro Sanchez's response: The readme file for this component is amazing to teach you how to think like a front-end developer. — Alejandro Sanchez (@alesanchezr) June 12, 2018 Direct Link to Article — P...

When we produce a PNG image, we use an <img> tag or a CSS background, and that's about it. It is dead simple and guaranteed to work. PNG is way simpler to use in HTML than SVGUnfortunately, the same cannot be said for SVG, despite its many advantages. Although you're spoiled for choices when using SVG in HTML, it really boils down to inline, <object> and <img>, all with serious gotchas and trade-offs. Problems with inline SVG If you're inlining SVG, you lose the ability to use browser cache, Gzip compression between servers and browsers, and search engine image indexing (inline SVG is not considered as an image). Even though your image may not have changed one bit, they are always reloaded and this causes slower loading times for your website, a trade-off that most are n...

A good candidate for the Blog Post of the Year from Zach Holman. I think Eric Portis' "w descriptors and sizes: Under the hood" is up there too, but perhaps even nerdier. Ooooh, also Frank Chimero's "The Good Room" is up there. But I digress. Zach's article is as educational as it is funny. But yeah, this UTC initialism doesn’t make any sense. Let’s dig into this a little more. So you’ve got a bunch of scientist types around 1960 who are like, hey, time is all screwy we should totes make a standard. And some of them spoke English, and some of them spoke French, which, of course, is the cause of so much conflict over so many generations. (In hindsight, maybe we should have split all those troublemakers up from the start.) The English-speaking folk were like yo, this definitely sounds like...

There are a lot of tools that aim to help you remove "unused CSS" from your project. Never a week goes by that I don't see a tool for this being shared or promoted. It must strike some kind of perfect chord for some developers. I care about performance, and I know that reducing file sizes is good for performance. Indeed, it is. I bet we have CSS that is unused in our stylesheets, if we removed that, that's a performance win. Yep, it would be. We should automate that. Ehhhhhh, I'm not so sure. There are major performance tooling players that play up this idea, like Lighthouse and how it gives you CSS and JS "Coverage", which will surely tell you that you're shipping code you don't need to be. The tools that claim to help you with unused CSS have to perform analysis to be able to tell you w...