We don’t always realize how much we’re actively learning in our day to day work. We’ve gotten so used to the daily grind of web development, that perhaps finding answers to “gotchas” or successfully troubleshooting a problem, is something we celebrate with a fist bump in the air before we move on to the next thing. What helps me keep this blog going is taking a few seconds to write those discoveries down in a draft. While small, each new bit of knowledge levels me up. I want to share some of those with you today as quick WordPress tips.
The great thing about these 10 quick tips, are that they can be absorbed in this one read. No in-depth tutorials, no lengthy explanations – just small bits of knowledge that hopefully help you grow the same way they’ve enabled me to grow.
Half of these tips are for HTML or CSS, the other half, WordPress functions that I’ve found handy during front-end development. Let’s start from the quickest tips down to ones that require a little more explaining.
1. Resize property for textareas
Did you know there’s a resize property in CSS to prevent the user from re-sizing a textarea? By default, browsers have this little handle on the bottom right corner of textarea fields that users can drag to make it larger, regardless of any width and heights you’ve set via CSS. This can potentially break the layout of a site and since I’ve been heavily into developing forms lately, this discovery made all the difference. While it seems like such a small thing, it was something I didn’t realize I needed until I did. You can set it to all textareas or target a specific one.
textarea {
resize: none; //user can't resize textarea
}
2. The difference between bold and strong tags
Accessibility has caused me to really think twice about the HTML that I write. I’ve seen the HTML tags for bold and strong being used interchangeably. It finally occurred to me, is there a difference? After all, don’t they do the same thing? Turns out, there is a difference and it’s pretty important to how I apply these tags in the future.
I credit a Stack Overflow question for enlightening me. While both visually increase the weight of a font, the bold tags are meant to be used as a style. Whereas strong tags, are used for semantic purposes regardless of a font’s weight. The same way headings create structure in a document for screen readers, regardless of their font size, strong tags communicate that the words are important. After all, font weights and any visual effect don’t mean anything for screen reader users. It’s the HTML that helps organize the content of a webpage for them to read.
So in the future, bold tags for visual effects only, and strong tags for semantics, regardless of the font weight. The case for italic and emphasis tags are the same, the former for styles, the latter for semantics.
<p> This <b>bold word</b> does nothing for semantics and a11y, but the <strong>strong word</strong> does. </p> <p> This <i>italic word</i> does nothing for semantics and a11y, but the <em>emphasized word</em> does. </p>
- MDN’s definition on the <strong> tag.
- MDN’s definition on the <b> tag.
- MDN’s definition on the <em> tag.
- MDN’s definition on the <i> tag.
3. No pseudo classes in <video> tags
I was trying to style an HTML 5 video tag recently and tried to use the :before and :after pseudo classes. It didn’t seem to work at all, and a quick google search confirmed that they aren’t supported in video tags. Something to be aware of in the future if you ever need to style videos using these tags. WordPress uses video tags in its video shortcodes.
4. Arrays in WordPress conditional tags
I love using WordPress’ PHP conditional tags for a variety of things. These conditionals can be the difference between which template part to load depending on whatever I want – custom post type, post format and so on. I’ve recently realized there was a neater way to use them. Below is an example of how I used to write them in a template, versus the better way.
<?php
//How I used to write it:
if ( is_page( 'foo' ) || is_page( 'bar' ) ) {
//load template part here
}
//How I write it now:
if ( is_page( array( 'foo', 'bar' ) ) ) {
//load template part here
}
Turns out you can use arrays in the WordPress conditional tags, like this example for is_page(). It’s the same as using the “or” symbol except neater. So if the page has a slug of “foo” or “bar”, the condition will be met in the examples above.
5. Adjacent sibling selectors in CSS
As I’ve mentioned earlier, I’ve been working with a lot of forms. Way. Too many. Forms.
There was a design I worked off of that changed the color of the field labels based on whether or not the fields were focused on, valid, or invalid. CSS tricks has a great article on form validation using selectors like :valid and :focus. Styling the field was not a problem, but the label was tricky. It was then that I discovered the adjacent sibling selector that lets me target a sibling directly after another element. In my case, the label and field were direct siblings.
However, I had the label placed before the field in the HTML. Since the adjacent sibling selector targets a sibling after it’s previous element, I had to switch them so the label was physically after the field. Then I used CSS to make the label appear as if it was above the field. Here is a stripped down HTML/Sass example:
<form> <fieldset> <input type="text" id="example-field" class="field-class" name="example-field"/> <!-- CSS will target label below --> <label for="example-field">Example Field</label> </fieldset> </form>
.field-class {
&:focus {
& + label {
color: blue; //focused field = blue label
}
}
&:valid {
& + label {
color: green; //valid field = green label
}
}
}
Using the sibling selector then allowed me to change colors, font weights, or whatever I needed on the label depending on the state of it’s associated field. Cool, huh? CSS for positioning the label above the field are not included in the examples above.
6. Negation pseudo class in CSS
I learned about this pseudo class about a year ago and I have loved it since. It’s also compatible down to IE9 if you’re a poor, unfortunate soul who still needs to support IE9 (points to herself).
It’s a way to write styles for a selector, but you can specify to exclude based on class or id. I like to use it for things like fixed/sticky headers. The header is not fixed until the user scrolls past a certain point, and then a class gets added to apply styles to the fixed header. Using the negation class helps me organize my CSS into styles that apply to both cases, styles for the fixed header, and styles specifically for when it’s not using the fixed class.
//Sass example
.my-header {
width: 100%;
height: 200px;
background-color: #fafafa;
color: #000;
a {
color: inherit;
}
&:not(.fixed-class) {
position: relative;
}
&.fixed-class {
position: fixed;
top: 0;
left: 0;
background-color: #414141;
color: #fff;
}
}
//how to chain in Sass
.my-div {
//This one works
&:not(#special-div-one):not(#special-div-two) {
background-color: green;
}
//If the above CSS was erased, this one works however...
&:not(#special-div-one) {
background-color: orange;
}
//This one won't work, it will get ignored
&:not(#special-div-two) {
background-color: orange;
}
}
Now if you need multiple cases for the negation class, chaining them can be tricky in Sass. It took me a few tries to find what worked and I’ve also included that example above. You can’t put multiple classes or ids in one negation class. If you try to separate them and use the ampersand in Sass, it will ignore any after the first. So it’s one ampersand per chain of negation classes, one negation per class or id, and no quotes inside the parenthesis.
7. Trim Excerpts and Titles
If you google how to trim excerpts or titles in WordPress themes, you’ll likely get several results ranging from using hooks and/or preg/string replace solutions. Having content that is too long can interfere with the site’s design and I’ve had to use the aforementioned solutions before. Turns out, WordPress already has two functions built in to trim content by word count, wp_trim_words() and wp_trim_excerpt().
<?php echo wp_trim_words( get_the_title( $post->ID ) ); ?> //or escaped version <?php echo esc_html( wp_trim_words( get_the_title( $post->ID ) ) ); ?> //trimmed excerpt doesn't need parameters //assumes you're in a WP Loop <?php echo wp_trim_excerpt(); ?>
They are handy if you don’t need to alter the length of titles/excerpts site-wide, and if you’re okay trimming with word count instead of character count. The excerpt trimmer is a bit tricky since it only works inside a WordPress loop and is meant as an alternative to get_the_excerpt() or the_excerpt(). The word trimmer can be used in or outside the WordPress loop. Also, if you want the “read more” for excerpts, even when trimmed, then using wp_trim_excerpt() is not the solution. It trims the content and appends it with ellipses, while not offering parameters to customize.
8. Dynamic font size with viewport units
I’ve been working on a site that has imported content with very long titles. The client wasn’t a fan of cutting off titles by character count or changing them completely to fit design. Since trimming the titles weren’t always an option, and setting heights or hiding overflows can only go so far with CSS, I needed something else, but what?
Enter the viewport unit solution. Turns out it was just what I needed and while it wasn’t a site-wide change, tackling specific cases with viewport units work well. Since I’m writing Sass for the project, I used a Sass mixin for viewport unit font sizes by Eduardo Boucas. I realized the caveat to using viewport units was being unable to set a min or max font size. The Sass mixin linked to above, resolves that issue.
9. Crop positions for custom image sizes
Setting custom images sizes in WordPress can be a great way to ensure any feature images on the front-end stay in line with design. I’ve been using them for a while, but I haven’t always known that there was a parameter to control how WordPress crops the image. Here’s an example pulled from the WordPress developer reference:
//That last array? That's where the magic happens add_image_size( 'custom-size', 220, 220, array( 'left', 'top' ) ); // Hard crop left top
By default, if the crop parameter is set to true, WordPress will hard crop an image by trimming it down so the center of the image is the focal point. Depending on the design, you might not always want that and can therefore change that behavior by using an array with the position. It can be hard to visualize how the cropping happens, so I tend to revisit this tutorial from David Coleman that comes with handy diagrams. I find that setting crop behaviors takes custom image sizes that extra step I need for front-end perfection.
10. Properly enqueueing IE only stylesheets or scripts
Some hospitals, banks, schools and financial institutions may hesitate to upgrade their browsers due to security concerns and it’s often not left to the individual employee whether or not they can upgrade. This is where supporting older versions of IE come into play. The most recommended way to include IE only files are by using HTML conditional comments, however Microsoft has dropped support for them for IE10 and up.
Luckily for us on the front-end, most of what works in major browsers will still look good in IE10 and up or degrade gracefully. Now IE9? Conditional comments all the way.
In a non-WordPress site, HTML conditional comments go directly into the site files. We don’t want to do that in WordPress as it’s considered hardcoding. The Codex actually recommends putting conditional comments directly into your theme’s header.php file.
Don’t do that.
We can enqueue IE specific files just like we do with all of our other files, except here we can make use of the wp_style_add_data() and wp_script_add_data() functions. You can enqueue your stylesheet or script normally, and use one of the above functions after. These two functions insert the HTML conditional comments for you without the need to hardcode into template files. Here’s an awesome tutorial on enqueueing WordPress files from WP Scholar.
In a nutshell…
While all of these tips were not solely WordPress, they’ve helped to level up my work one way or another. Most of these solutions pertain to making the site look good. Whether it’s properly enqueueing an IE stylesheet, writing neater PHP conditionals, learning some CSS selectors, or trimming WordPress content, I hope you found these quick WordPress tips helpful for your current and future development.
Have any of your own? Feel free to add them in the comments for others to pick up. Until next time!
Be First to Comment