This is an essay. It contains the advice or opinions of one or more Wikipedia contributors. This page is not an encyclopedia article, nor is it one of Wikipedia's policies or guidelines, as it has not been thoroughly vetted by the community. Some essays represent widespread norms; others only represent minority viewpoints.

Shortcut WP:QUIRK

The factual accuracy of this Wikipedia page may be compromised due to out-of-date information. Please help update this Wikipedia page to reflect recent events or newly available information. Relevant discussion may be found on the talk page.

This page in a nutshell: The many quirks have workarounds: Stack boxes/images from widest to narrow, to avoid text-eclipse. Insert "<!--XHERE--> beneath, to re-find a recent edit-spot. Upon page-edit, do 1 edit-preview to avoid an F5 erase. Indenting template lines, stop newlines by "|" ending first line. Several other quirks, some in Google, are explained in detail.

This essay is intended to try to explain what is happening, hourly, to Wikipedia, and to suggest work-around solutions. Everything is changing, without warning, and lots of it is quirky. There are hundreds of unusual, or unexpected quirks or glitches in the way things sort-of-do, sort-of-don't work. On any given day, new problems might arise, or old problems get fixed, as the developers adjust the servers or hack the MediaWiki code to alter character-shift typesetting for the 200+ Wikipedia languages (see below: Why quirks occur).

Not all problems are caused by Wikipedia's software configuration. Many problems are actually from each user's PC setup or browser, such as pressing F5 (before edit-preview) and losing all edit-text (see below: Browser nightmares). Also, Wikipedia is not alone in having website quirks, even Google has had them (see section below: "Google quirks").

There are several issues about page formatting:

• Text-eclipsing – Wide boxes, following narrow boxes, tend to overlap (or eclipse) the nearby text (during 2007-2009). Stack any boxes, or images, from widest to more narrow. If a box is only 5px (pixels) wider, it seems to avoid the overlap and fits ok.
• Bottom category jump-around – Sometimes the bottom category information tends to jump about an inch up the window. People might put an extra blank line (two) at the end of an article-page, trying to avoid this wack-a-huh whatever.
• Delayed rendering-shifts – The placement of images on a page, a few seconds after display, might suddenly jump, a fraction of an inch (perhaps 0.5 cm), such as yanking images toward the right-margin, away from the left-side text. Also, the caption in an image-box might jump a hop several seconds after the page appears (as of April 2009).

There are some issues about editing a page:

• Edit-preview reset to top – During a page-edit, the edit-buffer reset to the top line during a show-preview in late 2009. For years, when editing a Wikipedia page, a user could perform an edit-preview ("Show preview"), and the page would redisplay with the edit-buffer window remembering which line was being edited. By July 2009, an edit-preview would typically reset the edit-buffer window to the top (1st line) of the text. As a workaround, insert a searchable comment to re-find the edited region, such as: <!--XXHERE-->, several lines beneath. Then find "XXH" and the region appears.
• Copying old edit-page window – During a page-edit, prior to Nov. 2009, copying that browser window (Ctrl-N) might fill the new window's edit-buffer with older text, with the prior contents of the edit-buffer (as it appeared during the prior edit-preview). Before copying the window, users had to edit-preview first, and then both windows would have identical edit-buffer text. However, this prior-contents issue could be used (as a "neat feature") to access/copy the edit-buffer contents as they had appeared during the prior edit-preview, before typing the latest text into the edit-buffer.
• Forgetting to show the updated version - During an unfortunate few days in mid-November 2009, after an article was edited, Wikipedia would display the old revision of the page, giving the impression that most (all) edit-changes had been lost. Luckily, the history-tab showed the new revision was properly stored, so then, by deleting all browser files, the new revision could appear as expected. Obviously, many users were horrified a while.
• Scrambled list of prior revisions - This happened years ago, perhaps during 2002, when revisions were not properly sequenced, and stepping through prior revisions would skip some. Never seen again, revision sequences have appeared correctly during 2006-2009.

The MediaWiki markup language is a peculiar twisto-mash of 3 computer languages. The most normal language is the typical free-flowing text that allows triple-quote '''bold-font''', along with the HTML tags, such as <ref>...</ref>. However, along with that stuff, there is a 2nd language as wikitable codes (in Help:Table), so that a table begins with "{|" and ends "|}" which formerly were required in column 1 but can be indented now (at least sometimes, or maybe not whatever). Then there is the 3rd language: the "infamous" if-you-indent, you get "quotebox" yes the all-important quotebox, which in computer-typesetting typically requires only 2 markers; instead, just indent and the whole section turns into quotebox – quotebox – quotebox. Ah so, oh-so-important quotebox he look like:

 Me is quotebox – I so cool, so important.
 Me is quotebox – wiki would die without me.
 Me is quotebox – I exist here 8 years plus forever.

So, anyway, put all 3 schidzo languages, blended together, and you get MediaWiki markup (or markdown?) language, affectionately known as "wikipuke". Well, as can be expected with dissociative identity disorder (DID), the 3 languages fight for power: when HTML code is formatted with typical indentation, the me-is-quotebox personality, at times, hijacks the page, and you get hypertext-markup-laughter displayed in a box that looks like (...wait for it...) a QuoteBox!

So important, the quotebox:

• Footnote quoteboxing – The first footnote-coding on a page sometimes cannot be indented (as in May 2009) without spawning a "quotebox" so, instead, it is necessary to either, make a one-liner of the first footnote, or split it into multiple lines separated by HTML comments.

  Kids don't do this. Don't design coding as quotebox.<ref><!--
   -->''Computer languages 101 - Bad ideas to flush'', <!--
   -->"Chapter 1: Quotebox nightmares", Stae N. College,<!--
   -->Dept of Dropouts Become Billionaire Morons,<!--
   -->University of Thank God Others Got Education, 2009.
  </ref>

The above text, with the multi-line footnote shows use of 4 HTML comment lines "<!--" & "-->" to simulate indenting by putting each text segment on a separate line.

• Template quoteboxing – In some cases, the parameters passed to a template will contain newlines (CRLF carriage-return linefeeds) at the end, because the parameters were indented. Compare the following 2 ways to invoke a template:

  ((Mytemplate | param1=xxx   <!--param1 gets "xxx<newline>" -->
               | param2=yyy
               | param3=zzz ))
  ((Mytemplate | param1=aaa | <!--put bar "|" to stop newline. -->
               | param2=bbb
               | param3=ccc ))

In the first use of "Mytemplate", the value of param1 can be considered to be "xxx<newline>" because the coding was split, with param2 (value "yyy") on the 2nd line. In the second use of "Mytemplate", the value of param1 is only "aaa" because the vertical-bar (or pipe) "|" stopped param1 from including the line-break newline. When the template begins to process "xxx<newline>" then the newline might be seen as an indentation, within the template, so the template would start considering all subsequent lines to be part of the oh-so-important quotebox, generated now in the middle of the template procedural coding. Surprise!

Well, perhaps the users and article editors might find the coding steps somewhat annoying, adding the "|" bar, just to avoid producing quoteboxes. However, imagine the stress on the Wikipedia developers, having to ensure that any changes or enhancements, to the MediaWiki interfaces, must continue to work as before, generating the same demented, peculiar sets of quotebox indentations, everywhere they had popped up before.

Many problems that users think are caused by Wikipedia are actually caused by limited Web browsers. For example, in some mainsteam browsers:

• Pressing F5 might erase all edited text from a window, totally losing everything as typed (and the back-key can't recover the lost text). To prevent that, do one edit-preview before further input.
• At the end of a line, text might wrap in very spastic ways, such as splitting at a parenthesis "(" or left-bracket "[" in the middle of entering text.
• When using the backspace key to erase a prior character, the cursor might shift to the wrong prior character.

All of those problems are caused by quirky browser operation (not Wikipedia), as the browser does not reflect the way that people actually think. In advanced software design, users would be allowed to set preferences for text-wrapping, cursor-movement, cursor-shape, etc. Those preferences could be set to overcome some design flaws in the basic design of a system (such as a browser), until the more normal settings are preset as the defaults in later software versions.

The exact causes, behind each quirk, are perhaps too complex to explain in this essay. However, some general principles can explain how the problems have arisen, over the years.

Wikipedia's underlying software system, with the MediaWiki markup language, is constantly being changed to fix old problems and try to offer new, better features, but better for whom? Many changes are made to support the unusual typesetting needs of rare written languages that use split-character placement of text or other unusual options not seen in English or other European languages. The English Wikipedia is impacted because all 200+ languages share some common software, and that software gets changed for everyone.

Sometimes (or often?), some really bizarre features are added, such as allowing wiki-templates to pass newlines at the end of parameter values, simply by indenting the next line, when calling a template. Normally, bizarre features would be designed to require special coding to trigger those features, such as: if you want to pass newlines in parameter values, then specify them, explicitly, such as "param=aa#nuline;bb#nuline;cc#nuline;" where the code "#nuline;" or "<br>" (or some other invented thing) is the feature to be requested. Unfortunately, "one man's bizarreness is other man's ordinary dork-otopia" and some developers think that everyone should change their ways to adjust to the new stuff. Overly often, peculiar ideas are treated as mainstream "everyone-should-know-nerdisms" which become some of the widespread quirks that appear, from day to day.

Complicating the complications is the reality that, eventually, several multiple nerdisms are implemented. Rather than maintaining some basic, core levels of simplicity, the multiple nerdisms start interfering with earlier peculiar features, and the result becomes conflicting nerdisms with almost unpredictable, expanding quirks. Even the most level-headed, otherwise-normal software developers will become overwhelmed by the pre-exising nerdisms, so that even simple changes can introduce new quirks, and hence, no single group of people can be blamed for the combined, bizarre outcomes. Far surpassing "creeping featurism" the total system becomes "featured creepyism" or is unintentionally garbled to "feeping creaturism".

By considering the design flaws, and the operational instability, it is possible to get a better understanding of the psychological pressures that people face when using Wikipedia. Knowing the details, about specific quirks, can help avoid the stress or frustrations in the future.

Wikipedia is not alone in having many website quirks. Even Google Inc., with all the $billions, has had some very unusual things happening in the official websites (for years):

• Search-animation (October 2009) - Slow animation was added to the Google-Search page: on the main page, someone decided to try a fade-in of the menu options, every time the page appeared (not checking cookies), and it was a slooooowww fade-in, for millions of users per hour. Needless to say, it was removed within a few days, and perhaps some employees were also.

• Translation-overwrite/fadeout (19 November 2009) - In yet another re-write of the Google-Translate interface, someone changed the German-to-English webpage to display translated text, then overwrite it onto the input text (WTF?), and then have the translation totally fade-out (perhaps the fade-in crowd from the main page were reassigned to Google Translate).

So even an organization with $billions of revenue cannot seem to avoid utterly spastic, peculiar quirks in their webpages. Perhaps the world is seeing a rapid growth in the rise of "nerdnology" as typical notions of quality control have been abandoned, almost everywhere. No longer are major changes tested on a sample user-group, but instead, released untested to the entire world. The quirks are not merely planned obsolescence, similar to allowing computer viruses, which are known to kill user computers and cause people to buy new or fix-it software products (as the planned result). Instead, the quirks are not the work of college-dropout billionaires, but rather just a collection of misdirected changes.

[ This essay is a draft to be expanded later. ]