CSS in Sidebarplugin

[gimmel]

I'm working on a gallery sidebar-plugin that needs a default CSS styling. Sidebar-plugins are not able to execute (css) event hooks. Is there another solution for changing the CSS code in a sidebar-plugin?

[Don Chambers]

Each sidebar item emits a unique ID, and a class (which, like the HTML nugget, might not be unique). You can view the source of your page once the sidebar item is installed, check for this ID or class, then add code to your existing stylesheet.

Unless that was not your objective....

[gimmel]

Uhm, you mean I should visit every user who wants to use my plugin (hopefully available through spartacus) and change the CSS file of their template? And when they change their template, the plugin output looks horrible…?
No, I don't wanna do that.

My question was how to change the CSS output by plugin functions. It works perfectly with the CSS event_hook in event plugins. But there are no event_hooks in sidebar plugins and normally they are not needed. But since my sidebar gallery plugin needs a CSS default formatting (the images are shown as an HTML definition list) I'm looking for a working solution. Users who want to change that, can still do it in their own CSS template files, but there should be a working default.

[onli]

It's not nice, but why not just embed the css-code into the output? If you make that deselectable it won't harm users who want to cange the default.
Or you could combine the Plugin with an event-plugin which listens at the css-hook.
sincerely

[Don Chambers]

Sorry - I completely misunderstood your intent. Did not realize it was a plugin for distribution. I cannot, off the top of my head, think of any sidebar plugins emitting css... like you, I can think of several event plugins doing it. Maybe Garvin or Judebert can offer a suggestion.

[gimmel]

Not bad. I normally don't like CSS-Code in HTML, but using a switch to turn it off is a very good idea.
Combining the two kinds of plugins is a good idea, too. But wouldn’t it be curious for the user two have two plugin entries in the backend (event/sidebar) for just a sidebar plugin?

(BTW: I don't know how to combine a sidebar plugin with an event plugin… )

[onli]

I don't think that having an additional event-plugin with a explaining description would confuse the user. If you want to see an working example, check 'serendipity_plugin_templatedropdown'. The dependencies are marked like this:

Code: Select all

$this->dependencies = array('serendipity_event_templatechooser' => 'remove');

(I think I personally would prefer the inline-CSS because it's an easier solution, but of course it's up to you )
sincerely

[yellowled]

(I think I personally would prefer the inline-CSS because it's an easier solution, but of course it's up to you )

Please keep inline CSS to a minimum by any means. I realize it may be unavoidable in this scenario (since images are involved which might need to be floated etc.), but it is usually a pain in the rear end for template authors. In a lot of scenarios, just using the semantically correct (X)HTML markup will already ensure proper display.

YL

[gimmel]

Yes Yellowled, that's my opinion, too. CSS should stay where it belongs to: in a CSS file or the header of (X)HTML files. In my case, every list element would need an inline style definition. In an external CSS file I only would need one line of code to set the right parameters.
So I will try to bundle an event plugin. A lot of extra work, but it's most compatible, editable with template files and standard compliant.

Thanks a lot for the help, guys!

[kleinerChemiker]

Isn't it possible to change S9Y, that also sidebar plugins can use the css-hook?

[yellowled]

In my case, every list element would need an inline style definition.

Well, if that's all it needs, I would actually not bother putting up with the extra hassle A lot of sidebar plugins actually have minor inline styles like that.

Feel free to outline the extact purpose of the code you're thinking about, maybe there's another solution.

YL

[judebert]

I just tried to whip up a quick-and-dirty solution to this. I figured we could just add a "css" property to the sidebar plugin's config bag, then add them to the CSS output in css.inc.php.

Unfortunately, I turned out to be stupid. I can't find where in the code the plugins actually get loaded and introspected.

Code-wise, it would actually be easier to add a "generate_css" function to each plugin, and call it when we make our CSS. That would have ugly emergent properties, though: how would "stacked" plugins handle the multiple calls? How would we avoid generating CSS for plugins that were hidden, or for templates that didn't include a particular sidebar?

Maybe Garvin can make a recommendation on this one.

[onli]

Ain't it possible to output the css-code in a <style>...</style>-section? I know that normally belongs in the head, but it should work. That seems to me more hassle-free then extending the sidebar-plugins.

[gimmel]

Ain't it possible to output the css-code in a <style>...</style>-section? I know that normally belongs in the head, but it should work. That seems to me more hassle-free then extending the sidebar-plugins.

No, no! Please no! No „should work“, non-standard solutions.

[garvinhicking]

Hi!

Sidebar and Event plugins are technically meant to be seperate. We can't (and also I don't want to) really change that.

So your options are:

1. Emit the CSS in a <style> block. Maybe even use a @import rule to load the additional style

2. Create a bundled event plugin (you should even be able to put sidebar+event plugin in one directory, see serendipity_plugin_adduser)

3. Give your users an instruction which CSS to add into their usual style.css files

4. Now this is my favourite: Use javascript to inject the style tag into the DOM-Tree of the HEAD-section

@Judebert: I don't like the idea of hacking a CSS-like function selector to a sidebar plugin. This would be outside the conventions of usual event plugins and would confuse people even more.

Regards,
Garvin