I ran across the Styles plugin today, thanks to a tweet from Brady Vercher. I was intrigued because Brady said, “I really think this plugin could be the standard for easily customizing themes.” That’s quite a statement. But after installing Styles and playing with it a little bit, I can definitely see it being a great plugin for site owners who aren’t comfortable customizing CSS in WordPress themes.
Styles is a free plugin on WordPress.org that has extension plugins for each theme that it integrates with. Currently, you can get the extensions for each of the default themes, Twenty Ten through Twenty Thirteen, for free. The plugin homepage has a cart icon and a “free” banner on each of these themes, hinting rather obviously that their intention is to offer paid extensions for customizing other popular themes.
Here’s a video overview of Styles:
I like that the plugin is interfacing directly with the WordPress Theme Customizer API. At the same time, like other visual “frameworks”, Styles spits all of these customizations into the head of the document, and has potential for bloating a website. There are quite a few options by default, but I found myself wanting more. For instance, I wanted to change padding and margins on various elements, and it didn’t have them available for my demo. In general, if a user knows CSS, I think it’s just as fast to customize a site with CSS alone.
I look forward to seeing how Styles evolves, and seeing what themes they decide to integrate with next. I think the model can work for them, and there is certainly demand for options-based WordPress themes. Enabling a free customization ability for the default themes and other popular WordPress themes could challenge some existing options heavy theme models and visual frameworks.
Thanks for the review, Brian! I’ve been working on Styles for a long time. I’m excited to hear that you and Brady think it can be helpful to WordPress users and theme developers!
You brought up great points about selling add-ons, adding options, and theme bloat. I’d love to hear more of your thoughts — you can read my response here: http://stylesplugin.com/our-first-review
My hope for Styles is that it would save users a lot of time and frustration. Users who can’t code can find freedom to be creative. Theme developers can add options with one line of code while keeping their theme nimble and lightweight. 🙂
Thanks for your review! I think it’s my first review-of-a-review, so that’s fun 🙂
I love how much consideration you’ve put into this, and your willingness to take things out if you don’t feel they are quite “right”. Keep it up with your commitment to core compatibility and users first. Your responses make me excited to promote this plugin to potential users that could benefit!
I hope they change this. I guess the proper form would be using their own linked CSS file.
Hi Joan,
I did output CSS into a file in the past, but changed it to the head for two reasons mentioned in the article I linked above. ( http://stylesplugin.com/our-first-review/ )
The short version is that with the amount of CSS Styles outputs, it was both faster to load and more user-friendly to output in the head (because non-technically savvy users did not have to adjust permissions).
I’m happy to change this back if Brian or others can point me to evidence otherwise, but from what I experienced (again, detailed more in my article), the nature of dynamically-generated CSS caused more issues in a file than it did in the header.
Hey Paul, I was referring to the risk of bloat in general for frameworks that have styling options. I think you’re right about putting them into the head. That’s probably why most of them do it that way, versus dynamically generating a stylesheet 🙂 I recall Otto Wood mentioning a couple years ago that dynamically generated stylesheets are a pain in the butt, so since then I’ve been alright with a few styles in the head.
The toughest thing I see in this scenario, is when someone is later directed to edit their child theme CSS by another tutorial or whatnot, and they can’t figure out why their rules (which they were already scared to copy/paste) wouldn’t override something that turned out to be in the head of the document. I wonder how it would be received if you implemented a “custom CSS” feature as the bottom option of Styles? Maybe that would be beneficial for users that are comfortable copy/pasting but not getting into their files?
The WP customizer API is awesome. Glad to plugin devs taking advantage of it. Not a fan of spewing CSS in to the head – who is! Well done Paul.
Thanks Ruairi, that’s kind of you to say.
In regards to CSS in the head, believe me, I also am not a fan of what CSS in the head looks like. Unfortunately, when I compared outputting cached CSS to the head vs. to a file, putting it in the head was both more performant and caused fewer bugs for end users. At least that’s been my experience with the plugin so far.
I go into more detail on this topic at http://stylesplugin.com/our-first-review . In the past, Styles had options for outputting to the head, to a static file, or to a URL generated by WordPress. I used each for about a year, then pared down to only the head.
Paul ,
I’m familiar with how The Crowdfunding plugin by Spencer Finnell and Adam Pickering extends Easy Digital Downloads – they also have theme on TF. That is a great idea, and the very best of luck with it 🙂
And I agree that loading CSS in to the head is about convenience for your intended audience! It is simply about weighing the pros and cons!
Thanks Ruairi. I’m glad to hear that Pippin’s model has worked well for Spencer and Adam. I think his balance is a good balance that allows developers and users to both be empowered. 🙂
I posted an additional note for Joan, taking a look at how JetPack loads CSS. I really do want to make sure everything loads as fast as possible, regardless of the method used. I was pretty surprised by what I found. I think the comment is just awaiting moderation because it included links to load-time graphs as well as the testing site.
Yeah, I translated and used that plugin for two customers, it works like a charm.
I think that the best solution is the one that Jetpack uses: adding a tag pointing to a single, dynamically generated stylesheet containing all of your CSS snippets.
According to Google, adding stylesheets with a element is preferable over directly injecting it into tags or using @imports performance-wise.
JetPack takes the strategy of spinning up WordPress all over again just to send CSS. Consider this screenshot from a clean WordPress install, http://jetpacktest.pdclark.com , running only JetPack with the “Edit CSS” feature: http://go.brain.st/15IjjNV
That graphs shows that 2ms is spent actually transferring CSS, but 548ms is spent waiting for WordPress to load up a second time.
Let that sink in. These are ideal conditions for JetPack: Fresh install. No other plugins. But still, 99.7% of the wait time is associated with JetPack reloading WordPress.
For testing, I used what I would consider normal Styles output — every setting set in two groups, 18 settings total: http://go.brain.st/11KeaYj
You are absolutely right that in normal conditions, external CSS files are preferred. But in cases like Styles, where CSS is being generated dynamically, and the CSS size is a few lines of customizations (not a full-site stylesheet), outputting to the head provides a 99.7% reduction in overhead and load time.
Yeah, you are right. And 99.7% reduction in overhead and load time is worth!
Great! I’ll check it out as soon as it is approved. 🙂
Nice write-up, Brian.
Paul already covered most of the points I was going to bring up in his responses. Styles really does abstract all the complexity of declaring customizable settings and turns would could be a couple hours worth of work into a few minutes. That’s one of the big reasons I think it could be the standard.
Regarding CSS being injected in the head, I don’t think most people have thought through the implications of the various methods unless they’ve actually tried to do it at least once or twice. In the end, it may not feel very elegant, but it has the least impact and is widely compatible. I believe Paul caches the generated CSS on save, so it’s not being generated on every request, either.
Hi,
thanks very much for sharing this plugin, Brian. And congrats to it’s developers. Now I’m really curious to dive into it 🙂
Thank baby Jesus that developers are starting to move away from bespoken options pages–especially when there is already an options API in the Customizer.
The Customizer may have its place but I don’t like it to be used for each and every setting. It just makes no sense. If you have a cluttered Customizer sidebar like with these Styles plugins it is not really user friendly: Too many tabs! Also, the more options are in the Customizer the slower it becomes. Sure that may also rely on server ressources but shouldn’t it be in real time?
Also, the CSS styles are stuffed directly in the header source code which is really bad! Additional styles should be enqueued and minimized.
And, options that have no effect for the frontend shouldn’t be in the Customizer at all just because it’s confusing for users when all is mixed up. For a limited number of — frontend — options the Customizer is a real good thing. However, for some stuff a little options page goes a long way. Options pages are not all the same. It always matters HOW it’s implemented!
Hi David,
I think you have an excellent point that the simpler an administration panel can be for the user, the easier the user experience will be. Styles certainly does not force theme developers to use every setting — the default add-ons simply list all existing elements as an example.
Some of your other comments, however, make me unsure that you have a fair amount of information about the WordPress Customizer.
Concerning speed, you should be happy to know that the WordPress Customizer does make adjustments in real-time. Styles uses postMessage whenever possible, which does make all the updates in real-time without hitting the server at all. I think if you give it a try, you will be impressed to see that colors update instantaneously as you drag your mouse across a color palette. The developers of the WordPress customizer did an excellent job keeping scalability and responsiveness in mind here.
Concerning CSS in the header — please read the comments above. Styles uses both linked files (for generated javascript and static CSS), as well as inline CSS. You’ll see in the comments above that the screenshots show the reason for putting the CSS inline: it caused a 99.7% decrease in CSS load time for that particular instance.
As far as “options that have nothing to do with the front-end”, I’m not sure what you’re referring to. There are some general purpose settings in the WordPress customizer, but these are a part of WordPress core, not Styles, and each of them do effect the front-end. Styles specifically only presents options for colors and fonts on the front-end. Perhaps you’ve seen others use the Customizer in different ways? I’m not aware of instances where it’s being used for settings where an instant preview isn’t useful.
It sounds like you have a keen eye for how to best present useful settings with the user’s perspective in mind. If you’re creating themes yourself, I hope you’ll consider using Styles to add a small-set of relevant and responsive settings. I think you’ll see in the demo videos that it can save you a lot of time, and keep your server load light by using the Customizer’s most efficient methods by default!
Thanks for your feedback, Paul, much appreciated!
I am well informed about the Customizer, the overall idea is great, and for some typical theme options it is an awesome way of doing it and for some settings would be the best options. However, seeing 40 tabs or so with overwhelming sets of color pickers or such, this will not improve the user experience. Should the user really be able to set each and every color? For some theme use case this could be a must, absolutely. For the “average website” I doubt that, because my experience is, that the un-educated client will likely damage his/her site… (colors, whitespace, fonts…)
My comment above was not only about your Styles plugin & concept, but also in general about the Customizer – and how it’s “promoted” among WordPress developers these days.
Sorry, if I mixed it up myself a bit and did not explain good enough. For the comment part about the frontend options etc. I just meant that in a more general way, not really regarding your plugins :-). I don’t like these options pages with hundreds of options – this makes no sense! However, I also do not like to transfer lots of such settings into Customizer options. Each and every setting should be thought of: is it really neccessary, and if yes, where to place it in the admin or in the Customizer? A well balanced set of options on a small options page could be really great for users and admins alike – the same applies for the use of the Customizer by developers.
Thanks to input from Joan and David, I have minified the header CSS in version 1.0.8 and credited this comment thread in the changelog. This causes it to take up much less space. Thanks for your input everyone!
Thank you Paul, this is awesome news! This shows everyone you really care! 😉
I never understood why someone would inject styles or scripts directly into a page. One of the main reasons why I don’t understand it is loading order and specifity. When I want something to be not reliably overwritable and non-predictable in behavior, then yes, else simply no. What I do understand is that no one wants to load core just for a stylesheet. But as long as your application writes to a file everything is fine. At least it’s the theme developers responsibility to deliver a theme that has easy to read and understand code and styles and not to care about the number of stylesheets it delivers. This is something that should be handled by plugins that concatenate files, minify them and cache the output. If file permissions aren’t present, I’d simply add a textarea that holds the style definitions (ready to copy/paste) and tell users to add it to their style.css file. Yes, this is the culprit of WordPress: If you’re trying to do everything for everyone, then you have to meet the lowest goal with the highest expectations. And we all know how well this works out.
Wow, looks like a really impressive plugin, my guess is though that it only works well if the markup is structured in a standard way and doesn’t really work very well with highly customised themes. As a designer sometimes I need to create individual pages and target them by id but, I can code so I guess this plugin isn’t for me, not to say it doesn’t have it’s place though – I can see how a lot of consultants might use this to bang sites out for their clients.
Hi Elliott,
You are right that it takes a bit of extra work to set Styles up for a new theme, but it is very accommodating to any markup. Settings are created basically by just entering the appropriate CSS selectors. You can see a detailed walkthrough in the “code walkthrough” link at the bottom of wordpress.org/plugins/styles .
If you’re a designer who knows a minimum amount of CSS, I think you’ll find this to a great tool for clients or adding flexibility to a theme.
Paul