You can also achieve this for web typography by defining a simple style, like the following.

abbr { font-variant:small-caps }

If the text you’re trying to style has already been typed in capitals, then this above style does nothing. To overcome this, you’d do the following:

abbr { text-transform:lowercase; font-variant:small-caps }

The only problem with this though is that all capitalized words need to be enclosed within abbr tags. On my site, I have over a few hundred posts that have capitalized words. I don’t have the energy to sift through them all just to update the markup. I searched for a WordPress plugin. Apparently there aren’t any. So, I wrote one.

This plugin looks for capitalized words with 2 or more letters, and then applies the opening and closing abbr tags to such words. Now, all I have to do is add the abbr styling to my style.css to make it look small capitalized.

Let me digress here to put forth a couple of assumptions.

1. I use abbr, since most capitalized words I use are primarily abbreviations.
2. I apply acronym to those capitalized words that require an explanation.

Download: the small caps plugin from WordPress Plugin Directory.

Install and use

1. Extract and upload the small-caps.php file to your WordPress plugin folder (wp-content/plugins/). Go to Plugins page and activate “Small caps” plugin.
2. Styling: Copy-paste the following to your current WordPress theme’s style.css file: abbr { text-transform:lowercase; font-variant:small-caps }

FAQ

1. This plugin applies the abbr tag to words already in capitals. (Without adding the styling above, the plugin does not by itself automatically apply styling—and this is intentional.)
2. On the web, I think, small caps probably look best in serif fonts larger than 13pixels in size.
3. Due to the way it looks up a word within white spaces using REGEX, some linked capitalized words are not transformed to small caps—depending upon the punctuation used prior to or after the word.

Create a folder named m in your blog root—if you have a self-hosted blog. Dump a file named index.php with the following content in it:

1. <?php
2. header('HTTP/1.1 301 Moved Permanently');
3. header( 'Location: http://www.google.com/reader/m/view/feed/http://ckunte.com/feed/atom' ) ;
4. ?>
5.  
6. Download this example: /inputfiles/m.txt

Be sure to replace my site's feed address with yours in the code above. Your mobile blog version would now be accessible at this address, for example: yoursite.com/m (or yoursite.com/blog/m depending upon where you created the m subfolder on your host).

I am averse to creating a sudomain just for this, but if you still prefer a subdomain like address, here’s a plugin code I just whipped up.¹

1. <?php
2. /*
3. Plugin Name: Mobile version via Google Reader
4. Plugin URI: http://ckunte.com/
5. Description: m. subdomain address is redirected to google's mobile version.
6. Author: Chetan Kunte
7. Version: 1.0
8. Author URI: http://ckunte.com/wordpress
9. */
10.  
11. if ( !strstr( $_SERVER['HTTP_HOST'], 'm.' ) )
12. return;
13.  
14. header('HTTP/1.1 301 Moved Permanently');
15. header('Location: http://www.google.com/reader/m/view/feed/http://' . trailingslashit(substr($_SERVER['HTTP_HOST'], 2)) . 'feed/atom');
16. exit();
17.  
18. ?>
19.  
20. Download this example: /inputfiles/moplug.txt

Download the file above², and rename it to, say, moplug.php and upload it to wp-content/plugins folder. Your mobile site would now be accessible at m.mysite.com—all this without having to create a subdomain.

1. Do note that I haven’t been able to test this on my host, since I have a subdomain related problem at the moment, but I believe this code would work.
2. Make sure there are no empty spaces after ?> in both the code snippets

1. SACS input files are in a fixed format. Column sensitive information.
2. SESAM, USFOS and ABAQUS input files are in a free format. Column insensitive information.

I wanted a simple solution to display my structural analysis input files—for some articles I have restarted working on—without modifying them or embedding them within the post markup, albeit painfully. So I turned to Dunstan’s tag transformations. Mathias Bynens wrote a plugin—based on Dunstan’s tag transformation, which also includes image transformation. I didn’t need the image transformation bit, so I edited Bynens’s plugin to include only the code transformation.

How it works: I upload an input file or input file snippet—say filename.txt—to a folder called inputfiles in the root. Then, in the article, I add the following code—to display the input file, together with line numbers (auto-generated via the plugin):

<codeins="filename" />

Download: The edited plugin is here, if you’re interested.

Install and use: Rename the downloaded file to code-transform.php and upload to your WordPress plugin folder (wp-content/plugins/). Go to the Plugins page, and activate “Code transform” plugin. That’s all.

Important note: For this plugin to work, you will need to uncheck “WordPress should correct invalidly nested XHTML automatically.” under Options > Writing.

A demo of this plugin can be seen here.

Presentation style [update]: You may use Dunstan’s CSS code to style the displayed code in your post. Just copy the CSS code and paste it in style.css in your active theme folder.

Much like auto-discovering feeds², an Opensearch-standard compliant browser now auto-discovers the availability of search on this site.

Try loading this site in a supported³ browser. You’ll either notice a subtle search icon highlighted in the default browser theme—suggesting that there’s something you can add to your list of search plugins or more visibly via a “+” sign, if you use a theme like Winstripe. Pull the search menu down and you’ll notice this: Add “ckunte.com”.

Enabling this on any site is easy. You’ll need to add the following⁴ in your site’s header part of XHTML code. I’m using my (this) site’s code for example:

<link rel="search" type="application/opensearchdescription+xml" href="/ckuntecom.xml" title="ckunte.com" />

(I had previously explained the construction of Opensearch XML file—ckuntecom.xml, which enables search auto-discovery.)

As a user, for sites that do not offer this feature, you can always use OpensearchFox. But if you’re a site owner, it is probably a good idea to provide this option to your regular readers and referrers.

1. I am beginning to test Sneha’s patience now.
2. Via the orange feed icon on the right end of the address or location bar.
3. Available in Opensearch supported browsers—Firefox and Internet Explorer 7.
4. Change file location, file name and title as applicable.

How does this interest me? Well, it’s nice to get an accurate report of stats rather than the same domain fragmented based on user’s query. In addition, I continue to get hits from my old address: http://chetan.ckunte.com. I wanted to change that and so, I did. Simple really.

While www. is 4 characters, chetan. is 7 characters. So, my updated plugin code based on Matt’s no-www looks like this:

1. <?php
2. /*
3. Plugin Name: No Chetan
4. Plugin URI: http://ckunte.com/
5. Description: Chetan subdomain address is redirected to root.
6. Author: Chetan Kunte based on Matt Mullenweg no-www
7. Version: 1.0
8. Author URI: http://ckunte.com/
9. */
10.  
11. if ( !strstr( $_SERVER['HTTP_HOST'], 'chetan.' ) )
12. return;
13.  
14. header('HTTP/1.1 301 Moved Permanently');
15. header('Location: http://' . substr($_SERVER['HTTP_HOST'], 7) . $_SERVER['REQUEST_URI']);
16. exit();
17.  
18. ?>
19. Download this example: /inputfiles/subdomain-redirect.txt

(Seriously, no more posts after this for at least another 3-weeks, as I have been saying.)

Update: Did I mention that this technique also redirects all permalinks with old address to the new one?

Most feed readers, if not all, do not process javascripts/ecmascripts, and are ignored by the feed client/service. Since the Blockquote plugin uses javascript only to visually display (the credits already fed in the blockquote markup), it is essentially cosmetic. So let me try and kill two birds with one stone here.

One: That it is okay if the cosmetic appearence of title/link, meant for humans to read, is wrapped in a div, instead of cite below the quotation. Semantically speaking, it is aleady taken care of in the blockquote markup. For example, if you disable scripting in your browser, you won’t see the (cosmetic) citation and or link, but it still exists in the blockquote markup and it is still semantically correct.

Two: Blockquotes citation/title are viewable via the tooltip, irrespective of whether the scripting is enabled (in the browser) or not. And that these are viewable as a tooltip (hover over the blockquote for a second and you’ll see the title text) in both the browser and in feed readers (or in feed services).

I hope that clears the air.

Update: Having said that, I would like to iterate that there’s room for improving the tooltip feature inherently in browsers and feed readers. See my post Clarity of links with regards to enhancing the tooltip feature (within browser, by browser makers).

Cliche (update) 2: Egad, for a line of plugin code, I never thought I’d end up writing two pages clarifying it :).