Test

Extended ASCII Test, plus Comments

Let's see if TP will transform an ASCII 146 (right single quote) to it's numerically-referenced Unicode entity, ’. Here we go:

Let’s not ask what our country can do for us ...

... let it through. Dass bad. But then nobody else's parser traps for these characters, either.

Clear the Table

Awright, let's see how TypePad's parser handles inline block elements. First, a word about the mechanics of these things.

The two sentences above were keyed into TypePad's "Compose a New Post" textarea with no markup embedded by me. Since I didn't specify any markup, TypePad should be assuming the text block is a paragraph, and be sniffing for paragraph's end. The signal should be a pair of newlines or the occurrence of a new block-level element that I've keyed. Along the way it should transform single linefeeds into <br />s. There's one following this phrase
How'd we do?

Good. Single and double newlines generated <p>s and <br />s just as hoped. Hold it. That's an open <br>. Keep holding it. This is weird. Firebird/Win lets the user View Page Source but also to View Selection Source. Page source shows a well-formed <br /> but Selection Source a malformed <br>. Wassupwitdat? Anyhow, TypePad gets a pass.

Now to test the embedded block-level element trigger, first when one follows a single linefeed. Here's an explicit paragraph after a linefeed:

Hi, sailor.

… then another linefeed, and we're back. How'd we do?

Not so good. TP evidently always treats a single linefeed as a <br />, and didn't sniff-out my new, explicit paragraph — thereby knowing to close the prior one. It's not a deal breaker: users simply have to understand that behavior, which, I'll guess, is "It takes two linefeeds to signal that the prior paragraph should be closed." Like so:

Wanna party?

That should be valid. But it ain't. TP nested my explicit paragraph in one of its own. What's this mean? Can't apply inline styles to individual paragraphs, not simply. How about with a <div> wrapper?

I love you longtime

Well?

Now that's just plain weird. TP sniffed my <div>, let it through (natch) and didn't wrap it in a <p>. It looks ahead for some hand-coded elements but not others, specifically <p>s. Wonder why.

Now for a table. This one will have linefeeds between the table sub-elements, 'cause the thing's unreadable without them.

Test Table

Column 1	Column 2	Column 3
A1	B1	C1
A2	B2	K9 (heh)

Perfect. TP knew not to litter the <table> markup with <br />s

TP can handle <blockquote>s without fouling the markup. Here's proof:

Here's a <blockquote>

We also know that it handles lists and nested lists. So it seems that the TP parser's lookahead is sniffing explicitly marked-up block elements except for <p>. Mysterious. To my mind that's a bug.

Moreover, while it's obvious to me that two newlines trigger the look-behind for open block-level elements, that behavior should be stated: Not everyone will assume it.

Lorem, Please!

Lorem ipsum dolor sit amet, consectetaur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum Et harumd und lookum like Greek to me, dereud facilis est er expedit distinct. Nam liber te conscient to factor tum poen legum odioque civiuda.

I have a question:

• What will TypePad do with an unordered list?
• What sort of mark-up markup will it generate, if any?

Nice job! Handled the <del>, too. Did I mention that this page validates … so far.

Hmm ... handled a spanned style. Time for nested lists.

• Bullet One
  1. Whoa, what's this? A nested, numbered list?
  2. Hold onto your hats while we revalidate
• Just need to close the UL. Hang on.

Rendered properly, but it's invalid. Looks like a doctype problem ... checking ...

Sorry, my mistake. Like a dope I tried to contain an OL directly within a UL. The OL needs to be contained within one of the UL's list-items. Validates now. Sorry to bother you.

(This looks pretty fucking solid. TextBox is in some serious trouble.)

The formatting buttons provided on the post-editing page wrap selected text in markup. I thought that was an MSIE-specific behavior. Somebody's got some tight javascript running here, because the buttons work in Firebird 0.6. You're I'm soaking in it.

mailto: link is encrypted. Nice touch.

Photo album's pretty snazzy, too. No way to specify the cropping of thumbnails that I can see, so irregular dimensions produce weird results.

Et tam neque pecun modut est neque nonor et imper ned libidig met, consectetur adipiscing elit, sed ut labore et dolore magna aliquam makes one wonder who would ever read this stuff? Bis nostrud exercitation ullam mmodo consequet. Duis aute in voluptate velit esse cillum dolore eu fugiat nulla pariatur.