css – Changing Way

Custom CSS Grandfathered… or Overlooked?

For years, I’ve used two of the paid upgrades offered at WordPress.com: domain mapping and custom CSS. Domain mapping is the reason this is changingway.org, as well as changingway.wordpress.com. Custom CSS is the reason you see the date under the post title in small type, rather than large type, and the reason that the category names in the sidebar aren’t separated from each other by lines.

Those two upgrades came up fore renewal a few days ago. I renewed domain mapping, but not custom CSS. The main reason I didn’t renew custom CSS is that it no longer exists. It is part of the custom design upgrade, which also includes custom fonts, and is twice the price that custom CSS used to be.

I regret the passing of custom CSS, but there are a couple of reasons why the regret isn’t strong. One is that I understand that Automattic, the people behind WordPress.com, seem to be moving toward a simpler and more profitable menu of upgrades. The other is that my custom CSS is still in effect as of now. Perhaps it’ll stay in place as long as I don’t try to make further CSS changes. If so, I’m not sure whether that is by accident or design. Either way, I’ll take it for as long as it lasts, but may seek another (clean) theme if it goes away.

WordPress.com Custom Design: A Logical Price Rise?

WordPress.com has long provided a Custom CSS upgrade. I’ve been using Custom CSS here at ChangingWay.org ever since the blog has lived at WordPress.com and used the Simpla theme.

Custom CSS is now part of the Custom Design upgrade. Custom Design costs $30 per blog per year, twice what Custom CSS used to cost. So what else does the extra $15 buy? Well, you get more help with CSS from WordPress.com now. Back in the Custom CSS days, you paid to be able to edit CSS, and WordPress.com was explicit that it didn’t provide support to you in getting the CSS right.

But the main difference between Custom Design and Custom CSS is: Custom Fonts. In fact:

Custom Design = Custom CSS + Custom Fonts + Support.

Custom Fonts refers to the use of Typekit. CSS and Typekit go logically together, as I noted when I first tried Typekit. That was two years ago, before Typekit became available at WordPress.com. It would have made sense to me had Typekit been available as part of Custom CSS. After all, CSS allows you to specify fonts (among many other things), while Typekit lengthens the list of fonts you can use.

Instead, when WordPress.com first made Typekit available, it opened the Typekit door to all users, at no charge, while providing minimal support. I played around with Typekit at this blog, used it elsewhere, and responded to some questions about Typekit in the WordPress.com forums. But ChangingWay.org currently uses CSS, rather than Typekit, to specify fonts.

WordPress.com announced the Custom Design upgrade earlier this year. To recap, this means that for $30 per blog per year, you can get the combination of Custom CSS and Custom Fonts, with support for both. The combination is a logical one and, at less than $1 a week, seems reasonably priced – to WordPress.com, and probably to many of its bloggers.

But, to other WordPress.com bloggers, the bundling of CSS and Fonts into a single $30 package represents an unwelcome change. One blogger recently complained in the forums that he cannot use Typekit for free anymore (but follow the link to the thread for a way in which bloggers already using Typekit can continue to use it at no charge).

To me, Custom Design represents a doubling of the price I pay for using Custom CSS at this blog. I don’t need Typekit, and I don’t need CSS support. The price change is an input into my annual question: should I continue to pay for WordPress.com upgrades, or should I move to another WordPress host?

What are your thoughts on the Custom Design upgrade and its pricing?

Freemium and Fencing

Freemium mashes up free and premium:you can use a freemium service, such as WordPress.com, at zero cost; you can pay for premium features. I pay to add two such features for this blog. One of the features maps the domain changingway.org to changingway.wordpress.com.

The other paid feature I use is custom CSS (see one of this blog’s first posts for an account of how I use it).

The fence between zero and any positive cost is perceived as high. So some users of freemium services seek means of effectively getting a premium feature without paying the price for it: these “loophole-lookers” seek holes in the fence.

The WordPress.com custom CSS upgrade seems particularly prone to attract loophole-lookers. I base this mainly on posts in the WordPress.com support forums, some of which include arguments such as: some other hosted blogging services don’t charge for CSS; I only want a little bit of CSS, so why should I be hit with the full charge?

One particular forum thread started about a week ago with a question about changing the background color of a theme. Responses so far include:

You need custom CSS to change the background color.
No you don’t. Here’s some code you can include in a text widget to style the background color of the whole blog.
That loophole is going away soon.

The 3rd response is particularly interesting because it’s by Matt Mullenweg. He does use the word loophole.

This raises the question of how WordPress.com will change with respect to inline styling. And indeed, that question has its own forum thread.

I hope that WordPress.com will not, as one response in the thread suggests, use the blunt instrument of stripping out all inline style attributes. I think it would be reasonable to allow the occasional use of inline styling for things like using a font or image positioning appropriate to a particular post.

It would also be interesting to watch. The fence between free of charge and paying for custom CSS would see a fencing match. WordPress.com will plug the loophole of style code in a widget to style the whole blog. The riposte might involve putting similar code in a sticky post.

What do you think WordPress.com will do? What do you think it should do? I’d welcome comments addressing either or both of those different questions.

Typekit Made Simpla

The previous episode of Typekit Tales focused on the hero’s struggles with Typekit at WordPress.com, and involved his getting help. Help did arrive, followed by some thoughts about easing the struggle.

This post is intended to ease the struggle for those who follow the hero along the Simpla path: in other words, for bloggers who use the Simpla theme, especially at WordPress.com. In order to apply change the fonts you use, here is how to refer to some of the parts of your blog.

Everything*: body
Blog title: #header h1
Blog tagline: #header p
Post title: .entrytitle h2
Title of sidebar sections, including widgets: #sidebar h2

* Note that everything means everything not overruled by more specific CSS selectors.

I used Anisette STD Petite for everything, then Intruder Alert for the headings. As before, I chose those particular typefaces because they are distinctive rather than because I think that they improve the blog. So they will survive at this blog only in the illustrative image.

The post title should probably read Typekit for the Simpla Theme, but I couldn’t resist the one you see above.

Trying Typekit

Intruder Alert! That’s the name of the font currently gracing the title (Changing Way) at the top of this blog.

I chose that particular font to check whether I could get Typekit working here at WordPress.com. It’s hardly a subtle change from Tahoma, the main heading font for this blog, and it looks nothing like Georgia, the workhouse here. For this testing, I wanted an intrusive font, and was amused when I found one appropriate in name as well as in appearance.

This isn’t the first time I’ve tried Typekit, or posted about it. In my earlier post, I recommended that Typekit be available at WordPress.com, and linked it to the CSS upgrade.

Typekit has since arrived at WordPress.com, but doesn’t require the CSS upgrade. Well, in a way it does. Consider the following barriers to changing the CSS on a WordPress.com blog: (1) it costs money; (2) it requires knowledge of CSS; (3) it requires knowledge of the way CSS is used in the blog’s particular theme.

I find the third and last of these barriers to be the highest. What heading level does a WordPress theme use for the blog title? for the tagline? for the post title? for headings in the sidebar? And what other selectors (besides h1, h2, etc.) are used, and how are they used? The answer varies between themes.

The theme I’m currently using, Simpla, uses h1 for the blog title. So to test Typekit, I used its kit editor to associate h1 with the distinctive Intruder Alert. That font was for some reason applied to the blog’s tagline (rather than to its title).

I emailed Typekit support over the weekend, and today received a response. I needed to use the selector #header h1. At a more general level, I need to be aware of CSS selector specificity.

My point, and I do have one, and I am getting to it, is similar to this one. Getting TypeKit to work on your blog can be frustrating especially if you are not familiar with CSS. That’s a quote from (and a link to) a guide to using Typekit at WordPress.com. The guide is good, but the quote could be more specific. You need to be familiar with the CSS of the theme.

My CSS isn’t terrible. I’ve tweaked a few themes, including Simpla for this blog. I found Typekit it harder to apply Typekit to that CSS than I did to tune the CSS itself.

I suspect that using Typekit is trickier than editing CSS. I’m generalizing, not only from my own experience, but from what others have written (in, for example, a post in the WordPress.com forums).

So, although Typekit has lower financial barriers to use than the CSS upgrade, it has higher overall barriers to use. I have concerns about this. One is that it’ll cause frustration for WordPress.com bloggers who see that they can try Typekit for free. The other is that Typekit support may be swamped. Anyway, time to email thanks to the Typekitter who supported me.

Printable Blogs

It should be easy to get a good print of a post or page from a blog. I like to think that’s true of this blog. If so, it’s no thanks to me: my tinkering with the style sheet for the Simpla theme has not included anything specific to printing.

A couple of posts reminded me of this today. One, at ReadWriteWeb, concerns a printer-friendly version of RWW. It’s an example of a post in which the best points are in the comments, rather than in the original post. Summary: printer-friendliness is a job for the stylesheet.

The other post is Jeremiah Owyang’s account of the Community Manager role, which I’ve had cause to refer to and forward to others. There looks to be some great stuff in the comments, as well as in the original post. So I’ve taken advantage of the printer-friendliness of Jeremiah’s blog to run off hardcopy as part of my lunchtime reading.

Of the many silly predictions made about computers, the one that makes me smile the most is that they would reduce the amount of paper used. I regard computers and paper as complements, rather than as substitutes. To put it another way, paper is an information technology, and often a very effective and appropriate one.

WordPress.com CSS Upgrade

A few months ago, there was a topic in the WordPress.com forums in which the nature of the CSS Upgrade was clarified. The question was: what happens if you decide not to renew the upgrade?

To illustrate it using this blog: I purchased the CSS upgrade about a year ago, for $15. I had to decide whether to renew it. I learned from the above-linked forum topic that, if I didn’t renew the upgrade, my existing CSS edits would stay in place, but I wouldn’t be able to make further CSS edits without the upgrade.

What I learned then now turns out to be wrong. What actually happens is that although the CSS is ‘retained’ in the system… it is no longer displayed on your blog.

So: “Purchasing the upgrade entitles you to use Custom CSS on one blog for one year.” That’s what the Custom CSS page currently tells us. It used to tell us that “Purchasing the upgrade entitles you to edit CSS on one blog for one year.” The emphasis is mine. The old quote comes via Mark of Automattic.

I’m disappointed. That’s not because I feel forced to purchase the upgrade for another year. I purchased it before seeing that the rules have changed. I was thinking of making a few more tweaks to my custom CSS and then giving up the upgrade, but decided that I’ll probably want to make a few more in the coming year, and that it’s only $15.

No, I’m disappointed that we clarified the policy, were pleased with both the policy and the clarity, and now find that the policy is less favorable to users than we thought it was.

WordPress.com: Upgrades

I have two questions for you. I need to lead up to them…

Shortly after starting this blog at WordPress.com, I chose the Simpla theme, purchased the custom CSS upgrade, and customized the CSS. I also purchased the domain mapping upgrade.

That was almost a year ago. The theme-related posts (to which I linked above) have been steady sources of page views ever since.

My WordPress.com dashboard has started to remind me of the anniversary, and that I need to buy Automattic an anniversary present if want to continue the CSS upgrade for a further year. I’m inclined not to purchase it, since the custom CSS already in place will stay. What you purchase is editable CSS, rather than custom CSS; this was clarified in a support forum topic.

So the first of my questions is: are there any further changes to the CSS for this blog I should make before my upgrade runs out at the end of this month? In other words, CSS geeks, is there anything else I should change?

The second of my two questions is: why isn’t the dashboard reminding me of the fact that my domain mapping upgrade is about to run out? It expires at the same time as my CSS upgrade. It may be something to do with the fact that I buy the mapping, and not the domain itself, from Automattic.