derrell

The solution is to add a “overflow: hidden” to the div id:

<div id="map" style="width:200px;height:200px; overflow: hidden">

Update: I solved this by manually resizing my background picture to 742px. There’s probably a better CSS approved way, but I’m not a web geek.

gall,

I think the bug is related to how WordPress is deciding when to omit <br />, <p>, and </p> tags when processing text. I’ve noticed it terminates the last paragraph differently, depending on whether you press return on the last line (in ecto) or not. If you don’t, you get a trailing <br />; if you do, you get a trailing </p>. Of course what’s following this is only ever an HTML comment and another <p>, so there’s a dangling open paragraph which the modified template closes. So what I see is either:

<br /> (WP) <!-- </p> (template)

…if I don’t press return before clicking ‘Publish’, or:

</p> (WP) <p> (WP) <!-- </p> (template)

…if I do press return before clicking ‘Publish’. I note that MarsEdit, in showing you the HTML explicitly in your edit buffer, essentially reformats the end of your text ensuring, by default, that WordPress will terminate the last paragraph with a </p>.

I think the bug is essentially that WordPress is not smart enough to ignore the HTML comment that forms the Technorati start tag. It’s acting like the comment might be more paragraph content. Are HTML comments part of an existing paragraph or are they just pragma? Beat’s me, but WordPress is clearly treating them as if they were potential paragraph content, and that’s what’s seemingly getting it into trouble: both because it’s emitting opening <p> tags it shouldn’t and because it’s leaving the comment open with a <br />.

bdsays,

No, this is all either ‘ecto’ or ‘MarsEdit’. I’m only vaguely aware of ‘flock’. But I think any client might run into this depending on the exact sequence they send to WordPress, since the extra tags which mess up the validator are being generated on the WordPress side. The HTML stream the clients are sending is valid.

From watching the RPC sent by both MarsEdit and ecto, I’m pretty sure it’s mostly something that should be fixed on the WordPress side. Both MarsEdit and ecto are sending valid HTML via XML-RPC, but something’s causing WordPress to emit a <br /> instead of a </p> when it gets the post from ecto.

I’m a big fan of ‘be conservative in what you send and liberal in what you accept’. Which is to say that if you’re a server and if at all possible, you shouldn’t be depending on the client side to get it right.

As an experiment, I tried changing MarsEdit to use the Moveable Type API and it still works, so I don’t think the choice of API matters. In a similar vein, I tried the other APIs with ecto and they all fail too.

I have a workaround though. If I modify the template definition for ‘tags’ in ecto (“Weblog” > “Edit Templates…”) to be:

</p><p style="text-align:right;font-size:10px;">Technorati Tags: $tags$</p>

…which is to say, I force the </p> that I can see is missing when I do a View Source, I then get similar HTML and it passes the validator.

But the real problem remains in that what ecto is sending:

<!-- technorati tags start --><p style="text-align:right;font-size:10px;">Technorati Tags: <a href="https://www.technorati.com/tag/blog" rel="tag">blog</a></p><!-- technorati tags end -->

…ends up being served back as:

<p><!-- technorati tags start --><br />
<p style="text-align:right;font-size:10px;">Technorati Tags: <a href="https://www.technorati.com/tag/blog" rel="tag">blog</a></p>
<p><!-- technorati tags end -->
</p>

Perhaps I need to move this question to a different forum…

Watching the XML-RPC via tcpdump, ecto seems to be sending the right thing. The leading <p> (and <br />) along with the trailing <p> and </p> combo are apparently being added by WordPress.

Is this perhaps a result of the API I chose in the XML-RPC config?
I’m using the Moveable Type API, for no particular reason.

Ah, this also involves the ecto 2.4.1 client that I’m using to post. Here’s what’s failing to validate:

<p><!-- technorati tags start --><br />
<p style="text-align:right;font-size:10px;">Technorati Tags: <a href="https://www.technorati.com/tag/blog" rel="tag">blog</a></p>
<p><!-- technorati tags end -->
</p>

Clearly this is broken HTML as what’s expected is something along the lines of:

<!-- technorati tags start -->
<p style="text-align:right;font-size:10px;">Technorati Tags: <$TAGS$></p>
<!-- technorati tags end -->

At first I was inclined to blame ecto, but then again maybe WordPress is generating the <p> tags. More investigation required…

I’m in the process of switching from Moveable Type; the WordPress blog I’m working on is here.

WordPress 2.0.2, default, Akismet