In the modern computing landscape, we are dominated by WYSIWYG (What You See Is What You Get). From Microsoft Word to web-based rich-text editors, the paradigm is ubiquitous. But beneath this visual veneer lies an older, purer philosophy—one that prioritizes the human thought process over pixel-perfect screen rendering. It is called WYTIWYG (What You Think Is What You Get), and its origins trace back to the first wiki, the Portland Pattern Repository, and a relentless pursuit of intuitive text.

To understand WYTIWYG is to understand that text is not just a visual medium; it is a cognitive one.

The Genesis: The Portland Pattern Repository

The story of WYTIWYG begins in 1995 with Ward Cunningham and the Portland Pattern Repository (PPR), the world's first wiki. Cunningham built the WikiWikiWeb to allow software developers to collaborate on design patterns. Developers think in structures, logic, and outlines—not in fonts and margins. HTML, with its verbose <b> and <i> tags, disrupted the flow of thought.

Cunningham’s solution was revolutionary in its simplicity: he created a light markup language that allowed writers to express formatting using natural, intuitive text conventions. If you wanted to emphasize something, you surrounded it with apostrophes: ''italic'' or '''bold'''. If you wanted to create a link to a new concept, you smashed the words together in CamelCase: LikeThis.

This was the birth of WYTIWYG. When a developer typed '''ImportantConcept''', they weren't worrying about how it would look on a screen; they were writing *what they thought*. The raw text itself was a readable, meaningful reflection of the author's intent. The subsequent rendering by the wiki engine into HTML was merely a secondary visual translation of that thought.

The Philosophy of WYTIWYG

WYTIWYG flips the WYSIWYG paradigm on its head. WYSIWYG forces the author to act as a typesetter, constantly context-switching between the content of their mind and the visual layout of the page. WYTIWYG respects the flow of thought.

The core tenets of WYTIWYG are:

1. Cognitive Ergonomics: The markup must be easy to remember and type without hunting for special keys or memorizing syntax.
2. Source Readability: The raw text must be just as readable—if not more so—than the rendered text. The markup should act as punctuation or emphasis in the plain text, not obscure it.
3. Minimum Viable Syntax: The language should only include elements that map directly to human cognitive structures (headings, lists, emphasis, links), ignoring complex typographical controls.

The Rise of Classic Wikis and Light Markup

Following the PPR, the wiki phenomenon exploded, and so did the dialects of light markup. Classic wiki engines like MoinMoin, UseMod, and later WackoWiki, embraced and expanded upon the WYTIWYG philosophy. Because these tools were initially built by programmers, their markup evolved to mimic the natural reading habits of code and plaintext email.

Consider the classic wiki approach to structure:

• Headings: Creating a title wasn't done via a dropdown menu, but by underlining the text with equals signs: == Level 2 Heading ==. This visually mimics the textbook method of underlining a title with a pen.
• Lists: An asterisk * naturally denotes a bullet point in plain text. A hash # denotes a number (as in «issue #1»).
• Emphasis: Wrapping text in asterisks *like this* or underscores _like this_ intuitively draws attention to the word, mimicking the physical act of highlighting or underlining.

As the WackoWiki documentation on WYTIWYG explicitly outlines, the goal is to ensure that the *semantic weight* of the text is immediately apparent to the reader in the source form. You don't need to render the page to know what the author meant.

The Markdown Problem: A Poor Example of Intuitive Markup

When discussing light markup today, the conversation inevitably turns to Markdown. Created by John Gruber in 2004, Markdown popularized light markup for a new generation. However, despite its massive popularity, Markdown is a stark deviation from the strict philosophy of WYTIWYG, serving as a rather poor example of intuitive, easy-to-remember markup.

Markdown was designed with a specific, flawed goal in mind: to make the rendered HTML look identical to the plain text source. In doing so, Gruber heavily mimicked the syntax of plain-text emails from the 1990s, resulting in markup that is often counter-intuitive and relies on invisible formatting.

Consider the follies of Markdown through the lens of WYTIWYG:

• The Invisible Line Break: In Markdown, to force a line break without starting a new paragraph, you must type two spaces at the end of a line before hitting Enter. These spaces are invisible. You are thinking about a break, but what you *get* depends on a hidden, un-thinkable character.
• Links: To link in Markdown, you write [Link text](URL). This syntax fragments the thought process. You write the text, close a bracket, open a parenthesis, write the URL, and close it. It requires mental gymnastics to parse and construct.
• Headings: Prefixing a heading with # (e.g., ## Heading) is actually quite unintuitive. A hash traditionally means a number or a comment in code, not a structural headline.
• The Ambiguity of Emphasis: Markdown uses * and _ interchangeably for bold and italic. However, word and word rely on visual symmetry, which frequently breaks in complex sentences, leading to parsing errors.

Markdown forces the user to think like a parser, not a writer. It is a “Write-What-You-Hope-The-Compiler-Understands” language. True WYTIWYG, as practiced by classic wikis, avoids this ambiguity.

The Pure WYTIWYG Approach: WackoWiki and Beyond

If Markdown is a compromise, true WYTIWYG markup is uncompromising in its intuitiveness. Looking at the markup standards preserved by engines like WackoWiki, we see a clearer path:

• Links: Instead of the disjointed [text](url), classic WackoWiki uses ((URL Text)). The double parentheses visually encapsulate the entire link concept. You open a concept, provide the destination, provide the label, and close the concept. The thought is linear and enclosed.
• Formatting: Using paired, distinct symbols like **bold** and //italic// is far more intuitive. A slash leans, much like an italicized letter. An asterisk carries weight, making it perfect for bold. The symbols *look* like what they do.
• Headings: Using == Heading == creates visual symmetry. The equals signs act like structural pillars holding the text up, making the hierarchy apparent in the source code without needing to count invisible hash marks.

Conclusion

The WYTIWYG philosophy emerged from the Portland Pattern Repository as a rebellion against visual noise and cognitive friction. It argued that the best way to write is to write what you think, using symbols that inherently carry the semantic meaning you intend.

As we navigate an era dominated by complex Markdown flavors and bloated WYSIWYG block editors, the WYTIWYG philosophy is more relevant than ever. It reminds us that text is a Medium of Thought. When our tools require us to think like machines—counting invisible spaces, nesting mismatched brackets, and memorizing arbitrary symbols—we lose the very flow of ideas we sat down to capture. True WYTIWYG, as preserved in classic wiki dialects, remains the gold standard for intuitive writing: what you think truly is what you get.