NovaChild, try the <pre> and </pre > tag.

I kind of wish you wouldn't. The <pre> tag doesn't work correctly when viewing this board in Mozilla. Any time you do add a line break, it adds a bunch of extra line breaks with it, so the resulting text looks terrible.

t pre doesn't quite work, because it also puts it in monospace font. Which makes people thing "quote" here, rather than new text. I just don't like the way it comes out looking for poetry or lyrics. (shrug)

P-C, when we were very young, not all browsers seemed to respect the <font color="white"> and some people would end up accidentally spoiled by what we whited out. I'm not sure if that's still the case, but I have a hint of memory that the quick edit "s" protected more people.

Ummmm..... no. All the "s" does is surround the line with a <font color="white"> tag. The advantage is that users are less likely to make a mistake by dropping a quote mark or something similar.

The "s" quickedit does have the advantage that it can be easily changed server side -- which is where the background colour of the page is most likely to change too.

But that likelihood? Small.

Ummmm..... no. All the "s" does is surround the line with a <font color="white"> tag. The advantage is that users are less likely to make a mistake by dropping a quote mark or something similar.

I think what I was remembering was different from how I put it. Some browsers (Opera, maybe?) close any html tag at a pargraph break. That feature is pretty great when someone drops a t b or an t i -- but not so great when someone only puts in one t font color="white" at the beginning of his spoilery text, and one t /font at the end, and it's multi-paragraph text. Using the quick-edit "s" requires that you put an "s" at the beginning of every new paragraph, and we know that, so there was less browser-induced accidental spoilage.

I fear this makes no sense to anyone but me. At any rate P-C, you're right. The problem I was thinking of was really, if not actual user-error, then at least something caused by habit (only coding a whole bit of text, rather than each paragraph).

erm... yeah.

Using the quick-edit "s" requires that you put an "s" at the beginning of every new paragraph, and we know that, so there was less browser-induced accidental spoilage.

Aaaah. This was the issue I was referring to earlier. I think the one time I tried to use the quick-edit, I was spanning paragraphs and didn't put it at the beginning of every line, and it came out looking funny, so I went back to using HTML. But I think I've figured out how to work it now.

Yes. And actually for quick edit, you need the code at any intentional new line. In other words, if you force a new line, you need a new quick edit code at the beginning of the new line, if you want the quick edit to work in it.

And for some of your readers, the same is going to be true of HTML, because some browsers will close your HTML tag with a paragraph break, even if you don't intend for it to be closed.

some browsers will close your HTML tag with a paragraph break, even if you don't intend for it to be closed

The good ones will. The new paragraph is supposed to implicitly close the sub-block level tags within it.

The good ones will. The new paragraph is supposed to implicitly close the sub-block level tags within it.

Is there something built into the coding of this board that prompts that? I'm wondering, because in LJ, and on other posting boards where I've used HTML, the tag stays open until intentionally closed. The good (but not as good as this one) posting boards will force a tag close at the end of a post, so that it doesn't infect subsequent posts (all my other boards are upside down, such that the newest posts are on top).

Each paragraph here is enclosed in t p tags. Which means that compliant browsers won't let a t b or t i tag bleed into the next t p -- it's probably a closer match to HTML as designed than the other boards, but that doesn't make it better.