I’ve started to call this problem “Chrome Bias”, and over the past week, I decided I would do something about it by switching to Firefox. This way I could figure out what’s new in one of the most popular web browsers out there. But! While I was running this little experiment of mine, I found three Firefox features that you might not know about if you suffer from extreme Chrome Bias like I do.

I think these Firefox developer tool features are pretty nifty:

Theming the Developer Tools

I didn’t know that you can set the theme of the Developer Tools in Firefox. That is particularly helpful for me when I want to work on something at night and can configure the theme to dark:

Fonts tab

Firefox’s font tab might not be new but it certainly is to me. On the far right you can select the tab and see the type info for whichever element you’ve selected:

It’s pretty neat that it tells you not only how to use that @font-face rule, but also the location from which the font is being requested as well. My favorite button here though must be the “See all the fonts used in the page” button which sits in the bottom-right hand corner. Once you’ve clicked that you can see every font-family that’s been declared in the stylesheet that’s served to the page:

I can see that being super helpful in larger codebases where you might accidentally have lots of fonts being declared inconsistently.

Performance tab

After you’ve hit the 'Performance' tab and refreshed the page, you’ll see a waterfall of every resource that’s been requested. But did you know that you can see this data in the form of a graph, too? Here’s how that works:

This is a great tool to identify bigger problems in performance—perhaps you have a massive stylesheet being requested by the browser, and from here you’ll be able to see the scale of the problem faster.

Wrapping up

Here’s the thing: the more we experience how other browsers work, the more we learn about how different users experience our websites. Understanding how developer tools differ was useful in this instance, but learning about how unfamiliar browsers look and feel is enlightening as well.

For the next step in my experiment, I want to try out more mobile browsers because I imagine the differences between them are even larger than those between desktop browser apps.

What tricks have you learned from your non-regular browser lately?

Chrome Bias (and Finding Things To Like in Firefox) is a post from CSS-Tricks

Until it doesn't.

I do a little work for a WordPress plugin. The number one thing that gets reported to the support team is, without a doubt, are situations where the plugin conflicts with either the installed theme or another installed plugin. The person reporting the problem has the plugin installed, but what it is doing looks nothing like the screenshots advertised by the plugin.

This can be extremely irritating for the person managing the site. If this plugin is downloaded from the WordPress directory, then it ought to work right out of the box, right?

You could argue this is an unrealistic expectation when you consider that most themes and plugins are developed by different people. It's understandable that mashing code from multiple authors into the same site will lead to at least some conflicts now and then, despite everyone's best intentions to deliver good work.

This post is going to look into the specific area of style conflicts and ways to overcome them.

I'll start off by saying that it's a tough position being a WordPress theme or plugin developer. On one hand, any stylesheets a plugin includes need to be opinionated enough so that they do what they need to do and look great. On the other hand, they need to respect the work of the active theme and other plugin developers so that the styles play nicely together. It's a balance that even a trained tightrope walker can appreciate.

We're not going to talk about the different methods WordPress plugin developers have to make theme and plugin styles more compatible or theme-able. Instead, we're going to look at the different ways we can override conflicting CSS in WordPress that allow you to take control of the styling for any component of a WordPress site, regardless of whether it originates from the theme or a plugin.

Override Styles in the Active Theme

All WordPress sites employ a theme. CSS-Tricks runs on WordPress and it has its own custom theme, which contains all the template and style files needed to generate this post. Well, assuming you're reading this on the site and not from a syndicated feed.

The point being that all themes require at least two files, one of which is the magical `style.css`. This file is required because it contains information about the theme that WordPress would be unable to recognize the theme without.

Those of you who know a thing or two about WordPress might want to stop me here because style.css does not have to contain CSS and you would be right. It does not have to and we could simply add our own stylesheet to the header of the theme instead and use style.css as a shell for the theme to be recognized. That's legit. However, the file was indeed intended to be the primary location of a theme's files, regardless of how we choose to develop our sites.

If your theme uses the file to contain the theme styles, you can modify it directly to change any of the styling properties of your site. It can also be used to add and override styles that might come packaged in plugins or other third-party sources.

Override Styles in a Child Theme

The active theme method is only great if you are the developer of the theme. Many folks, however, roll with themes made by other developers. I'm sure you've seen the many theme marketplaces out there that sell premium WordPress themes that you purchase, download, and install into WordPress. That's what we're talking about.

If you're using one of these themes, then best practice is to manage your customizations in a child theme. This is really a fancy way of describing the process of creating a new folder in your WordPress `wp-content/themes` directory that is the same name as your parent theme, only with `-child` appended to it.

For example, if our parent theme directory is called `css-tricks` then our child theme directory would be called `css-tricks-child`. This directory requires `style.css` just like the parent directory and it will be loaded on the site after the parent theme's `style.css` file so that any styles contained in the child theme version will override the parent.

Don't you wish that's how your teenage years worked?

Now you can make as many changes as needed and you will not lose those changes when installing future updates that the theme developer releases.

Register and Enqueue Your Own Stylesheet

This is one of my favorite ways to go about overriding styles in WordPress. The idea is that you create your own stylesheet and load it into the site theme after all of the other stylesheets so that yours overrides the others.

There are two well-documented WordPress functions, one called wp_register_style() and the other wp_enqueue_style() that allows us to do this and it can be added either to parent or child theme functions.php file in order tell WordPress to look for it and load it in the site header.

This is a basic example of how the function can be used to call a stylesheet by the file name (aka handle) and file path:

function my-custom-styles() {
  // Register my custom stylesheet
  wp_register_style( 'custom-styles', get_template_directory_uri().'/lib/styles/custom-styles.css' ) );
  // Load my custom stylesheet
  wp_enqueue_style( 'custom-styles' );
}
add_action( 'wp_enqueue_scripts', 'my_custom_styles' );

We could get a little more fancy by telling WordPress to load it only on a specific page:

// Load my custom stylesheet
function my_custom_styles() {
  // Register my custom stylesheet
  wp_register_style( 'custom-styles', get_template_directory_uri().'/lib/styles/custom-styles.css' ) );
  // Check that the current page is the homepage
  if ( is_home ) {
    // Then grab the custom stylesheet
    wp_enqueue_style( 'custom-styles' );
  }
}
add_action( 'wp_enqueue_scripts', 'my_custom_styles' );

Note that adding an extra request to all pages is a performance consideration, but you can certainly wrangle control of that as well.

Art Direction

Art direction seemed to be all the rage in something like 2009, though recent data suggests a slight rebound. The idea being that adding styles to the head on a one-off basis would allow you to create compelling layouts on a post-to-post basis. Styles injected into a <style> block in the head, as long as they come after the regular stylesheets of the site which are probably <link> elements, will have the opportunity to override existing styles nicely.

Art direction can be used as an effective means for overriding conflicting styles as well and is particularly effective when those conflicts only exist in very specific places without having to create and load a full stylesheet to clean things up.

There are plenty of WordPress plugins that enable art direction. It's actually not too incredibly difficult to build this on your own.

Using a Plugin

Hey, if a plugin got you into this mess of conflicting styles, then maybe there is one to get you out of it, right? Of course, there is.

I am sure there are others out in the wild, but the one I am most familiar with is Simple Custom CSS. The idea is pretty straightforward: a new screen is added that allows you to write CSS. The CSS entered and saved gets added to the document head which, like the art direction method we discussed, gives you the opportunity to override other styles on that particular page.

WordPress Customizer

WordPress 4.7 introduced a new feature in the WordPress Customizer that adds a CSS editor:

This is essentially WordPress adding native support for the the Simple Custom CSS plugin mentioned earlier. In other words, styles are added to the head upon being saved.

WordPress Editor

Oh yeah, remember that? You can actually edit a site's style.css file directly in WordPress by navigating to the buried tavern that is the Appearance > Editor screen.

I'll preface this by saying I find this to be a scary place to hang out. It provides you with access to edit the code of any theme file, including PHP templates. The changes are not version controlled, so it's hard to know what has changed in case you screw something up, and if your version control system is in charge of deployment, and changes there might override changes made here.

Still, it is possible to override styles here and to do so without needing to open up a text editor, saving your changes, then uploading them to a server (via whatever you do for deployment).

Wrapping Up

Look at that: seven methods for overriding styles in WordPress. The next time you run into a situation where something does not look right after installing a theme or plugin to your WordPress installation, you now have the power to take control of the mess and clean things up like a boss.

Methods for Overriding Styles in WordPress is a post from CSS-Tricks

There are currently four active methods for storing data on the client side.

1. Cookies (old school, still useful because they are sent with server requests)
2. Local Storage (very easy to use)
3. Session Storage (exactly the same, only clears when the tab is closed)
4. IndexedDB (quite complex, quite powerful)

Direct Link to Article — Permalink

An Overview of Client-Side Storage is a post from CSS-Tricks

Before we get into specific techniques, there are a couple basic guidelines we want to keep in mind:

Guidelines for scaling responsive animations

1. Size the animations based on a container

Whether we're using responsive or adaptive scaling (see below), we should try to size animations based on the container's sizing. In responsive scaling this is simple enough, but in adaptive scaling we have to look to element (container) queries. The only exception is if we know that in every circumstance the element is going to be positioned and sized relative to the viewport. Even so, it might be wise to size each piece based on a container in case we change our minds later.

There have been times where I've finished polishing an animation exactly the way I want only to realize that it only works for that particular screen size. Those times have included making mistakes like using absolute units (like px), only viewing it in one screen size, using responsive units but failing to check extreme dimensions, and a couple other occasions where I had to go back and completely refactor my approach. Sizing animations relative to the parent elements helps prevent that from happening, as does the following point:

2. Know the environments in which it will be used

Will the animation be a module that is repeated across multiple parts of your application? Is it only going to be used for a page loader initially? Does it need to scale at all? Keeping this in mind can help determine the method in which an animation should be scaled and keep you from wasting effort.

Now, let's look at the three most important ways that we can scale animations: scaling with responsive units, proportional scaling, and adaptive scaling.

Scaling with responsive units

Size pieces based on the parent

When we use responsive units like % or em, our animations automatically resize themselves based on the parent because their values change as their parent's do.

• In the case of percentages, the child's width value is set by the parent's value for the property, multiplied by the percent value set on the child.
• In the case of ems, it looks at the parent's font-size which determines the child's size values, multiplied by the number of ems.

This allows us to make sure that each piece of our responsive animation retains the behavior we want with respect to each other.

Sizing containers based on the viewport

From there, if we size our containers relative to the viewport, our responsive pieces will then end up resizing themselves based on the viewport as well.

We could use percents to size our containers based on the viewport, but that often requires setting something like html, body { height: 100%; } and making sure that the parent is sized with respect to the body, which may not always be the case with nesting. Adding this new rule can also affect other style changes.

Alternatively, we can use viewport units, which sizes the container based on the viewport regardless of how deeply it is nested. One thing to keep in mind is that support for viewport units is not perfect, though it's definitely in a state where it can be used for most projects.

I tend to use solely responsive units as a scalar for animations when it's a really simple animation, such as this illusion. Most the time it requires a pairing of responsive units with an approach from below to keep the animation proportional.

Proportional scaling

There are three main ways we can keep our responsive animation proportional while scaling it.

1. Size based on the width

To keep an element sized based on the width of the container, we can use the following approach:

.container {
  height: 0;
  padding-top: 100%;
}

See the Pen Infinite Mountains CSS by Zach Saucier (@Zeaklous) on CodePen.

However, if you're sizing your container based on the viewport, a more straightforward approach would be to use vw like so, though it doesn't reach as far back regarding support.

2. Size based on the height

We can also size our container using the height by using vh as seen in this demo, but it is the least-used technique that I've seen. The only time I can recall doing something like this myself is when I used responsive units to create this loader, but even then I didn't use a container or viewport units.

3. Size based on the larger dimension

Sizing based on the larger dimension is by far the most common way I size my responsive animations, especially my visualizations, because I almost always want all of my responsive animations to be seen entirely. This method ensures that that happens.

.container {
  max-width: 100vh;
  max-height: 100%;
  margin: 0 auto;
  overflow: hidden;
}
.container::before {
  content: "";
  display: block;
  margin-top: 100%;
}

See the Pen Swirling dots by Zach Saucier (@Zeaklous) on CodePen.

This technique doesn't make use of the vmax unit, so any browser that supports viewport units (back to IE9) can use it. However, it does make use of a pseudo element (unless you want to use a real element) which should be kept in mind.

If you are scaling the container on the viewport itself and can use viewport units, it's very simple to size based on the larger dimension. All you need is:

.container {
  width: 100vmin;
  height: 100vmin;
}

This approach can be done only when the animation is sized with respect to the viewport, not some smaller container.

Adaptive scaling

Adaptive scaling is switching between variations at specific breakpoints. See Geoff Graham's CSS-Tricks article on the distinction between responsive and adaptive scaling.

At times we may want at least part of our responsive animations to change how they're sized at a particular screen size. This is most commonly done when text or thin lines are used, though sometimes it's also applicable when there are a lot of intricacies that would look busy when made smaller. Logos are probably the most commonly adapted elements because they need to be precise.

There's no one way to make something adaptive, but I approach it in the same way I do responsive design: by scaling my animation until something starts to look ugly, then add a breakpoint to fix what looks ugly.

Sometimes it's appropriate to mix responsive pieces with adaptive ones, such as in the Pen below. The top part is responsive but the text is adaptive to prevent text scaling from becoming ugly during in-between font sizes.

See the Pen Breakout by Zach Saucier (@Zeaklous) on CodePen.

A note on SVG

SVG can make use of any of the approaches outlined above. Most commonly, I treat SVG like a modular animation and make sure my SVG is sized by the SVG element itself, mostly treating it as a container based on the larger dimension, as covered above. This way it makes use of the vector nature of SVGs, allowing it to scale to be as large as it needs to be.

For more information on how to scale SVG specifically, check out Amelia Bellay-Royds' post on scaling SVG components here on CSS-Tricks or Sara Soueidan's Codrops post on making SVG responsive.

Make it look great in all contexts

With a bit of planning, animations can work just as well at small sizes as they do at large sizes. Don’t use pixel units, and make sure every width, height, and distance value are defined based on one or two variables based on the container/viewport dimensions or by font size.

Scaling Responsive Animations is a post from CSS-Tricks

On December 17, 1996, W3C published the first standard for CSS.

Very interesting to see what historic points made the cut for the timeline. The Zen Garden, acid tests, preprocessors... good times!

Direct Link to Article — Permalink

20 Years of CSS is a post from CSS-Tricks

• Don't use them as a label
• Don't use them as a secondary label
• Don't use them as example input
• Don't use them as helper text

Which amounts to pretty much: "Don't use them". Notice there are no examples of good use cases, and even the examples in the "Do" graphics just say "Placeholder Text", which isn't exactly demonstrative of usefulness.

I wonder if placeholder text will fall completely out of favor.

It reminds me of float labels. Float labels were a fun little fling, but they aren't actually useful. The reason you'd reach for them is when you're so space-limited that you can't show a regular label beside the input. But you can't actually ever remove the label, just move it. So if the label is still there and readable, why not just leave it there the whole time?

Direct Link to Article — Permalink

Alternatives to Placeholder Text is a post from CSS-Tricks

The number of config files per repo is slowly but surely overtaking the number of code files.

Seems to me /config/ or /.config/ as a directory to keep them are also too overloaded to be a real solution. I agree: "something’s gotta give at some point."

Direct Link to Article — Permalink

Propelling developer experience through configuration is a post from CSS-Tricks

Matt Smith (calling it "flexible type"):

My preferred approach for more flexible type is to calculate the font size based on the viewport height and width using the :root selector

Richard Rutter (calling it "Responsive Display Text"):

In one fell swoop you can set the size of a display heading to be proportional to the screen or browser width, rather than choosing from a scale in a series of media queries.

Both are all about leveraging viewport units to size type that doesn't jump from size to size at breakpoints, but gracefully scales.

I'd highly recommend checking out Mike Riethmuller's Fluid type though, which is nearly just as simple but allows for setting minimum and maximum sizes, which feels like the way to go for me.

I moved to fluid type on CodePen blogs recently and I love it. Notice we also stole Mike's fluid modular scale as well. As in, on large screens, the size difference between h1-h6 is more dramatic, while on small screens that scales back, all fluidly.

“Fluid Type” i̶n̶s̶p̶i̶r̶e̶d̶ stolen from @MikeRiethmuller now live on @CodePen blogs. Including “Fluid Modular Scale!” pic.twitter.com/0yJk8Iq8fR

— Chris Coyier (@chriscoyier) October 27, 2016

A "CSS lock" is how Tim Brown calls those minimums and maximums, and he demonstrates it can be useful for line-height as well as font-size.

That Fluid Type Stuff Again is a post from CSS-Tricks

I don't think most front-end developers are as comfortable as SVG as they should be. It's one of the most powerful technologies available on the web.

He makes a very strong case for inline SVG, which I wholeheartedly agree with. This screen from the video does a nice job of that:

You could do worse in leveling up your SVG knowledge than picking up a copy of Practical SVG.

Direct Link to Article — Permalink

Why Inline SVG is Best SVG is a post from CSS-Tricks

I’ve created this handy tool to help you say “no” to free and low-budget work and to help ask for more favorable contract terms before the start of a project.

Direct Link to Article — Permalink

Client Email Helper is a post from CSS-Tricks