Image padding and border issues with WordPress 3.9

Not saying this is the most copacetic way to do this, but for those who are desperate to have quick access to borders and padding, you can,if you choose, drop into ‘text’ mode and add the style attribute directly into the img src tag. It’s almost faster to type this in than to use the old text-box-update routine.

Yes, that’s what I did. But I’ve since downloaded a plugin (Advanced Image Styles) to handle it in future. Time is what I don’t have a lot of, which is why having the function in visual editor was so cool. I haven’t used the plugin yet, but I’m hoping it lives up to its good reviews.

It seems that most of the people who want to edit padding and borders on each image are fundamentally not grasping what @esmi is saying. This post explains the reasons more thoroughly: https://mor10.com/using-css-classes-fields-wordpress/

Excellent article — and responses. Thanks for sharing.

Sorry but that post doesn’t explain it at all I copied it and gave it to 12 of my clients who all said WTF. This rubbish about the right and wrong way is just that if you want to add css code fine you do that but 80% of users want to point and click. I don’t want to mess around with code I want fast and simple. What Esmi is saying is nothing but bull if it works and works successfully how the hell is it wrong!!!!. And as for Mortons explanation and instructions, Well typical developer to heavenly minded to be of any earthly use.

Oh, yeah! Removing a way to easily add an image border, and padding around an image, is a new WP “feature”. I catch that there is a right, and wrong (different) way of doing these things. I also catch that all the users (students/staff at college) that I want to give a useful communications tool to, that they don’t have to learn CSS or HTML to do some simple functionality, isn’t a step forward, but backward.

You can explain it all you want, but if a majority of users go, “Huh” then what have you gained? Less users.

I was surprised by this today and kind of annoyed but I get why they are doing it. Inline styling is not ideal so it’s better not to encourage it. At least, that’s my assumption as to why they removed it and other people have said the same thing.

I do see why people would rather have the option to enter the margins/padding for the sake of simplicity and maybe not caring about what is the “right way” to do things.

Instead of waiting for the feature to come back, I just created a bunch of standard image styles and pasted them into my CSS file. I have a CSS template I add to all my sites and will add this in. In covers most of the typical margins that I use.

.imgupleft {margin: 0 20px 20px 0;}
.imgupright {margin: 0 0 20px 20px;}
.imgdownright {margin: 20px 0 0 20px;}
.imgdownleft {margin: 20px 20px 0 0;}
.img20 {margin: 20px;}
.img20zero {margin: 20px 0;}
.imgzero20 {margin: 0 20px;}

You can add more to it like borders and paddings as needed. Then you just add the class name to the Image CSS Class field under Advanced in the image settings. After you memorize the classes, this should prove to be faster than entering manual margins in the box.

I’ll probably make a video of this since I’m sure I’ll be explaining it to clients.

But why is it not ideal what does it break?

https://stackoverflow.com/questions/3142710/inline-styles-vs-classes

It doesn’t break anything, but that doesn’t make it ideal.

webeminence if it doesn’t break anything what makes it so bad. I am at a loss to understand this . I thought WP was meant to be easy for those who didn’t want to or could use code to me it would seem they have lost their focus and are pandering to the developers who want more control probabily to sell their themes or services to folks who previously wouldn’t of needed them

Think of it the reverse way. Removing in-line styling from a part of WordPress core solves a problem for people who try their best to make the web more accessible by maintaining standards. Think of it from a business perspective, in-line styling can effect page speed and shock horror Google ranking.

WordPress is modular, so if you want to carry on creating web content in an inefficient way for ease of use, install the plugin that returns and actually improves the desired functionality.

I know that it doesn’t seem like it at times, but I want to reiterate that we DO ‘hear’ you all and I’m sorry if it feels like your voices haven’t been heard and listened to.

We hear the frustrations, we hear that hours upon hours can and have been ‘lost’, we hear that it has been a difficult time not just adjusting to these changes but also trying to pass on this adjustment period smoothly to clients as well who may be even less comfortable with the changes, and we also hear that this change to WordPress does not make sense in some ways.

It’s such an awesome thing – to have such a diverse userbase whose members can all say that they are a part of WordPress – but unfortunately as seen in an issue like this one, we also have instances where frustrations are coming in from multiple angles of the spectrum of people who use WordPress and are passionate about WordPress.

Personally, I’m an in-between user – a combination between the end-user who uses WordPress fairly ‘vanilla’ out of the box and a theme developer – and I would like to share my thoughts on the issue at hand.

Firstly, In-Editor Image Padding and Border Was, Indeed, Useful…

Even though I myself never used that function as I turn Visual Editor off, I HAVE handcoded inline styling for individual images outside of my normal CSS specifications and I have done it enough to see where this function could definitely be a time-saver and useful…

Especially if it was quick and able to be applied as needed per image per Post or Page and existed as a functionality that was once straight out of the box.

Perhaps what is most important to note and bold and underline is the phrase as needed per image per Post or Page.

And Here is Where the Arguments Happen…

Yes, CSS styling and within a stylesheet is possible and – for the sake of web standards – considered the ‘best practice’.

Web Standards is not something WordPress on its own decides but rather, the web development world at large.

Web Standards affects things like web browsers and how they render websites.

This in turn means that, to ensure that WordPress-generated sites render correctly now and in the future, WordPress (and TinyMCE which WordPress uses in its content Editor) needs to follow the ‘best practices’.

This in turn eventually translated into something like the removal of some native inline image styling via the Editor via TinyMCE and offering the functionality as a plugin, instead.

Why?

Because Web Standards has – for quite some time – said time and time again that inline styling is best kept to a minimum.

The rationale?

It helps to keep coding clean (which helps with not just rendering but also debugging) and helps to ease the ‘patching’ of broken sites if a certain style option becomes defunct (easier to patch a single CSS file than thousands of images with inline styling on a site, for example).

There are other reasons, but these two probably make the most sense.

And Here is a Reason/Viewpoint on Why the Removal of the Native Image Styling Function Could Have Significant Impact on Users…

Unfortunately, what CSS in stylesheets does NOT do ‘well’ (in my opinion) – without adding a lot of highly post-and-page-specific code – is customize styling on the fly per image per post/page.

For example:

Let’s say someone wants to stylize the images in Post 100 with a padding of 10 and a border of black and a background of dark grey to give the impression of the images being framed.

But then in Post 101, that particular ‘framelike’ styling is no longer necessary and instead, the background color needs to be changed, the padding thickened or thinned, etc.

Or, let’s say in Post 102, there is ONE image out of a collection of 10 that needs to be ‘framed’ nicely while the rest can just be as they are.

CSS is great… but it honestly is best used when it can be applied uniformly with a few tweaks here and there. Like, one style set for ALL images posted in posts… one style set for images in sidebars… and one style set for elsewhere.

If a website doesn’t follow that sort of predictable pattern then there is more specific CSS that is needed and soon, what was supposedly ‘cut out’ of the visible website coding itself (when you look at a site’s source code) is simply added bulk in the CSS file.

Additionally, this is slower than in-Editor editing (editing the CSS every single time an image needs to be styled differently) and it would need to be individually applied for every. single. person’s. WordPress install (for those managing other people’s WordPress installs, and nobody is going to have the same image styling preferences or habits!).

Yes, inline CSS can also be typed in as a person types posts… but then that leaves a lot of room for human error. Forget to close a tag or add a semicolon or add an extra space or something and you get a broken post/page/website.

The native function both addressed the two points above and also took care of the potential ‘ooops!’.

As such, it’s no wonder this function has been so ‘useful’ and so:

A Compromise Happened.

In this case, plugins.

For those who want a uniform way to style the bulk majority of their images, CSS within a stylesheet really is the ‘best’ way to go. It isn’t the only way to do it, obviously, but it really is the ‘best’ way.

Not because I say so or WordPress says so or anyone else related to WordPress says so… but because Web Standards says so and to ensure forward/future compatibility of websites.

It is less about ‘pandering’ to theme developers and more about the sheer necessity of following web standards – standards not dictated by WordPress but standards that more or less ‘rule’ the web development world which includes web browsers and how they render web-based code and therefore, websites… which includes WordPress-generated websites.

Additionally, going back to TinyMCE… TinyMCE is used in WordPress’ content editor (used to write posts and pages) and so part of this whole change is also a TinyMCE thing as well.

In TinyMCE4, the people doing the work on TinyMCE decided to make certain inline styling options less accessible saying that padding and the like ought to be handled in stylesheets rather than in inline styling.

For those who need more of the on-the-fly capacity to edit, the plugin will do the trick going forward as it brings back a functionality that TinyMCE themselves have moved away from (and likely will not return to).

It isn’t a ‘perfect’ solution and I know people are going to be understandably unhappy about it, but unfortunately, the issue is more complex than what it initially may appear to be and going forward, the plugin compromise seems best.

As a web developer and theme developer, I see where web standards take priority.

As someone who has managed a site and has helped others manage image-based sites where images in posts needed to be styled differently from post to post (one of my clients liked to use paddings and backgrounds and borders to create individual frames for their pictures and they didn’t always reuse their ‘frames’), I can see where the flexibility of on-the-fly editing would take priority.

There IS a place for both; it’s the harmonizing of the two that’s what’s difficult to manage at times.

I know that it doesn’t seem like it at times, but I want to reiterate that we DO ‘hear’ you all and I’m sorry if it feels like your voices haven’t been heard and listened to.

EMG, thank you for your thoughtful explanation.

EMG:

Well written and in someways I can almost agree with this however the problem isn’t us, and I have been around for many years in the field and at a time when hand Coding was the norm, but again you yourself are missing the point here, and although creating these in CSS can be easier for some it might not be that easy for the rest, and maybe just maybe WordPress should understand that and so should you of all people in this world!

NOT everyone knows how to use CSS like we do, and regardless of this we as developers and be stuck up either just because we know what we are doing and know how to fix the issue, but maybe just maybe it is time for someone to give options within the whole theme, or maybe a way of making these CSS rules easy for people to understand and fix. I have seen in cases where is people have an easy way to fix something that it should be that way, like maybe in the CSS editor in WordPress have a area to write these rules into the CSS without coding by hand, that is a great solution, but again as you stated it is all about the now and not the past.

Great job man!

Standards take priority? What about choice? I love how bandwidth availability is up ten fold, development technologies are 10x more efficient. NOW! We wallow around editing css for every image because someone or some group of somebodies decided it’s the right thing to do! Like they are saving the wold with web standards. What a crock, I’ve worked in web technologies for 15 years and I don’t get excited over web standards. Maybe I’m unique.

Thanks for the explanation… but it doesn’t make it right! I seriously can’t believe the WP dev team signed off on this. Clearly if they wanted it changed it would have been changed.

PS the plugin that everyone else is raving about doesn’t show up when I activate it. I’m running lucid and instabuilder among other things. Plugins are necessary for certain things NOT IMAGE BORDERS AND PADDING! After wasting an hour finding out in my case and many others this plugin fix doesn’t work, I’m off to waste even more time in the interest of the almighty web standards… SMH!

As web developers, this is really not all that complicated. It takes three lines of code to make a basic selector and then use it in your Image CSS class input box on the image properties form. I’ve already given a few of my clients a little document that allows them to easily configure their images using classes– and they understood it quite easily. It’s not rocket science. All this hoopla is almost embarrassing.

Honestly… WordPress is the (if not most) popular choice *because* of their adherence to quality of standards. The web has always been a place for convention. Without out convention organisations like Microsoft would have asserted even more obscurity than they have been allowed. Form and function is the mainstay of why WordPress is so easy to use in the first place. I would hazard to say that they should actually be congratulated for their steadfast insistence and unapologetic justification on this topic. I’m not about to cry because they took a couple of input boxes off the table.

Food for thought:
Of the thousands of posts here reporting display issues when a theme is changed or updated, I’d guess many if not most result from inline styling being applied. The simple truth is styling doesn’t belong in the database, which is where inline styling puts it, it belongs in the theme files.
That said, changing things with the old “Microsoft we know best” approach is never going to be popular. I think the solution is probably to have some sort of css generator that combines a tinymce type interface but outputs code to a stylesheet in the theme. It wouldn’t surprise me if someone develops one.