When it comes to quick-edits, I see returns not inducing line-breaks as a feature. The return ends the quick-edit but doesn't induce a line break. Otherwise, I don't see how they're connected. Even if you're not using quick-edits, you run into the same return/line-break issue.
Buffistas Building a Better Board
Do you have problems, concerns or recommendations about the technical side of the Phoenix? Air them here. Compliments also welcome.
Still say there should be some easy way to tell the board to temporarily not do the ignore-single-line-breaks thing. I'm a big fan of double line breaks most of the time, anyway, and it is very useful for quickedit, but it is very annoying when you're posting poetry or song lyrics to have to use <br> and the end of every line.
Wish we could implement our own HTML tags. Like, t poetry and t /poetry to simply turn off the single-line-break thing inside the tags, though my initial (long ago) suggestion of a quick-edit code (l, maybe (that's an ell)) to make the following line have a single line break at the end would help as well. Saves 2 whole characters per line, and 'l ' is much easer to type than "<br>", too.
Example:
l 'Twas brillig and the slithy toves
l Did gire and gimble in the wabe
l And mimsy were the borogroves...
Hah! I put in my pin! This is the coolest thing ever!
(deep breath) Ah, yeah, thanks Gus.
I know about the quick edit, but it's confusing to use because of the way returns don't induce line breaks.
P-C, when we were very young, not all browsers seemed to respect the t 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.
Still say there should be some easy way to tell the board to temporarily not do the ignore-single-line-breaks thing.
NovaChild, try the
t pre
and
t /pre
tag.
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.