Marcin Wichary has a fantastic series of posts documenting Medium’s commitment to beautiful web typography. Apart from being intrigued about some of the little tricks they use to enforce better typing habits, like disallowing users from entering two spaces in a row, I was also interested to read the technical supplement for designers and developers. It reminded me of a few things I’ve been meaning to add to my main theme and introduced several things I hadn’t really thought about.
I have been experimenting with a custom AJAX page loader for my WordPress blog in recent months. Today I broke this project out into its own repo, available here: WP AJAX Page Loader. It is readily installed via Bower:
bower install wp-ajax-page-loader. Some additional work is required to integrate and configure this script for your own projects.
I starting working on this project after learning about some of the many problems associated with history.js, a polyfill that many infinite scrolling implementations rely on to this very day. After having a look at some of the options I decided to adapt one of my own scripts to achieve pretty much the same effect with a much smaller payload size and a bit of a smoother user experience (or one that suits my needs anyway).
This script requires jQuery (already included in WordPress), HTML5 History API, and spin.js. Without jQuery (but with the other dependencies) it clocks in at about 15.5 Kb minified (comparable to the 21 Kb of Paul Irish’s Infinite Scroll).
Read the documentation or peruse the source code for more information or have a look at Pendrell for an example of integration and configuration. This script is currently active on this site so you should be able to demo it by browsing around any of the archives and clicking on “next” (or simply positioning the viewport near—but not at—the bottom of the page, for I am running the script in “footer safe” mode).
This week I have challenged myself to get up to speed with responsive images and Picturefill, a polyfill for the upcoming HTML5
picture element as well as two new attributes for the
img element. It wasn’t easy—there’s a surprising amount of reading and processing that needs to be done to understand the many problems and proposed solutions to responsive images on the web. Along the way I realized that I am not yet hugely interested in the art direction use case—which means I have focused more of my time on two less hyped
img element attributes,
sizes. Together these provide for most of what I am interested in: swapping source imagery at different resolutions.
A comment archived from Twitter:
Another WordPress thing that should be easy but isn’t: removing the taxonomy base from the URL. ‘Use a random old plugin’ is not a great option.
Responsible use of WordPress plugins requires code evaluation. Sometimes this is easy and straight-forward but at other times one must stop and ask about the benefit derived versus time invested. For this little feature I decided I had better come back to it later. Some promising leads:
Writing term descriptions for categories, tags, and custom taxonomies can be a real chore in WordPress. It is easy enough to edit term names and slugs with the quick edit box but if you’d like to edit descriptions it will be necessary to open up the full edit screen. This is less than optimal if we wish to write or maintain complex taxonomies with dozens or even hundreds of terms.
WordPress is highly customizable and extensible so there’s a way of making this easier. Of course, this being WordPress, things aren’t nearly as straight-forward as they could be. The problem, in this case, is that you cannot hook the
quick_edit_custom_box action without the presence of a custom column. Since
description is among the default columns this action is not called and there is no opportunity to modify the contents of the quick edit box. The current solution (as of version 4.0) is a bit of a hack: use a hidden custom column to trigger the
quick_edit_custom_box action and output the necessary HTML.
Recently I wrote a little about using Markdown and WordPress together. This time around I’d like to share some tricks for using Markdown in term descriptions.
But first, a recap. Terms, in WordPress jargon, are objects in a taxonomy—a system of organizing content. WordPress ships with categories (which I don’t use) and tags (which I do—extensively). You can also implement custom taxonomies to organize content in whatever way you wish. I happen to organize some of my posts into series and many others by location but the sky’s the limit as far as custom WordPress taxonomies are concerned.
When I started using Chinese characters on this blog I quickly ran into several issues:
- WordPress incorporates actual Chinese characters into permalinks e.g. the slug for a post titled ‘Wuchang temple 武昌宮’ will be
http://synapticism.com/wuchang-temple-武昌宮. This works well enough but isn’t great if you prefer URLs that are easy to remember and type.
- Pinyin tone markings aren’t available in most fonts. If you use pinyin in post titles your content will typically end up looking rather ugly, both on your blog (if you aren’t using a header font with the requisite characters) and on the rest of the web (whenever your content is shared).
In WordPress there are all kinds of different ways to approach problems like these. I am generally interested in a parsimonious solution that doesn’t involve a plugin or a lot of extra code. I’ll readily sacrifice perfection for “good enough”. Here’s what I came up with…
Markdown is an awesome shorthand system to format text on the web. I have been using it for slightly more than a year now and absolutely love it. Peruse the syntax and you’ll see why—it’s easy to pick up and builds on many existing patterns of usage.
Using Markdown with WordPress is fairly straight-forward. You’ll need a plugin, of course, and there are many to choose from, as always. I currently use JP Markdown, a repackaging of the Markdown module from Jetpack, Automattic’s sprawling mega-plugin, which I am otherwise not interested in using.
Recently I noticed that one of my WordPress blogs was running an alpha version, automatically installing nightly builds. It seems I am not alone in noticing similar behavior, though I don’t think I was affected by the exact same bug.
At any rate, since I am not actively testing WordPress I went looking for a quick way to downgrade to the latest stable release without manually re-installing everything. I found this article, which offers a succinct solution: open up
wp-includes/version.php and modify the
$wp_version string to
3.9.1 (or whatever the stable version number is at the present moment). Back in the WordPress admin panel simply navigate to Dashboard > Updates and click Re-Install Now.