Why Doesnt Wiki Do Html

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

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.

Wiki's Text Formatting Rules were designed to Do The Simplest Thing That Could Possibly Work.

Typing Hyper Text Markup Language tags breaks the flow of one's thoughts, particularly for complex tags such as tables. (See example below.)

Part of Wiki Nature is that the code should be readable; that extends to the raw text of Wiki Pages. When editing, content should be instantly identifiable, not lost in a sea of angle brackets.

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, You Arent Gonna Need It.

Allowing all HTML opens security holes through Java Script exploits, etc (although this is easy to fix; see discussion on Java Script Enabled Wiki).

Converting 25,000+ pages and the scripts that run the site would be a major undertaking without equivalent benefit. In other words, It Just Works. If It Aint Broke Dont Fix It.

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

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

There are some more reasons at www.usemod.com .

See Wiki Design Principles which is a statement from the early days.

An Example of HTML vs. Wiki Syntax

A table formatted so:

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

Until Tab Munging farks it up.

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

Testimonials

From Robert Di Falco:

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

...in monotype! :) -- Robert Di Falco

Big Bracketed Tags is not Wiki Zen. -- Anonymous Donor

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 Wiki Zen. 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 Wiki Wiki Markup Language (see Text Formatting Rules) allows you to avoid Cant See The Forest For The Trees problems.

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

I think Wiki Markup is one of the best things Wiki Wiki has given us. Well, I do think that the emphasis characters are ill-chosen (and Wards Wiki'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, No Hidden Content, convertible. -- Panu Kalliokoski

From another Anonymous Donor:

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 Text Formatting Rules

Wiki's Text Formatting Rules aren't perfect. Some of the most common objections:

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

Tabs. Typing tabs is difficult in many browsers, so much so that the page Tip For Typing Tab was created.

0. Quote blocks. Combine tabs with obscurity and the result is the syntax for quote blocks:
" + space + colon + " is hard to remember and to type. See Simulating Quote Blocks.

It's hard to remember whether it takes four, five, or Six Single Quotes to break the Link Pattern.

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

The Text Formatting Rules are incomplete. The rules do not support some markup features which might be necessary in certain contexts, for example underlining text and Html Tables.

Alternatives

See Wiki Style Sheet. Wikis with this system can turn their <br> back into
, so you can add custom tags as you need them, not all Big Design Up Front.

Add a Wysi Wyg 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:
Lynx Browser, Web Tv (though the Web Tv users at Wiki are probably few to zero)

Add Wysi Wyg functionality on the server using web browser Rich Text Controls for basic functions, like Epoz, mjablonski.freezope.org which works with zope.org and plone.org , but apparently not yet 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 Wiki Syntax instead of HTML, or allow multiple formats in your wiki server (best idea). See betterdifferent.com for more ideas.

Allow people to type either HTML or Wiki Syntax, 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 Xml Based Wiki.

Use HTML as THE syntax for the Wiki system. There are a few Wikis and Wiki Like Things that simply work with HTML instead. Mass Mind is one example, and there must be others.

Another View

Maybe the consistent desire we see to put Big Bracketed Tags into Wiki Wiki Markup Language is because the Text Formatting Rules 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 Text Formatting Rules on Text Formatting Rules Revised. -- Matt Behrens

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). -- Cortland Haws

In that spirit Wiki Text Formatting Rules totally breaks this goal allowing bold, underline, italic, etc instead of only or etc. IMHO Wiki Text Formatting Rules is more about presentation than about semantic. So always IMHO all answers to the question at the top of this document are completely nonsense. -- Bruno Beaufils

"Is it any more intuitive to type two single quotes than ? People are familiar with HTML. Wiki forces them to learn new Text Formatting Rules."

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. -- Mike Smith

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 Alternative Text Formatting Rules?)

Someone wrote, "Wiki's Text Formatting Rules were designed to Do The Simplest Thing That Could Possibly Work" - 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

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 Wiki Wiki.

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 Text Formatting Rules 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 Good Looking Page, concentrate on just making a Good Page.

The fact that Wiki supports Mark Up 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 (Good Looking Page/Good Page) are not mutually exclusive, rather they are often the same goal. If part of the Wiki Nature 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 Mark Up 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 Wiki Clones (a good example is en.wikipedia.org ) 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 Java Script (make them instances of Wiki With Programmable Content), e.g. Fox Wiki.

Admittedly, Wiki Wiki Markup Language (see Text Formatting Rules) may not be the perfect way to achieve Wiki Zen, 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 [Wu Wei], and I think that if you simply strip out all the

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). -- John Douglas Porter

On the other hand, HTML, like word processors, intermix typesetting with content. Consider XML, instead. See ricardo.ecn.wfu.edu , with www.goems.com as an introduction.

-- Douglas Auclair

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: is omitted. PS the markup variation used by Wiki Pedia is far superior to the markup used here. -- Robert Lee

XML is not a data storage language. This is a big and common mistake that lead to Xml Databases. You can call XML a Data Representation Language. 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 Relational Model enthusiasts, that defended that Relational Databases would be the most effective way to store and retrieve data. Later, in the 90s, new application requirements, like Multi Media , have boosted the development of Object Oriented Databases, which lost the battle for commercial acceptance to Extended Relational Database or Object Relational Databases. The widespread acceptance of XML has, somewhat, lead to the idea that could be useful to store data as XML. Extended Relational Databases 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. -- Anonymous Donor

Some Wiki Engines like Php Wiki/Erfurt Wiki (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: wikifeatures.wiki.taoriver.net 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 Word Perfect 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) Word Pad 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?

-- Puck Puck

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. -- Anonymous Donor

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 1? 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 Text Formatting Rules is a non-starter. J6P users have no interest in learning either HTML markup *or* wiki markup.

For our corporate intranet Wiki Clone, I took another approach: we use the TinyMCE rich text (Java Script-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, Free Text Box, 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 Text Formatting Rules: double-equals for headings, dashes for HRs, auto-linking of web URIs and email addresses, and three Wiki Link Name formats (run together w/ or w/o underscores, all-uppercase, and inside double-brackets).

-- Richard Tallent

Contributors: Puck Puck, Sunir Shah, Robert Di Falco, Glenn Vanderburg, Brian Ewins, Matt Behrens, Curtis Bartley, Ted Neward, Joey Kelly, Richard Tallent, and several Anonymous Donors

See Wabi Sabi, Wiki Philosophy Faq

Category Wiki Category Wiki Editing

See original on c2.com