This is a question tackled by Chris Coyier at CSS-Tricks this week in his article, which doesn’t so much prescribe one answer, but instead takes a look at many different techniques you might consider using.

Color lends itself to this question in an interesting way, largely because colors can frequently change on a website, and we tend to have a wide array of them that can be very similar. At scale, it can become inefficient trying to change all the references to a single color. So, when we turn them into variables, it allows us to make one change that filters everywhere.

It’s funny to me reading this article, because as Chris goes through the different approaches, I find myself realizing I’ve used a frightening number of them at different times, especially as it would apply to a monochrome palette. For my part, I’ve recently settled on using the abstracted color names closest to what I’m using to maintain the differences between shades.

Which pattern is right for you will partly depend on how you work, and what you are working on. For instance, using numbered levels or a light/medium/dark approach can become problematic if you find yourself inserting shades over time. Likewise, using color names is better when the shades might change slightly, but still gives you the same find-and-replace hurdles you’d face just hardcoding the colors because of their specificity.

Shoot us a message on Twitter and let us know which pattern works best for you and why, we’d love to hear what folks are doing.

Your long read of the week comes from Ferdy Christant with a piece from his blog looking ahead at the future of browsers in a world with Chromium domination, now that Microsoft will be adopting it.

This is a followup to a previous article he wrote that we’ll link to in the shownotes that looks at the somewhat challenging landscape of browsers today.

While his first article had a somewhat… blunt tone to it about the problems Chromium domination brings with it, this one takes a more positive look ahead at how things will likely be changing for both developers and users.

For instance, the increasing homogeny in rendering engines means users can expect a lot of the web to work as intended with consistency. It also means less testing time for developers which means fixes can get in front of people’s eyes faster.

Those things, however, don’t come without some amount of risk. He also discusses the challenges involved when one entity has power and control over the market in a field driven by standards. This can be tempered by the small players in the field though, and a reminder that Microsoft’s commitment to Chromium is an ironic contrast from a company that itself was once the leader in the browser market.

At any rate, be sure to check out both articles at Ferdy’s blog. They aren’t short reads, but they are deeply interesting and take a valuable look at how browser engines impact the work we do in our field. It may well impact your own strategy and workflow in the coming years.

And finally this week we have a piece on accessibility at the 24 Ways blog by Scott O’Hara – Inclusive Considerations When Restyling Form Controls.

So, speaking of rendering engines, one of the most consistently frustrating and time consuming processes you go through as a front-end developer is styling forms and trying to get them the same across devices, especially when the design asks for very particular styling.

This challenge becomes even more detailed though when you start trying to ensure that those styles are also accessible. After all, making something match a design is only part of the battle.

Sometimes this discussion sounds a little silly, because some parts of forms, the most common ones, are relatively easy to style. But when you start dealing with fields that imply different behavior, that’s where we learn just how hard the process is.

For instance, I’m talking about date fields, sliders, file uploads and others. It’s a common tactic to replace date pickers with custom JavaScript solutions in order to meet design requirements, but you can also implement those in a way that can break the underlying feature for users that don’t get the special feature you deployed.

That’s where accessibility and inclusive design factors into your design strategy. Scott looks at a number of these use cases and form elements, providing a discussion of how to style the elements, what the limitations are, and the accessibility considerations to keep in mind when working with it.

Definitely swing by the 24 Ways blog and give this a read before you build your next form to make sure you’re considering all the best practices before moving forward.

Thanks for listening to Real-Time Overview today and we hope you found these selections helpful for whatever it is that you are working on this week. For The Drunken UX Podcast, I am Michael Fienen. If you want to get the links to any of the articles from today’s episode, be sure to swing by our website at drunkenux.com, we’ll have all of them linked in the shownotes there.

Tune in this coming Wednesday for Build Process number 7, where I sit down to talk with Caleb Smith and John Kuefler from DevSquared about how they got into web development and the advice they have for young developers. You won’t want to miss it.

For now, the last thing I can think of to leave you with is to keep your personas close, and your users closer.