Re: Proposed Fix For Variants CSS issues
Reply #16 –
Well if the change to make loading variant files the default is accepted given that this now applies to loading CSS and Javascript I'd say it gives people a lot of ability to do many things in a variant, but conveniently doesn't require them to do hardly anything if they don't want to. Who knows what people will do with it but it's nice to give them that option.
Currently I see 12 css files in the default theme css directory and four in the css/_light directory. Who knows which of those 12 someone might need to tweak in a variant. That's the problem with making specific exceptions piecemeal and the reason I wrote the version I posted.
Re: Proposed Fix For Variants CSS issues
Reply #17 –
Oh I totally agree. The variant system has to be able to handle anything in the CSS anywhere or it will end up driving people nuts.
My ruminations were more to do with the (unavoidable) greater complexity of the file system in Elk compared to 1.1.x or 2.0.x, and the resulting greater complexity of getting wild with colour variations. I've been sorta thinking it would make as much sense to use the variants system to give layout variants of a theme, with different colour variants done as separate themes. It's something I'd have to play around with a bit to get a real feel for the best all-round options.
Plus, of course, there's still the option of manually coding your own superimposed options in index.template.php so you can effectively add variants to variants (sounds bonkers, but have done it before - can be handy occasionally).
Re: Proposed Fix For Variants CSS issues
Reply #23 –
Well, if we're discussing a major change and want index.css to not be an exception, I'd personally rather have it still go variant=>current base=>default base and not split index.css into a base part and a variant part.
I'm not sure what that split is supposed to do actually. I recall seeing color and structure in both the main and the variant. But obviously the majority of css files are happily shared between _light and _besocial since it's a 12 to 4 split between base and variant dir. So I'd rather have no file ever load more than one copy.
The css is just a part of the theme. A lot of it is also all the php templates and all of the js scripts. So having variants that have very different css is not necessarily a good reason to split it into two themes.
So I'd drop the base theme index.css and only have it exist in the variants if I was going to get rid of the exception. (Yes, you'd have to merge the base index.css into the two existing variants.) Or make the base index.css be the current base index.css and index_light.css combined (since I think _light is still the default variant) and remove index_light.css. Then people using index_light.css would just load the main index.css and people using just besocial would load just index_besocial.css (which has now been combined with the parts of index.css it didn't overwrite.)
This also has the advantage that you don't have to make a special case for javascript. (Which if you're going to do that you should just go back to two separate functions and ditch loadAsset.)
Now you have no special exceptions and variants can override any css or javascript file if they want, but don't have to override any of them. Which would mean if I was creating another light them probably all I would have to do is copy either _light/index.css or _besocial/index.css to my variant and modify those.
But if we keep the index files separate (and someone had a reason to that) I'd still prefer that index.css be the one special case and that otherwise nothing loads two files. I think the two files leads to a lot of css bloat.
Re: Proposed Fix For Variants CSS issues
Reply #27 –
Quick question. If our licenses were compatible in the near future... Would you look into reusing the Wedge skin system? That would solve all of your problems... Smf's Css variants suck. Nuff said.
Re: Proposed Fix For Variants CSS issues
Reply #29 –
Ok, I don't like the two layer approach but it's trivially easy to do in my last proposal if that's what the variant writer wants.
For your sidebar example if I create my own sidebar.css file which I'm going to have to write code to load somewhere (in a hook probably) and I want to have a base/variant split all I have to do is loadCSSFile(array('sidebar','sidebar_variant') and suddenly I've got the split approach and don't have to worry about keeping files in sync. But if I don't want the split behavior it's not forced on me.
If I want to create a split style override of an existing css file in the base theme you can do that with a hook too. The pre_css_output hook puts those files after all the others so I can use that hook to do, using sceditor as an example, loadCSSFile('sceditor_variant') in the hook. Then you get the split style. And if you only have one variant (say a dark one) that needs to override sceditor you only need to have the file exist in that one directory.
So with my latest approach you can easily go either way and it's minimal changes to your existing code and it eliminates all the special cases (other than the sceditor wiz) that currently exist.