Blogging equals complaining, right?
This has got to be THE MOST annoying dialog box to ever come out of Redmond.
Is there anyway to make “Restart Later” mean “Don’t bug me about restarting my computer. Ever. Again.”?
This post first appeared on From the Belly of the Beasts, a weblog from some of the people who build O’Reilly websites.
My old cellphone developed an annoying affliction. Since St. Patrick’s Day, when someone called me, every so often they got the following message:
The PCS telephone number you’ve dialed is temporarily not in service.
Message 262. 3.
Since I dial my own phone number to check my voicemail, I also started hearing the message occasionally. Too occasionally. Usually it would happen when there was a significant gap of time (a few hours) between incoming calls. When someone dialed my number again, they’d most likely get through.
The only problem with always-on voicemail is that it conditions us to expect to ALWAYS get through. When you get a unexpected message like the one above, people think I didn’t pay my cell phone bill, or my phone number is no longer good. And they don’t always try to call back. Which means just like that, Sprint has begun providing me with an unacceptable level of service.
But I couldn’t determine if the problem was my trusty but ancient, monochrome Samsung SCH-A460, or if there was an issue with Sprint’s network. Predictably, tech support was little help. In the end, they suggested I get a new phone. I was long overdue for an upgrade, and apparently I could get a $150 rebate with a new 2 year contract. Yay. Let me take this opportunity to say that I HATE CELL PHONE CONTRACTS.
I shopped around, but in the end I really just wanted a cellphone that made phone calls. The only improvement I could imagine would be finally having the ability to send and receive text messages. So though I cooed at the Motorola phones offered by T-Mobile, I ended up sticking with Sprint, having 7 months still left on my current 2 year contract. Plus they had a decent looking phone, actually their only decent looking phone, on clearance for only $19.99, the Samsung PM-A840.
I was hoping I’d get the phone for free with that $150, long time customer “New for You” rebate program, but it turns out in a feat of devious marketing, the $200 clearance rebate that brought the phone cost down to $19.99 was actually same as the “New for You” rebate. And then as if to add insult to injury, they charge me 8% sales tax on the full price of the phone even though the rebate was instantaneous. Is that even legal? So I ended up paying $37.59 for my shiny new phone. And they tack on trial “PCS Vision” services I can’t decline unless I call customer service in a few days. What a scam. At least I got a new plan for the same price with 100 more minutes.
And guess what. The annoying message that started off this whole process is still happening. Except now I can receive text messages.
In the blogosphere (and on the web) permalinks are sacred. Every broken link is like a demerit against your credibility. Even more so with syndication.
So I spent my day trying to figure out why Movable Type 3.2 occasionally appends an “_1” (an underscore followed by the number one) to the end of a published permalink (a basename in MT parlance) when there is no conceivable collision with any other basename, and without creating a duplicate entry.
We thought maybe Ecto was to blame. But I couldn’t recreate the problem with the latest versions on either Windows or Mac.
I talked to a few of our bloggers, and no one could point to a discernible pattern—other than that it only seemed to happen after an edit was made to an already published post. So I tried multiple combinations of setting a post from Published to Unpublished and then back again. But no game.
I reached out to the MT ProNet list and someone suggested that this may be a “known issue” in MT 3.2:
Turns out this was spot on. Here’s how to reproduce the bug:
I wouldn’t be able to sleep at night if I knew my blogging platform was producing unstable permalinks when users preview their posts and resave them. This is a problem on the scale of “our software is breaking the world wide web.” C’mon Six Apart, can I get a little more gumption than “this is a known issue”? This has been a known issue for five months!
Update: after my rabble-rousing on the ProNet list, Jay Allen posts a patch for fixing the “MT incrementing basename bug”. Thanks Jay!
This post first appeared on From the Belly of the Beasts, a weblog from some of the people who build O’Reilly websites.
Let’s say I create the following entry in Movable Type 3.2. Five paragraphs with the middle three enclosed in a blockquote. Fairly standard blog post skeleton.
paragraph 1 <blockquote> paragraph 2 paragraph 3 paragraph 4 </blockquote> paragraph 5
What HTML do I want MT to produce as a result?
<p>paragraph 1</p> <blockquote> <p>paragraph 2</p> <p>paragraph 3</p> <p>paragraph 4</p> </blockquote> <p>paragraph 5</p>
What HTML does MT actually produce? Invalidly nested HTML. Fun.
<p>paragraph 1</p> <blockquote> paragraph 2 <p>paragraph 3</p> <p>paragraph 4<br /> </blockquote></p> <p>paragraph 5</p>
What a bummer. I would consider this a fairly critical bug. Oh, and WordPress gets this right. Workaround: manually mark up the paragraphs inside the blockquote. One more thing I wish I didn’t have to remember.
This post first appeared on From the Belly of the Beasts, a weblog from some of the people who build O’Reilly websites.
Gotta love IE’s little surprises. I’m not sure if this is a known bug, in fact I’m not even sure if this is a bug at all, but I thought I’d write it up for future reference.
One of the challenges of laying out pages in HTML is that there’s no native way to associate a caption with an image so that the caption’s width is constrained to the width of the image.
In order to accomplish this, we wrap both the image and the caption in a div with the width set to be exactly the width of the image. Because both the image and the caption are inline elements, this should force the caption below the image and cause the text to wrap appropriately for the size of the image.
Here’s some test code to demonstrate what I mean. Note: I’ve added the red border in order to make the div easier to see.
<div style="width:100px;border:1px solid red;"> <img src="caption-bug-test-image.gif" width="100" height="100" alt="caption bug test image" /><em>This is the caption for this test image</em> </div>
Now in Firefox, the code above looks just like we want it to:
However, Internet Explorer interprets the HTML above in a vastly different way:
Because there’s no whitespace between the img tag and the caption (surrounded by em tags), IE chooses to break the line after the first word in the caption rather than before. The best (read: most annoying) part is that if I modify the source above to include a newline in between the image and the caption like so:
<div style="width:100px;border:1px solid red;"> <img src="caption-bug-test-image.gif" width="100" height="100" alt="caption bug test image" /> <em>This is the caption for this test image</em> </div>
…then IE behaves as expected (or at least closer to expected):
Adding a <br /> tag between the image and the caption also works in both IE and FF without adding an extra line between the image and the caption, but that’s an annoying thing to have to enforce. Might make sense though considering that an image is an inline element.
Of course in this context we’re essentially treating the image like a block level element. So another solution would be to create a class for our image container divs that sets a CSS display:block; rule for any image inside the div. Except sometimes we include multiple images (side by side) inside the div. Oh shucks.
This post first appeared on From the Belly of the Beasts, a weblog from some of the people who build O’Reilly websites.