'''"Why doesn't Wiki do HTML?"''' is a question often asked by people new to Wiki. It has many answers: 

	0. Wiki's emphasis is on content, not presentation. The simple markup rules make people focus on expressing their ideas, not making them pretty. Some people have found that working in this minimal medium improves their writing.

	0. Wiki's TextFormattingRules were designed to DoTheSimplestThingThatCouldPossiblyWork.

	0. Typing HyperTextMarkupLanguage tags breaks the flow of one's thoughts, particularly for complex tags such as tables. (See example below.)

	0. Part of WikiNature is that the code should be readable; that extends to the raw text of WikiPage''''''s. When editing, content should be instantly identifiable, not lost in a sea of angle brackets.

	0. Allowing the full range of HTML tends to turn pages into bewildering mess of multiple fonts, colors, etc. If you just want to communicate an idea, YouArentGonnaNeedIt.

	0. Allowing all HTML opens security holes through JavaScript exploits, etc (although this is easy to fix; see discussion on JavaScriptEnabledWiki).

	0. Converting 25,000+ pages and the scripts that run the site would be a major undertaking without equivalent benefit. In other words, ItJustWorks. IfItAintBrokeDontFixIt.

	0. Many people don't know HTML. Wiki markup is easier to learn. [CitationNeeded]

	0. Some other wikis in fact do HTML, e.g. http://www.wikihtml.com ''[Doesn't work 9 July 2012.]''

There are some more reasons at http://www.usemod.com/cgi-bin/mb.pl?RawHtmlWiki.

See WikiDesignPrinciples which is a statement from the early days.

----

'''An Example of HTML vs. Wiki Syntax'''

A table formatted so:

 <table>
 <tr><th>X</th><th>Y</th></tr>
 <tr><td>1</td><td>2</td></tr>
 <tr><td>3</td><td>4</td></tr>
 </table>

is a '''lot''' uglier (and takes more time to type) than a simple

 X  Y
 1  2
 3  4

''Until TabMunging farks it up.''

However the markup for WikiTables used on other wikis retains the benefits of HTML tables without the noise:

 | X | Y |
 | 1 | 2 |
 | 3 | 4 |

----

'''Testimonials'''

''From RobertDiFalco:''

I should say here that I am a big time WikiWikiWeb '''lover'''. But then again, it drives me crazy that I can only do:

 one<br>
 two<br>
 three 

...in monotype! :) -- RobertDiFalco

''BigBracketedTag''''''s is not WikiZen.'' -- AnonymousDonor

Ya know? You're right. I've changed my mind. Our Twiki at work allows HTML, and some people can't help but take that to extremes making editing unruly and certainly not WikiZen. Some pages are so full of big bracketed tags that one cannot find the text or its structure. They detract from the flow. Many people know and can edit HTML, but very few can look at an unrendered HTML document and see the text and not the markup. By contrast, unrendered WikiWiki MarkupLanguage (see TextFormattingRules) allows you to avoid CantSeeTheForestForTheTrees problems.

I love finding out I'm wrong, makes me feel that I'm still a kid at 37 (02 March 1963). -- RobertDiFalco

I think WikiMarkup is one of the best things WikiWiki has given us. Well, I do think that the emphasis characters are ill-chosen (and WardsWiki's HTML output is bad), but the idea of having a simple, easy-to-read markup language with standard formatting rules to simple, easy-to-read HTML is good. I think all content should ultimately be in a format like this: plaintext, NoHiddenContent, convertible. -- PanuKalliokoski

''From another AnonymousDonor:''

The argument that tags are more natural for blockquote is silly when I can recall several instances of my work at a helpdesk involving the removal of spaces and carriage returns from a secretary's attempt to do blocked quotes. Even fewer people would ever use blockquote in the first place.

----

'''Objections to Wiki's TextFormattingRules'''

Wiki's TextFormattingRules aren't perfect. Some of the most common objections:

	0. '''Obscurity.''' Is it any more intuitive to type two single quotes than <i>? If contributors must use a markup language, why not use one that already exists (HTML)?

	0. '''Tabs.''' Typing tabs is difficult in many browsers, so much so that the page TipForTypingTab was created.

	0. '''Quote blocks.''' Combine tabs with obscurity and the result is the syntax for quote blocks: "<tab> + space + colon + <tab>" is hard to remember and to type. See SimulatingQuoteBlocks.

	0. It's hard to remember whether it takes four, five, or '''SixSingleQuotes''' to break the LinkPattern.

	0. It can be '''hard to distinguish between participants''' when more than three or four contribute to a discussion.

	0. The '''TextFormattingRules are incomplete'''. The rules do not support some markup features which might be necessary in certain contexts, for example underlining text and HtmlTables.

----

'''Alternatives'''

	* See WikiStyleSheet. Wikis with this system can turn their &lt;br&gt; back into <br>, so you can add custom tags as you need them, not all BigDesignUpFront.

	* Add a WysiWyg Java editor to the edit page. However, this creates problems:
		* It won't be powerful enough for some users
		* People have to learn yet another editor
		* Some folks disable Java
		* Some folks don't install Java in the first place
		* Some browsers ''can't use'' Java: LynxBrowser, WebTv (though the WebTv users at Wiki are probably few to zero)

	* Add WysiWyg functionality on the server using web browser Rich Text Controls for basic functions, like Epoz, http://mjablonski.freezope.org/epoz/test.html/edit which works with http://zope.org and http://plone.org, but apparently not yet http://zwiki.org, the (only?) wiki that runs on Zope. You need mozilla 1.31+ or IE 5.5+ or Netscape 7.1+. I guess you could modify it to render WikiSyntax instead of HTML, or allow multiple formats in your wiki server (best idea). See http://betterdifferent.com/software/superwiki for more ideas.

	* Allow people to type either HTML or WikiSyntax, and translate it to a standard format (e.g., XML) at save time. Translate it back to the user's preference when presenting the page for editing. See XmlBasedWiki.

	* Use HTML as THE syntax for the Wiki system. There are a few Wikis and WikiLikeThing''''''s that simply work with HTML instead. MassMind is one example, and there must be others.

----

'''Another View'''

Maybe the consistent desire we see to put BigBracketedTag''''''s into WikiWiki MarkupLanguage is because the TextFormattingRules are unnatural to the user. I find it hard to believe that it's because it's not powerful enough.

I put my thoughts on a new set of TextFormattingRules on TextFormattingRulesRevised. -- MattBehrens

----

'''HTML Semantic View'''

HTML is technically for content, not presentation, unlike noted in the second bullet at the top. Works like XHTML and CSS aid in clarifying this. As such, perhaps it is more or less of anti-HTML presentation elements (such as b, i, and font), rather than just anti-HTML (which includes some excellent elements which can be used to create semantic data). -- CortlandHaws

In that spirit Wiki TextFormattingRules totally breaks this goal allowing bold, underline, italic, etc instead of only <strong></strong> or <em></em> etc. IMHO Wiki TextFormattingRules is more about presentation than about semantic. So always IMHO all answers to the question at the top of this document are completely nonsense. -- BrunoBeaufils

----

"Is it any more intuitive to type two single quotes than <i>? People are familiar with HTML. Wiki forces them to learn new TextFormattingRules."

What people are familiar with HTML? Programmers and Web designers. What about everyone else? We use a wiki at my day job, and I'm sure glad I didn't have to teach my whole company (which includes electrical and mechanical engineers, physicists, salesfolk, skilled technicians, and admin assistants, not just software geeks) HTML in order to be able to use it. I'm sure it would've been an immediate turnoff for most people. -- MikeSmith

''Good point. The comment above has been changed to emphasize instead the fact that Wiki introduces a new markup language in a domain where a standard already exists.''


(Possibly move to AlternativeTextFormattingRules?)

----

Someone wrote, "Wiki's TextFormattingRules were designed to DoTheSimplestThingThatCouldPossiblyWork" - but the simplest thing would be for the wiki server to simply copy the text of the page from its database to the Web server, and not muck around with converting quotes to boldface, stars to <li> tags (maybe with a preceding <ol> if it's the first one), and all that dreck. -- BillTrost

''While that would be simple to implement, it wouldn't "work" in that it doesn't meet the requirements. People who tried to edit with no familiarity with HTML would have a lot of difficulty writing plain paragraphed text and creating links between pages, which is the essence of WikiWiki.''

''I would agree that the bold, italic, and list syntaxes used here are confusing and arbitrary - particularly anything requiring a tab followed by a space! But they are incidental features, not essential ones. The majority of text here consists of paragraphs of text with embedded links, and the Wiki syntax for these is perfectly simple and intuitive for the user and very simple to implement as well.''

----

Wiki's TextFormattingRules are incomplete. For example, in order to properly annotate a written source someone would need to have the ability to underline text. Also, image source tags are automatically created and there is no option to dictate how text should wrap around the image. As a result one does not have the ability to generate good looking page. A more extensive ability to markup would be nice, though it certainly does not have to be comprehensive.

''Instead of worrying about a GoodLookingPage, concentrate on just making a GoodPage.''

The fact that Wiki supports MarkUp at all is an indication that format and layout is important to being able to convey meaning and ideas. Contrary to what appears to be the consensus for this wiki the 2 goals (GoodLookingPage/GoodPage) are not mutually exclusive, rather they are often the same goal. If part of the WikiNature is to have readable text, then it should not allow images at all. The URL reference for an image is not necessarily useful in determining the information contained in the image. For example a graph named "Web Log Traffic Analysis" does not communicate to the reader of the text the information contained in the graph itself. Rather you must see the rendered page to see the trends in the graph, at which point explanatory text becomes useful to interpretation of the data. Further it would be useful, and improve readability of the finished rendered page if the text could appear to the right of the graph as opposed to necessarily being below the graph. In general systems have wider displays than they are tall, it is good design to be able to set up pages with this in mind. The bottom line is that the current text formatting rules are lacking.

''The wiki markup isn't a presentational markup, it is a semantic markup. The fact that it is always discussed in the context of text formatting is merely because this is the easiest way to explain it. It provides enough markup to give emphasis, separate sections and define lists. Each of these provides a level of information to the text. Making text appear next to images or other layout issues are pure aesthetics'' 

First of all, aesthetic choices are important. The choice to not allow a "bewildering mess of multiple fonts, colors, etc" is a purely aesthetic choice.

Second, the ability to place text in relationship to an image is a functional necessity, not just aesthetics. People's eyes are trained from years of reading to scan efficiently from left to right. ''(If your language reads left-to-right; not all do.)'' The ability to place an image with explanatory text to the left or right of the image makes a huge difference in the ability to effectively and efficiently process the image and explanatory text. This is especially true if the image is tall. If I inserted a tall image in this wiki it would leave a lot of wasted white space to the right of the image and force users to scroll up and down to see the image and get the explanatory text. This is an issue of functionality for the rendered page.

Lastly, perhaps it is the lack of presentation capabilities which is the reason the MarkUp is ineffectual. Perhaps it is beyond the scope of this wiki to allow more advanced presentation. Please bear in mind that this criticism is aimed at the wiki software running this site, not this site itself. Perhaps the limits of the software are acceptable for the scope of this site, but the creation of the WikiClones (a good example is http://en.wikipedia.org/wiki/Biological_cell) is a testament to the need for wikis with more capabilities than this site's software offers currently.

----
There are wikis that do HTML including JavaScript (make them instances of WikiWithProgrammableContent), e.g. FoxWiki.

----
Admittedly, WikiWiki MarkupLanguage (see TextFormattingRules) may not be the perfect way to achieve WikiZen, but it's much closer to it than HTML. Don't you think?

	 :	I for one have been thinking about that... I think HTML is much more powerful and intuitive [WuWei], and I think that if you simply strip out all the <script>'s etc., then it shouldn't pose much of a security risk. HTML was meant to be intuitive, but maybe it hasn't lived up to those claims? c.f. WikiNature -- SeanPalmer

	 :	''No, HTML was meant to be a web-useful subset of SGML, which was meant to be powerful, and not particularly human-readable (only somewhat). -- JohnDouglasPorter''

On the other hand, HTML, like word processors, intermix typesetting with content. Consider XML, instead. See http://ricardo.ecn.wfu.edu/~cottrell/wp.html, with 
http://www.goems.com/~sds/data.html as an introduction.
-- DouglasAuclair

	 :	Clearly XML would be better than HTML. The tags in XML are *NOT* markup. Markup refers to formatting (bold, underline, colors, fonts, images, etc.). XML does not define appearance at all, it defines data. Note that the name is misleading. Its actually a data storage language, not a markup language. XSL defines the appearance. Secondly, both HTML and XML are both too cumbersome for a wiki. They are too error-prone to enter directly in production articles and not everyone has a good WYSIWYG tool. It would also encourage people to add unconventional formatting to individual articles like background images, music, marques, blinking text, scripts, page transitions and etc. And HTML errors could corrupt the page to the extent that the edit link doesn't render thus making the mistake irreversible. For example: <IFRAME SRC="hi"> will cause all text following it to be hidden since the </IFRAME> is omitted. PS the markup variation used by WikiPedia is far superior to the markup used here. -- RobertLee

	 :	XML is not a '''data storage''' language. This is a big and common mistake that lead to XmlDatabase''''''s. You can call XML a '''DataRepresentationLanguage'''. Although it is possible and perhaps useful to store some kind of data in XML, most of the time it would be cumbersome and inefficient. This kind of discussion was very common in 70/80s and was completely won by RelationalModel enthusiasts, that defended that RelationalDatabases would be the most effective way to store and retrieve data. Later, in the 90s, new application requirements, like MultiMedia , have boosted the development of ObjectOrientedDatabase''''''s, which lost the battle for commercial acceptance to ExtendedRelationalDatabase or ObjectRelationalDatabase''''''s. The widespread acceptance of XML has, somewhat, lead to the idea that could be useful to store data as XML. ExtendedRelationalDatabase''''''s are implementing XML fields that can be useful for some specific types of data, or if you want to store the exact format of some data you received.

It's the 'etc.' which is the problem, you won't believe how many things you have to strip out. The only way to do it is with a list of safe tags and attributes. Anyway, do you really want people writing in Frontpage and copying-and-pasting?!

----

I generally like the Wiki approach over HTML most of the time. It is usually more WYSIWYG and less typing. However, sometimes HTML is more powerful. Thus, it would be nice if there was an "escape" to html in Wiki when needed. Also, I wish reliance on tabs was yet more reduced in wiki. -- AnonymousDonor

Some WikiEngines like PhpWiki/ErfurtWiki (and certainly a lot others) allow to enable html markup in certain pages, so whenever needed you can enable it (page flags or via "escape"). After all HTML isn't all that evil and sometimes there is no way around, you just shouldn't have it on every page. In other news: http://wikifeatures.wiki.taoriver.net/moin.cgi/CssMarkup may be a superior idea if you only want to style a page (CSS means no security problem but has more power).

----

Is Wiki the poor man's choice over HTML/XHTML? What's wrong with a WYSIWYG editor? What's wrong with using a Word Processor? So instead of trying to make a better HTML editor, instead we'll try to invent a new markup language just to further confuse the public. We'll add a bunch of text formatting rules, that people must re-learn. Sure we could make a Wiki WYSIWYG editor, but wouldn't that just be going down the same route HTML is? If you ask me, the *nix people who are too scared to realize that graphical user interfaces are where it's at, and text screens are things of the past as of 10 years ago, decided that they needed to invent a new language so they could easily read it on their text only systems, yet allow the graphical systems to still display them in a "slightly" richer format.

From what I gather from the comments, wiki is used to allow people to share formatted text with each other. Isn't that why WordPerfect was invented 15 years ago? Are we too cheap in said companies to invest in a word processor. What's wrong with a FREEWARE HTML editor? RTF is a document format that has been standard for years. Since Windows 3.1 (maybe even before) WordPad has been a product shipped with the Operating System. So let's see that means that over 90% of the computer user base has an RTF editor that actually works.

'''Why confuse people with yet another markup language, when solutions to the problems that the markup language are targeted to solve, have already been solved before some of the inventors of the markup language were even born?'''

-- PuckPuck

''But no word processor, nor HTML, can allow anyone with Internet access to communicate on a public forum such as this. BYOB - bring your own browser - any web browser. And any operating system, too. It would be too impractical - and with little or no benefit - to give up that accessibility/freedom in favor of some WYSIWYG editor or HTML editor or something else that can't easily be run in any web browser. Of course, you could eliminate formatting, but why? As long as it remains relatively simple, it's a good thing, IMO, and there's no compelling reason to revert to plain text. -- AnonymousDonor''

----

''Wiki is a simple markup language, it offers a powerful way to contribute without overhead. In some ways the initial success of the Web was born from a similar simplicity, some would say this simplicity has been lost in the passage of time with the complications of trying to turn the web browser into an operating system. If we reflect back on why HTML/email is so compelling and changed the world when more complex systems failed to do so we see that the simple ability to deploy content and communicate in a secure reliable way is powerful. This power underpins Wiki. -- AJC''

----

The Wiki markup language is such crap! If you're going to allow HTML, allow all HTML, not just some subset that the Wiki authors couldn't think up anything silly enough to replicate. The rational is that it is easier than HTML? Bull! *#[~[3|three]]* to create an anchor is easier than <A NAME="three">1</A>? Since Wiki wouldn't take a numeral 3 as a anchor, I had to use text (thus the "3|three"...uck!). What garbage!

The concept of having a web page that could easily be scribbled on is great. But the implementation...

----

In the non-IT corporate environment, requiring TextFormattingRules is a non-starter. J6P users have no interest in learning either HTML markup *or* wiki markup.

For our corporate intranet WikiClone, I took another approach: we use the TinyMCE rich text (JavaScript-based) editor, which allows us to enforce XHTML conformance and severely limit the HTML markup that gets into the system (you can whitelist tags/attributes to be allowed; all others are ignored). Our users get to edit in a simple, mostly-WYSIWYG environment and they can copy/paste content from other sources without introducing gobs of FONTs and styles and other nasty markup. (We've also used HTMLArea, FreeTextBox, FCKEditor, and a custom rich-text control, but TinyMCE has given us the best results so far in both MSIE and Gecko-based browsers).

We still support a few TextFormattingRules: double-equals for headings, dashes for HRs, auto-linking of web URIs and email addresses, and three WikiLinkName formats (run together w/ or w/o underscores, all-uppercase, and inside double-brackets).

-- RichardTallent

----

Contributors: PuckPuck, SunirShah, RobertDiFalco, GlennVanderburg, BrianEwins, MattBehrens, CurtisBartley, TedNeward, JoeyKelly, RichardTallent, and several AnonymousDonor''''''s

----
See WabiSabi, WikiPhilosophyFaq

----
CategoryWiki CategoryWikiEditing