Plugin styling

Bloke · 2010-10-06 09:49:57

One of the things that bugs me a little about developing a plugin is how to go about styling it. Everything works very well under the default themes but when you start installing new admin side themes, things often begin to fall apart. The stylistic choices made when the plugin was developed may simply not be suitable for the new theme.

There are a few current avenues, in order of most-to-least ideal:

use existing styles names and hope they exist in the current theme
allow the plugin to install a proper Presentation->Style sheet which can be altered by users
hard-code a <style> block in the code
in the hard-coded style blocks, use explicit attributes for every rule in case something else has overriden them (e.g ALWAYS specify a fg colour and a bg colour and a font size, etc in any custom rules)

Option 2 is more visible than Option 3 and doesn’t require hacking code, but still means you have to modify the sheet if you change theme. Option 3 is pretty nasty, but is the simplest to implement in code, albeit the least flexible. Option 4 is virtually guaranteed to look the same on all themes but it won’t gel with them.

Aside from guaranteeing the availability of core style rules, the trouble with Option 1 is twofold:

the mantra is that we should employ our 3-character prefixes wherever we can in plugins to avoid name clashes. But CSS is a little different because it makes more sense to re-use style rules than create new ones
quite often the default style rules are prepended with an HTML tag or DOM node ID so you need to use the same tag in your code (or use your own if the rule employs a unique ID). Thus you are often forced to create your own rule and thus need to prepend it with your prefix in case the core (or another plugin) later uses the same rule name

Perhaps if the core rules were a little more generic (e.g. there was a ‘.active’ rule and a ‘.hover’ rule which simply set up background and foreground colours) then we might be able to offer some style guidelines for plugin authors to say which rules are available for general use. This might cut down on the need to use custom rules, and theme authors are more likely to include these generic rules in their theme stylesheets if they’re widely known and used: who’d deliberately make a theme that didn’t work with most plugins?!

But is there an alternative to all this? Or at least something that runs alongside? My radical thought of the day was to (ab)use the Textpack concept and treat ‘CSS’ as a language. As an example, if a fictional Textpack contained a special code, e.g.:

#@style
#@default
.smd_something {
   background:transparent;
}
#@theme vitraux
.smd_something {
   background:black;
   color:#ffc;
}
...

Then it could install this block into a dedicated area (table? as a preference?) and the relevant rules automatically get loaded when a particular theme is active. If a dedicated theme ruleset doesn’t exist, the default rules are used and if no rules are defined you get the ones in the stylesheet and ultimately the browser’s set.

I’m not proposing that we hijack Textpacks like this, but the sentiment is similar: it’s ‘localisation’ of content based on the current environment; the environment in question just happens to be visual rather than textual. If such a system existed, theme or plugin authors could distribute Stylepacks with their themes/plugins, or people could create their own to support the current look ‘n’ feel of their admin side.

While the best practice might still be to work towards a common set of style rules and advocate their reuse as often as possible, there are times when custom styling is unavoidable so we need a way to manage this simply and cleanly.

Bottom line is I don’t know how best to go about this but there’s a nagging sensation in the pit of my brain that is telling me there has to be A Better Way™ of managing plugin/theme interaction from a style viewpoint.

If anyone has any thoughts or ideas on this topic, please share. Even if it’s to propose some core rules that would be beneficial to have in TXP 5’s default stylesheets that we could all use and thus become some sort of TXP standard naming convention. Thanks in advance.

Last edited by Bloke (2010-10-06 09:58:47)

jsoo · 2010-10-06 10:34:15

Bloke wrote:

Perhaps if the core rules were a little more generic (e.g. there was a ‘.active’ rule and a ‘.hover’ rule which simply set up background and foreground colours) then we might be able to offer some style guidelines for plugin authors to say which rules are available for general use. This might cut down on the need to use custom rules, and theme authors are more likely to include these generic rules in their theme stylesheets if they’re widely known and used: who’d deliberately make a theme that didn’t work with most plugins?!

I think it’s as simple as that. Make it easy for plugin authors to use common style rules, stick some guidelines on the Wiki, encourage admin theme authors to be aware of plugins. Encourage plugin authors to use the common rules whenever possible, and to propose new (but generalized) ones as needed.

Bloke · 2010-10-06 10:53:37

Oki doke. I’m all for keeping it simple. Any starter rules to kick things off?

The default textpattern.css needs a makeover and some simplification and will need to be revisited anyway with the new default admin side markup. I guess theme authors will know which rules they use or override most often and which can be safely genericised, and plugin authors will know which actions/widgets they have to keep making custom rules for.

jsoo · 2010-10-06 11:26:26

Most of my plugins are public-side so I’m not that familiar with the backend markup/css. I should think the main problem of theme/plugin conflicts is with colors. Also, admin-side plugins often have specific needs for layout. So I think we get the most compatibility benefit by convincing plugin authors confine custom style rules to layout and to use Txp class names for font/color/background styling.

thebombsite · 2010-10-06 22:27:41

I’m with Jeff here. I can see the obvious point of positional styling being within the realm of the plugin’s styling but when it comes to colours, backgrounds, hover and active states etc. I believe those are within the realm of the theme’s styling. When a new admin theme is developed designers are generally re-styling “id” and “class” hooks that already exist within the “Classic” or “Remora” themes and in the future there could be a third default theme to work with. The 2 existing themes both use the same hooks and thus so do the new admin themes that are being developed from them, except within the header and end_page blocks where major changes can be made via the .php file.

Plugins however do not sit in the header or end_page blocks so should not be affected by any changes made here by the theme. They exist within the main content area of a page and for the most part are not actually adding anything that doesn’t already exist somewhere else such as an input of various types, a select, a textarea, a header, maybe a paragraph, maybe an expanding block. These all exist within the default themes and, apart from any positioning aspects, they should take their styling from those themes or any installed theme.

Now I should say here that most plugins work just fine regardless of which admin theme is applied however there are instances where a plugin requires something completely unique to itself. As an example I cite Stef’s own smd_admin_themes plugin which, on it’s grid page, requires some pretty unique HTML. I doubt it would be possible to add appropriate “default” hooks to the mark-up to allow it to be styled correctly by whichever theme is being employed. In such circumstances I would be in favour of the plugin inserting it’s own style block. This would allow users to modify the plugin to suit the theme they are employing. Having said that, such a method is something I would personally be quite comfortable with however I am aware that not everyone would be as comfortable as I with modifying plugin code so I’m not sure that it could be a final solution, but what if we could get plugin developers to put this style block right at the top of the plugin code, or at least just below the “if (@txpinterface == ‘admin’) {}” block, so users don’t have to go searching for it? I’m not a PHP guru but can a style block be a function that can be called later on in the code?

Plugin styling should be transparent. They should employ “id” and “class” hooks that already exist wherever possible. Apart from positional aspects and unique HTML blocks, styling is not their prerogative. That rests with the theme and developers should concentrate their very welcome efforts on ensuring that their plugins work correctly, safely and do everything they say they do and for that we would be most grateful.

Textpattern CMS

Textpattern CMS support forum

#1 2010-10-06 09:49:57

Plugin styling

#2 2010-10-06 10:34:15

Re: Plugin styling

#3 2010-10-06 10:53:37

Re: Plugin styling

#4 2010-10-06 11:26:26

Re: Plugin styling

#5 2010-10-06 22:27:41

Re: Plugin styling

Board footer