Indi in the Wired

Once Again, Testing New Toys

When I edited this blog to serve as proper XHTML, I was required to disable the footnotes plug-in I originally selected. It was a bummer, to be sure, because I really wanted footnotes. It took me a while to sum up the cojones to try again, but I finally did decide to test out a couple new plug-ins.

Footnotes

You may have noticed that my old footnotes no longer work in some of my older posts.[1. If you are seeing this text inline, you can see what I mean.] To be honest, I was always underwhelmed with the syntax, but it worked (at first), and I figured I could live with it. The only viable alternative seemed to be a dead project. Until I got around to writing my own (which I figured was inevitable, and may still be), it was going to be the best that I could get.

A couple of weeks ago, the alternative got a flurry of updates. The author claimed that all invalid mark-up had been fixed, but the proof is in the pudding. As you can see,¹ the author deserves a medal. It works, and it looks good. In fact, it looks better than the other did. In fact, even the bare mark-up that would show when the plug-in is disabled looks better.

But it’s still not good enough.

I cannot add any code or equations to footnotes yet for two reasons:

• First, the plugin does not work properly with nested HTML. Some works, some doesn’t. Notably, in my case, neither <pre> nor <math> work. (I found a cheap workaround for the former, but not yet the latter.)
• WordPress’s parser never get a chance to parse the <pre> tags for my code-highlighting plug-in. Even when (if) I fix the problem above, I will be able to have formatted text in my output, but not automatically syntax-highlighted text.

Still, what I have is better than nothing, by far.

Image Captions

While I was looking for the footnotes plug-in, I stumbled across another neat plug-in that automatically captions images using the title attribute’s text.

Cool! I thought. Hook me up!

The plug-in’s author was even careful to note that the plug-in generates valid XHTML, and it does. But unfortunately, once I activated it, my entire blog crashed.

What happened? Was it the plug-in’s fault? No. It was WordPress’s. Read on.²

I Hate Software That Thinks It’s Smarter Than Me

If I have one beef with WordPress so far it is that it is so “smart”, it’s bloody stupid. Even the “HTML” editor tries to be clever, with disastrous results. For example, I can understand the WYSIWYG editor taking the initiative to replace “dumb quotes” ("") with smart quotes (“”) – that is helpful most of the time and only annoying in rare occasions. But those rare occasions are important. When I want to write code, it is imperative that that code shows up correctly. The types of quotes used make significant difference. Try copy-pasting this code into an HTML page, and it won’t work: <span lang=”es”>Español</span>. I can fix that particular problem with only some effort, true (<span lang="es">Español</span>) that is a symptom of the underlying problem. WordPress is written under the assumption that its users are stupid.

One bit of nonsense that is very problematic is that WordPress automatically inserts paragraph and line breaks between lines. If I type a sentence, then hit enter, then type another sentence, WordPress inserts a <br /> tags to create a line break between the two lines. If I hit enter twice, WordPress interprets the two lines as two separate paragraphs, and surrounds each with <p></p>. In the WYSIWYG editor, this is brilliant! But in the HTML editor… well, take a look at an example. If I type this:

<math mode="inline" xmlns="&mathml;">
   <mrow>
      <msup>
         <mi>&ExponentialE;</mi>
         <mrow>
            <mi>&ImaginaryI;</mi>
            <mo>&InvisibleTimes;</mo>
            <mi>&pi;</mi>
         </mrow>
      </msup>
      
      <mo>+</mo>
      
      <mn>1</mn>
      
      <mo>=</mo>
      
      <mn>0</mn>
      
   </mrow>
</math>

<p><math mode="inline" xmlns="&mathml;"><br />
   <mrow><br />
      <msup><br />
         <mi>&ExponentialE;</mi><br />
         <mrow><br />
            <mi>&ImaginaryI;</mi><br />
            <mo>&InvisibleTimes;</mo><br />
            <mi>&pi;</mi><br />
         </mrow><br />
      </msup></p>
      
<p>      <mo>+</mo></p>
      
<p>      <mn>1</mn></p>
      
<p>      <mo>=</mo></p>
      
<p>      <mn>0</mn></p>
      
<p>   </mrow><br />
</math></p>

Which completely fucks up the mark-up.

This kind of thing is what prevents me from getting footnotes that work, and what crashes the image captions plug-in.³ In fact, it has been the cause of all of my headaches with WordPress, bar none.

The depressing part is how silly and unnecessary it is. All they would have had to do when making WordPress is add a one-time filter every something in the visual editor is switched away from to the HTML editor or saved. Whenever a post is saved from the visual editor, or the user switches from the visual editor to the HTML editor, all of that neat beautification can be done – replacing of “dumb quotes” with smart quotes, adding paragraph and newline tags, etc. Then the HTML editor could be a true HTML editor (probably better termed a raw source editor, I suppose). Then anything is possible, and even easy. The only further filtering done is by plug-ins during the rendering construction phase.⁴

Perhaps someone can explain to me what the reasons are, if any, for WordPress doing things the way it does them, rather than being much, much simpler. Is there any real logic to it, other than simply trying to outsmart the guy writing the post? I’d be curious to hear.

1. In this footnote example. [↩]
2. I should note that it may be possible to fix things, if I go back and re-edit my old posts to a specific format, which I may do. [↩]
3. In the case of the image captions plug-in, what happens is that when the text is something like:
   <a href="image.png"><img src="image-small.png" alt="Alt" title="Title" class="alignleft size-medium wp-image-18" /></a>Some text.
   The final mark-up is:
   <div class="img alignleft size-medium wp-image-18">
   <a href="image.png"><img src="image-small.png" alt="Alt" title="Title" class="alignleft size-medium wp-image-18" /></a>
   <div>Title</div>
   </div>Some text.</p>
   Do you see the problem? Where is the opening <p>? Uh-oh! Crash!
   This problem can probably be avoided simply by always putting the image code in the middle of a paragraph rather than at the beginning or end, but I have to experiment before I can state this with certainty. At any rate, it is frustrating to be so constrained by a plug-in that does – effectively – nothing useful. I do not mind making concessions for footnotes – which are important for adding additional contextual information to text – but such effort for eye candy is frustrating. [↩]
4. To see how this would fix the image captions plug-in, realize that in this system, the <p> tags are visible in the HTML editor, and remain untouched right through to final rendering. The plug-in would do its code replacement unhindered, leaving the original opening <p> tag. Even if you opt to use the visual editor, the <p> tags surround the text at saving (although they are not visible), and stay there right up to rendering – the plug-in simply does its replacement, without a problem. [↩]