« Merge topic - notify the user
Practical plugins problem with WeCSS
About SMF and this project »

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Practical plugins problem with WeCSS
« on November 14th, 2012, 03:00 AM »
So I'm working on the plugin system and a problem hits me. I want to display three calendars in a row together at times. No bother, I thought, I seem to remember three-columns being declared for that, but it was obviously a long time ago because it's no big deal.

So, I thought, fine, I'll copy the definition for two-columns and adjust the width... except I can't, because you can't use extends in a plugin's CSS file to extend something in the main files. There's all kinds of good reasons for that, mostly that you don't want to potentially make exponential CSS files to cover for each combination of plugin where the files are loaded (three plugins will potentially generate 8 variations of everything)

That also rules out using inline-block as a base for extending (since that's what I really need here), so I figured I'd pull it in as a class, except I can't because it's defined as a virtual style (which means there's several loose places in the source where it IS used that need to be fixed)

Now, it's not a huge deal, I can use display: inline-block and only cut out IE6/7, and for a plugin I'm cool with that - but it does irk me that something that is in the core, I can't meaningfully use in a plugin. I also don't know how to get around it but I'm getting it out here in case someone does have an idea.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
Re: Practical plugins problem with WeCSS
« Reply #1, on November 14th, 2012, 09:00 AM »
Quote
you don't want to potentially make exponential CSS files to cover for each combination of plugin where the files are loaded (three plugins will potentially generate 8 variations of everything)
Is that a problem? IIIRC, each variant is stored inside its own folder. Although, it'll mean many folders... what am I missing?
A confident man keeps quiet.whereas a frightened man keeps talking, hiding his fear.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Practical plugins problem with WeCSS
« Reply #2, on November 14th, 2012, 11:08 AM »
Isnt it possible to include common.css in the CSS loader for your plugin? That's what it's for. If it first work then it's something I need I fix once I'm ready to get back to work.
Also, you can use mixes keywords if you don't want to extend. But there is no reason not to extend because it in it own CSS cache file anyway.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Practical plugins problem with WeCSS
« Reply #3, on November 14th, 2012, 02:31 PM »
Quote
Is that a problem? IIIRC, each variant is stored inside its own folder. Although, it'll mean many folders... what am I missing?
I deliberately kept plugin CSS separate from core CSS because if you were to intermingle them, you hit the problem of compounding.

If you have 3 plugins that may or may not include their CSS on any given page, there's an on/off for each, so that alone will build 2^3 = 8 potential files - JUST for that, and that's before you multiply that by the number of variants there are.

What are the odds that people are going to have just 3 plugins?
Quote
Isnt it possible to include common.css in the CSS loader for your plugin? That's what it's for. If it first work then it's something I need I fix once I'm ready to get back to work.
The plugin just calls add_plugin_css_file and expects it to work. If that were to mingle common.css with the plugin's CSS before including it that would likely not be too horrific in terms of duplicate code.
Quote
Also, you can use mixes keywords if you don't want to extend. But there is no reason not to extend because it in it own CSS cache file anyway.
Which is fine - until I *do* want to extend something in the core CSS from a plugin, which I can't do.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Practical plugins problem with WeCSS
« Reply #4, on November 14th, 2012, 05:03 PM »
Quote from Arantor on November 14th, 2012, 02:31 PM
If you have 3 plugins that may or may not include their CSS on any given page, there's an on/off for each, so that alone will build 2^3 = 8 potential files - JUST for that, and that's before you multiply that by the number of variants there are.
There's a single file for all plugins..? Why not one cache file per plugin..?
Quote
The plugin just calls add_plugin_css_file and expects it to work. If that were to mingle common.css with the plugin's CSS before including it that would likely not be too horrific in terms of duplicate code.
Why?
- If you don't use the extra classes, it takes no extra space.
- If you do, it just re-creates these classes in your custom file as needed... It doesn't waste space or anything. We're mostly talking about .inline-block and short hacks like that... ;)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Practical plugins problem with WeCSS
« Reply #5, on November 14th, 2012, 05:21 PM »
I was going to get into a thorough explanation of the problem but I'm really not sure I care at this point. One of us, and I'm not entirely sure it isn't me at this point, has a fundamental lack of understanding in how WeCSS works especially with respect to plugins.

One of the problems, adding a simple CSS file from a plugin generates interesting filenames.

Like calendar-chrome24-member-m1-admin-local-global-replace-1352904776.css.gz and calendar-firefox16-guest-local-global-replace-1352904776.css (the only difference is the way box-sizing is expressed for Firefox's benefit), so we're already going to create a shit-ton of files from plugins, so the notion that 3 plugins each with their own stylesheet might generate 8 combinations is a silly consideration.

Sod trying to be efficient and not eat space, we might as well rewrite add_plugin_css_file just to add them to the main CSS file and be done with it because that won't be any worse than making a metric shit-ton of files how it is now.
Re: Practical plugins problem with WeCSS
« Reply #6, on November 16th, 2012, 05:37 AM »
Oh, this gets better and better.

So, I'm using live627's dateinput in the calendar, and I call add_plugin_css_file('Wedgeward:Calendar', 'css/dateinput', true); which goes and gets it. In this particular case, I'm inside a given board.

And it generates this filename:

Code: [Select]
http://localhost/wedge/css/calendar-dateinput-chrome24-member-m1-b1-c1-admin-local-global-replace-1353039526.css.gz

The calendar, dateinput and chrome24 bits I'm cool with. But I have no way of indicating, as far as I know, anything about the others. This is going to generate a very large shit-ton of files, and I don't know anything about stopping it.

It may or may not be members only, it may or may not be admin only, it may not even have a board when it's called.

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Practical plugins problem with WeCSS
« Reply #8, on November 17th, 2012, 12:33 AM »
Hmm... Let's be clear on this, I didn't write the plugin version of that function and as such, it's likely that I made changes to other functions that weren't moved to the plugin version as well.

If anything, the fact that the filename has local/global/replace keywords in it when there's no reason, is proof that the function is quite a bit behind...

Also, would probably be best to create one folder per plugin, e.g. /css/Wedgeward-Calendar/chrome24-123456.css.gz

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Practical plugins problem with WeCSS
« Reply #9, on November 17th, 2012, 12:49 AM »
Quote
Hmm... Let's be clear on this, I didn't write the plugin version of that function and as such, it's likely that I made changes to other functions that weren't moved to the plugin version as well.
I know, I wrote the plugin version, but I wrote it long before the other stuff was added, it certainly predates the m, b, c and other prefixes. Given that it basically just acts as a wrapper to wedge_cache_css(), I had sort of hoped that it would 'just work'... :/

I also realise that my temper got the better of me in this thread (and I'm sorry, because you're the one who's going to be getting that, and that's wrong). Figuring out the many skeins of why the calendar is broken is not a pleasant task and in some ways I might just have been quicker building it from scratch, and it has felt like every single time I tried to do something, everything else seemed to break, and I know if I'm encountering these errors, others will as well.
Quote
Also, would probably be best to create one folder per plugin
This actually brings me back to the original point I made when creating this thread - while it is nice to segregate like that, it does mean that a plugin not only can't share from the core, it also can't share with other plugins, though if you can't extend the core, you can't extend other plugins' stylesheets anyway.

Nao

  • Dadman with a boy
  • Posts: 16,082
« Merge topic - notify the user
About SMF and this project »