Achieving enhanced web typography, by a 30-year veteran

This overview takes a look at the various typographic elements I’ve given special treatment on the Hermit Spirit blog and website, including a number of WordPress plug-ins that have been utilized. For those who are more intrepid, what’s covered in this post should hopefully be enough as a jumping-off point to help get started implementing these solutions as well. Although I had experience hand-coding a couple of previous websites (HTML and CSS, though not more advanced code like JavaScript or PHP), I myself could certainly have used an overview like this over a year ago when I began trying to get Hermit Spirit going in my spare time using WordPress.

Higher-caliber typography on the web too much trouble until recently. In the past, even as a long-time career typographer, I did not bother trying to achieve enhanced typography on the web. It was either impossible or just too frustrating, involving too many kludged lines of convoluted code that I felt were ridiculous. With many other business responsibilities to handle at the same time, the excessive code-wrangling it would have taken simply wasn’t justifiable.

This time around, though, it appeared it might actually be possible without having to be a total code-ninja, so I decided to give things a shot. On the downside, as I might have known, it did lead to an untold number of hair-pulling sessions — hours, days, and weeks of experimentation and trial and error in my spare time — often ending in frustration, before trying again later.

Typographic possibilities better now, but still have a way to go. On the positive side, even though the web is still not “there” yet (capable of something reasonably close to what Adobe InDesign can do, we’ll say) it was still gratifying for this lover of the printed word to be able to get as far as I did. By my standards, at this juncture we might be about one-half of the way there. And although high-end typography still has not arrived, things have come far, even if it has taken over 20 years — twice as long as it should have, in my opinion. We are far enough along now that those who don’t mind getting their hands at least halfway dirty may find it worthwhile. The ease-of-implementation “usability” factor still isn’t where it ought to be in many cases, but it’s not as bad as it once was.

Covering primarily typography here, not site design. I won’t be covering much about the overall site layout except as it impinges on the typography. I have purposely kept Hermit Spirit simple in terms of layout for a couple of reasons. One, I was after a minimalist feel intended as an “oasis” for those like myself who want to focus mainly on the written word without distractions. And, two, most of the flashy-looking WordPress and other website themes that one finds are heavily photo-dependent and photo-driven, and fall apart without liberal use of images. I personally do not want either the headache of having to come up with a featured image or other photos for every blog post, nor to be a slave forced to serve the demands of a theme voracious in its need for visuals at every turn. For me that would not be sustainable. (I do employ graphics and photos where truly useful and appropriate.)

Typography’s key role in design still often given short shrift

Professional fonts not enough by themselves

I learned high-end advertising typography in the 1980s when it was a complete craft of its own (just prior to the desktop publishing era), and people seemed to care more about it. Yes, web designers today, and even everyday people, care about fonts. But that isn’t the same as caring about and knowing how to create professional typography that’s actually inviting to read.

Among the criteria for engaging, appealing typography are: not just which fonts one uses but what one does with those fonts — how they’re used in terms of spacing relationships of all sorts, including: kerning, tracking, wordspacing, and typographic “color”; linespacing; dealing with widows and orphans; employing the right kind of size, scale, weight, and style differences for contrast; special touches for extra visual or editorial interest such as pull-quotes; and so on.

Web layout still far ahead of typography

The overall design of websites has gotten sophisticated these days in terms of layout, but in my opinion, typography on the web is usually still very “plain vanilla” on most sites despite the recent explosion in use of a wide variety of professionally designed typefaces. From what I have seen, except for graphic designers who work at advertising agencies or “boutique” studios, most designers — while they may be creative at layout and/or illustration — really do not exhibit much facility with what’s involved in creating appealing typography. This is especially true of web designers, who appear (judging by widespread results) far more often to be code jockeys than experienced in graphic design.

Examples of what’s often missing in action

Attention to better typography on the web is typically shunted aside in favor of “cool” features like photo sliders, parallax-effect images, fancy multi-column layout options, successive full-width horizontal sections for layout, flashy sidebar widgets, tag clouds, “sticky” headers and social-sharing buttons, Google Maps integration, and so forth. Poorly executed or ignored are a range of typographic goodies that can not only beautify the actual text content on the page — which many if not most people come to read in the first place (no, you must be kidding!) — but that can increase readability and readership both. Visually prominent among these ingredients are:

• Drop caps: A single, extra-large capitalized letter that begins the first word of the body text in a new chapter or section of a piece of writing, to draw attention and beautify the text. A drop cap is inset into the body of the text, with its baseline resting on the baseline of the second, third, or some succeeding line of text, and the top of the cap aligning with the cap line of the first line of the body text. (Raised caps, an alternative, rest on the same baseline as the first line of text.)
• Pull-quotes: Quotations, hopefully of a compelling nature, pulled out of the text copy and typeset as a larger block, usually somewhere near the original occurrence, to attract attention and pull readers into the body. More themes nowadays are including these but they tend to be implemented rather crudely or unimaginatively, or take up the entire column width forcing readers to jump clear over them when reading the adjacent text itself.
• A thoughtfully designed hierarchy of heads, subheads, and bold paragraph lead-ins that goes beyond today’s typically monotonous, one-dimensional size variations all using the same font weight and styling. (And just about always from the same font family as the body copy as well.)
• Intro “decks”: Concise summaries or teaser copy of anywhere from a few to several lines set in a larger and/or contrasting font from the main body text, to pull readers into articles. (The introductory text to this post, set larger in Sanvito script, is an example.)
• “Kickers”: Short lead-in or teaser phrases of a few words set in a smaller font just above the main post or page headline.
• Use of a contrasting font variation for captions — whether italic, bold, bold italic, or a second, complementary font family entirely — and designed in an integrated way to set off the overall theme’s typography, rather than as an afterthought that doesn’t enhance the look.
• Alternate text formats for variety depending on the subject matter of a post or page. See the Life Sucks, and Then You Die humor post on the site here for an example of something different from the norm when the writing approach could benefit from it.
• Planned use of thematic second and/or third colors for various elements in the text for contrast and added visual interest. On Hermit Spirit, I’ve used teal and copper for various elements to contrast with the basic black of the body text.
• Colored or alternate non-default bullets. Teal-colored bullets were set up as an option I can use as desired here.
• More stylish or raised numerals as an option for ordered lists. See the Cats versus Kids post here for an example.
• Use of horizontal rules or typographic ornaments as dividers in body text when appropriate.

Then there are lesser-noticed or more subtle aspects of typography that can work to enhance the feel, professional appearance, readability, and legibility of the text without the reader necessarily being aware, such as:

• Attention to comfortable-to-read text column widths for posts and pages intended for more extended reading — neither too wide (I’m looking at you, Divi and Avada, to name two of the best-selling WordPress themes ever) nor too narrow.
• Font size large enough to read comfortably for anyone over 40 years old. (Virtually all popular themes set the default point size much too small — ditto for Divi and Avada, once again.) Not to mention a font size large enough to bring out the real beauty and visual appeal of a typeface. On the web, type size needs to be larger for more subtle font features to become apparent, due to more limited computer monitor resolutions compared to print. Also, people tend to sit back further when reading on computer monitors than they do reading books due to the wider field of view.
• I would suggest 1rem/16px as a bare minimum for news articles and blog posts, and larger is almost always better. (1.25rem/20px is the value in use here.) The result need not look “too big” or clunky if the designer knows how to handle type properly in terms of various spacing relationships — tracking, line-height, column width, white space around the margins, designing a hierarchy of size/font relationships between body text and headlines for best contrast, etc. Obviously, the font-size value will need to be scaled down some for sidebar widgets, footers, and media queries targeting smartphones and similar-sized devices.
• Small caps: Capital letters the same size as the x-height of lowercase letters — or slightly larger in some cases — that blend in better with running text than regular capitals without sticking out so much. True small caps, as opposed to what are called faux small caps, are different than a simple reduction in size of regular tall caps (which would result in a lighter stem weight). Instead, the stems are drawn to match the weight of the surrounding lowercase, and the width of the letterforms is increased slightly to maintain openness of the counters at the smaller size.
• Uses vary, ranging from replacing typical regular-cap acronyms, to serving as an alternative way to emphasize words in running text instead of italic, to providing a distinctive way to style the initial phrase of the first paragraph in a new section of a document.
• Widow control: A widow is a very short string of characters on a line by itself at the end of a paragraph. Widows are considered undesirable because they tend to look like a stray isolated fragment not well integrated with the fuller lines above, and can be visually distracting.
• A widow can be either a single short word or a brief phrase consisting of two or three tiny, two-or-three-letter words. The number of characters on the last line, or sometimes, the percentage of the total column width — not how many words — is really the determining factor. In the “olden days,” before desktop publishing, an average figure for how many characters constituted a widow might have been anything less than, say, seven or eight characters. A widow consisting of the remaining portion of a hyphenated word is usually considered the worst kind.
• Ligatures: Combinations of two or three characters that have been redrawn by the font designer to be rendered as a single glyph for better aesthetics. The purpose is to fix certain “problem” character combinations — typically “fi,” “ff,” “fl,” “ffi,” and “ffl” — to remove distracting visual artifacts where part of one character overlaps another. For example, depending on the design of the alphabet, the right overhang of lowercase “f” may crash into the i-dot in a way that creates a bit of a hickey or visual dark spot.
• Another combination sometimes addressed by ligatures is “Th.” If the T-bar is wide enough that a large hole will be left underneath the overhang before the “h,” the font designer may create a ligature to blend the bar into the “h” in a smooth way while also shortening the right side of the T-bar a bit to reduce the visual hole.
• Ligatures in particular are not something most readers will consciously notice, but subliminally they make for cleaner-appearing text.
• Style-sheet formatting in the WordPress editor, lastly, makes it possible and easy for post and page authors to both quickly apply the above features to text as well as verify successful application of them. This is not often available, but the instant feedback greatly aids the process of composing and editing articles to a higher caliber of typography.

Typography on the web is filled with land mines

Even for someone like myself who’s done paid typographic work most of my adult life, achieving good typography on the web — at least using WordPress — can be difficult and fraught with land mines at times. The number of contortions I have had to go through in the initial design of this site to get the typography I wanted has been dumbfounding and often maddening in comparison to the ease with which it can be accomplished in professional graphic design applications such as Adobe InDesign or Illustrator, QuarkXPress, or CorelDraw. Or even in Photoshop, which is somewhat on the clunky side in comparison to the others just mentioned.

I am sure I cannot be alone among those originally from the print-design world, most of whom must marvel in frustration at how ridiculously complicated and unforgiving it is getting good typography to happen on the web.

Three examples of problems worked around: small caps, drop caps, and pull-quotes

To point to three examples: the drop cap at the beginning of this paragraph, the small-caps phrase following, and the pull-quote in the paragraph below all involved considerable hair-pulling to get working properly. (Note: If you are reading this on a smartphone, the pull-quote may not be present. I’ve disabled pull-quotes for viewport sizes below a certain width, due to word-truncation issues when the reduced size of the pull-quote container cannot accommodate longer words.) I’ve provided options for handling these elements further below, but first I want to look briefly at the types of tradeoffs one can face when it comes to implementing typographic features like these on the web.

Small caps

Missing from fonts, or no browser support. Take the lead-in small caps on the first line of the paragraph above — there is still no universal CSS for small caps that has true cross-browser support. For example, see Adobe’s discussion of the thorny exceptions as well as recommended code using vendor prefixes to force browsers to cough up the built-in small caps in fonts. Which I would have done myself, but with Hermit Spirit I didn’t have that option because the font I chose for the body text here, Angie Sans, doesn’t include true small caps, at least not in the web version available on Typekit I’m using. (The designer does include them in the font. Adobe — of all foundries! — just hasn’t made them available for some reason.)

Consequently, I was forced into using the time-honored kludge of scaling down the size of uppercase letters to simulate small caps. Many experts will tell you it’s a mortal sin to do this, of course, because doing so unavoidably also decreases the stroke weight, as is well known, resulting in a bit of a mismatch in weight between the small caps and surrounding text. However, what is the alternative? Nothing at all? I’ll therefore be suggesting a few things one can try in the bag of tricks further below.

Drop caps

Plug-in limitations/oversights. Then I ran into the problem that Adobe’s drop-cap plug-in wasn’t able to cope entirely successfully with the scaled-size approach used for neighboring small-cap text. On Hermit Spirit, along with drop caps to call attention to a new section of text, I have employed the practice of putting the initial phrase of the accompanying lead paragraph in small caps. Using faux small caps by means of a scaling factor slightly skewed the drop-cap plug-in’s calculation of where to place the baseline of the drop cap so it will align with the adjacent baseline of text.

I was able to fudge things and set the plug-in’s parameters to compensate and achieve “close enough” base-alignment — that is, assuming the small caps didn’t wrap from the first line into a second. No problem on desktop browsers with their wide screens, but when viewed on a smartphone, the small-caps lead-in phrase would sometimes wrap to a second line, throwing off the base-alignment of the drop cap.

At that point, my solution was to use a media query to disable display of small caps for the small-caps lead-in phrase on mobile devices with a viewport size below a certain breakpoint, and just display them as normal lowercase to preserve better, though still not ideal, base alignment. (Later note: After further experimentation, I arrived at values for the plug-in’s parameters that give a pretty good compromise for base-alignment of the drop cap with adjacent small caps, even when the latter wrap to an extra line or two on small mobile devices.

Pull-Quotes

Plug-in bugs. The pull-quotes have worked pretty well without any issues except a couple so far: I found that when using CSS styling of white-space: nowrap for the last couple of words within the pull-quotes to prevent widows, it would cause the web page to freeze up and time out. The solution here is either to use no-break spaces ( ) instead, or just let widows occur. (Note: the widow control in the wp-Typography plug-in, discussed later, will handle them for the Graceful Pull-Quotes plug-in I’m using under some but not all circumstances.)

Unfortunately, no-break spaces don’t show up in WordPress’s page/post editor any differently than regular spaces, though, so you may not remember that you added one when re-editing a document later on down the road, and could therefore end up with bad line breaks. (I therefore decided to just live with widows in the pull-quotes, while grinding my teeth a bit.) I am actually a big fan of the Graceful Pull-Quotes plug-in. Nonetheless, even with things you like, you still sometimes need to deal with bugs and either find workarounds or just compromise.

A second issue was that a WordPress caching plug-in I was using to minify JavaScript caused Graceful Pull-Quotes to fail. In this case, because Graceful Pull-Quotes works so well, I was willing accepting the compromise of not minifying JavaScript.

DTP typography “just works” — enhanced web typography often doesn’t

Two different worlds. None of the issues described above are a problem using Adobe InDesign, for instance. It all just works. Easily. Elegantly. Perfectly. Without fail. (Ahem, well… there is one exception. Widow control, which works very well in justified copy in InDesign, has been seemingly overlooked when it comes to flush-left, ragged-right settings.) On the web, however, with a few exceptions, most typographic features or enhancements like the above, at the current time (early 2016), do not “just work.” A technique or plug-in may work in some situations, then fall short or fall apart under other conditions. You may have to engage in workarounds or accept compromises, or both. Fortunately, most of the time I was able to automate or semi-automate things so at least they aren’t too fiddly in actual use, but still…

CSS experience usually needed. Also, generous helpings of CSS coding, experimentation, and troubleshooting are often required to style and massage the output from a plug-in well so it really shines at its job. That’s because as good at coding as some developers may be, nonetheless most of them just don’t have the typographic eye needed for things to look that great, straight out of the box.

Targeting the relevant code for typographic styling with CSS selectors remains a black art. Also, as anyone who has tried it probably knows, by far the most frustrating thing of all is trying to find and then successfully target with CSS selectors the appropriate bits of code in a WordPress theme to change its typography. Once you actually get those bits of code properly selected, in many cases it is not necessarily all that hard to massage the basic typographic result. But for me, even using Firebug (as typically recommended), successfully pinpointing those bits of code with a correctly crafted CSS selector in the first place is perhaps the most difficult aspect of the process. That alone easily quadruples and in truth more probably quintuples, sextuples, or even septuples (need I continue?) the number of hours it takes to get results.

It is therefore no wonder that prefabricated WordPress themes are so popular. But even these themes often do not pay much attention overall to the typography despite lip service in that direction. So there you are: thrown back on yourself to get the job done on your own if you really want more richly executed typography.

With that as an introduction and caution about the kinds of things one might expect to deal with, here’s a rundown of the WordPress plug-ins and other techniques I’ve used to achieve the various typographic “extras” seen on the website.

Fonts used on Hermit Spirit

Adobe’s Typekit for fonts

• Body text: Here, I’m using Angie Sans, a humanistic sans incorporating tapered stems, from Typekit. I did consider Google Fonts, however as a professional typographer I’ve been spoiled.
• In exploring both companies’ web-font libraries, it doesn’t take long to discover that Google just doesn’t provide the breadth and depth of offering Adobe does. (No surprise there, of course, for anyone familiar with the landscape of type design.) I wasn’t able to find what I was looking for in Google’s library: a highly readable and inviting humanistic sans with a hint of calligraphic feel (Angie Sans), as well as a fully calligraphic semi-script typeface with a renaissance-era appearance for headline and display usage, and available in several weights for best adaptability to different situations (Sanvito, see below).
• Also, Adobe takes great care with what is called the “hinting” of its web fonts, so that the appearance on devices with limited resolutions like computer screens maintains the highest degree of fidelity and smoothness possible. Since I already pay for Adobe’s Creative Suite software license as a necessity in my line of work, and which gives full access to Typekit for web fonts, for me it wasn’t much of a choice.

• I don’t know how others feel, but personally, I find that many of the sans serif fonts used on the web today are too monoline in appearance and monotonous for the purpose of extended reading on a blog — tiring to read at length after a while. I first looked at serif fonts (Calluna was my initial selection), but in the end decided computer-screen resolutions may still not be quite high enough to use serif fonts to best effect, at least for my taste. But more importantly, I could not find an oldstyle serif with quite as much of a calligraphic feel as I wanted, which is what I was really after as long as it wasn’t too “in your face” or distracting. One I’ve used in the past that I like is ITC Gilgamesh, but it isn’t available from Adobe Typekit.)
• After combing through Typekit’s offering typeface by typeface, I ran across Angie Sans. (I was familiar with Angie, the serif version, but hadn’t realized a sans companion existed.) The typeface was really just what I was looking for in terms of a restrained calligraphic appearance that was inviting, and easy on the eyes for extended reading.
• Heads and subheads: Sanvito, by Robert Slimbach (1993), was my choice here, and it’s also employed for dressing things up in certain other situations. For a display typeface, I wanted a font with a very strong calligraphic flavor to catch and please the eye, but also a literary, renaissance-era feel. And I wanted multiple weights to choose from for versatility — Sanvito has four — which is rare to find in a script like this. I also looked at Vatican, which has three weights, but decided it was too condensed and a little too quirky or distracting without the same tasteful, literary feel of Sanvito. (In another situation, it might have been just right.)
• The tradeoff to using a script font like Sanvito is there are no italics (how could there be for a script?). Since italics are preferred in publishing for indicating the titles of literary and artistic works, that meant if something like a book title occurred in headlines or subheads (in a review piece, for instance), I would need to use quotation marks instead. Not ideal, but newspapers did it for decades, and typically still do even today when there is no real need. (This is undoubtedly due to AP Stylebook rules, which are easily 50 years behind the times when it comes to typography — based on my experience as a freelance proofreader, having had to use the guide myself since the ad agency clientele I serve often follows it.) Overall, to me, though, this tradeoff in using Sanvito was worth it for the added zest and humanistic feel the typeface brings.

Plug-ins for enhanced typographic features

Adobe’s dropcap.js

Download plug-in (for any website). This JavaScript plug-in is really the only worthy solution of any kind currently available for traditional drop caps. It will work with any site (WordPress or not), and works well in modern browsers except for the slight alignment issue when neighboring faux small caps are used, mentioned above. The algorithm used is slated for eventual implementation into CSS as the initial-letter property.

Older browsers it does not work in are IE8 and IE9. In IE8, no drop cap is generated at all. The initial character of the paragraph remains the original size instead. In IE9, an initial cap is created — at least for the first drop cap on a page — but it’s centered vertically on the first line of the paragraph, therefore crashing into items at the bottom of the preceding paragraph. Subsequent attempted drop caps on a page produce no result, as with IE8.

To use dropcap.js, upload the JavaScript file to the folder for JavaScript on your site, or the appropriate place in the /wp-content/themes/ folder structure of your WordPress site, then put the following snippets of JavaScript where footer scripts go for your HTML. The code below shows the parameters used on my site. Be sure to change the script src="yourwebsite/file" code to point to the correct location for your site.

    <!--Adobe dropcap.js--> <!--Three parameters are (CSS class,
    heightInLines, baselinePos). Baseline value 3.0075 instead of 3 to compensate
    for how faux small caps affects base-alignment calculation--> <script
    src="http://www.yourwebsite.com/wp-content/themes/yourtheme/dropcap.min.js"></script>
    <script> var dropcaps = document.querySelectorAll('.dropcap'); window.Dropcap.layout(dropcaps,
    3.0325, 3.0075); </script>

Here is the CSS I used to go along with the above:

    /* Adobe's dropcap.js drop-caps */ .dropcap { font-family: "angie-sans";
    font-weight: 400; color: #856135; }

Tips: You might want to try Adobe’s interactive demo page to get a feel for how the parameters in the JavaScript code above work.

• If baselinePos and heightInLines are the same, you get a drop cap, but you can create a raised cap instead by setting baselinePos to be less than heightInLines.
• Thoughtfully, the values can be fractional if you like. This enables baseline adjustments, as well as setting the size of a drop cap so that, for instance, you can have it jut a little above the cap line of the first line of adjacent text. And a fractional value for heightInLines allows for handling any unforeseen situation where you might want to adjust the cap alignment more to your liking, if something is perhaps a bit off optically due to the design of the alphabet you’re using for the drop caps. (Note: Fractional values aren’t allowed for in Adobe’s online demo, but they will work if used in the JavaScript code parameters.)
• Also, note that the drop cap or raised cap need not be the same font as the body copy. With CSS, you can style the drop cap to be different.

Adobe’s jquery.balancetext.js

Download plug-in (for any website). This additional plug-in from Adobe uses an algorithm they call BalanceText to break multi-line, centered text so that all lines in a paragraph or headline are roughly the same length, eliminating short final lines that look odd. Theoretically, it should also work in any ragged-set copy (flush-left or flush-right in addition to centered), but see my “Disappointing Note” below. As with dropcap.js, this plug-in is also web platform-agnostic.

In addition to centered blurbs, I tried using jquery.balancetext.js for heads and subheads on the site, except for the main article head for each WordPress page/post, which isn’t directly targetable with the plug-in. PHP would apparently be required to expose it to the plug-in, which I would have to get into later sometime. (The wp-Typography plug-in for WordPress covered below will deal with widows in the main page/post headline, as well as other heads, but that’s different than what BalanceText does.) In any event, Adobe’s algorithm (presumably adapted from InDesign’s “Balance Ragged Lines” feature) is superior for this type of thing and would be the preferred way to go.

To get the plug-in working, upload it to your site’s JavaScript folder, and include this JavaScript snippet to go in your footer scripts (changing the source location for the plug-in as appropriate):

    <!--Adobe BalanceText--> <script src="http://www.yourwebsite.com/wp-content/themes/yourtheme/jquery.balancetext.min.js"></script>
    <style type="text/css"> /* Plug-in looks for elements with class
    named "balance-text" */ .balance-text { text-wrap: balanced; /* Apply (proposed)
    CSS style */ } </style>

Disappointing note: Unfortunately, I ran into a bug with jquery.balancetext.js while editing this article that I could not find any workarounds for, so I had to disable the plug-in, at least for heads and subheads set flush-left. (I am continuing to try it for paragraphs that are centered, such as introductory quotations that might be inserted above the opening paragraph of posts — my initial “use case.”)

Basically, the plug-in would sometimes break h2s or h3s set flush-left into more lines than it should have. For example, more than one headline that could easily have fit on two lines was broken into three instead. On a smartphone, the same head should have taken three lines, but went to four. Ah well, too bad, and a shame.

And to think this code is under proposal for the text-wrap: balance property to be standard in CSS eventually. Hard to believe Adobe’s web design/coding engineers have not encountered this bug yet, when I did so just within the first 24 hours of use. Hopefully, at some later date, Adobe will get things fixed here.

Clean My Archives

Download plug-in (for WordPress). This plug-in auto-compiles “one-liner” archives by date. (For an example, see this site’s archives, accessible from the main menu bar.) I don’t know about other people, but to me the default WordPress archive pages are hugely cumbersome to have to wade through. Please just give us a way to spit out simple one-post-title-per-line archive listings that are quickly and easily scannable. This is what Clean My Archives does, and it does the job very well. It has one drawback, however: it outputs only date-based archives. You say you want category-based archives as well — like I do? Sorry, it’ll take yet another plug-in (YAPI ;-) ). And that plug-in is:

Archive-Pro-Matic

Download plug-in (for WordPress). There may be other category-capable archive-generating WordPress plug-ins out there, but this is the only one I was able to find that lets you output them in one-liner form. As with Clean My Archives, it works well, but it too has a drawback: it’s not intelligent enough to know which categories have posts associated with them, and to spit out a one-liner listing that’s automatically separated into each of those categories. Instead, it’s up to you to insert a shortcode yourself for each category where you want them to go. It’s also your job to typeset your own subheading above each category as well. So it’s not a “set and forget” plug-in like Clean My Archives, but as far as I know, currently there’s nothing else that goes even as far as it does.

Graceful Pull-Quotes

Download plug-in (for WordPress). As of this writing, no other WordPress plug-in for pull-quotes comes close to this one, as far as I am concerned. It gives you a couple of highly desirable things that others don’t:

• The ability to automatically alternate which side of the surrounding text column (left or right) in which the pull-quote occurs. Not only that, you can override that automatic placement for any given pull-quote, and put it on the other side instead, simply by setting its class to .pqLeft or .pqRight for that quote. And smartly, it then adapts to what you’ve done by putting the next quote on the opposite side of the column and continues alternating after that without a hiccup.
• Also, you can substitute an edited pull-quote in place of the original wording of the quote contained in the body text if you like. From an editorial point of view, this is very often necessary for either of two reasons — brevity, or to adapt the quote so it can stand on its own without reference to another clause or adjacent sentence that the original may be grammatically dependent on.
• Finally, the same option that enables substituting edited pull-quotes gives you the ability to locate them in any paragraph you like. This is helpful if the pull-quote text also begins the paragraph in which it would otherwise occur. The lead sentence in a paragraph is the one most easily noticed as the eye scans down the page, and pull-quote text obviously jumps out as well. You don’t want both occurrences of the same, or similar, text easily visible simultaneously (“doubled”) right next to each other. In such cases, therefore, it’s usually better to place the pull-quote somewhere nearby, but not immediately adjacent.

Here’s the fully functional CSS for how the plug-in’s output was styled on Hermit Spirit. Basic CSS is provided in the developer’s plug-in package, which I began with. However, I added and tweaked a lot from there, and code from both sources is reflected here. (Note: Media queries aren’t shown in the code below, but I should mention that I’ve disabled Graceful Pull-Quotes for mobile devices below a certain viewport width. This is due to the fact that the pull-quote container in these circumstances isn’t wide enough to accommodate longer words without force-wrapping them (without a hyphen) to the next line.

    /* Begin Graceful Pull-Quotes plug-in */ .entry-content blockquote.pullquote,
    .entry-content div.pullquote { /* box */ display: block; border: none;
    background-color: transparent; background-image: none; vertical-align:
    middle; /* positioning */ /* Top-margin value controls vertical position
    relative to adjacent paragraph body text. Make sure same value is used
    for .pqRight CSS further below.*/ /* Bottom-margin value controls spacing
    below pullquote and main body text. Make sure same value is used for .pqRight
    CSS further below.*/ float: left; margin: .343em .671em -.157em 0; padding:
    0; width: 43%; max-width: 10.5em; /* typography */ color: inherit; font-family:
    "sanvito-pro"; font-size: 1.69rem; font-style: normal; font-variant: normal;
    font-weight: 600; text-align: left; text-decoration: none; text-indent:
    0; text-transform: none; } .entry-content blockquote.pqRight, .entry-content
    div.pqRight { float: right; margin: .343em .286em -.157em .428em; text-align:
    left; } /* Background gradient for pullquote. */ .entry-content blockquote.pullquote
    p, .entry-content div.pullquote p { background: #e9f4f5; /* Old browsers
    */ background: -moz-linear-gradient(top, #e9f4f5 0%, #f1f6f5 55%, #faf8f5
    90%, #fcfaf8 100%); /* FF3.6+ */ background: -webkit-gradient(linear, left
    top, left bottom, color-stop(0%,#e9f4f5), color-stop(55%,#f1f6f5), color-stop(90%,#faf8f5),
    color-stop(100%,#fcfaf8)); /* Chrome,Safari4+ */ background: -webkit-linear-gradient(top,
    #e9f4f5 0%,#f1f6f5 55%,#faf8f5 90%,#fcfaf8 100%); /* Chrome10+,Safari5.1+
    */ background: -o-linear-gradient(top, #e9f4f5 0%,#f1f6f5 55%,#faf8f5 90%,#fcfaf8
    100%); /* Opera 11.10+ */ background: -ms-linear-gradient(top, #e9f4f5
    0%,#f1f6f5 55%,#faf8f5 90%,#fcfaf8 100%); /* IE10+ */ background: linear-gradient(to
    bottom, #e9f4f5 0%,#f1f6f5 55%,#faf8f5 90%,#fcfaf8 100%); /* W3C */ /*
    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#e9f4f5',
    endColorstr='#fcfaf8',GradientType=0 ); */ /* IE6-9 */ border: 2px solid
    #30929a; border-width: 6px 0 0 0; border-top-color: #339ca6; border-bottom-color:
    #829799; font-family: "sanvito-pro"; font-size: 1.69rem; letter-spacing:
    -.010em; word-spacing: .030em; line-height: 117%; color: #143c40; padding:
    .229em .317em .375em .343em; } /* Capitalize first letter of quote */ .entry-content
    blockquote.pullquote p:first-letter, .entry-content div.pullquote p:first-letter
    { text-transform: uppercase; }

Widow control with wp-Typography

Download plug-in (for WordPress). Controlling widows can be tricky and error-prone when performed by software if the code is not well written. On the other hand, dealing with widows manually can be very time-consuming. Up until quite recently (December 2015), a good automatic solution did not exist anywhere for any web platform, that I know of, until the WordPress plug-in wp-Typography — which had been abandonware for almost five years — was revived and taken over by a new developer. So unless you’re using WordPress, it’s understandable (in this typographer’s opinion) if the “solution” of simply opting out and not worrying about it too much is taken when it comes to websites.

The development of wp-Typography had been dormant from January 2011 until December 2015, when the original developer agreed to turn the code over to another developer who was/is a long-time user of wp-Typography. The plug-in handles a number of other typographic niceties beyond just widow control — including automatic hyphenation in many different languages — and each feature can be turned on or off and adjusted individually. The plug-in can increase page-load times (a built-in caching feature helps address this), so use wisely.

wp-Typography’s competitors: How not to handle widow control. Aside from wp-Typography, I should mention that there are a few other WordPress plug-ins and/or platform-independent JavaScript solutions for widow control available, but in my opinion none of them give desirable results. I have personally investigated the approaches used, and rejected all other than wp-Typography. That’s because the rest are based on the ham-handed method of indiscriminately applying a no-break space ( ) to glue the final two words of a paragraph together, no matter what. In every case it is done without regard for the total number of characters contained in this glued-together unit, which can vary from a measly three or four characters up to an outsize 15 or more, perhaps even 18 or 20 on occasion.

This is just brain-dead — perhaps a quarter to a third of the results look worse than what you started with. While you don’t want widows, neither do you want a hefty chunk of white space pockmarking the end of the penultimate line in a paragraph either. And that’s exactly what you end up with a significant amount of the time by applying a   in willy-nilly fashion to the final two words of every paragraph in a post. If one is going to use  , some method of judgment is required (whether human or algorithmic) to assess the resulting length of the final string of characters, and whether it is acceptable or not. That should be the criterion for a widow, not simply a single leftover word.

The right way to do it. wp-Typography, on the other hand, allows you to set two complementary parameters for widow control: (a) the minimum number of characters allowable in a single-word widow, as well as (b) the maximum number of characters allowed to be pulled down from the previous line to go with widows that fall below the minimum threshold. This is a pretty intelligent approach considering how simple in concept it is. There are better, more sophisticated ways of doing it, but probably not many with as much bang for the buck in terms of simplicity.

Potential improvements: One way to make the algorithm better without getting too complicated would be to specify the maximum number of characters that a widow-cluster could total, regardless of the number of words it contains. Even better: utilize a second criterion specifying the widow also cannot exceed a certain user-defined maximum percentage of the column width, perhaps 15% or so, and if that is not possible, then the algorithm gives up entirely and doesn’t try to fix anything. This second criterion would help prevent a large bite being taken out of the end of the next-to-last line when the penultimate word in the paragraph might otherwise be pulled down to accompany the final word — which can be particularly unsightly on narrow column measures.

One minor bug. I will mention one issue: if hyphenation is turned on in wp-Typography, then you can end up with a hyphenated widow fragment (less than one word long) that ignores your minimum character threshold for widows. This doesn’t happen very often, however, at least with the parameters I’m using, so I’m living with it for the time being. (My current settings: minimum hyphenated word must be at least 9 characters, with at least four characters before the hyphen and three after. Note to self: must file that bug report.) If you leave hyphenation off, though, then the plug-in’s widow control seems to work perfectly according to its design spec. (Later note: I have been flip-flopping on whether or not I can live with this bug, as well as without other more sophisticated hyphenation controls I’m used to in desktop publishing, so you may notice soft-hyphenation turned off instead of on.)

May 9, 2016: Update regarding wp-Typography and page-load performance: I hate to say this, but I have decided to turn off the plug-in due to the performance hit it entails. I had not realized how significant it was until recently. After having switched to a new web hosting service (SiteGround) well-regarded for its server speeds and built-in caching solution, my posts and pages still seemed slow to load. I did some experimentation and discovered that deactivating wp-Typography resulted in roughly a tripling in page-load speeds. (This is my subjective impression. I did not use a stopwatch, so you may want to take that estimation with a grain of salt.)

This improvement was very welcome, and given the magnitude of the increase in speed, I’ve concluded I can live without widow control for the time being. If I hear that things have changed with wp-Typography, or I try out a new version of the plug-in in the future that addresses the speed issue, I’ll report back with an updated assessment then.

Other widow control software the web might never see

Adobe InDesign and the TeX algorithm. When it comes to widow control, Adobe InDesign should be mentioned, which is probably the gold standard today in its use of the TeX paragraph-processing and justification algorithm. The TeX algorithm, originally programmed by mathematician Donald Knuth in 1978, processes each entire paragraph as a whole, with a point-scoring system that ranks all potentially useful ways of breaking the lines in the paragraph to find the most typographically pleasing result overall. This is in contrast to most algorithms that work one line at a time, make an irrevocable decision, and then go on to the next line without any ability to make line-breaking tradeoffs across the paragraph.

Even Adobe’s implementation is incomplete. In contrast to the approaches outlined above, the TeX algorithm should enable widow-control decisions that don’t potentially compromise the appearance of the rag of the next-to-last line in the paragraph. From my experience with InDesign, it very much appears that Adobe’s implementation does include widow control for justified text (though how it works is opaque), with superior results to anything else I’ve seen. However, the widow-prevention function isn’t utilized when it comes to flush-left/ragged-right copy. This is very strange given that Adobe could presumably use the same, or at least nearly the same, pieces of code to control widows in ragged copy that they do in justified copy.

Proprietary advantage for Adobe. Short of Adobe adapting its implementation for flush-left, ragged-right copy and releasing it for open-source use on the web (unlikely, since they probably consider the algorithm to be a competitive advantage vis-à-vis QuarkXPress, and rightly so), other approaches will probably continue to be used on the web. That is, unless someone else were to step in with a competing TeX approach to up the ante. One hurdle that would need to be dealt with on the web, though, is that the TeX algorithm is processor-intensive and might slow down page-load times too much.

Tabby Responsive Tabs

Download plug-in (for WordPress). Similarly to the Graceful Pull-Quotes plug-in mentioned earlier, there is no other way to say it: Tabby Responsive Tabs is, at this time, simply heads above all the other tabbed-interface plug-ins for WordPress I’ve looked at in all the categories you would care about: appearance, functionality, versatility, and ease of use. While tabs are not really a typographic item per se, I include them as a layout element here because they provide a good solution for situations where you might otherwise consider multiple side-by-side columns of text.

For more complete functionality, Tabby Tabs Customiser lets you style the tabs by way of a very nice menu-based interface (no CSS-hacking necessary), and Tabby Link to Tab provides the ability to link to another tab in the same set from the text in another tab. You’ll find these two premium add-ons for the plug-in plus another couple at the developer’s site.

Tabs provide an ideal approach when you have equally important sections of text for which you want the headings visible all at the same hierarchical level, such as for business products or services. See my “Work” pages, available from the main navigation menu, for example, where tabs are often used to present my services: typically something like “Portfolio,” “Business Overview,” and “Details.” (Multiple columns do make better sense for homepage magazine-style layouts or “masonry”-style blog index pages, of course.)

WP Edit Pro

Download plug-in (for WordPress). Among a boatload of other features, this plug-in enables styling of the text in WordPress’s page/post content editor so you can make it match the font and other formatting the article will assume when published. Without something like this to make the text you’re composing in the WordPress editor reflect the same style formatting you’re applying (drop caps, small-caps, pull-quotes, subhead styling, etc.), it’s very difficult to easily implement and verify the actual typographic styling you’re going to get once an article is actually published on your site. Otherwise, you’re constantly publishing and republishing a post or page just so you can preview it — making a “round-trip” back and forth from editor to published page, ad infinitum.

Custom CSS required for other enhanced typographic features

To style basic typography with CSS properties such as font-size, letter-spacing, word-spacing, line-height, and so forth, refer to sources such as w3schools.com or your favorite educational resource. When it comes to features such as kerning, colored bullets, and specially styled numerals for ordered lists, I’ve provided actual code to cut and paste here, since there are some thorny bits that can be difficult to get right.

Automatic kerning

As with a good deal of web typography, getting kerning to operate properly in all browsers currently requires a kludged mixture of standard CSS with vendor-prefixed code:

    /* Kerning everywhere */ body, default { text-rendering: optimizeLegibility;
    /* Use with caution, may cause issues in some browsers, needed for some
    older browsers. */ -moz-font-feature-settings: "kern"; -moz-font-feature-settings:
    "kern=1"; -ms-font-feature-settings: "kern"; -o-font-feature-settings:
    "kern"; -webkit-font-feature-settings: "kern"; font-feature-settings: "kern"
    1; font-kerning: normal; }

I cobbled the above together primarily from Bram Stein’s discussion on the Adobe Typekit blog.

Ligatures

One nice thing about using Typekit is that if the web font you’re using from the Typekit library has built-in OpenType ligatures, and you turn on OpenType features (in Typekit) for the font, you’ll automatically get ligatures on your web pages without having to include any CSS code to enable them. This is what I’ve done on Hermit Spirit. Otherwise, you will want to include this bit of CSS:

    .your-class-name { font-variant-ligatures: common-ligatures; -moz-font-feature-settings:
    "liga", "clig"; -webkit-font-feature-settings: "liga", "clig"; font-feature-settings:
    "liga", "clig"; }

For more info, see Adobe’s OpenType features help page section on enabling/disabling ligatures from which the above code was taken.

Note that if you turn on ligatures site-wide, you will want to selectively turn them off for code and pre tags, i.e., monospaced copy. Here is the CSS for that:

    /* Turn off ligatures in monospaced text */ code, pre { font-variant-ligatures:
    no-common-ligatures; -moz-font-feature-settings: "liga" 0, "clig" 0; -webkit-font-feature-settings:
    "liga" 0, "clig" 0; font-feature-settings: "liga" 0, "clig" 0; }

One drawback to ligatures on the web to consider: if you are applying much tracking, i.e., letter-spacing to a font (either negative or positive), ligatures can create a noticeable spacing anomaly that looks odd. Ligatures are designed for the default case when tracking is set to a value of zero. This means if you track the font past a certain level of tightness, for example, the spacing between the vertical stems in the ligature will look noticeably looser than the surrounding text and disrupt the reading rhythm. This can be particularly distracting in headlines, which typically need to be tracked tighter than body text for a professional look.

Just the opposite can also be a problem: sometimes ample amounts of positive letterspacing are used for headlines in certain situations. Here, a ligature will look just as odd as the reverse condition, by comparison with the loosely spaced surrounding characters — if not more odd, because the positive letterspacing value that might be applied can be much greater than values employed in negative letterspacing. (With negative letterspacing there is a limit encountered early on, after which characters start to overlap. In the opposite direction, extra space between characters can be arbitrarily large.)

Professional desktop publishing applications like InDesign and QuarkXPress don’t exhibit the above problem, since they will automatically break ligatures into their individual constituent characters once tracking exceeds a certain negative or positive threshold. No such luck with the current state of web typography, though.

Custom tracking/letterspacing and wordspacing

Specific fonts and font/size combinations often require different amounts of tracking for best appearance and/or legibility. The default tracking of zero built into a font is typically intended for body copy sizes in the range of 10 to 12-point (equivalent to 13.33px to 16px). Much above that range, and you typically need to go tighter. Below that range, looser.

Although I won’t provide any sample code here, I’ll offer the observation that the default letterspacing and wordspacing values of a font are not always to an experienced typographer’s liking. The better and more experienced the type designer or foundry, the more likely I will find them just right. However, even Adobe and other big-name foundries don’t always make what I feel are proper choices.

Case in point: For my website here, I found Sanvito’s default letterspacing to be too loose but its wordspacing too tight, and experimented till I got them as I wanted. If the default tracking and wordspacing don’t look right to you, and you’ve gained enough experience to know or figure out why, don’t be afraid to go in and either tighten or loosen wordspacing and tracking (CSS properties word-spacing and letter-spacing, respectively) as needed. Foundries’ defaults are not sacred, and sometimes they make less-than-optimal decisions just like anyone else, or at least ones that may not suit your needs.

Angie Sans’s default word- and letterspacing, in contrast to Sanvito, suited me just fine (for body text copy) and I left them alone.

Better bullets on the web: flush-left, colored, and multi-paragraph options

I’ve included code below for both conventional browser default bullets as well as colored bullets, since in my implementation colored bullets are set up to replicate the same formatting as conventional bullets in terms of margins, padding, indentation, bullet size, etc. (The end results are the same, but the numbers to achieve them are different, due to the alternative approaches.) This makes it easy to switch between the two if you like without any layout repercussions.

    /* Main content area conventional bullets, flush-left style */ div.entry-content
    ul, div.entry-content ul li ul, div.entry-content ul.indented { margin-top:
    .85em; margin-left: 0; padding: 0 0 0 1.041em; } div.entry-content ul li.no-bullet,
    div.entry-content ul.indented li.no-bullet { list-style: none; /* For li
    tags used as extra paragraphs in a bullet point */ } /* Main content area
    colored bullets using alternate technique vs. conventional bullets */ div.entry-content
    ul.colored-bullets li { /* color: #000; */ /* Color of list item text */
    list-style: none; text-indent: -1.1em; } div.entry-content ul.colored-bullets
    li:before { color: #228ba1; /* Bullet color */ content: "\2022"; /* \2022
    is numerical Unicode for bullet, \b7 is middot, \a0 is space.*/ font-size:
    1.25em; /* Font-size of bullet. Use em or %. */ top: .06em; /* Vertical
    position of bullet. Use em or %. */ padding-right: .37em; /* Give bullet
    padding from text. Use em. */ position: relative; } div.entry-content ul.colored-bullets-indented
    li { list-style: none; text-indent: -1.041em; } div.entry-content ul.colored-bullets-indented
    li:before { color: #856135; content: "\2022"; font-size: 1em; top: .03em;
    padding-right: .5em; /* Give bullet padding from text. Use em. */ position:
    relative; } div.entry-content ul.colored-bullets li.no-bullet:before, div.entry-content
    ul.colored-bullets-indented li.no-bullet:before { visibility: hidden; /*
    For li tags used as extra paragraphs in a bullet point */ }

Why I chose the above approach instead of the alternatives. I should mention a couple of things: First, I either evaluated or tried all permutations of the colored-bullet implementations out there I could find, but most were very finicky (some using float: left for the bullet itself). With these, just about any time I tried altering the formatting of the bullet to suit my own tastes, the result blew up in my face. For example, the float: left approach only works well with a single line of text for each colored bullet — succeeding lines will wrap back to the left margin and not align properly flush-left with the text on the first line. Crazy, I say — especially for something that should be drop-dead easy and built in to the CSS spec itself.

CSS class required for use. Given the above, I favor the li:before technique shown below to insert a user-defined Unicode character for the bullet that can then be colored. The tradeoff is my implementation of this approach requires that you include the class colored-bullets in the ul tag of each run of bullets. It’s very little extra code since it’s inserted only into the ul tag and not the associated lis. However, it does require that you remember to do it or, alternatively, set up a style that you’ll use religiously. (Even with methods that work robustly, as this implementation does, there is almost always a drawback with stuff that isn’t built into CSS itself.)

Blanket site-wide use without using a CSS class won’t work. The second thing is that at first I tried to set up the CSS for my WordPress site here so that colored bullets were automatically applied to all instances of bullet items in the body. However, attempting to do so caused colored bullets to be applied to navbar menu items as well as sidebar widget items (both of which use list-item code to achieve their formatting). Not to mention that I ran into the same issue with Clean My Archives’ (and maybe Archive-Pro-Matic’s) archive listings.

The reason for this is that navbar menus, widget lists, and many other things you see on websites use the list-item function to achieve their ends, and they do so by using list-style: none to turn off the default bullets. Since this is exactly what my favored li:before technique does, in part — it removes default bullets but then replaces them with colored ones — trying to make that a site-wide default for bullets ends up adding bullets to any li item that strips out the conventional default bullets. This is why an update to the CSS spec for list-items is needed if we are to ever have colored bullets that are hassle-free. But leave it to the web-standards code geeks to have completely ignored a simple typographic need like this for 20 years and counting now.

Rather than attempt to route around this, which might be possible if one were interested in banging their head against the wall long enough (you might have to completely outdo all the punk-rockers that have ever lived, for starters though), I decided it would be much less troublesome to simply insert the colored-bullets class in the ul tag for each run of bullets. (Enforcing site-wide use would also open up the possibility of colored bullets being applied to the output of other plug-ins that one might decide to use in the future.)

Bullet alignment: I prefer to align bullets so the bullet itself is flush left with the margin, not inset to the right (i.e., the standard browser formatting), and that is reflected here. It makes for a cleaner look compared to the chopped-up, zigzagging left margin one gets whenever default browser-formatted bullets are used. The approach here also allows for use of default bullets anywhere by simply using a standard, bare ul tag without assigning the colored-bullets class.

Important IE8 note: This approach works reliably in many older browsers including Internet Explorer as far back as IE8. However, to work in IE8, the li:before pseudo-element must utilize a single, not double, colon. Double colons are now the preferred though not mandatory syntax for pseudo-elements, but will not work with IE8. Unless or until single colons are deprecated for pseudo-elements in modern browsers, you might want to continue using them for a while longer.

Special display numerals option for ordered lists

Using ordered-list numbers that are different than the surrounding text requires use of CSS counters. For more explanation of how they work in this context, see David Storey’s Automatic Numbering with CSS Counters. (If nothing else, I wanted to provide a link for myself here as a reference — screw the rest of you folks ;-) — since as a non-developer, even if pretty geeky graphic designer, it’s hard to remember how all this stuff works.)

My Cats versus Kids post shows one way an ordered list can be dressed up and made more attractive than the usual default ol numbering. The code below was adapted for it from an example by Russ Weakley:

    /* Large display numerals for ordered lists */ ol.display-numerals { counter-reset:
    display-list; padding-left: .05em; /* This definition and next one are
    for better alignment at left margin by compensating for italic lean of
    Sanvito. Eliminate unless using italic or script font. */ text-indent:
    -.05em; } ol.display-numerals li { counter-increment: display-list; list-style:
    none; } ol.display-numerals li:before { content: counter(display-list);
    font-family: "sanvito-pro-display"; /* substitute your font parameters
    here and on following lines */ font-weight: 700; font-size: 2.063rem; color:
    #228ba1; letter-spacing: -.020em; padding-right: .4em; /* spacing between
    large numeral and first word of text to its right */ } ol.two { counter-reset:
    display-list 1; } ol.three { counter-reset: display-list 2; } ol.four {
    counter-reset: display-list 3; } ol.five { counter-reset: display-list
    4; } ol.six { counter-reset: display-list 5; } ol.seven { counter-reset:
    display-list 6; } ol.eight { counter-reset: display-list 7; } ol.nine {
    counter-reset: display-list 8; } ol.ten { counter-reset: display-list 9;
    }

The final series of counter-reset lines enable restarting the list numbering with an arbitrary number anywhere in an ordered list, for which the need can arise on occasion. (If you need to restart with numbers higher than ten, add further numeric definitions to the above.)

In my own very first use case, for example, only the first part of the ordered list in the Cats versus Kids post is displayed on the blog homepage or archive search pages, after which the reader needs to click WordPress’s “Read More” button to see the full article. Unfortunately, it turns out that wherever you split the post after the “Read More” button, WordPress will restart numbering with “1” for the second part of the list that occurs on the full article page. That is, unless you begin a new ol and restart the numbering yourself by inserting the appropriate class name (i.e., number) from the counter-reset code just above.

Alternate text treatments such as verse-style formatting

Rather than make any specific recommendations here, I’ll just provide an example. See my humor post Life Sucks, and Then You Die for an illustration (using Sanvito) of how one might dress things up when they contain multiple short, successive one-liners, aphorisms, stanzas, etc. Here are the relevant lines of CSS controlling the fonts and formatting:

    /* Dressed-up text for either verse-style or successive one-liner presentation
    */ /* The .decorative-verse class is used for a container div enclosing
    an entire section of verse-style formatting */ div.entry-content .decorative-verse
    p, div.entry-content .decorative-verse .decorative-verse-text { font-family:
    "sanvito-pro"; font-style: normal; font-weight: 400; font-size: 1.563rem;
    font-size: 25px; line-height: 116%; letter-spacing: 0; word-spacing: .045em;
    /* margin-bottom: .85em; already taken care of in main bottom-margin declaration
    for primary text elements */ } .decorative-verse .smallcaps { font-family:
    "sanvito-pro"; font-style: normal; font-weight: 600; font-size: .81em;
    color: #1a1a1a; text-transform: uppercase; letter-spacing: .025em; word-spacing:
    .045em; } .decorative-verse .smallcaps strong, .decorative-verse strong
    .smallcaps, div.entry-content .decorative-verse .decorative-verse-attribution
    { font-family: "sanvito-pro"; font-style: normal; font-weight: 700; text-transform:
    uppercase; letter-spacing: .035em; word-spacing: .045em; } div.entry-content
    .decorative-verse .decorative-verse-attribution { font-size: 1.266rem;
    font-size: 20.256px; color: #228ba1; line-height: 108%; margin-top: -.85em;
    margin-bottom: 1.05em; } div.entry-content .decorative-verse .decorative-verse-remark
    { font-family: "sanvito-pro"; font-style: normal; font-weight: 400; font-size:
    1.329rem; font-size: 21.256px; letter-spacing: .010em; word-spacing: .045em;
    line-height: 108%; margin-top: -.83em; margin-bottom: 1em; }

Better faux small caps

Yes, yes, I know, this is supposed to be verboten. But as I mentioned above, many web fonts — even from high-end foundries such as Adobe — simply do not include small caps, like Angie Sans that you’re reading here. So here are some techniques for faking them better, if you must do so (as I myself have). That said, if you’re going this route, I would still suggest being judicious in how often or where you use them. Pick situations where the faux approach isn’t as easily perceived, so the fact the small caps are being faked doesn’t call undue attention to itself.

• Use less vertical scaling. First, to reduce the disparity between the weight of scaled-down faux small caps and adjacent text, don’t attempt to scale them all the way down to the x-height. Instead aim for somewhere in the range of about 80–83% the size of the full caps. Not all true small caps are exactly the same as the x-height anyway — some type designers prefer them a little larger. (Note, in web typography, small caps that match the x-height are called petite caps, with the plain unmodified term small caps reserved for larger small-cap versions.) For any of the subsequent tricks below to be worthwhile, in most cases you will need to have started out with less of a reduction factor like this.
• Add some modest horizontal scaling. Second, here’s a trick that doesn’t work right now with current web standards, but I’ll mention it anyway, because while it doesn’t work today, it may in the future as standards continue to evolve. To compensate for the thinner stem weights that result from scaling full caps to get small caps, one approach I tried at first on Hermit Spirit was to electronically expand the width of the scaled-down caps a little (say, 105% to 108% or so), which gives a bit of extra horizontal weight to the stems.
• This was something I devised and resorted to frequently in my days as an advertising typographer when working with fonts that had no built-in small-caps complement. (I am sure I’m not the only one who did this back then.) Not only does this flesh out the vertical stem weights a bit, it also compensates for character widths that look a little too narrow in scaled-down caps. However, currently, unfortunately, electronically expanding or condensing text (using transform: scale) either isn’t supported or simply doesn’t work as advertised in the browsers I tested it with.
• Judicious letterspacing/wordspacing. A third technique that can help a bit is to letterspace the resulting caps slightly, since scaling full caps down in size to make faux small caps also reduces the spacing between letters. Letterspacing the characters out some gives them more of the appearance of true small caps, which have proper spacing built in. A little extra wordspacing helps for the same reason, as well as helping the appearance and readability of all-caps settings, I have found over the years (or in this context, all caps used to fake small caps).
• Darker color. A fourth trick did help here, although the effect is slight. When first designing the website, in order to simulate the traditional printed page, as well as make things a little easier on the eyes for extended reading, I styled the text color for Angie Sans here to be #1a1a1a (90% black) rather than the usual default of #000000 (100% black). (I find the contrast of 100% black against white to be too stark, and hard on the eyes when reading body copy for any length of time.)
• This opened up an avenue I hadn’t thought of before to make faux small caps appear to have a little extra weight that isn’t actually there. Since a quirk of human perception is that color affects the perception of boldness (stem weight) and vice versa, making the font color darker also makes it seem just a wee bit bolder (i.e., thicker). Here, I have styled the Angie Sans faux small caps to be 100% black instead of the 90% black of the regular text. Obviously, the opportunities for this approach are rare, and it only works within very modest limits. Otherwise, too much disparity in the color of adjacent objects will begin to be noticed by the eye and stick out as a perceptible “mismatch.”

• Bolder font weight. A fifth technique that may or may not be available in any given situation is to make the font weight a little bolder. If a type family has enough incrementally stepped gradations in weight, the next weight up may be just about right to get you a decent match. This worked pretty well for Sanvito on the site here, which also was not provided with true small caps by Adobe for the web-font version. (Thanks, guys — you’re really living up to your name as the market leader, here!) Again, see Life Sucks, and Then You Die for a few examples, where I was able to use the Semibold weight to simulate Regular small caps. (The examples of this occur in the black-colored text at the above link. Ignore the teal-colored small-cap items, which are separate.)
• With Angie Sans Regular here (my body copy font), this might have worked also, if the Demi weight had been available for use, but Adobe makes available only the Regular and Bold weights for web use. That failing, one devious potential little trick I looked into as a substitute was whether it might be possible to apply faux-bolding to the Regular weight to beef it up some, but alas — if a font family has a true bold weight available, the browser will use that instead, closing off the faux-bold avenue. (Probably wisely so, otherwise faux-bolding would be in use everywhere on the web with no discrimination being applied in its use whatsoever, in most cases.)
• Note: I hate faux-bolding as much as the next person, but was curious what the results might be in this context, if nothing else. After all, we’re trying to think outside the box here — sometimes that means saying “screw the authorities” or the “font police.” ;-)
• Follow-up: It turns out that I was either mistaken about Adobe not offering the Demi weight of Angie Sans with Typekit, or they have added it since I first set up the typography for Hermit Spirit. Consequently, I am now using the bolder-font-weight technique for the lead-in small-caps phrases that follow a drop cap on the website. (See second example in the code just below.)

Here’s the code for how the faux small caps here were handled for both Angie Sans and Sanvito:

    /* Angie Sans faux small-caps example: initial solution, no change in
    font-weight */ .smallcaps, .smallcaps-lead-sentence { font-family: "angie-sans";
    font-weight: 400; font-size: .81em; /* scale to 81% of size in effect for
    surrounding text, to simulate small-cap size */ color: #000; /* make slightly
    darker to appear a tad bolder as compensation for reduced stem weight;
    #000 = 100% black; adjacent text is #1a1a1a = 90% black */ text-transform:
    uppercase; /* convert preexisting text to all caps */ letter-spacing: .055em;
    /* increase letterspacing from zero default */ word-spacing: .015em; /*
    increase wordspacing from zero default */ } /* Angie Sans faux small-caps
    example: later/better solution, using Demi 600 font weight for better match
    of scaled small caps with adjacent lowercase Regular 400 font weight */
    .smallcaps, .smallcaps-lead-sentence { font-family: "angie-sans"; font-weight:
    600; font-size: .81em; color: #262626; /* make slightly lighter to appear
    a tad less bold as compensation for slightly too-thick stem weight; #262626
    = 85% black; adjacent text is #1a1a1a = 90% black */ text-transform: uppercase;
    letter-spacing: .035em; word-spacing: .005em; } /* Sanvito faux small-caps
    example, with change in font-weight */ .decorative-verse .smallcaps { font-family:
    "sanvito-pro"; font-weight: 600; /* weight of adjacent text is 400 Regular;
    600 is Semibold */ font-size: .81em; color: #262626; /* make slightly lighter
    than adjacent lowercase text color of #1a1a1a to compensate for slightly
    too-thick stem weight */ text-transform: uppercase; letter-spacing: .025em;
    word-spacing: .045em; }

A word about abandonware

Universally supported CSS should be “Plan A” when it comes to getting the results you want, of course, but isn’t always possible. Beyond that, the software plug-ins for enhanced typography I chose for my own use and have outlined here were selected not just based on features and ease of use, but in terms of long-term developer support and hopefully future-proofing as well.

Always keep long-term viability in mind. In the past, for some years I tended to choose the slickest, most tailored software I could find for my needs. Over time, though, my approach changed after having gone through experiences where software I had relied on was eventually abandoned or sold off by its developers to an eventual executioner. (This includes even big-name software for its day such as FreeHand. This popular competitor to Adobe Illustrator was rather unceremoniously knifed in the back by Adobe in 2007, a year and a half after they acquired it from Macromedia, despite having announced not long after acquisition that they planned to continue its development.)

Free vs. vendor-based solutions: which for the long-term? Now, there are two things I look at: first, preferably, is the solution an open-standards, “off-the-shelf” solution? Second, if one doesn’t exist or isn’t adequate, which of the available vendor-based solutions has the most promise for the long-term? And by the second I mean, not only, does the software have an enthused, widespread user base, but how does the developer behave? Do they listen and are they responsive to user suggestions and complaints? Are they charging a fair price for their software — reasonable in cost for users, but also enough that they can afford to continue developing the software and will be around for the long-term?

Personally, I have learned to avoid “free” unless it is a widely based, very popular open-source effort. Yes, it may be noble for an individual to offer the fruit of their labors in the spirit of largesse, but it is usually not practical in the long-term. I have seen too many small developers offering free software eventually abandon it (presumably after not having the wherewithal to continue their unpaid volunteer venture), leaving users high and dry.

Sometimes, I will go with an open standard and accept some compromise even if the software is not completely adequate, if the solution is at least workable. Especially if it looks like the developer(s) is/are adding features, motivated, and will continue developing it over time. This way, at least the probabilities are that it potentially has a viable, longer-term future ahead of it. Other times, I choose a vendor-based solution, but am careful to evaluate the developer’s behavior, seeming long-term commitment, and respect for users based on reviews.

JavaScript vs. shortcode-based plug-ins. You can’t always foresee when a plug-in will slide into the oblivion of abandonware-dom, of course. That being the case, to my way of thinking, if you can’t accomplish something with CSS, JavaScript-based plug-ins are to be preferred over shortcode-based. If a plug-in is abandoned, shortcode-based solutions will leave nonfunctional shortcode junk scattered in the text of your site pages wherever you’ve inserted them. With a JavaScript-based plug-in that becomes abandoned, you will lose its functionality when you deactivate it, but you won’t be left with shortcodes littering your site’s text.

In some cases, of course, you have no choice but a shortcode-based solution to get the functionality you want. Keep the tradeoff in mind, though, and have a plan of action for how you will clean up any leftover shortcode junk that might get left behind in the future.

Good typography is dependent on good “editorial”

Ignoring photos for our purposes here, not all of what goes into making a website inviting to read is purely typographic in nature. I’m a big fan of usability consultant Jakob Nielsen’s observations and research showing the importance of using frequent subheads and bullets, boldfacing key phrases, and so forth for best scannability. The purpose of making pages “scannable” in this way is to speed readers along in finding what they are really after, and to invite readership. But while the on-page result of this is typographical in appearance, the rub is that the actual doing of it requires editorial attention. (As an aside… Lack of vertical scannability is a notable drawback to the current craze for sites with successive horizontal “bands,” rows, or sections — whatever the terminology. This was one of the reasons I decided to “roll my own” site layout, using a more traditional “blog-style” approach.)

Marrying typography with microcontent. The editorial side of adding subheads, bullets, and boldface for scannability — once the appropriate CSS styles have been created to support the look you want for them — is really all about writing what on the web is called “microcontent.” Creating good microcontent requires that you consider things with an editor’s eye and summarize the important point of each paragraph, or each few paragraphs, then come up with a concise snippet of text that suitably captures it. Then decide the best way to insert it: as a head or subhead or bold lead-in sentence to help escort the reader through the text. Alternatively, one might break things up into bullet points in a logical way, perhaps combined with the use of bold lead-ins. Selecting passages for use as pull-quotes is another route that can be used for occasional spice. Obviously this takes time, but it’s well spent when you consider how much more likely it is visitors will then actually read what you have to say.

Good typography by itself isn’t enough. It has to be integrated with attentive editing to fully “work”: in this area of design it’s very much true that the whole is greater than the sum of the parts. The total package is what counts.