Adding Borders to WordPress Images the Right Way – a.k.a. Why Inline Styles Have No Place In Your Posts

As with most updates to popular software the 3.9 release of WordPress has brought with it some controversy. In this case the point of contention is the removal of a little known feature that allowed the user to add borders and margins (vertical and horizontal “space”) to individual images right from within the image editor. The feature was removed and not surprisingly those that used and depended on it are enraged. WP Tavern has a great rundown of the story complete with links to forum posts so I’m not going to rehash it here. Instead I’ll show you how to add borders to images the right way, explain why inline styles are to be avoided whenever possible, and finally provide a suggestion on how theme developers can prevent this type of issue from happening again.

How to Add Borders to Individual Images the Right Way in WordPress

So, when you have an image, you want that image to have a border, and your theme doesn’t apply a border automatically, what do you do? You add some CSS. And that CSS needs to be added separately from the content. In other words no inline styles.

Depending on your level of skill this may or may not seem like a big deal. I’m here to tell you it’s actually super easy. Let’s say you know nothing about HTML or CSS or anything else. Here’s all you have to do:

With your new CSS rules in place you are ready to apply them to your image. To do so go to your post, find your image, click the edit button by hovering over that image, and in the edit window click the Advanced Options tab to open the Advanced Options.

From here all you have to do is enter the class name for your CSS rule (“border-black” for black, “border-gray” for gray) in the Image CSS Class field and save your image.

If you want to add multiple classes you can. Just separate them with a space. Also, remember to not put the dot (punctuation mark) in front of the class names. This is not necessary.

If you look at the image above you’ll see it has a black border. This border was added using the exact method described in this tutorial.

Explanation

So what have we done here? First we created two new CSS rules that define a 1px border around any element that is either black or gray. Then we use the WordPress editor to apply those styles to our image through a class. And voila! The image has a border.

The key difference between this approach and that of adding the border with an inline style is that we can now quickly change the border on all images at once by editing the custom CSS. And since we used the Custom CSS function in Jetpack the border will persist even if we switch to a different theme.

Jetpack? You must be off your rocker Morten

At this point if you’re a seasoned WordPress pro you’re probably blowing a gasket over my recommendation of Jetpack. “Jetpack is huge and cumbersome and slows the site down and there are a million other better more awesome solutions etc etc etc.” And this is true. I am no fan of Jetpack. However we have to consider the end-user here: If you are using the add image border function you probably do so because you don’t want to tamper with your theme or child theme. If that’s the case, Jetpack provides an easy way around the problem. Of course if you have the skills and the time you can add the exact same code to your child theme or custom theme you built from scratch, but this is not a workable solution for the majority of WordPress users. Jetpack is.

Inline Styles are Bad, Mmmmmkay?

Some will interject here and say that you can achieve the same thing by using inline styles. After all that’s what the old solution did and what the new Advanced Image Styles plugin does. Here’s some sobering web standards news: Inline styles is a non-starter. To understand why you need to understand how HTML and CSS interact and why inline styles have no place in WordPress content.

There are two main types of code that go together to create a website:

HTML

CSS

The HTML marks up the content and tells the browser or other reader how different parts of the content relate to each other. The CSS adds a presentational layer to that markup telling the browser or other reader how to display that content. This provides a clear separation between style and content and it works exceptionally well, especially in applications like WordPress where we can switch themes (and with them the CSS) of the content and see a global change in the appearance of the content without having to change the content itself.

Inline styles are an old leftover from the time when CSS was just being introduced and they work counter to the separation I explained earlier. An inline style allows you to place CSS code inside the tag of any element meaning that style only applies to this singular element. That’s what a function like add borders and space does: It puts presentational code inside the markup.

Why is this bad? There are many reasons:

The inline style will apply everywhere regardless of where you display the content.

The inline style overrides any CSS supplied by a stylesheet and interferes with media queries and other responsive approaches.

The inline style applies to one element only and cannot be easily repeated (ie it has to be applied to every single element).

The inline style does not allow us to make a global change to the style that applies to all elements at once.

The inline style is presentational code placed in the markup. This goes against current web standards and should be avoided.

There are very few cases where inline styles are appropriate. The only one I can think of is where you use PHP to inject a conditional background image into a specific element, but even there we have better ways of approaching the problem. Needless to say inline styles have no place in WordPress, and especially not in adding borders or margins to images.

But what about margins?

I’m sure you’re itching to point out that my proposed solution only addresses borders, not “space” or margins. And you’d be right. Of course you can use the same approach as before to add margins as well but I have serious reservations about this which I’ll explain in a few paragraphs. However, if you must tamper with the margins I’d make sure to add them as separate CSS rules. I’m willing to bet that if you are adding custom margins it is because the positioning of your images out of the box is not ideal. So essentially you are fixing a layout problem in the theme. Chances are you also add different margins depending on the image, but you tend to add the same set of margins over and over. In that case you create a new CSS rule for each of your margin scenarios and apply them as necessary the same way we applied the border.

As an example you could have this margin rule:

.margin-medium {
margin: 0 1em 2em;
}

which adds a margin of 0px on top, 1em on left and right, and 2em on the bottom. Then to apply both the black border and the margin you simply enter “border-black margin-medium” in the Image CSS Class section for the image.

Now that you know how to do it I’m going to strongly recommend you don’t mess with the margins. This requires a bit more of an explanation:

The Problem

The problem at hand is not one of deprecated WordPress features nor of bad user behaviour. The cause of the outrage and frustration is that theme developers are not accounting for the user scenario where the user wants to add a border. When there is no option the user will find a new way of doing it outside of the theme and this is not ideal for anyone.

There are many reasons why you’d want to add a border. The most obvious one is if your image background color matches the color of your theme so there is no clear separation between the image and the main background. I’ve encountered this many times and this is why my themes ship with custom CSS to address this particular issue. More on that in a bit. Let’s first take a look at what happens when you add images to a post or page in WordPress:

When you add an image to a post or page in WordPress you also add some CSS classes to that image. The classes vary depending on the image size and alignment and other factors. A good theme has CSS rules that apply to these classes and provide proper margin and padding for all images. And this is why messing with the margins is a bad idea:

In a good theme the designer and developer has made decisions about how an image is to be presented in relation to other content based on its size and alignment. That means margin has been added where required and removed where it shouldn’t be. If you go in and start adding or subtracting margins you are interfering with what the theme does out of the box and this can lead to crazy behaviour, especially when you switch to a new theme.

Here’s the thing: If your images jam up against text or other elements in your theme it is either the explicit decision of the theme developer that they do so or more likely the theme is not all it’s cracked up to be. Yep, I said it: If your images look wrong in context, your theme is likely not worth its salt and you should look for another one.

The Solution: A Unified Border Class Name Standard

There is an obvious solution to this issue that will allow users to do what they want (add borders to images) while ensuring cross-theme compatibility while avoiding the addition of plugin functionality like Jetpack Custom CSS or plugins that add inline styles: Create a unified border class name standard.

All theme developers should add a set of CSS rules targeting a pre-defined list of border classes the user can call when required. The list could look something like this:

In addition theme developers could make rules whose colors are set through the customizer with class names like .border-thin-custom. That way custom colors can be introduced as the user switches themes while the predefined colors stay intact.

Let your voice be heard

I know you have opinions on this. Don’t internalize your strife. Voice your thoughts, concerns, and opinions in the comments below and start a conversation.

35 thoughts on “Adding Borders to WordPress Images the Right Way – a.k.a. Why Inline Styles Have No Place In Your Posts”

I wouldn’t argue about any of this if all WordPress users were coders…or if WordPress had provided some “warning” about this.

But the inescapable fact is that removing the easy but “incorrect” way of applying borders to images, with no warning or notice, is a low blow to millions of unsuspecting WordPress users who are never going to figure out what’s wrong.

It reminds me of some of the nasty tricks Adobe has pulled every once in awhile when they have (without comment) removed certain features from their applications, leaving thousands of users in the lurch, trying to figure out what happened.

If the WordPress developers were so hellbent on forcing everyone into compliance with coding “best practices” they should have written a “border creation” feature into the 3.9 update…rather than forcing non-coders to waste hours trying to figure out what happened to the feature they used to use…forcing them to use the bloated JetPack plugin, or forcing them to play around with code.

Keep in mind that a huge percentage of WordPress users came over to WP to escape the world of hand-coding.

I won’t have any problem figuring out the CSS for this, but it’s annoying to have to do that…and this whole this is…

Hey man, I agree with all of this. And I stated exactly that in the article. The approach is all wrong and the solution (adding the feature into a plugin) is not a solution at all. This is why I’m proposing a default set of CSS rules to be included in all themes. If we (the community) want to stay standards compliant (and we should) the work has to begin with the theme developers. Adding proper CSS for image borders takes all of 20 seconds and is a no-brainer. The only reason you wouldn’t do it was that you are too lazy, and if that’s the case… well…

I agree 100% that forcing the end-user to write CSS is a terrible idea. However there are many tutorials popping up right now that suggest the end-user insert inline styles, and that’s much worse because it teaches a non-standard method and it is destructive. Thus I provide a simple though not ideal solution and propose a more permanent change across all themes that can curb the problem while remaining fully standards compliant.

To be honest, as an end user, I couldn’t care less about developer “standards.” The arguments against inline styles don’t seem very strong to me; I don’t see anything destructive amongst the potential problems listed.

At the end of the day, is WordPress being built to actually be used by non-developers, or is it being built to impress developers with its adherence to “web standards?” Because if they end up losing end users because people can’t figure out how to do simple things, they’re opening themselves up to get replaced by a different platform.

My solution: let users choose whether to do things the “right” way or the “wrong” way (which as far as I could tell worked perfectly and never caused me or anyone else I know any issues).

The challenge here, Beau, is that while you couldn’t care less about developer standards, you will care a lot when poor implementation starts negatively impacting your content. Users shouldn’t need to worry about the application doing something improperly in the same way that you shouldn’t have to worry about other software like your tax software taking shortcuts that come back to bite you later.

Let me give you a real life example of why implementing solutions that are non-standard can become a huge problem down the road:

I started writing this blog many years ago. Over those years I’ve published over 360 posts, many of which contain extensive code examples. These code examples were added using a couple of popular plugins. Which it turns out is a huge problem because those popular plugins display code in an incorrect way. So while the code used to display just fine, with new versions of the plugins and new applications on my end they are no longer doing what they should and are instead destroying the code examples for the visitors. What went wrong here is that the plugin developer didn’t apply proper web standards but instead allowed code examples to be added in a simple but incorrect way. The result is that now that I have to display the code correctly I have to go back and change every code example by hand. That means editing over 1000 different code examples which is an enormous undertaking and something that would not have been necessary had the original plugin developer followed web standards.

The same can be said for the image borders and margins issue:

Let’s say you use image borders and margins on your blog and it looks great. Then you switch to a new theme that already applies borders and margins to images. Now one of several things will happen: Either you will see double borders and margins which will look terrible, or your inline styles will override the main styles on the page and your images will be displayed in a way that doesn’t match the theme and you will find broken, or in the worst case scenario there will be a serious conflict.

In all these cases you will first blame the new theme for being broken (it’s not) and then you will blame WordPress for not working the way you want it to. Meanwhile the culprit is the inline styles.

And it gets more involved than that: In a couple of months WordPress will likely ship with the new WPAPI which allows developers to pull content straight from WordPress and display it in new ways. This means we’ll see a whole new range of themes, plugins, and other WordPress-based solutions you’ll want to use. Think your WordPress blog on a watch or Google Glass or whatever other tool is coming down the pipe. This new approach will take the content sans theme and display it in the way that suits the device. Except when it comes to inline content. The inline content is tacked to the content itself and will carry along. So now you’ll have images with hard-coded borders and margins that directly interfere with the distribution of your content. And you are going to see this as an error on WordPress’ part and you will complain about it. So will thousands of other users.

To fix the problem you’ll have to either manually go back and remove the inline styles from all your images or you’ll have to employ some sort of code solution that scrubs your database and removes the inline styles. None of this is ideal and none of it is workable for the current user base.

The solution to all this is simple: Create proper standards-based approaches for adding borders and margins, and place a graphical user interface like the one we have now on top. For the end-user the experience doesn’t change, but the actual code output will not harm the user in the future.

This is a two-level conversation and the two levels need to be kept separate: On the one hand you have a discussion about user interaction and ease of application. On the other hand we have a discussion about back-end implementation. My article is about the back-end implementation and also serves as an explanation of why the old method and the new plugin are not good solutions. Your complaint is about the removal of the front-end solution which is separate. A new back-end solution can be created with the same front-end as before. That would solve your issue and solve mine at the same time and would also ensure that the end-user could trust that WordPress does what’s right.

I agree with practically everything, right up until the way you go about the final solution. The issue (and I don’t really have a solution, so this is more of a point I’d like to address than anything else) as I see it is that classes in markup should describe the content, not the way that content should be styled.

So adding a class of border-thin-gray isn’t as semantic as it perhaps could be. Consider buttons in the admin in WordPress. They don’t have styles of blue or white. They are primary and secondary. The classes describe the type of button, not the style of the button.

Perhaps – and this is only a perhaps – the solution is to go with something like border-primary and border-secondary. The, going further, those styles can be refined based on classes of something further up the DOM tree, i.e. a body class.

There’s pros and cons both ways, I just try and remain as semantic as possible.

Thanks for the reply Richard. While I agree with the semantic class argument in general, there are times when it is not sound to follow. WordPress already uses presentational class names like alignleft to solve similar challenges and from a user perspective I think descriptive class names that clearly state what they do (like add borders or margin) are the right path to follow here.

In this case the point of contention is the removal of a little known feature that allowed the user to add borders and margins (vertical and horizontal “space”) to individual images right from within the image editor. I wouldn’t say it was a little known feature when around 80% of WP user use it. and I’m sorry but you still haven’t given any good reasons why not to use it.

I question the 80% number you keep referring to. This is not a well known feature nor is it one that is often used based on my experience. Regardless, my article is not about the ability to add borders and margins: It’s about how this has been implemented behind the scenes and why that implementation is not good. As I’ve said in the article and elsewhere I am working on a different solution that outputs the correct type of code to solve the problem without causing all the problems outlined above. The goal is always to give the user control, but when that control is given at the expense of future development the user is being misled. That’s what is happening now.

I’ve used themes that have inline styles within PHP tags, so they can utilize the WordPress Theme Customizer. And, I’ve used themes that add a block of styles in the functions.php file for the same purpose. Great for non-coders, but a real pain for those of us who code. Too much bulky code.

I have never used the image attributes fields in WordPress for styling. I only use CSS. Because of this I generally use child themes whenever possible. Granted I, and others like me (you included, of course), have the tools and knowledge to edit our own CSS rules. Good for us. But for those who know nothing of HTML and CSS, they’re stuck with whatever tools are presented to them. Which means if the border and margins are removed from the Advanced options for an image, and they’re forced to add CSS classes, they will have some homework to do. Thus I understand the frustration.

But isn’t WordPress meant, not only as a tool for web presentation and web development, but also for community development? After all, WordPress itself is built by and depends highly on a huge community of like-minded individuals working to make life easier for the rest of us. I say, let’s teach those that wish to learn, and prompt those that are still a bit frightened of the acronyms HTML and CSS.

I think everyone will see that there are clearly two sides to this issue.

I understand standards. I’m a designer/developer. My clients couldn’t care less. During the transitioning between table layout and css, I lost jobs to designers who continued using tables. The client didn’t care. The client still doesn’t care. At least my small and medium sized clients don’t. My WordPress clients don’t care that inline styling is wrong. What the client cared about was that WordPress gave them the ability to edit their website and with a small amount of css knowledge, a lot of flexibility.

To the point of writing separate css style declarations, has anybody looked at the number of style declarations that the typical WordPress theme loads currently? style.css for twentyfourteen has 3125 lines (yes some are blank and it all could be compacted) and then add the other style sheets plus a child theme stylesheet, sheesh — that’s a lot of css declarations. And, I’ve seen plugins that offer more control to the end user and what they do is write the custom styles between the so every page has to load them everytime (the client is concerned about page speed!). Plugins like this are not great.

It’s hard to argue against standard based but it is frustrating for the saavy WordPress enduser who wants full control of their website text/images and know’s just enough css to make spacing and border edits so the page layouts look like they want them to without wading thru code/creating stylesheets.

Thanks for the input dgallek. In an ideal world the style rules I’m proposing would be hidden behind a simple UI for the end user. Or handled in a more simplified way. My point in writing this article was not to tell all WordPress users to learn CSS but to tell WordPress users looking for a workaround that a) there is a reason the feature as it was implemented was a bad idea and b) don’t listen to the people who are telling you to hand-code inline styles into your content. If you do a search online you’ll see tons of people including several WordPress authorities explaining to users how to write their own hand-coded inline styles to bring the borders back. This is not only a terrible idea, but it’s more complicated than my approach. The interesting part of this is that no one brings up complaints about overcomplicating things on those articles.

I’m with dgallek. While I hear a lot about the developers needs, the MOST “bread and butter” important portion of the developers need has been ignored: we build sites for CLIENTS who are not as versed and prefer the simple, no-nonsense way to add images. “Woops! The image is stuck on the text! OK, I’ll add this little number here: 5. Saving…. There… ! Now that’s better.” Time elapsed: 45 seconds.

By taking this feature out, you are surely going to make a lot of gurus happy. But the bulk of your clientele and users are not gurus, they are people who love WP for it simplicity. And our clients only want to know this:
– it will look good and be easy to navigate
– they will be able to go in an continue building their site without needing to pay anyone to simply place a padding around an image

I am in the throws of a project of a site with over 700 pages, to bring from 1995 HTML to 2014 WP. How do you think I felt when I went to create a space around an image to better present the text? Now I have to find a way to give my CLIENT this ability via a plugin or some other method that will make this as simple as possible for her. She is 70 years old.

So when you think about this globalization, standardization and democratization of WordPress, I would suggest maybe listening to those who complain about the loss of an important feature used EVERY DAY by their clients. We’re not whiners. We have boots on the ground and know what we need.

This being said, I do appreciate all the marvelous features WP offers, however I do believe that this one is a big mistake. Somebody will come around and fix it for you, BECAUSE IT IS NEEDED. So if anyone knows of a plugin to restore this function/feature, please share. I can’t fathom having to look for a different CMS, so much work has been done now. But I need to keep my promise to my client: she will be able to edit her site and add content, including images. Without them looking like the person doing the site has no idea how to put inline code…

You do realize we are in agreement, right Andre? As I’ve explained both in the article and in comments, this post was written specifically to address a) the reason I think the removal of the feature was correct, b) all the tutorials that tell the end-user to write inline CSS in HTML by hand (a terrible idea that is not user friendly at all), and c) what we can do to fix the problem. My proposal is to create an interface that makes sense for the end-user while at the same time outputting proper HTML and CSS. All I care about is the end-user. That’s why I teach WordPress and that’s why I teach WordPress developers to follow web standards so they don’t put the end-users in this impossible situation.

Furthermore this has nothing to do with “developer needs”. This has to do with web standards which is what makes the web work. Following web standards is beneficial to the end-user. Not following web standards hurts the end-user because search engines etc de-rank content that is not marked up properly.

You could also just create the CSS to automatically style images properly, so all your client has to do is write the content, upload and image, and call it good. Isn’t that the whole point behind using WordPress to develop a client’s website? So they don’t have to worry about adding the proper styling with a cumbersome process that asks them to know what 5px is vs 50px? And remember that property so they can apply it consistently across the website?

I would even say the use of classes, as described in this article, falls short in the same way. The end client will end up having to remember to upload the image, insert, what custom class they need to assign it, and then assign it.

I re-read your post and have to apologize as I was more focused on the negation of the feature than the solution you offered, which involves Jetpack. I never used Jetpack actually, but will look into it.

No worries buddy. This is a hot button issue and people have opinions. That’s the whole point of comments. In the theme you are looking at right now I’ve included border styles for black, grey, and custom colors so all the user has to do is add the correct class names border-black, border-grey, or border-custom to an image to get the border required. That’s the way it should be done and it would be easy for theme developers to include these rules in the theme styles.

I can just about stomach (through gritted teeth) the idea that CSS is a better way to do inline styles, but what really irritates me beyond belief is the new “supposedly improved” visual way of resizing images. It seems to be premised on the idea that ad-hoc resizing with a drag and drop is a better way of doing things than precisely stating the number of pixels.

In reality all that does if you need precise sizing is either force you into manually cropping/resizing something in a graphics programme, or editing the html (i.e. the exact opposite of what this supposedly “easier visual editing” approach is intended to achieve). As a consumer I no more care about the reasoning behind it than I do with any other inconvenient service – if I go in a restaurant and get a bad meal I don’t run through all the many reasons why it might have made sense to cook a meal in this way, I stop eating it and go somewhere else.

Excellent post, thank you. I also made the mistake to adjust each image individually with the style option. I’m not a programmer but maybe you can help me with this: I placed a border around each image with this code:
style=”background-color: #f1f1f1; border: 1px solid #e2e2e2; display: block; height: 160px; padding: 5px; margin: 0px 15px 5px 0px; width: 160px;”
Now I’m supposed to figure out what the CSS style code is and thats where I’m lost. Do you know the CSS code which I can paste in the CSS Style sheet editor?

Then you apply the custom-image class to the image and it kicks in. That said, the code you are applying is pretty restrictive and will force a theme override. If you need to do this you should probably consider a new theme.

Come to think of it, I do have a question. I have a one-off image that I wish to create a border around in a single post — http://atelieremmanuel.com/steampod-heat-styling-without-compromise/

I use Suffusion theme, which has a “Custom Includes” section for custom css. I imagine that this serves the same purpose as using Jetpack? And, I assume I can add a new class to do this:

.border-blue {
border: #1ea8e1 solid 1px;
}

But, as a non-coder, it seems an odd practice to me, to be adding code like this for one-off instances. Like, if nothing else, if I keep having to create all this coding for one-offs, it will make my theme’s Custom Includes cluttered.

Is there a way to add the css to the post itself, and is that an okay practice?

sir i m a muslim and i wanted to be the wordpress expert and i m doing bechor degree in information technology i have downloaded your tutorials (essential training for wordpress) from lynda.com those are not enough i have joined a session of wordpress but they are also teaching basics i need your tutorials from begginig to last including html, css, js, jquery of wordpress your tutorials are very best plz help me and reply me or give me any link to download your tutorials about training wordpress

While I agree with 99% of this, and was not sad to see this feature go away, I must say that inline-css isn’t as horrible as you make it sound. The ideal solution would be applying a global style in the themes CSS stylesheet, to maintain a consistent appearance, and in my experience reduces the chances of a client mucking stuff up after the fact (if we style things correctly, all they have to do is add the image, instead of worrying about adding classes, or inline-styling).

And while the use of a second style sheet might seem like an equally ideal solution, it is not completely true when we are talking about a single or even a multiple tweaks.

In other words, the weight of a new CSS stylesheet, another HTTP request, etc. is much worse than the ill effects of having some inline CSS styling in the HTML. Not ideal in some ways, but a single or even a couple instances is much better, big picture, than adding another HTTP request for 3 lines of basic CSS code.

Google PageSpeed even recommends inlining CSS, albeit in the head section, and dynamically by the server so you have on the backend an HTML file and a CSS file, then the server inserts the CSS into the head in place of the link, but none-the-less, it loads faster, and renders faster.

I agree with all of this Patrick. The ideal ideal solution would be to build some sort of system that allowed the image editor to generate inline (head-located) styles that are tied to a specific page or specific image. That’s pretty complicated though. The separate stylesheet solution is the absolute fallback when nothing else works. Ideally the whole issue of image borders should never happen to begin with. A theme that forces the user to arbitrarily add borders is a theme that doesn’t account for realistic usage imho.

Great post Morten! I’ve been going through some of your videos on Lynda and it’d be great to have a video series dedicated to HTML/CSS coding with WordPress like the example above.

One thing, though, how would I go about applying text on top of the image by using this method? I know how to do this by using div tags but where would I need to insert my h2 tags in the HTML code for example?