Bitbucket user srean complained on the Google Group about the white background in bitbucket’s code view. I agree — a black background is much better for viewing code, and the gray highlighted text is almost invisible against white.

I whipped up a greasemonkey script to correct this situation. It makes the background color of the highlight section black, with a default text color of SpringGreen. If you don’t like SpringGreen, you can of course modify the script. Enjoy!

I’m only going to publish this one on bitbucket.org, since you have to use bitbucket before you’d need it.

Since I first published the tr-rectify Greasemonkey script to ease my TechRepublic reading experience, Chad Perrin joined the project. He and I have improved the script apace. Among the changes we made a while ago is that for every element the script hides, it sports a little white-on-blue “+” that you can click to expand it. We then made tr-rectify remember which elements you left expanded and which collapsed, so you can tune your visibility preferences.

One problem that regulars experience with the TechRepublic discussions is in “catching up” — returning to a discussion of one or two hundred comments, and trying to find all the comments that you haven’t yet read. In thinking about how to solve this problem, I thought about adding a widget to allow you to hide all comments posted before a specific date/time, but that has complications not only in the implementation but also in usage.

Then it occurred to me to use our existing framework for collapse/expand. All comments now start out in life expanded, but they each get a little “-” in the upper right-hand corner. If you click it to collapse the comment, all that’s left of it is a “+” with which to re-expand it. Since every comment on TechRepublic has a unique message ID, I use that ID for recording your preference for expanding/collapsing that comment. This works both in Expanded and Collapsed discussion modes.

So, to use this facility for weeding out comments you’ve read, just collapse each one as you read it. You can always expand it later. If you want to take a peek at all comments, just disable Greasemonkey temporarily by clicking on the monkey icon in Firefox’s status bar.

I’ve been meaning to learn more about Greasemonkey for years. The ability to customize your experience by executing JavaScript for specific URLs seems to hold out possibilities that I haven’t yet imagined. But I never had a pressing reason to dig into it, until TechRepublic’s recent site upgrade.

I write for TechRepublic on a weekly schedule, and I’m considered the “host” of the IT Consultant blog. So I spend a lot of time on the site, mostly reading and responding to comments from readers. I also read the works of some of the other writers and join in on their discussions. My usability goals therefore include minimizing page reloads and vertical scrolling.

TechRepublic’s redesign helped me in one way: they now offer an “Expanded” mode for discussions, so I can see all responses at once without loading a new page to read each one. I can respond in situ as well, so I don’t lose my place in the discussion. Kudos.

But the vertical space issues pretty much cancel out those benefits. TR made all the fonts bigger, especially headings. As a result, even after collapsing one of the upper sections, real content gets less than half of the screen on my 17″ notebook display without scrolling. They also added a lot of white space between sections, and all sorts of bells and whistles like “featured comments” that I have to scroll over to get to the threaded discussion. Finally, the content area has a fixed width, thus wasting a lot of horizontal space — which naturally pushes more content in a vertical direction.

Time to get up close and personal with the Slippery Simian.

The Greasemonkey script that you can download at the links below applies to all pages on www.techrepublic.com, and accomplishes the following:

• Reduces font sizes, especially for the headers.
• Reduces padding and margins in the discussion.
• Makes three sections invisible: the header, the “featured comments”, and the huge section that only contains a link to the previous and next articles.
• Sizes the left and right sections based on the browser width. Since TechRepublic sends me checks, it would be imprudent for me to suggest that you could modify this to hide the right section completely. I gave it 25% of the width, and allocated 70% to the content (the extra 5% is needed for padding slop so it doesn’t wrap). On really wide screens, that 25% is too much for the ads, but 70% is probably still good for the content.

Naturally, you can adjust all of the above to your own preferences. Some people like the bigger fonts. I don’t.

As you can see in the script, the only Greasemonkey feature I used is GM_addStyle, so all my changes reflect mere CSS adjustments. I could have gone crazy with the DOM, but the result gives me just about everything I want.

Suppose you want to present an error message to a web user in the form of a stop sign – you know, to get their attention.  Let’s further suppose that you don’t know the full text of the message until runtime, so you can’t just use an image.  What you want is a stop-sign-shaped section into which you can place text.  This is a job for CSS.

The first hurdle on our quest is creating the 45-degree sides of an octagon using web elements that typically prefer orientations in multiples of 90 degrees.  But that’s easily accomplished by creating a very wide, beveled border that uses different colors on both sides of the bevel.

Breaking the octagon into five parts like this:

We can see that the left-most portion can be created as a zero-width div section that has a border on three sides that is 1/4th as wide as the entire octagon:  the right border being red, while the top and bottom borders are transparent.  The same trick can be applied to produce the other three outer edges.  The middle area, where we’ll put text, is just square.  We then position all four areas using absolute positioning within a container that uses relative positioning.

The final step is to place the text inside an inner div that we can move up or down within the middle section, so we can center it vertically without altering the size of the middle section.   Et voila:

Well, at least in Chrome, Firefox, and Safari.  When I tried this technique in Internet Explorer 8, I got this masterpiece:

Picasso would be proud.  It turns out that the longer dimension for each side needs to be specified twice as big for IE as for all the other browsers.  But there is a way to get around it without browser-specific code:  specify width or height the way IE wants it, then impose a max-width or max-height that brings it back down for the other browsers.

But I still had a problem with Internet Explorer.  For the top and bottom sections, it appeared to ignore height:0px, because each one sported a small, empty rectangle above (the top) or below (the bottom).  It turns out that I needed font-size:0px so IE wouldn’t automatically include space for some text (even though it contained none).

But I still had another problem with Internet Explorer.  Even after eliminating the space for text, the top side was always placed two pixels too low, resulting in the little rough spots you can see below.

I never figured out why this happens.  So I resorted to browser sniffing after all, setting the top of the top section to –2px for IE, 0 for everybody else.

In the download below, you can see a completely static page with no JavaScript in stop_sans_js.html.  The IE-specific styling is invoked via a <style> tag that is within an <!—[if IE]> comment tag.

For a more interactive approach, see stop.html and stopsign.js.  This invokes a JavaScript function to produce a stop sign of a specified size.  The script requires jQuery, which I have also included in the download – and it uses jQuery’s somewhat deprecated $.browser.msie sniffer flag to apply the correct style.

Both versions now work correctly in IE8, Chrome, Firefox, Safari, and Opera.  If you use a measurement other than pixels, though, you might run into issues.  IE8 especially seems vulnerable to rounding problems, which can leave little gaps between the sections.  If the text is too large, the middle box can bump outside its bounds also.

UPDATE 2010-03-24:  My original version wasn’t a regular octagon.  I was using width / 3 for the length of a side, but it should really be width * (sqrt(2) – 1).  I’ve corrected the JavaScript in the download to apply that calculation.  I didn’t bother correcting all the hard-coded numbers in the non-JavaScript version.

Sam Mela liked my WiPeD debugger for WordPress, but he wanted an easy way to include call traceback information.  So he added it, and he kindly shared his addition with me.

I’ve adapted what he did to my own tastes and included it in the download below.  Whenever you want to add the current call stack to the debug log, just call:

WPD_backtrace();

In order to test this, I added a new option in the Options page:

Trace the following actions (comma-separated)

Just enter the name of any action hooks on which you want to get a traceback added to the debug log.  This is not only useful for testing the plugin, it can also be used to find out where in the twisty little passages of WordPress each of the actions gets invoked.

Largely because of this feature, I now initialize this plugin whenever it is activated.  Previously I delayed setting it up until WPD_print was invoked.  So this plugin now imposes a small overhead if it is activated and not used.  Be advised.

I also adopted Sam’s idea of providing default styling (which I modified significantly).  If you don’t like it, you can remove or modify WiPeD.css.

I’ve made a few revisions to my JavaScript version of Sudoku (which you can play here).  Changes include:

• As soon as you press a number key, it is checked (instead of waiting for you to leave the cell).
• You can use h, j, k, and l to move around the puzzle (a la vim), in addition to the arrow and tab keys.
• If you press the letter q, the current cell is toggled “questionable”.  The provided stylesheet colors questionable cells with a yellow background.  This can help you backtrack on your guesses.
• When a new game is presented, the first empty cell is now focused (previously, nothing was focused).
• I added a “Help” button that pops up a floating help window.  You can click and drag this window anywhere, and you can close it by pressing ESC or by clicking on the “x” button in the title bar.  Three new style classes were added for this window (see readme.txt and sudoku.css).
• When you successfully solve a puzzle, an alert pops up that says “Solved!”  Waiting for that to happen will prevent you from thinking that you’re done when there are still some empty cells left.
• I separated the styling for cells that are corrected by a Solve (class sudokuCorrected) and those that were still empty when Solve was pressed (sudokuSolvedEmpty).  The provided stylesheet colors the text for these red and blue, respectively.  This helps you better determine where you went wrong.

Yes, this is such a major upgrade to my OPML Browser plugin for WordPress that it warrants bumping the initial digit in the version number.  Here’s what changed:

1. The plugin now expects to be installed in its own folder: (siteurl)/wp-content/plugins/opml-browser
2. JavaScript and CSS have been separated into their own files.
3. JavaScript events are now hooked on window load instead of in the HTML.
4. Added “alt” attribute to all “img” tags.
5. Images are now looked for in (siteurl)/wp-content/plugins/opml-browser/images
6. If an image cannot be found, it will be replaced by the supplied unknown.png (a question mark).
7. Added “Sort items?” option.  This sorts within categories, unless the “flatten” option is enabled (see next item).
8. Added the “Flatten hierarchy?” option.  This combines all items into one level.  If sorting, all items get sorted together.
9. The OPML description attribute is now displayed as a tooltip (as in the OPML Blogroll widget, but it also works in IE and Opera now!).

As far as I know, the OPML Browser can now do everything that the OPML Blogroll widget could do (items 7 through 9 filled that out), so I am herewith declaring the OPML Blogroll widget retired from further upgrades.  Please use this plugin’s widget instead from now on.  Let me know if I’ve forgotten any functionality that you need.

A big “thank you” to all of my users who requested various features and reported bugs.  This plugin would not be what it is today without your input. 

I’ve often found that one of the best ways to learn how to do things in a programming language is to attempt to write an interactive game.  My daughter got me hooked on Sudoku, and I thought to myself “this should be a pretty trivial algorithm to implement in JavaScript.”  I’ve been working on it a few minutes at a time in between other projects ever since.  This morning I finally put a lid on it.  You can download the code below, and you can see it in action and play it as often as you like.

The Game

This version of Sudoku presents the usual 9 x 9 grid which is divided into nine 3 x 3 regions.  The object of the game is to fill in the grid with numbers from 1 to 9, such that each row, column, and region contains one and only one instance of each number.  To get you started, each game provides a number of “givens” — cells that already have their value filled in, and which you cannot change (indicated by a gray background).  By default, this version randomly provides 36 givens — without any attempt to evenly distribute them across rows, columns, or regions.

When you enter a number in a cell, if the value conflicts with another cell in the same row, column, or region, then the background of both cells will be changed to red (unless the other cell is a given, in which case it remains gray).  If a cell has two or more conflicts, a darker shade of red is used, up to four conflicts — beyond which point the color remains the same.  If you try to enter a value in the cell other than the numbers 1 through 9, the cell is cleared.  You can also clear the cell by pressing “delete”.  When a cell is focused, the arrow keys can be used to navigate to the next cell in the specified direction, with wrap-around.  Tab and Shift-tab follow the browser’s defined behavior for navigating input controls — the cells are defined in column order within rows, followed by the buttons.

The “Hint” button provides another given, randomly choosing an empty cell to fill in.  If there are no empty cells remaining, an alert “Can’t fill in anything!” will be displayed.

The “Solve” button will reveal the entire puzzle.  Note that it may be possible to solve a Sudoku in more than one way for the given values, but this button reveals the solution that was generated when the puzzle was created.

The “New” button generates a new puzzle.

You can use your browser’s “Zoom” or “Text size” functions to resize the puzzle.

Browser-specific differences

This game was tested with the following browsers, and revealed a few minor issues where noted:

• Google Chrome 1.0.154.46
• Mozilla Firefox 3.0.6
• Safari 3.2.1
• Internet Explorer 7 & 8 – Sizing the browser small enough causes the cells to misalign.  Corners on the container aren’t rounded.
• Opera 9.25 – border width differences used to delineate the regions are not honored, and neither are the rounded corners on the container.
• Opera Mini Simulator- same issues as Opera.

I’ve attempted to make this game mobile-friendly, but of course it only works on platforms that support JavaScript and CSS.

Styling

All styling for this game has been separated out into the file sudoku.css.  You can modify this or provide your own stylesheet to change the effects for the following class names (note that more than one class name may be applied to an individual cell):

• sudoku – the container for the game (defined in sudoku.htm)
• sudokuButton – the control buttons
• sudokuCell – every cell in the puzzle
• sudokuGiven – a cell whose value is given
• sudokuCorrected – a cell whose value has been corrected by pressing the “Solve” button
• sudokuConflict0 – a cell whose value does not conflict with any other cells
• sudokuConflict1 – a cell whose value conflicts with one other cell
• sudokuConflict2 – a cell whose value conflicts with two other cells
• sudokuConflict3 – a cell whose value conflicts with three other cells
• sudokuConflict4 – a cell whose value conflicts with four or more cells
• sudokuRegionTop – a cell that is along the top edge of a region
• sudokuRegionBottom – a cell that is along the bottom edge of a region
• sudokuRegionLeft – a cell that is along the left edge of a region
• sudokuRegionRight – a cell that is along the right edge of a region
• info – the section that contains the link to this page

Using the code

This code has been designed to play well with others.  It introduces only one global symbol, the name of the Sudoku function.  However, it does use the jQuery framework (included in the download).

You can instantiate a Sudoku puzzle within any HTML element using the following code:

new Sudoku(elem, ngivens)

where elem is the DOM Element that will contain the puzzle, and ngivens is the optional number of givens to display (default = 36).

Algorithm

For every new puzzle, the script generates a completed solution and then randomly chooses the location of the givens to reveal.  The algorithm for generating the puzzle can probably be made more elegant, but it works.  The generatePuzzle() function is called recursively, beginning with the first cell and progressing to the last one.  At each cell, the numbers 1 through 9 are attempted in a random order until no conflicts are found and we successfully recurse through the rest of the puzzle.  Thus, if no solution can be found for a given combination up to this point, we backtrack through the recursion and try something else.  This could certainly be optimized — for instance, we could keep track of unused values within the current row and only try those.  But I’m not certain that the benefit of that optimization wouldn’t be offset by the additional array manipulation required.  Ideally, this is a problem for graph theory — perhaps one day I’ll attack it from that angle.

For checking conflicts, the script maintains arrays of arrays:  an array of rows, an array of columns, and an array of regions.  Each element of these arrays is an array of DOM elements:  the “input” element for each cell.  Each of those elements also has back-linked properties for its row, column, and region.  Thus, when the “onchange” event occurs for a cell, we can easily check it against the other cells that might conflict.

For more details, see the comments in the code.

UPDATED 2009-02-17 to add styling for cells corrected by “Solve”.  Also added readme.txt and license.txt.

In my consulting business, I often have to switch my attention between different projects.  Unless I keep good notes, it can be difficult to figure out at the end of the day how much time I spent on each one.  So I developed this little stopwatch application that you can download below.  It lets you create as many independent stopwatches as you want on a single page, then start and stop them as appropriate.

To keep track of what each clock represents, they each contain an edit field for a description.  And if you forgot to start the clock, you can adjust the time whenever it is stopped by typing over the clockface’s value.  When you restart it, whatever is in the clockface will be parsed.  If it contains a string that matches the pattern H:M:S, those values will be used to compute the initial time on the clock.  You’re not limited to 60 minutes/seconds or 24 hours either.  For instance, if you want to start with a value of 110 minutes, you can type either 0:110:0, or 1:50:0.  On the first update, the value will be converted into the usual time notation.

You can see a demo of this application, or feel free to use it at that URL as often as you like.  You can also embed a timeclock in any web page simply by including a reference to timeclock.js and executing the following JavaScript snippet:

new TimeClock(elem)

where elem is a DOM Element that is to be the parent element of the new clock.  You can style the clock in CSS using the classes that are applied to each of the clock’s elements:

.tc-timeclock /* the clock's outer box */
.tc-close  /* the 'X' box for closing the clock */
.tc-descr  /* the description edit field */
.tc-face   /* the clockface */
.tc-start  /* the Start button */
.tc-reset  /* the Reset button */

See timeclock.css for some examples.

Tested with Google Chrome 0.3.154.9, Mozilla Firefox 3.0.1, Opera 9.2.5, Safari 3.1.2, and Internet Explorer 7.

Here’s a Windows desktop version written in C#, if that suits your style better.

Last year I changed the theme on this blog and my other ones to make use of Matthew Levine’s Holy Grail approach to layout – or rather,  a simplified version of it, since I only need two columns.  My motivation for doing this was to render the content before the sidebar (for impatient and mobile users, as well as for SEO), yet have the fixed-width sidebar float on the right and leave the remaining space to the content.  Although simplified for two divs instead of three, wedging it into an existing style sheet was anything but simple.  I wrestled with padding and margins until I got it working for Firefox and IE7.  In Opera and Safari, the sidebar kept popping out below the content, and (with apologies to their users) I didn’t care enough about those browsers to spend any more time trying to remedy this mostly cosmetic issue.

Enter Chrome.  It’s such a fast browser that I decided to start using it as my default for a while.  Of course, it uses WebKit for rendering, same as Safari — so sure enough, my sites had the same bug, only you’d see it faster.  I decided it was time to do something about my problem.

One of the reasons why I never figured out what was going on in Opera or Safari is the dearth of web debugging tools available for those browsers.  Chrome adds a JavaScript console that also shows you the dimensions of the sections and what styles actually get applied to them.  Turns out, though, that confusion over CSS inheritance wasn’t my problem.

As usually happens when you can’t figure out a problem, I had more than one.  So tweaking one of those settings wouldn’t show me any difference.  But, by carefully progressing from the working model to my version, I was finally able to ferret out the buggers.

First, Matthew’s approach sets the main fluid (center) section to a width of 100%.  But my theme set the width of an outer box to 96%.  That apparently allowed WebKit (and Opera’s Presto engine) to extend the logical edge of the inner section outside the outer box, squeezing out the sidebar.  I removed that outer 96% setting and changed the inner one to 96%, letting the inner divs push the outer one out.

Second, it appears that WebKit and Presto count border widths in addition to the width specified for a section.  Those widths had to be added to the size of the padding for the container and the negative margin used by the sidebar, to prevent two pixels of borders from squeezing out a 200+ pixel sidebar.

The net result moves the sidebar a little to the left from where it was in Firefox before, but I can live with that.  Let me know if you spot any other Knights Who Say Ni!

Thanks to a suggestion from Diego, I have added tooltips to each entry in the OPML Blogroll widget for WordPress.  These tooltips display the content of the “description” attribute of each outline entry, if one exists, when the user hovers the mouse over the entry.

Note that this is not an update to the OPML Browser plugin, although I plan to add the same feature to that plugin as well (along with a ton of other enhancements).

I used JavaScript to pop up and remove the Tooltips.  I decided to roll my own (with much help from Shelley Powers’ book Adding Ajax) rather than use an existing library, in order to keep the widget lean and to avoid conflicts with other libraries that might be in use on your blog.

Thanks to Internet Explorer, this seemingly simple enhancement required about twice as much JavaScript code as as a Firefox/Opera/Safari-only version would have.  Here are the differences that required special code for IE:

1. Of course, events don’t get passed to event handlers.  So you use window.event.  No big deal.
2. And we all know about addEventListener vs. attachEvent.  Not a problem, just wrap it in a function.
3. If you attach a property to a DOM object, lose the reference, and then reacquire that same element from the DOM later, it doesn’t have the property you added any more.  Apparently IE gives you a new object each time.  So in IE, this plugin has to look up the tooltip for the current item every time it wants to be displayed.
4. Not having the “currentTarget” property on the Event object in IE really sucks.  You can use “srcElement”, but it isn’t the same element as “currentTarget”.  For instance, if you have a “mouseover” event on an element that contains a link around an image, “currentTarget” gives you the element on which the event was specified, whereas srcElement will give you whatever contained element the mouse was actually over.  So this plugin accesses parentNode until it finds the one that’s meaningful.

Another nice “feature” of Internet Explorer keeps the tooltips from displaying at all in my theme – perhaps due to the use of float on nearby div’s.  I tried the fix outlined here to no avail.  It does work using the WordPress default theme, though, so there is hope.  Let me know how it works with your theme.

I also fixed a problem with the auto-discovery link in which the ending quote on the href was missing.

Linking to earlier versions for pingback.

UPDATE: 2009-05-11: I have incorporated all the features of this widget into my OPML Browser plugin version 2.0.  Please upgrade (it’s free). 

In a recent article I wrote on [Geeks are Sexy] Technology News about the new Google Chart API, I mentioned that the only thing that’s not simple about this API is the data encoding. So, I set to work to remedy that and I whipped up the little tool you can download below to help prototype Google charts and generate the URL.

It doesn’t include all of the options in the API, but I did provide an “Additional qualifiers” field where you can append anything you want to the chart’s URL.

For now, it only supports Simple Encoding. I may add Text and Extended Encoding at some point in the future.

Next in line is to add some JavaScript to make this more interactive, as well as to wrap the Chart object in a WordPress plugin.

You can see this in action (and use it all you want) at http://chipstips.com/demo/chartmixer.php.

A few days ago I started reading Shelley Powers’ new book, Adding Ajax, a free copy of which Shelley generously sent me.  In the very first chapter, Shelley said something that helped me solve a nagging problem that I’ve had for months.

Readers of this blog and my other one may have noticed (and some of you have remarked) that when my sidebar length exceeded the content length, the sidebar overlapped the footer and extended into dark space.  How amateurish.  But I had spent way too many hours tweaking the HTML and CSS trying to remedy the situation, and had finally given up.  The thing is, I knew how to avoid this aberrant behavior, but not without either displaying the sidebar first or making the content section fixed-width.  What I wanted was to have the content size fluid, the sidebar size fixed, and to display the content before the sidebar (for the benefit of all readers, but especially those using a screen reader or mobile device).  So I used a large right margin on the content and applied an absolute position to the sidebar.  But with that arrangement, clear:both on the footer ignored the sidebar’s length.  For someone who cut their web teeth using tables (or dare I admit it, frames) for layout, it was enough to drive me crazy.

In Shelley’s book, she gives a very clean and simple example that applies float:left to the content and float:right to the sidebar, drawing the latter last and applying clear:both to the footer — which works fine, except that in that case a fluid content section will take up all the available space, forcing the sidebar to appear beneath it.  But Shelley hinted that this was possible with fluid layouts, and said something even more useful at the end of her example:

For additional reading on CSS layouts, search the web for “fluid fixed elastic CSS layouts”.

Now, I had previously googled until my googler was sore trying to find a solution to this problem, but I hadn’t used those exact search terms before.  Since I’m not interested in fixed or elastic layouts, I omitted those words and googled anew.  This led me to the Holy Grail of web design.  Matthew Levine explains a simple but unique approach to making fixed-width sidebars float either left or right of a fluid center section, with a footer below them all.  In brief:

1. Enclose all three sections within a container section, using position:relative and float:left to keep them from stacking vertically.
2. Apply padding to the left and right side of the container for the desired size of your sidebars.  This restricts the fluid center section to the remaining space.
3. Use negative margins on the sidebars, to move them back out over the container’s padding.
4. For the left section, specify the position.  The right section gets bumped out automatically by the size of the center section.
5. Use clear:both on the footer, to position it beneath all three sections.

Since I don’t have a left sidebar, I was able to do this even more simply:

1. Enclose the content and sidebar sections within a container section, using position:relative and float:left.
2. Apply padding to the right side of the container for the space to reserve for the sidebar.
3. Use a negative right margin on the sidebar.
4. Apply clear:both to the footer.

Naturally, this didn’t work the first time (when does it ever?) — I had issues with inherited padding, prematurely closed div’s, and other such nonsense that had accumulated like dust in my theme files over the course of many tweaks.  These were relatively easy to hunt down using the Web Developer toolbar for Firefox (which Shelley also recommends in her book), using the Display Block Size and Display Div Order options on the Information menu.  One issue that I suspect would have taken me much longer to hunt down had it not been for this feature was a conflict between div class names — my theme used “content” for the class of the main content section, and the Brian’s Threaded Comments plugin uses the same class name for the section that includes the contents of each comment.  So when I added float:left to ”.content”, the comments section went haywire.  That’s a good example of why, when writing a plugin, you shouldn’t use common class names or ids for elements it produces — you should always prefix them with something to make them unique, because you never know who else might be using that name as well.  To work around it, I just renamed my “content” class to “blogcontent”.

Over the years, I’ve learned CSS and Javascript on an “as needed” basis.  Shelley’s book seems well targeted for an audience of people like me, because it’s all about bringing existing sites forward to these newer approaches.  I’m sure that it will fill in some gaps for me — and that this won’t be the last solution that gets sparked from reading her pages.

Call me clueless, but I did not know until I found out from Jenn that the <FONT> element has been deprecated and will not validate XHTML 1.0 strict DTD.  The keywords-tagcloud widget for WordPress uses that element with a SIZE attribute to scale the tags in the cloud (extends wrists, awaiting slap).

Far be it from me to fly in the face of progressing standards, so I have just released version 2.3 of the keywords-tagcloud widget that uses a STYLE element specifying font-size instead.  You can get it by pressing the button below.

Besides averting a visit from the W3C police, using the font-size style provides much more flexibility on how the font is, um, sized.  You got pixels, percentage, etc. to choose from.  So I added a field to the widget’s control panel where you can specify what units to use.  The scaling maximum/minimum fields in Options/Jerome’s Keywords/Tag Cloud Display can be used to control the range of units to apply.  Unfortunately, these values get rounded down to the nearest integer, so “em” doesn’t work well for units.  Also, CSS units don’t provide an exact mapping for the old font size attribute, but “ex” is pretty close, so I made that the default.  However, I found that “%” with a range of 70-250 looks nicer for my theme, and you can see that on the right sidebar here.

If you do your own styling of the widget, make sure you read the upgrade notes.

Thanks, and keep on tagging!

Pingback to all previous posts on this subject for the sake of those who subscribe to comments.