Suggestion: Custom CSS Input

[Mihari]

Here is just a thought that I got while reading over the other recent (and even past) issues with inkblot.

I currently use this plugin in conjunction with 95% of the sites I use these days when WordPress is involved:

[(https://wordpress.org/plugins/simple-custom-css/)]

Now, I never mean to complicate your life, or add more work to the table, but it seems like replicating this plugin's abilities where users could have choice in the appearance option for the theme specifically to enter custom css, and it would directly output to a custom.css to minimize end user having to make external files would be a beneficial thing.

Of course, there is that whole deal where you could just point everyone to that plugin and call it a day too, but then again I'm not sure what output the plugin uses either, since there have been occasions where it's still required me to use an !important tag.

[mgsisk]

Thanks for the suggestion Mihari! I like the idea… though I'm concerned bundling something like that with Inkblot might run afoul of the Theme Directory guidelines (specifically the Plugin Territory section). It's hard to tell, though; the guidelines are a total mess right now. XD

Let's assume for the moment that I couldn't specifically replicate the functionality of that plugin, though. Do you think WordPress' own content editor would work well enough for this? I ask because after the stylesheet issues mentioned in issue #26 I'm taking a closer look at exactly how Inkblot's dynamically-generated stylesheet works, specifically with child themes. Bear with me as I work through my reasoning here, and let me know if you think this is crazy or not.

Right now, style.php builds itself like this:

1. Load the active theme's style.css file. This means that if you're using a child theme, the child themes style.css file is loaded first. This is a big problem, because child theme style.css files typically only have modifications to the parent theme CSS.
2. Load the @font-face declaration (which is apparently iffy at best XD)
3. Load the Customizer styles.
4. Load a custom.css file. This one is a bit odd because of how the locate_template function works; this might load the child's custom.css file (if it exists), or the parents (if the child doesn't have one but the parent does), or nothing (if neither theme has a custom.css file).

This is all a bit of a mess and doesn't actually work right if you're using a child theme, so the fix I'm proposing at the moment would change that process to:

1. Load the main Inkblot style.css. Even if you're using a child theme, the parent theme's CSS would be loaded first to make sure everything has the necessary default styles.
2. Load the @font-face declaration.
3. Load the Customizer styles.
4. Load the main Inkblot custom.css, if it exists. This would be mostly for legacy support, and probably be removed at some point in the future.
5. Load the child theme's style.css file.

With this setup creating a simple child theme with just a style.css file would be enough to override all of Inkblot's default and Customizer styles. You wouldn't even have to @import the parent theme's stylesheet or enqueue it via functions.php in your child theme, because Inkblot's dynamic stylesheet would automatically include the child themes style.css file. Then you could just use WordPress' built-in file editor to tweak the CSS (which is not, admittedly, as nice as the one in Simple Custom CSS).

I'm probably going to make this change anyway as it solves a lot of problems… I suppose my real question is: do you think creating a child theme and putting all of your custom CSS in the child theme's style.css file (using WordPress' file editor or however else you like) would be enough, or do you think building functionality similar to Simple Custom CSS into Inkblot is a better option?

[Mihari]

It's hard to say, without more user feedback, the question lies in how many people actually use a child theme. Those that simply make CSS edits wouldn't need a child theme. I guess the real thing the plugin really helps with no matter what your theme is, the changes made there stay because they are not bound to the theme.

For example, lets say you went ahead and did incorporate that plugins functionality into the theme. Could it be made so that the file it generates is NOT replaced on a theme update? Cause as far as I can tell that would be the only folly of the idea. Lose all your customizations cause the default custom.css came down and overwrote it.

Now, if the theme just had a conditional statement to check for that custom.css's existence when compiling the final stylesheet, and not requiring it that would be perfect. So, even if the theme did completely update, that custom.css would still be there cause it's not included in the inkblot package.

The final thing to consider is overhead, would incorporating that perform better, worse, or the same as letting the plugin handle that?

[mgsisk]

The overhead question is a good one, and I'm not sure what the answer actually is. More plugins tend to be bad, but not always; there really isn't a significant difference between bundling a plugin's worth of features into Inkblot vs loading a separate plugin. If it were bundled with Inkblot, though, I'd essentially be forcing whatever overhead there might be on everyone that uses Inkblot – even if they didn't want it – and it would be a bit more limited than the Simple Custom CSS plugin (e.g. it would only work with Inkblot).

What you're describing in your third paragraph is actually how Inkblot works now (even after 49ee40b0e19e583e85b747240d23d8f8af1339a1): it will load a custom.css file as the very last thing in the theme's stylesheet – if it exists – so anything you put in custom.css takes precedence over everything else (even Customizer modifications). The actual custom.css file is no longer included in Inkblot, so theme updates shouldn't blow it away.

I feel like it's not much more work to create a style.css file and throw it in a new theme directory (the child theme) if someone is going to be editing raw CSS anyway. The crux of the issue might be the automation: wether you use Inkblot's custom.css or a child theme you still have to manually create either of those by FTPing to your site and adding files, which is, admittedly, kind of lame.

The Theme Directory – for all it's weird guidelines – might provide a reasonable compromise between replicating that plugin in Inkblot and forcing users to mess with FTP for a bit of custom CSS: you can host child themes in the Theme Directory. This would have several advantages:

1. Essentially no overhead. WordPress already knows how to work with child themes, and Inkblot already understands how to load a child theme's CSS. The child theme could be as simple as a single style.css file.
2. Simple installation. Like any other theme in the directory the child theme could be loaded directly from within WordPress; no need to FTP anything.
3. Update safe. Changes to the main Inkblot theme wouldn't affect the custom CSS in the child theme.

[Mihari]

The one big thing knocking my mind is this, sure we know about child themes and their advantages. However, how often does a new user, who just discovered that the Webcomic plugin and thus WordPress is the best way to go about making a comic. Will they know that editing a child them is the best way to go? Would they even look for one in the repository? Moving past that lets assume no, they just download inkblot and go to work on making it work for them. Now in most cases the basic colours and customization opens are sufficient enough for most people I'd assume...

A few niche people would finish with the customizer's options and would want to take it a tiny bit further and want to change this one little thing. Let's assume they also come to you asking how to do it. I just think it would be easier to tell them to go into the custom css tab under the appearance menu and add a "display: none" for whatever they want would be a lot better than the instructions to walk them through child themes and their use / installation / customization. Now if you were able to have the child install with inkblot that would work perfectly and be ideal...

Anyhow, so, it all comes down to this, out of all the options, what is the easiest thing for the general Webcomic plugin user who downloads inkblot?

[mgsisk]

I see your point… but if they're coming to me asking how to do that then I feel like I've already failed. XD I mean, if it gets that far, I might as well tell them to download the child theme and drop the display: none; in that theme's style.css file through the Appearance > Editor page. I think the trick for implementing this would be to make it blindingly obvious; a separate page under the Appearance section probably isn't going to be obvious enough. I like the idea of using the existing Appearance > Editor more, but custom.css would easily get lost in Inkblot's rather long list of template files (and it wouldn't be at all obvious what it's actually for).

Let's forget a separate custom.css file for the moment. What if there was a section right in the Customizer to enter CSS? WordPress 4.0 added support for <textarea> inputs in the Customizer. It might not be super fancy (no syntax highlighting or line numbers), but – for your scenario – I think it might actually work better. It'd be right there in the Customizer, so they wouldn't have to hunt for it. The CSS would be saved as a theme mod, so it wouldn't require any additional files that might get blown away in a theme update. The styles could be entered and saved directly in the customizer, with live previews and everything (I'll have to actually test this, of course). And then they'd be appended to Inkblot's generated stylesheet with all of the other theme mods when changes are saved.

[Mihari]

Could work...and does sound like the best middle ground of all the options with the least amount of extra overhead.