Rootbeer277's Top 10 Edits
please stop doing this, it's getting repetitive

There are no end of nit-picking guides to formatting, we don't need another one. We don't need randomly constructed advice on how to use HTML tags and how to format our writeups and what mistakes to avoid. What we do need is a listing of the errors I see show up most often. A random list is easily ignored because most of it doesn't apply to you. This particular list has been generated by my experience as an E2 editor; they are, in order from most to least common, the errors I see creep up over and over again. Please put extra effort into watching for these specifically when proofreading your work. Oh and by the way, please proofread your work. You'll save us some work and yourself some aggravation.

I should point out that I'm not just being picky with the HTML standards I've included. In order to demonstrate the improper formatting used in this writeup, I couldn't properly implement the <OL> tag! The bad formatting screwed up the formatting of the list and I had to manually type in the numbers 1–10 (including the ever-so-fashionable ASCII decorations). So it does cause problems, I'm not just being a stickler for the "rules".

-= 1 =-

It's/its errors
My #1 edit is, without a doubt, the all-too-common it's/its error. I can't remember the last day that's gone by that I didn't send out a correction on at least one of these. I'm sure you all know the difference, I'm sure it's just an accident. Either your fingers instinctively reach for the apostrophe or you're just not paying attention, but you keep doing it. This can be caught easily with a careful proofread.

On a related note, I occasionally see plurals with an apostrophe, such as "Put all the spoon's in the drawer." This isn't so common but it's just as obviously wrong. You all seem to be doing pretty good with affect/effect and their/there/they're. It's/its still trips a lot of people up though.

Example: Its easier to read your work when it's formatting and grammar are clean of errors.

-= 2 =-

Spelling mistakes and typos
If I see one, I'll copy-paste your whole writeup into MSWord to find them all, then send you a list. You could just as easily do this yourself, in fact it would save a lot of effort on your part because you won't have to track down where my corrections are in your writeup. Please do not draft your work from the text input box in the nodeshell you've created, or even in your scratch pad. Not only does any decent modern text editor come with a spell checker, but it's a lot easier to lose your work when drafting in your browser. E2 doesn't ask you if you want to save your work before closing.

If you're using Mac OS X, you can enable spell checking in your browser, but I would still advise drafting in TextEdit.

I must congratulate E2 as a whole, though, for not falling victim to the spellchecker affect.

-= 3 =-

Unreadable formatting
I know that most of you have been taught that punctuation should pretty much ignore formatting. You're not technically supposed to include surrounding double-quotes or parentheses with the italics or the ending period in the boldface and suchlike. But following these rules can make it difficult to read on a pixellated computer screen, and the rules you have been taught were for printed text. Tall or high punctuation like double quotes, exclamation points, and parentheses are most readable when included with the italics, otherwise the leaning text runs into it.

Furthermore, when using odd characters like Greek letters, accent marks and other diacritics, and mathematical symbols, you'll want to double check to make sure they're not crowded by punctuation or parentheses, or worse, obscured by the underlining a hard link adds. It's often a good idea to include a space between quotes or parentheses and the character you're using if it's crowded.

Finally, do not nest SMALL tags more than 2 deep, and do not combine SMALL with italics. It's very hard to read, especially for people who don't have the best eyesight to begin with.

(∫) vs. ( ∫ )
"Wait!" vs. "Wait!"
Is this readable? vs. Is this readable?
vs. ≡

-= 4 =-

Thousand-word paragraphs give me a headache
Remember that text on a computer screen is different from text in a book or newspaper, especially with regard to the length of lines. A line across the computer screen can be many, many times longer than a standard line in a book, which causes problems when drawing your eyes back to the beginning of the next line from the end of the previous line. This is why many textbooks are formatted with two columns per page, it can be easy to lose your place. For this reason it's good to keep your paragraphs on the short side. There have been numerous writeups I've been forced to read by highlighting lines so I don't lose my place.

On a related note, sometimes you'll have a OL or UL list in which each listed item is a paragraph in its own right. Normally these will be single-spaced and difficult to read. In this case, it's best to use <LI><P> to double-space your listed items (don't get it backwards though). Remember to end the list item with </P></LI>, or the double-spacing won't work properly in Internet Explorer.

-= 5 =-

Using ALL CAPS instead of italics
All caps have very, very limited use in a medium that allows italics and boldface. Acronyms like NASA obviously use them, and shouted dialogue uses them. But there is no more reason to use all caps for emphasis than *asterisks for boldface* or /slashes for italics/ or _underscores for underlining_. You've got the formatting tools to do this properly, so use them. Don't forget that you've also got <TT> for inserting monospaced fonts in the middle of a sentence, too.

-= 6 =-

Very long sentences with grammar errors
Most of you do a great job of using correct grammar in normal, short, straightforward sentences. However, when writing long sentences interrupted by multiple parenthetical, prepositional, or subjunctive clauses, things can get pretty ugly. Subject/verb disagreement turns into a problem, cases and tenses get swapped around, and sometimes the sentence taken as a whole turns into a sentence fragment because something got left out. The solution to this is to imagine the sentence with all the clauses and phrases removed, stripping it down to its bare subject - verb - direct object essence to make sure this makes sense. The clauses themselves rarely have errors. The problem here is that a very long sentence is difficult enough to read as it is, but grammatical errors compound the problem because the struggle to make sense out of it is destined to be fruitless.

-= 7 =-

Invalid HTML using "li" without "ol" or "ul" tags
Yeah, every major browser will interpret it pretty much the same way, by putting a bullet in from of each item but not indented — normally. It's still invalid HTML, you can't guarantee it will look the same way on every browser now and in the future, and it makes you look like an HTML n00b. If you try to nest this inside of another list, you'll definitely mess up the formatting. If you really want the bullets without the indentions, you can use &diams; — ♦

On a related note, sometimes I'll see bullets with letters or roman numerals after them, because somebody wanted the indentions but didn't know that the OL lists have more options than the default Arabic numerals. You can use <OL TYPE=A> to get capital letters, a to get lowercase letters, I to get capital roman numerals, and i to get lowercase roman numerals.


  • Wrong
    • Right
    • A. Wrong
    1. Right
    ♦ &diams;
    • &bull;

    -= 8 =-

    Indenting with UL instead of BLOCKQUOTE
    UL and OL are for defining the beginning of lists, and only for defining the beginning of lists. BLOCKQUOTE is for indenting text. Yes, this is important, especially when nesting your formatting with other types of HTML formatting, especially other lists. Browsers can usually determine what you meant to do, but get confused easily when you use multiple nested tags for purposes which they were not designed. Use them correctly and you don't have to worry about that. Remember that what looks right in Internet Explorer running on Windows XP might not look right in other browser/OS combinations (what, you mean the whole world doesn't use IE and Windows?).

    -= 9 =-

    Using TAB in a PRE formatted list
    One of those things that sounds like a good idea at the time. The problem is TABs are interpreted ever so slightly differently depending on your browser and what monospaced font it's using. If one of your words is crowding up just on the borderline of the next TAB spacing, a different font or browser could push it over that limit and you'll wind up with one line offset from the others by a full TAB. You will never have this problem if you use normal spaces instead of TABs. I see this most often on actor/character lists in movie nodes.

    -= 10 =-

    Confusing BBCode with HTML
    This one pops up from time to time when someone who uses a lot of public forums with BBCode starts using E2. Tell-tale sign: bhard linked formatting tags/b, because BBCode uses square brackets for formatting while E2 uses standard HTML angle brackets. This one's easy to spot and diagnose, and an excellent example of why you should proofread your formatting in your scratch pad before posting.