Writing CSS in WordPress isn’t much different that for a static HTML site. The main difference is being familiar with how WordPress dynamically outputs classes and why. There’s a saying that I like about CSS and writing code for websites. Make it classy.
For example, if you style a widget, using the ID of the widget to style is an issue. That ID can change after deployment, as a result of updates, or because of internal page changes. If that happens, your CSS will no longer work. Here’s ehat I mead by styling using the ID:
<div id="nav_menu-3" class="widget widget_nav_menu"> – the ID “nav_menu-3” is a dynamically generated ID. Don’t style with these. The #3 means it’s the 3 entry in the nav_menu function in the Database.
Instead, create a class on the elements you want to target and your code will scale as your site continues to grow and change. That said, here are some ideas and practical tips on good CSS coding.
Selectors
Ref: https://en.support.wordpress.com/custom-design/css-basics/
There are three kinds of selectors. First is a “tag.” A “tag” is an HTML tag such as an <h1> or <p> for paragraph. Second is a “class.” A “class” is an attribute of one or more elements. These can be used multiple times like class="class1 class2" in a selector. They are referenced in CSS with a “.” before them. Third is “ID”. An ID is a attribute of a unique element. They should only be used once per page and are referenced with a “#” in the style sheet before the element.
Here are some examples.
HTML tag selector:
<p>Sample paragraph.</p>
HTML tag selector CSS:
p {
color: red;
font-size: 200%;
}
Watch the ID’s (not the CSS ID’s)
Earlier I mentioned styling your code using WordPress ID’s. This dangerous and not reliable as they are dynamically generated. In fact some plugins generate them on every page refresh. Thus making it impossible to write CSS to style a page. If you are using WordPress ID tags, stop now. Instead, as I said earlier, “make it classy” by adding those classes.
Bring order from chaos
Imagine a chaotic world where your foot can sometimes be called your head. And in other places your head is called your foot. It’ll leave you scratching your foot… or head. It’s called order of declaration. So when writing CSS watch the order. Don’t style anchor links with the :hover before the static selectors. And using !important should never be used unless you know what you’re doing.
Commenting
Next time your downloading WordPress take a look at the code in core. You’ll find that each function is extensively commented inline and refers to versions and where it’s used. That’s because out of the hundreds that use WordPress, there are equal amounts of people that develop on it. No one is a mind reader or can trace back to what a anonymous selector meant when it was written.
Without that rosetta stone in the code, you are not a considerate designer. Remember, the person behind you cannot collaborate and follow up on the work if there is a revision. Comments in CSS look like this:
/* this is a comment */
Spelling and what you name selectors
Proper naming to CSS selectors is paramount to ensure follow up for your team to code along. Additionally, it’s bad to always use a single piece of information to style everything. But that’s a rabbit hole for later to dive down into. Naming a selector to whatever comes to your head should be avoided. Instead, follow proper standards followed that are set by the team. If a name cannot be chosen quickly, then see my previous point, and leave a comment. It’s the nice thing to do.
Use name spacing for your selectors
Name Spacing refers to corralling the CSS or code written to only affect the elements and functionality in your plugin, module or page. Unfortunately, in WordPress not all plugin authors follow the rules. So if you activate a plugin and notice your theme looks different, the problem can often be traced back to a plugin. This can happen because plugins have CSS too. A button style in a plugin may not be named spaced and thus, change your buttons styles. Both the theme author and plugin author should style according to their theme or plugins name.
For example: button is a selector that can be used without a class or ID. Thus, you’ll simply see “button” (without quotes) in your style sheet. To name space you should find .my-button {styles here} in your theme or plugin to avoid clashes.
Finally
In a perfect world a plugin can never interfere with the theme’s styles, and themes don’t make the task of writing styles for a plugin harder than it should be. But in reality, a vicious circle exists where plugin authors have to write extremely inefficient CSS selectors. They do this in order to overcome badly written theme styles. And in turn, theme authors that try to override global rules that plugins introduce in their stylesheets.
Writing CSS is nuts, and it’s not as easy as you think. That’s why it’s best to hire experienced coders and not ones that can’t answer the difference between margin and padding in CSS. Hint: One is for out, the other in. And I don’t mean your belly button. Also experienced coders that know WordPress don’t, and shouldn’t, rely on plugin page builders. There is fundamental knowledge available in the WordPress Codex about page templates and their order. But more on that in the next post.
If you like this post, please share and leave a comment.
