Today’s Readings

From Yair Even Or comes Multi-Value CSS Properties With Optional Custom Property Values. A sweet little trick, though it definitely leans heavily into the realm of “this will confuse the hell out of anyone else (or perhaps even yourself in a few months)”… Also note the Sass bug at the end, in case that applies to you.

The native dialog element will be pretty awesome once its support gets a little more deeply absorbed. You can now completely style, word and programatically control situations where we once used alert, confirm and prompt! And even more, because you can add literally anything inside of dialog that you want, even forms, long scrolling text, etc. Some features that you or your users might expect are “missing”, like backdrops, click-outside-to-close, etc., but those can also easily be added, because it is all in our control now!

runs us through a few more dialog details, pros and cons.

Another native HTML that I really, really want to love, is details, but I have always been frustrated with the lack of control we have via CSS (primarily not being able to force it to be open when printing). But has a neat little component that helps, actually adding quite a bit more, although leaning completely on JS for all the customization.

Tip: Shave up to 90% off the size of Google Fonts by declaring only characters you need with &text
Reduce Google Font file size by subsetting only the characters you need. [vcard Addy Osmani https://twitter.com/addyosmani]

For you Mac devs out there, just stumbled across the DevUtils app, an offline toolbox for a bunch of common dev needs, like en- or de-coding a hash, formatting or validating JSON, beautifier/minifier, and a bunch more. (It also offers one of the best onboarding experiences I have ever seen from an app.)

And for you Windows peeps, there is DevToys. Seems to offer a similar, if not identical, bunch of tools.

offers a nice-looking “Add to Calendar” dropdown, containing numerous calendar options. has a few thoughts.

writes about what happens when incredible performance improvements result in horrendously worse statistics. Some times you have to dig deeper to find the “why”, and some times that “why” actually turns out to be kind of good news…

And speaking of performance, although two years old now, ‘s When Performance Bytes presentation from the 2019 performance.now() conference continues to be more relevant than ever… A few key take-aways:

  • The software to land men on the moon was < 1.7 MB of highly-commented, uncompressed code.
  • The median mobile site (in 2019) downloaded 1.8 MB of uncompressed JavaScript…
  • Very few sites have JS that is taking people to the moon (okay, this one’s my take-away…)
  • Great chart showing page load speed in Japan increasing at the end of each month, as the page loads per users goes down, equating to data plan caps kicking in, slowing people’s experience, causing less usage (that means you have less users, meaning you are selling less)
  • 17% of JS is still shipping uncompressed
  • Use the -has-response-header:Content-Encoding filter in Chrome DevTools’ Network panel to find uncompressed files
  • You can import your own site’s GA data into Can I Use to check what is supported by your audience!
  • Multiple, multiple slides showing how slow JS processing is, especially frameworks, especially on mobile, and while things have certainly gotten better since 2019, this is certainly still problematic.
  • Wondering which devices to test on? Check Amazon’s Best Sellers… #lifegetsscary
  • Depending on your target market device range, if you want to hit 4s TTI, you have about 130-170kb of total critical path resources… That includes HTML, CSS, and JS… So maybe 100kb of JS?
  • Chrome’s V8 does script streaming, meaning, after downloading about 30kb of any script file, V8 will start parsing, often on a different thread, even while the rest of the file is still downloading (all downloading and parsing of a file still has to be completed before execution of that file can begin, and regardless of which files are ready for execution first, execution order always follows page source order, unless marked as async)
  • This means “ideal” JS file size is around 50-100kb files… (Tim’s math, not mine)
  • Lots and lots of talk about Webpack, Webpack Analyzer, tree shaking, Yarn, etc., that somehow had amazing reductions…
  • No matter how much work you put into shaving KBs from the existing code base, if you do nothing to prevent it from coming back, it will come back…
  • Possible to build-in restrictions and blockers when using CLI and from within IDEs

If anyone out there is currently looking for a gig, and is considering working remotely, perhaps from another country, has compiled a very helpful list to scroll through, from prepping your resume, to international job sites to companies currently hiring and more! And while you’re prepping for that first interview, has a collection of questions that you might want to ask your interviewer.

And finally, Opera now supports emoji-only website addresses… What… is the world… coming to…

Happy reading,
Atg

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.