Arrggh! Don't overdesign templates

[svasti]

Just putting together a new plugin and I find that in some of the bundled templates the template-css simply goes too far.

Take for instance "structure1_black"

Code: Select all

img {...;vertical-align: bottom;... 

Now vertical-align:bottom affects all images and messes up the plugin.
These things should be used in a more specific and limited way.

Or take "n6200tbisGPL3"

Code: Select all

.tbisgpl3-postcontent ul > li:before, .tbisgpl3-post ul > li:before, .tbisgpl3-textblock ul > li:before {
    content: url('images/postbullets.png');
    margin-right: 6px;
    bottom: 2px;

Too bad, all the content is in .tbisgpl3 and this css affects all lists !

The Plugin needs a huge stylesheet.css just to counteract all these overdesign. For the same reason a lot of code had to be added to the core.css to make the backend usable.
I think CMSimple_XH is not WordPress and templates also should be kept simple.

I propose to discuss some guidelines for templates.
Thus the core.css can be made smaller.
The template designers should see to it that the backend is usable.

[cmb]

These things should be used in a more specific and limited way.

I'm not sure, though, how to do that. E.g. styling lists in the template seems to be reasonable, but that could already result in unexpected styling of some plugins. Restricting the list styles to a certain class would require the user to set this class for all her lists.

I propose to discuss some guidelines for templates.

ACK. I hope we can agree on some basic guidelines.

Any thoughts (especially from the template designers)?

[Tata]

I think that strict names of all system/core stylesheet selectors and also a convention to name all templates-stylesheet selector by author's unique prefix would solve it.

[cmb]

I think that strict names of all system/core stylesheet selectors and also a convention to name all templates-stylesheet selector by author's unique prefix would solve it.

I fully agree that both should be done (the former has been started for XH 1.6, and is further on the roadmap to 2.0; the rest is up to the template designer).

But is that sufficient? What if the template designer wants all unordered lists to have a certain bullet?

Code: Select all

ul > li {list-style-image:url(...)}

as well as

Code: Select all

#main ul > li {list-style-image:url(...)}

will affect plugins which use <ul> (consider e.g. Pagemanager or Slideshow, which use <ul> quite liberately).

While it is no problem for a plugin author to overwrite a few rules, there are far too much to overwrite nowadays (CMIIW).

The following more restricted variant would require the user to set the CSS class for the <ul> manually, what would rather be unconvenient for the user:

Code: Select all

ul.tpl_ul > li {list-style-image:url(...)}

[Tata]

The following more restricted variant would require the user to set the CSS class for the <ul> manually, what would rather be unconvenient for the user:

Code: Select all

ul.tpl_ul > li {list-style-image:url(...)}

That's exactly what I ment.
Drop short conventioin note in readme.txt as how to give names to all specific selectors used in templates and plugins.
1. selector.plugin_prefix > subselector{...}
2. selector.tpl_selector > subselector{...}
etc.

[svasti]

styling lists in the template seems to be reasonable

my point is to distinguish between what is reasonable and what is not. A plugin author should expect a reasonable variation of settings. However sometimes there are some very unusual and unexpected settings which the plugin author does not anticipate and which break plugins unnecessarily.

For the mail form I would have liked to give the textarea 100% width in the core.css. It would have been nice if the area would occupy the normal full width of the normal text. However this didn't work with "n6200tbisGPL3": here the text areas were shifted to the right and 100% width would overlapp the content to the right. Looked quike ugly.
The point is: Why is it necessary to shift ALL text areas? If the template author wants to have a special effect somewhere in his plugin, he should limit it to that specific area.

Another example is "structure1_black" with vertical-align: bottom to all images. This effects all images the user puts into the text. Why is ist necessary to have vertical-align:bottom to all images? If the template author wants some template images to have vertical-align:bottom, it should be limited to that special case.

In my plugin I wanted to put images and text into ul > li. I thought .plugin ul {list-style-type: none;list-style-image: none;} would be enough. However things are MUCH more complicated: "structure1_black" requires also .plugin ul li img {vertical-align: initial;} and "n6200tbisGPL3" .plugin ul li:before {content:none !important;}. Yes, !IMPORTANT, otherwise the list-style-images won't go away, and still there remains a big left border which I haven't figured out how to get rid of.

I think that strict names of all system/core stylesheet selectors and also a convention to name all templates-stylesheet selector by author's unique prefix would solve it.

In 1.6 we started like this and the mail form has selectors like #xh_mailform and .xh_mailform. Also "n6200tbisGPL3" has .tbisgpl3 before everything — still, as the mailform is inside the content area, the #xh_mainform textarea is dependend on the preceding .tbisgpl3 definition, because css is cascading.

[svasti]

I have been working with Thorstens template n6200tbisGPL3 a bit more and the problem is, that this template has 4 (yes FOUR) css files and is loading some of these css files after the plugin css is loaded.

So there is no chance for a plugin css, since these values will be overwritten by his subsequent extra template css. Except plugin css values add !important. However that should be avoided.

[mikey]

ok, this thread has my attention

since all of my templates only use base cmsimple css, i guess mine have no problems that you describe

[cmb]

my point is to distinguish between what is reasonable and what is not. A plugin author should expect a reasonable variation of settings. However sometimes there are some very unusual and unexpected settings which the plugin author does not anticipate and which break plugins unnecessarily.

Okay. However, when I look at Chrome's developer tools, there are currently 253 valid CSS properties for <li>...

For the mail form I would have liked to give the textarea 100% width in the core.css. It would have been nice if the area would occupy the normal full width of the normal text. However this didn't work with "n6200tbisGPL3": here the text areas were shifted to the right and 100% width would overlapp the content to the right. Looked quike ugly.
The point is: Why is it necessary to shift ALL text areas? If the template author wants to have a special effect somewhere in his plugin, he should limit it to that specific area.

The shift is caused by padding + border in this case, and it is not unreasonable to specify both properties for all textareas to achieve a consistent look.[1]

In 1.6 we started like this and the mail form has selectors like #xh_mailform and .xh_mailform. Also "n6200tbisGPL3" has .tbisgpl3 before everything — still, as the mailform is inside the content area, the #xh_mainform textarea is dependend on the preceding .tbisgpl3 definition, because css is cascading.

Indeed, that is our basic problem here.

I have been working with Thorstens template n6200tbisGPL3 a bit more and the problem is, that this template has 4 (yes FOUR) css files and is loading some of these css files after the plugin css is loaded.

So there is no chance for a plugin css, since these values will be overwritten by his subsequent extra template css. Except plugin css values add !important.

Not necessarily. Everything depends on the specificity. As IDs have higher specificity than classes, we could solve some issues by requesting the template designer to not define rules for selectors containing any IDs. Plugins could always use selectors with IDs, and so would overwrite the template's rules.

PS: [1] Besides in this case the padding comes from core.css, and the border is the default property of the UA.

[svasti]

Plugins could always use selectors with IDs, and so would overwrite the template's rules.

I just tried using id instead of class and indeed, I don't have to use "!important" to overrule n6200tbisGPL3.
The remaining little problem is: If the plugin is called more than once on a page, several identical ids will exist. Ok, it'll still work, only it will not validate. Still better than using "!important".

The shift is caused by padding + border in this case,

I see and just checked it: it's my mistake and Torsten is not to blame.
Just tried in core.css:

Code: Select all

#xh_mailform .text, .xh_mailform textarea {
    width: 100%;
    -moz-box-sizing: border-box;
    box-sizing: border-box;
} 

and it works (even in IE8, in IE6 n6200tbisGPL3 doesn't work) and looks much better. So we may want to adjust this in 1.6.2 along with the rendering of the mail form on dark backgrounds.

So in the end, I guess I'll simply have to adjust my plugin.

i guess mine have no problems that you describe

No problems .