A lot of my WordPress consulting work involves scripting with CSS. CSS is relatively rudimentary but extremely powerful. I was thinking about what makes CSS (and many other scripting languages) such fun to work with. For me it comes down to a select few items:
- The ability to very quickly create a new Website look.
- The limitations of CSS that encourage ‘lateral’ thinking.
- The evolving nature of CSS that creates new challenges to solve.
Limitations of CSS and Troubleshooting
Focusing on the second item above, the creative and problem-solving necessity that CSS presents I thought I’d provide a real-world example.
I recently blogged about the frustrations with the !important CSS declaration being used in WordPress Themes. Sometimes the !important declaration can make certain styling changes almost impossible but, occasionally, it’s a great way to really think out the box; I recently had a client using the Avada Theme purchased on Themeforest. The client wanted quite a specific look that required various new functionality and styling. Functionality was implemented using existing available Plugins and quite a bit of CSS scripting was needed for the styling.
It very soon became evident that the dreaded !important has been used very extensively by the Theme developer. This makes custom styling with CSS a challenge (which in turn takes time) which raises costs for the client. As a specific example of having to use laretal thinking to get around CSS limitations (in this case it isn’t actually a CSS limitation but lazy scripting by the Theme developer), the H3 style of a widget inserted via a Plugin had a bottom-border specified in the Theme CSS with the !important declaration. There seemed to be no way to change the declaration to border: none; because of the !important. It also wasn’t feasible to change the Plugin HTML to insert a different style (as upon the Plugin update all changes would be lost). The solution … don’t try to define the border-bottom declaration to be border: none; but just change the border-bottom-color to transparent.
How to tell the client that they are using rubbish coding
I really cannot say enough times how important it is to only use well coded and standards compliant Themes and Plugins (using poorly coded Plugins and Themes will cost you more in the long run). My recommendation is to only ever use Themes by suppliers listed on the WordPress Commercial Theme portal. Fortunately, in the example above, the client was technically astute and understood the problem. He had a deadline for the Website to go live so a change of Theme to a better coded one wasn’t viable. As a Website developer it isn’t usually simple to have a client understand that, because of them buying a badly scripted Theme (or Plugin), it is going to cost them a whole lot more to have customisations done on their WordPress Website.
I digress into one of my rant about poor quality coding and scripting so back to the topic at hand; the fun of CSS scripting …