Recently my team was tasked with building a favicon fetcher. As a warmup, I looked to see how Chrome handles favicon loading. Do you know that the favicon loader in Chrome is many thousands of lines of code? Why is it so complicated? We realized we knew very little about the favicon ecosystem. Eventually we decided to fetch the Tranco top 100,000 websites and analyze their favicons. We checked each home page for favicons, Apple touch icons, and manifest icons.
Tricks like this have their place, and Facebook (which can clearly afford to hire the best of the best CSS developers) might be one of them. But speaking personally, when forced to pick between a trick like this and an ever-so-slightly less optimal but far more readable solution (say, a media query), in 99% of cases I’d plump for the latter. There are some reasons for this: I work at an agency, and most of the code I write will need to be maintained long-term by several developers with various levels of CSS knowledge. Most of their work will involve fixing bugs and building new features at the client’s request, within a limited budget. If the client asks to change the border radius on the cards and they’re faced with this monstrosity? They don’t have time to do an afternoon’s worth of research to make what should be a simple change.
Until now, the only way for CSS to modify the styling of a custom element from outside of the shadow DOM was to use CSS custom properties. In a strict design system where you only want to allow limited changes, that might be ideal. If you want your component to be more versatile, it creates a problem. Every CSS property you want to offer up for styling needs to be defined using a custom property. Just the sound of that seems tedious.
The NYTimes text balancer measures the number of lines, and then reduces the width of the text container until the point where it breaks onto a new line. Then it widens the container a bit to avoid the extra line break. The method is suitable for headlines and a single short paragraph of text. It yields no benefit over the browser’s default layout engine when the text exceeds a couple of lines. You’ll also end up with paragraphs of uneven widths, which breaks up the cohesion of the right-hand text edge of your design. It works great for two–four lines of text, though.
Accessibility is too often seen as a compliance domain which needs to be tracked. As a result, organizations are doing a bottoms-up race to whatever the bare-minimum grade they need to attain in order to stop being concerned about it. For instance, if an organization happens to regard a “B” as good enough, then that will be their target and they will pursue accessibility no further. This approach to a “score” is misleading and dangerous. A score’s value should be solely in measuring your distance from a goal and that goal should be full compliance with WCAG.
Thanks to Cloud Four for sponsoring this week’s newsletter! If you’d like to help with the costs of running Friday Front-End, you can back our Patreon for as little as a dollar a month.
Tweet
Share