line breaks?

I think it used to be that if I
inserted a newline in my post by myself
it would be like regular HTML and would
stay on a single line unless I used
paragraph tags or whatever.

That seems to have gone away, and now
the posts are some strange mixture
of HTML beahviour and not: newlines
appear to turn into <br> which
seems incongruous to me.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Can you see the input format

Can you see the input format radio buttons at the bottom of the input form? I am not sure normal users can, but you if you do notice the difference between "filtered" and "full" HTML.

Re: input format

I don't see any radio buttons. I took a
screen shot.

P.S.: "Lines and paragraphs break automatically" is a confusing statement to me. I don't know what it really means, especially given the changing behaviour of line breaks.

Ok. Will investigate...

Ok. Will investigate...

Re: radio buttons

I see them now, yay! However, the system doesn't seem to remember or let me set the default one I want, and it always chooses the one I don't want so I have to manually change it every time I post: a human throttling mechanism, I get it.


I'll see if there's anything we can do about that...

The old version of Drupal had two ways of formatting comments, depending on how they were written:

If a comment included no HTML tags, then line breaks in the input were automatically converted into sensible equivalent <br> elements <p> elements in the final page.

If a comment included HTML tags, the auto-break behavior was turned off, and normal HTML rules were used instead. This meant that if you wrote a comment relying on the auto-break behavior, but then included e.g. a single hyperlink, the auto-breaks would be lost and you'd either end up with a single big paragraph, or would have to insert paragraph tags.

The new version doesn't change behavior depending on the input. Currently, a single line break is interpreted as a <br>, and a pair of line breaks are treated as a paragraph break. That's what the help text means by "Lines and paragraphs break automatically".

This can actually be quite convenient, once you're aware of it, although a lot may depend on how one authors comments.

We have the option of customizing things in various ways. The current behavior seemed like a good compromise, and is the default Drupal behavior, IIRC, or at least an easy one to configure. However, if there are strong opinions about How It Should Be(TM), state them in this thread and we'll take them into account.

Strong Opinions

Well, not really, but I think I like the new behavior. The old behavior always confused me... I'd toss in a blockquote or something and everything would go to hell.

Either way

As long as it's predictable. :-)

While I'm here, I'd also like to mention that the pages are automatically refreshing themselves on the back button. Probably something to do with the page timeout being set (and probably related to a fix in the login requiring a manual refresh).

Only problem is that if I jump to a link within a thread and then page back to the thread, a page refresh occurs. This means that (a). I lose track of where I was in the page; and (b). I lose track of which posts I haven't read yet - assumming I clicked a link on the first unread post.

Not sure if there's a good compromise to be had. I like the current behavior for the Recent Posts page. Kind of a pain though for the viewing of an individual thread.

New Data

  • Personally, I think text that uses HTML tags should behave like HTML. Would you expect your Haskell code to suddenly be interpreted in a different way? This really strikes me as usability 101 here, folks.
  • The kicker is that even old posts are now rendering differently!


Personally, I think text that uses HTML tags should behave like HTML. Would you expect your Haskell code to suddenly be interpreted in a different way? This really strikes me as usability 101 here, folks.

Usability depends in part what your expectations are. Ironically, in the "old post" you linked to, you wrote: "I think Jef Raskin had it right: [usability] is not an absolute, it heavily depends on individual experience." Many people posting on blogs have the expectation that they can type a few paragraphs separated by blank lines, and include a hyperlink or some other minor piece of HTML formatting, and still have the paragraphs render as intended. See Matt's comment above, for example. In addition, this behavior can be convenient, if you're not using an HTML editor to write your comments.

We'll consider some options for satisfying both sets of expectations, though.

The kicker is that even old posts are now rendering differently!

Thanks for pointing that out, it was an oversight in the upgrade process (I converted comments, but not forum nodes). It's fixed now.

Re: usability is relative

Yup, I bow to the fact that usability is relative (but I guess that doesn't mean I won't stop being as pig-headed as the rest of the world about it :-).

Re: ( :-)

As an aside, do people think (xyz :-) is allowed, or should it be (xyz :-)), or should it just be avoided outright? :-)

there should be an emacs

there should be an emacs mode that allows unbalanced smileys.

hmmm. i guess winking smileys are ok in lisp mode! ;o)

New optional input format

We've added an input format option to allow a choice between blog-style plain text input, and pure HTML. You can select the input format you want to use via the radio buttons below the comment input box.

The default input format hasn't changed - it's the one called "Plain Text + HTML". It interprets a single line break as the equivalent of an HTML <br>, and a pair of line breaks as a paragraph break. This supports the input of plain text, as well as allowing HTML tags to be included.

The new, optional input format is called HTML, and it doesn't do any special line break handling, it just renders the input as standard HTML.

The allowed HTML tags for both options are limited to the same fairly liberal set.

HTML tags

Not to be a whiner, but that is a "liberal set" of tags? It may have gotten lost, but I mentioned the lack of <sup> and sub as two examples. I'm not sure why they are not included, there are no doubt many others.

Another minor comment, that probably went unnoticed, is is there any way to have the blog software automatically close unclosed tags in a post?

Texas liberal, maybe?

Your comment did get lost, sorry. We'll add sup and sub, and any others suggestions which make sense.

Closing unclosed tags was one of the reasons for starting to use an HTML filter, and it was a surprise to me that it wasn't happening (we noticed it the other day). I'll look into it.

Closer to Vermont now

<sup> and <sub> have been added.

Formatting in RSS feeds

One other minor complaint... I read the site primarily through RSS, and since the upgrade, the HTML formatting has been different.

HTML in the RSS feeds used to be formatted the same as it is on the site. In particular, newlines in comments appeared as <p> tags (or whatever), just like on the site. That's no longer the case. It seems like content is now showing up in RSS in their raw unformatted form. So comments that look fine on the site are one big paragraph in the RSS. I'm not sure how hard this would be to fix. I wouldn't worry about it just for my sake: when the formatting gets too hard on the eyes, I just click through to the site.

It seems fine in Blogline,

It seems fine in Blogline, as far as I can tell.

Which RSS client?

As Ehud said, formatting appears correctly in Bloglines, and it's also correct in the Mozilla Thunderbird RSS client. So, which RSS client are you using?

BTW, as part of the upgrade, the story & forums feeds swicthed to RSS 2.0. The comment feed is still RSS 0.92, so if you see a difference in formatting between those two feeds, that would be a clue.

Maybe just comments?

Well, my RSS client is, mmm, "of my own devising," so it's certainly possible that there's a problem there. And the problem does seem to be with the comment feed only.

But it definitely is occurring on Bloglines as well. If you take a look at the comment feed, you'll see that virtually all the comments show up as a single large paragraph. Comparing the LtU reveals that the formatting is definitely different, and it does seem that newlines aren't getting converted to HTML in the feed.

Many of the comments show this, but just as an example, take a look at this one on the site, (here on Bloglines.)

Comment feed needs upgrading

Thanks, I see the problem. The comment feed is an add-on module which needs to be upgraded to support the new input formats. I think the problem affects messages in the "plain text + HTML" format, which aren't being converted for RSS. Watch this space...