Post Archive
› May 8, 2003
New tweakings to Webgraphics
Have you noticed the new larger comment box? *phew* that was needed for a long time. Also glad to report that we finally have comment previewing! This very handy (default) feature of Movable Type was purposely omitted by me when I first setup MT because at the time I couldn't figure out how to easily allow previewing without using the mini-comment pop-up window. Not that I'm against it, just thought I'd avoid it here.
In any case, it became clear that if you're going to allow markup tags and keep line-break conversion on, it might be helpful to check how it looks before posting. So this brings me to a question: to line-break, or not to line-break. The advantage - easy and no-nonsense, it rewards those who just want to make a simple comment without markup. The disadvantage - if one wants to use markup in a comment, the entirety of their comment has to be a long text string to avoid sprinkling in br tags, the result is usually just a lot more whitespace than expected. The comment previewer will help matters, but is that enough? Regardless of if you have an opinion on the line-break matter, leave a comment to test out the improvements, then leave another one to let us know what you think!
Comments
1. May 8, 2003 02:26 AM
2. May 8, 2003 02:34 AM
Nate Posted…
Now testing recursive previewing. I added this line after the first preview. Now I'm adding a third line after the second preview. Ok, so far, recursive preview is stable and quick, now let's post it.3. May 8, 2003 02:59 AM
ksmith Posted…
You could allow the user to choose between plain text & HTML-formatted comments, like Slashdot does.
I'd like to think your users are at least as savvy as that gang ;)
For my site, I require comments be previewed at least once before they can be submitted. OTOH, I don't allow HTML in the first place, so it's probably overkill.
4. May 8, 2003 03:06 AM
Nate Posted…
The plain text vs. HTML formatted would be very slick. I wonder how one would accomplish that in MT?5. May 8, 2003 04:05 PM
Andreas Posted…
Looks good, Nate. It would be cool to include also the <code>-tag (for e.g. CSS codebits) and the <acronym>-tag. And also: we've got <strong> already; do we really need <b>?6. May 8, 2003 04:16 PM
Nate Posted…
Good points Andreas - I'll add in code and acronym (or should it be abbr?), and I'll take out the b tag. I guess I'll also need to specify a style attribute of whitespace:pre with a selector of code in the style sheet. I'm still also pondering the plain-text vs. markup text option, and how to do that in MT. It seems like there would be a fairly easy way.7. May 8, 2003 05:13 PM
Andreas Posted…
Well, maybe it's better to stick to acronym for now as IE6 doesn't display the abbr's title value when hovering over it.8. May 9, 2003 03:01 PM
Michael Hanscom Posted…
At the risk of sounding overly egotistical (but isn't that what the web is all about?), you may be interested at what I've got up and running on my site. Since I wasn't happy with the pop-up previews either, I ended up finding a very nifty little hack that incorporates a "live preview" directly into the page. Supports HTML, linebreaks and paragraph breaks show up, works quite well for me. You may not want to use it, since you've got this up and running here, but I figured it might at least be of interest. Just pop into the comments for any post and play around for a bit, you'll see what I'm babbling about. :)9. May 9, 2003 04:38 PM
10. May 11, 2003 06:24 AM
Jesse Ruderman Posted…
I wish whitespace conversion would only apply when the whitespace is not redundant. For example, if there are two newline characters between paragraphs marked with P tags, they should be ignored. Newline characters over the number of line breaks "implied" by surrounding BR tags or by the default margins of P, UL, LI, or BLOCKQUOTE tags should be converted to extra BRs. Newline characters at the beginning and end of ULs should be ignored so that the open and close UL tags can be on their own line without affecting layout. I think this would allow the following types of comments to come out correctly, without the need for options:- plain-text comments
- comments that only use HTML for inline style
- comments that only use HTML for lists (such as this comment) (kind of like mixing plain-text with HTML-formatted)
- comments that use HTML for everything
Nate Posted…
Did you guess? I'm testing it out right now.