CUNY Academic Commons

I'm sorry but I feel I need to push back on this issue a little. I understand that working with WP means that there are quite a few users that don't know how to use css. But as I was working on this issue I couldn't help but think that the tradeoffs don't add up for me. We're talking about requiring our plugin users to load an addition css file for what amounts to the following:

.cfcw-content img { margin-right: 10px }

That's one extra browser request, wasted bandwidth, network overhead, all for a single line of css? And (AFAIK) we can't target the page containing the plugin's UI, so we're requiring users to load this extra css file on EVERY page! If the plugin was far more UI intensive I can see the validity of the argument. But so many sites will be so different in where they want to put a widget and how many times they want to display it, I can't imagine that SO many users wouldn't know how to add a single line of css to their site.

What do you think about waiting to see how many issues are opened after the first release? Unless there's some simple way of adding this css that I am unaware of, it just seems like SO much overkill. Am I wrong?

Thanks for the pushback, Dom. You make sensible points.

(AFAIK) we can't target the page containing the plugin's UI

We can, if we're a bit tricky about it. Inside of the widget display method (I think it's widget()), you can make a call to wp_enqueue_style(), and the stylesheet will be loaded in the footer of that page. Since the display method is only called when the widget is displayed on the current page, that more or less solves this particular issue.

That's one extra browser request, wasted bandwidth, network overhead, all for a single line of css?

Yeah, I'm not crazy about it either. However, it's mitigated to some extent by the fact that browsers cache stylesheets very aggressively, and hosts are likely to send very generous expiration headers with .css files. So in many (most?) real world cases, there won't actually be another request made.

More broadly, there is the question of what the alternative is. I see basically three options:
1) Enqueue a stylesheet, as discussed here
2) Do nothing
3) Print styles inline

If we go with (3), we make the styles more or less impossible to override in a theme's stylesheet.

If we go with (2), the widget will look bad for 100% of users out of the box. As you note, it only takes a line of CSS to make it look good, and this can be noted prominently in the documentation. But, realistically speaking, 90% of the people who install the widget cannot or will not make this change.

On the other hand, while going with (1) will, indeed, require extra network etc overhead, it won't turn any casual user off from using the plugin. And any 1337 h4x0rs who are looking to squeeze extra performance out of their sites will either already have a script-compressing solution, or will have the option of manually using wp_dequeue_style() on our stylesheet.

I suppose there's kind of a rogue (4), which is to print our styles directly in the header or footer:

function cacfc_print_style() {
    echo '<style type="text/css">.cfcw-content img { margin-right: 10px; }</style>';
}
add_action( 'wp_head', 'cacfc_print_style', 1 );

The trade-off here is that we either load it very early in the head (like I have here - wp_head:1) so that stylesheets can override it, but before we are able to reliably tell whether the widget appears on this page (so that the extra script is added in the head of every page); or, on the other hand, we can load it in the footer, in which case we can hook it to wp_footer in the display method (limiting it to the pages where it will actually appear), but it will be output after the user's stylesheets, and so will not be easily override-able.

So, on balance, my inclination is to enqueue the stylesheet. It will provide the best experience for 90% of potential users, and there are fixes for those additional 10% that are well within the skillset of the 10%. Also, it's just generally "the WP way" to enqueue stylesheets, for better or for worse.

However, I don't feel so strongly about this issue that I'm going to command on high that my will be done :) If you would like to try an initial release without the stylesheet to see if people complain, it's OK by me.

All excellent points, I always forget about the caching aspect of the client server paradigm, prob because I've never worked with Total Cache or any of the other caching plugins. Plus, a user on multisite has almost certainly tweaked their server config to provide the most advantageous caching.

I like the idea of enqueueing in widget(). For some reason I was thinking that wp_enqueue_style() HAD to be attached to a hook at the beginning of the plugin.

While reading your reply I thought of another reason for including this in the first release. Other users will always be able to tell us about their edge use cases through Github issues, and having a stylesheet ready to fix display problems on site setups that we can't imagine just makes good sense.

I will get this into the repo before release.

Awesome. Thanks, Dom!