An interesting conversation summary from Chris Coyier about whether we still need CSS files, or whether we should be applying inline styles via JS… Initially I just about choked on the concept, but, while there are valid points raised, I still feel like the method we have, of separating HTML, CSS and JS, and affecting page states by changing CSS classes via JS, is a powerful, tried-and-true approach. The biggest issue people seem to raise is global cascading, which can be easily resolved by using element IDs as namespaces in your style sheets.

Much the way Eric Meyer uses global styles to create a flag module, then specifically styles the flag with the ID rainbow… :-)

Chris’ article above links to Glenn Maddern‘s Interoperable CSS article, which discusses enhancements to CSS to try to make it less “cascady”… He lost me the moment he used the word “compile”… :-/ (Though, I guess that really is what Less and Sass are already doing…)

Harry Roberts continues on the theme of dealing with nested (and thus cascading) CSS by taking a more philosophical approach, considering whether such problems are truly development issues, or whether they might be design issues… I love this collection of thoughts:

The problem here isn’t How do we style this?, it’s Why has this been designed like this in the first place?. Put another way, the problem here doesn’t exist in code, it exists in design… The design issue here is solved by subtly inverting the problem: instead of saying The buttons need to be smaller when they’re in the header, we need to be saying We have a smaller variant of our buttons, and it’s these that we use in the header… It’s that subtle. They’re not smaller because they’re in the header, they’re smaller and they’re in the header.

This video starts with a nice top-level intro to how a browser renders a page; you may have already seen something like this before, but if not, it is interesting. But, for me, the video gets really interesting at about the 3:23 mark, where the presenter gets into Chrome DevTools and starts dissecting the various Paint steps that go into creating a fairly simply square image with a border.

Speaking of Chrome DevTools, Damon Bauer takes us on a tour of a new tool (currently in Canary only) called Filmstrip. As Damon shares, this is a lot like the incremental screenshots that WebpageTest provides, but now right in your DevTools! Freaking awesome!

And speaking of performance improvements, here are two articles dedicated to improving WordPress database performance:

• The Developers Guide to the WordPress Database (and Writing Better Code) takes us on a long journey deep inside the various tables and structure of the WP DB. I didn’t see a lot of developer tips for writing better code, but I guess once you understand the structure better, you could write better code. :-)
• 10 Tips for Keeping a Squeaky Clean WordPress (and Multisite!) Database walks through cleaning old crap out of your WP DB, but does so via direct SQL commands… This is WAY too risky for me, so I wouldn’t recommend this approach. Nearly all of the suggested clean-up steps can be handled much more safely via the plugin that is tossed in at the very end of the article, WP Optimize. I’ve used it for years and never once ran into an issue. Maybe it is not as thorough, but you are also never going to accidentally delete all the content from one of your WP DB tables…

Speaking of WP, and continuing with the above CSS theme, here are several ways to add animation to your WP site. The article takes some time to get around to anything that is WP-specific, but further down the author does get to WP Plugins that help add animation to themes.

Okay, just one last WP post, this time showing how to use WP for rapid prototyping. Includes discussions on multiple variations of prototypes, and finally offers a 45-minute how-to video!

Hmm, interesting proposal for trying to standardize the handling of custom web font loading, time-outs and fallbacks.

Haven’t talked about this in a while, but here is an extremely thorough responsive images “state of the union”, including edge-cases, quirks, and work-arounds.

Anybody using vw or vh units for their font-size? I do, for headings mostly, but as Eduardo Boucas points out, at some point those tend to get too big or too small, and you have to craft custom @media breakpoints to change the font-size. That’s why Eduardo created this Sass mixin to automagically create breakpoints for you. Okay, it doesn’t really fix the problem (and you still have to find the desired breakpoint and pass it into the mixin), but as with most things preprocessors do, it makes getting around the problem much easier… :-)

Not sure if anyone still does their debugging in Safari, but I really like the data-type indicators they’ve added to their Web Inspector Console. I can’t say that differentiating between, say, a number and a string, was hard before, but this does make it easier…

So, up to now, I’ve basically been ignoring ES6, figuring “It isn’t close enough to being usable, so why bother?” And depending on which browser support table you look at, I may be right, and I may be wrong… But Wolfram Kriesing suggests we all start learning ES6 now, and has even created a collection of ES6 Katas to help us all learn! Vielen Dank, Wolfram!

And finally, further proof that there are only two kinds of people… And if I had any ability to draw, I would add one more example: eating corn-on-the-cob… There are those that eat like a typewriter (eating the length of the cob, then rotating to eat the next “row”), and those that eat like a lathe (rotating the cob as they eat, then moving on to the next “column”). But in this example, there is actually a third kind of person: those that randomly bite at the cob, in no systematic order whatsoever… Watch out for these people, they are clearly not to be trusted… ;-)

Happy reading,
Atg

Top⇪