Comments line graph

I had promised a WordPress pluggable version of the comments line graph and here it is. The line graph application is in two pieces: one to place in your theme directory and include in your page template; and a plug-in that will create the cached comment count file.

File one is graphcomments.php, which is installed in your theme. You’ll include the following in your web page template where you want the graph positioned:

<object style="width: 810px" data="/wp/theme/graphcomments.php" type="image/svg+xml" ></object>

Change the location for your environment. The element needs to be styled to fit the preferred width. The number of comments remains the same, but the graph resizes based on this width. The following is the same graph, but the containing element is set to 500 pixels wide.

[object removed]

In addition, the graphcomments.php has a style section with three values that you can change: line width (stroke-width), color (stroke), and opacity (stroke-opacity, a value between 0 and 1, with 0 being transparent, 1 being fully opaque).

The second piece is the plug-in, store_comments.php, which needs to be added to your plug-in directory. Both of the files require access to a single file, called comments.csv. This is a file that must be writable by the world, stored wherever you want. You can make it by creating an empty text file, and then use “chmod 766” to make it writable. If you don’t make this file, the application will attempt to create the file, which means the whole directory has to be world writable.

Both store_comments.php and graphcomments.php have a constant, FILENAME, which needs to be altered to fit the location of where the comments.csv file is stored.

How the comment graph line works is that whenever a new comment is saved, the comments.csv is updated to reflect the comment counts from the most recent 100 posts. The application that generates the SVG reads this file for the comma-separated values, and then creates the line graph.

At this time, the comments line graph is restricted to 100 comments or less, so, be forewarned if you get those 130+ comment days, the peak will be truncated.

The graphcomments.php application can be used on any data that is located in the file, each value separated by a comma. You can use it for category counts, unique visitor counts, anything that has simple totals over time.

Version 1.0 beta:

graphcomments.php store_comments.php


  • Click the links and save the files, changing the extension to php from phps.
  • Place the graphcomments.php in your theme.
  • Place the store_comments.php in your plug-ins directory.
  • Create an empty text file named comments.csv, and place it in a directory. The directory does not have to be web accessible.
  • Change the file permissions to world writable, chmod 766.
  • Change the FILENAME value in both graphcomments.php and store_comments.php to the location of comments.csv file.
  • Add the line graph object element, example given above, to wherever your want the line graph to display.
  • Style the object element and the line graph.

The line graph is created using SVG. You don’t have to serve your pages as XHTML when you include SVG via an object element, as this application does. The line graph should work in IE if the person has the Adobe SVG plug-in installed, but no promises. Or you can set a container DIV element in which the object is installed to not display for IE. Check my header to see how to create IE specific style sheets.

I tried to center the line graph so that the tips aren’t truncated until after the 100 comment mark. There is white space at the top and bottom, but using negative margins for the top and bottom should eliminate most of it.


Safari fills in the background with white, by default, for the object container. I’m exploring how to change this, but I don’t expect to have a lot of luck. It looks like this behavior is a bug (or as planned, but not wanted). Feel free to use, but the graph won’t have a transparent background like the graph in my header, which is inline SVG. Of course, you can also copy my inline SVG, but then you’ll have to serve your pages as XHTML.


Even the mistakes are fun

Anne Van Kesteren:

A new survey reveals that at least Microsoft and IBM think the HTML charter does not cover the canvas element.

I have to wonder, when reading the survey results, how much the people who voted actually used either SVG or the Canvas element. I covered both SVG and the Canvas Element in the book, but I focused more on SVG. Comparing the two–SVG and Canvas–is like comparing the old FONT element with CSS.

The Canvas element requires scripting. The SVG element doesn’t, even for animation if you use the animate elements. In addition, mistakes in SVG can be fun, as I found when I missed a parameter value in mistaken animation. A couple lines of markup. No script. Both Opera and Safari do an excellent job with the animation elements. I’m expecting Firefox to join this group in the next year.

If you use scripting, you can access each element in the SVG document as a separate element. You can’t do that with Canvas.

I still don’t think the Canvas element should be part of a new HTML 5, whatever the grand plans. However, since all but IE supports the Canvas element, it would be foolish to drop it. A better option would be to consider the Canvas element a bitmapped version of SVG and create a separate group to ensure it grows in a standard manner.

I did like what David Dailey wrote in the survey results:

I have considerable ambivalence about <canvas> as I have noted previously. If we were designing HTML 5 from the ground up , SVG and canvas ought to share syntax and ought not to duplicate so much functionality. <canvas> brings a few needed things with it, though it seems rather a bit of poor planning on the part of the advocates of <canvas> that has gotten us to this point. Those historically frustrated with W3C chose to ignore SVG and now seem to want W3C to ignore SVG in favor of a lesser technology. At the same time, <canvas> does enable client-side image analysis by giving the developer access to pixel values, and that alone allows for some tolerance of what otherwise seems to be a curious decoupling of reason from politics. Does it re-invent the wheel? — only about 95% of it is redundant with 20% of SVG.

As for all the discussion about semantic API…years ago I, and others, made a fight for a model and associated XML vocabulary, RDF, we said would stand the test of time and hold up under use. The road’s been rough, and few people are going to defend reification, but RDF fuels the only truly open social graph in existence. Five years ago. That was about the time when everyone believed that all we’d need for semantics was RSS. Including Microsoft.


Flawed Safari on Leopard

It would seem that Apple released Leopard with the branch of Webkit that can’t hack certain uses of SVG. Because of this, you won’t be able to see the comments, due to the use of SVG to provide head and footer caps surrounding my comments.

This was a known problem with Webkit, and I filed a bug. I’m disappointed that Apple would release a broken version of Safari. I mean, it’s not as if the company isn’t taking a hit for it’s use of graphics in Leopard, already. At the least, it could put out software that’s working.

In the meantime, I may end up pulling my use of SVG. Or I might ask if you would please use another browser and let Apple/Safari/Webkit know that the browser’s handling of SVG is broken.


I found the problem, and an old unassigned bug related to this at WebKit.

What’s happening is that the SVG is expanding to fill the entire containing DIV element within which the SVG is placed (when display is set to ‘block’, not ‘inline’), either wiping out or ‘hiding’ the other contents. I surrounded the SVG in the comments and sidebar within a containing DIV element, and the SVG is no longer ‘overlaying’ (or removing) the rest of the content.

Question is, where is the bug here? Me for not embedding the SVG element in it’s own DIV element? Or WebKit for wiping the other content out on the parent element?

Regardless, the SVG is now working for Safari on Leopard.