When I implemented Hackadelic SEO Table Of Contents, there hardly was an alternative TOC solution for WordPress. Meanwhile, several have arisen, all of which provide a subset of SEO Table Of Contents’ features. When observing this development, I’ve been (naturally) asking myself why people bother to reinvent the wheel. Artem Russakovskii, who has also contributed to the development of SEO Table Of Contents, has recently asked that question out loud at the youngest offspring in the TOC plugin familly, Ted Carnahan’s WordPress jQuery Table of Contents plugin.
This technological choice is the most compelling characteristic of Ted’s plugin – and the most problematic one. In fact I have considered a jQuery implementation myself, and it hurt me badly that I had to reject it – for a good reason. Follow me on this…
Saving Server Time
Manipulates DOM instead of HTML text
The DOM is ultimately well-formed. There is practically no way to “spoil” the well-formed-ness of the DOM by manipulating it. Manipulating a clean HTML document through the DOM always results in a clean HTML document.3
The DOM is browser-specific, so cross-browser differences how irregular HTML is rendered are already ruled out.4
In the case of a table of contents, the most important deficiency implied is that it will fail to produce a complete TOC for a multi-page post (as it will only ever see the headers on the current page only).
- The DOM is a representation of a HTML document as a hierarchy (i.e. tree) of HTML elements. [↩]
- Though you may well violate some specific W3C standards even by DOM manipulation, but that’s another story. [↩]