Tuesday, September 20, 2016

What a coded web page can look like

Note added Wednesday June 27th 2018: This is actually an HTML compatible language called
Wiki markup language with some Javascript too. What I'm trying to get across is that there
are many compatible HTML languages that are viable on HTTP or Hypertext Transfer Protocol.
in addition to HTML.

end note.

If you have never before seen what a page of html looks like here is the page for the 
wikipedia article I just quoted.

(NOTE added 6-27-18 But, this page is not exactly HTML but rather
Wiki markup language and some Javascript which ARE TWO  of the compatible languages to HTML 
that
 work on HTTP WHICH IS HYPERTEXT TRANSFER PROTOCOL.THE PROTOCOL TRANSLATES THE DIFFERENT
LANGUAGES COMPATIBLE TO HTML TO MAKE THINGS RUN SEAMLESSLY OVER VARIOUS MEDIA ALL OVER THE
EARTH FROM MAINFRAME COMPUTERS TO IPHONES TO LAPTOPS TO IPADS ETC.
 end note

 If you want to see the page source and you are in Firefox browser
like I am now you can see the (usually) html or other similar language source by clicking 
on Tools (in firefox) up to the top left. Then scroll down to "web developer" and then
scroll over and down to "page source" 2nd from the bottom. By clicking on this you can
see the page source for literally any web page online by doing this. What I did originally
to teach myself HTML was I did this and then I saved a "yahoo" opening page in the 1990s
and I played with it to see what different things did like changing colors and moving
things around. This is how I first began to teach myself HTML. However, presently I'm
not sure how I would do this now because this was with Windows 95 which is a different
operating system than now. But, I did get you this far today!
 
Also I'm not fully sure this is exactly written in HTML either because it doesn't say which
form it is in but obviously it works to display the page. One thing I did figure out is
it is written partly in Javascript which is one of the directions you can go when writing
code even though sometimes it has security problems too. 

If you have a site here at blogger.com (blogspot) you can paste this in your page if
you want to try to run it to see how it generates if you are in the "Html" mode rather 
than the "Compose" mode: But, unless you are giving credit to the site I wouldn't leave 
it there long. The following word button also contains the word button of where this 
came from:

 
<head><title>Why Doesnt Wiki Do Html</title>

</head>
<body text=black bgcolor=white><h1><img src="http://c2.com/sig/wiki.gif">
<a href="fullSearch" rel="nofollow">Why Doesnt Wiki Do Html</a></h1>
<div id="wiki">
<strong>&quot;Why doesn't Wiki do HTML?&quot;</strong> is a question often asked by people new to Wiki. It has many answers: 
<p></p>
<OL>
<li> 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.
<p></p>
<li> Wiki's <a href="wiki?TextFormattingRules">TextFormattingRules</a> were designed to <a href="wiki?DoTheSimplestThingThatCouldPossiblyWork">DoTheSimplestThingThatCouldPossiblyWork</a>.
<p></p>
<li> Typing <a href="wiki?HyperTextMarkupLanguage">HyperTextMarkupLanguage</a> tags breaks the flow of one's thoughts, particularly for complex tags such as tables. (See example below.)
<p></p>
<li> Part of <a href="wiki?WikiNature">WikiNature</a> is that the code should be readable; that extends to the raw text of <a href="wiki?WikiPage">WikiPage</a><strong></strong>s. When editing, content should be instantly identifiable, not lost in a sea of angle brackets.
<p></p>
<li> 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, <a href="wiki?YouArentGonnaNeedIt">YouArentGonnaNeedIt</a>.
<p></p>
<li> Allowing all HTML opens security holes through <a href="wiki?JavaScript">JavaScript</a> exploits, etc (although this is easy to fix; see discussion on <a href="wiki?JavaScriptEnabledWiki">JavaScriptEnabledWiki</a>).
<p></p>
<li> Converting 25,000+ pages and the scripts that run the site would be a major undertaking without equivalent benefit. In other words, <a href="wiki?ItJustWorks">ItJustWorks</a>. <a href="wiki?IfItAintBrokeDontFixIt">IfItAintBrokeDontFixIt</a>.
<p></p>
<li> Many people don't know HTML. Wiki markup is easier to learn. [<a href="wiki?CitationNeeded">CitationNeeded</a>]
<p></p>
<li> Some other wikis in fact do HTML, e.g. <a href="http://www.wikihtml.com" rel="nofollow">http://www.wikihtml.com</a> <em>[Doesn't work 9 July 2012.]</em>
<p></p>
</OL>
There are some more reasons at <a href="http://www.usemod.com/cgi-bin/mb.pl?RawHtmlWiki" rel="nofollow">http://www.usemod.com/cgi-bin/mb.pl?RawHtmlWiki</a>.
<p></p>
See <a href="wiki?WikiDesignPrinciples">WikiDesignPrinciples</a> which is a statement from the early days.
<p></p>
<hr>
<p></p>
<strong>An Example of HTML vs. Wiki Syntax</strong>
<p></p>
A table formatted so:
<p></p>
<PRE>
 &lt;table&gt;
 &lt;tr&gt;&lt;th&gt;X&lt;/th&gt;&lt;th&gt;Y&lt;/th&gt;&lt;/tr&gt;
 &lt;tr&gt;&lt;td&gt;1&lt;/td&gt;&lt;td&gt;2&lt;/td&gt;&lt;/tr&gt;
 &lt;tr&gt;&lt;td&gt;3&lt;/td&gt;&lt;td&gt;4&lt;/td&gt;&lt;/tr&gt;
 &lt;/table&gt;
<p></p>
</PRE>
is a <strong>lot</strong> uglier (and takes more time to type) than a simple
<p></p>
<PRE>
 X  Y
 1  2
 3  4
<p></p>
</PRE>
<em>Until <a href="wiki?TabMunging">TabMunging</a> farks it up.</em>
<p></p>
However the markup for <a href="wiki?WikiTables">WikiTables</a> used on other wikis retains the benefits of HTML tables without the noise:
<p></p>
<PRE>
 | X | Y |
 | 1 | 2 |
 | 3 | 4 |
<p></p>
</PRE>
<hr>
<p></p>
<strong>Testimonials</strong>
<p></p>
<em>From <a href="wiki?RobertDiFalco">RobertDiFalco</a>:</em>
<p></p>
I should say here that I am a big time <a href="wiki?WikiWikiWeb">WikiWikiWeb</a> <strong>lover</strong>. But then again, it drives me crazy that I can only do:
<p></p>
<PRE>
 one&lt;br&gt;
 two&lt;br&gt;
 three 
<p></p>
</PRE>
...in monotype! :) -- <a href="wiki?RobertDiFalco">RobertDiFalco</a>
<p></p>
<em>BigBracketedTag<a href="wiki?edit=BigBracketedTag" rel="nofollow">?</a><strong></strong>s is not <a href="wiki?WikiZen">WikiZen</a>.</em> -- <a href="wiki?AnonymousDonor">AnonymousDonor</a>
<p></p>
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 <a href="wiki?WikiZen">WikiZen</a>. 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 <a href="wiki?WikiWiki">WikiWiki</a> <a href="wiki?MarkupLanguage">MarkupLanguage</a> (see <a href="wiki?TextFormattingRules">TextFormattingRules</a>) allows you to avoid <a href="wiki?CantSeeTheForestForTheTrees">CantSeeTheForestForTheTrees</a> problems.
<p></p>
I love finding out I'm wrong, makes me feel that I'm still a kid at 37 (02 March 1963). -- <a href="wiki?RobertDiFalco">RobertDiFalco</a>
<p></p>
I think <a href="wiki?WikiMarkup">WikiMarkup</a> is one of the best things <a href="wiki?WikiWiki">WikiWiki</a> has given us. Well, I do think that the emphasis characters are ill-chosen (and <a href="wiki?WardsWiki">WardsWiki</a>'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<a href="wiki?edit=NoHiddenContent" rel="nofollow">?</a>, convertible. -- <a href="wiki?PanuKalliokoski">PanuKalliokoski</a>
<p></p>
<em>From another <a href="wiki?AnonymousDonor">AnonymousDonor</a>:</em>
<p></p>
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.
<p></p>
<hr>
<p></p>
<strong>Objections to Wiki's <a href="wiki?TextFormattingRules">TextFormattingRules</a></strong>
<p></p>
Wiki's <a href="wiki?TextFormattingRules">TextFormattingRules</a> aren't perfect. Some of the most common objections:
<p></p>
<OL>
<li> <strong>Obscurity.</strong> Is it any more intuitive to type two single quotes than &lt;i&gt;? If contributors must use a markup language, why not use one that already exists (HTML)?
<p></p>
<li> <strong>Tabs.</strong> Typing tabs is difficult in many browsers, so much so that the page <a href="wiki?TipForTypingTab">TipForTypingTab</a> was created.
<p></p>
<li> <strong>Quote blocks.</strong> Combine tabs with obscurity and the result is the syntax for quote blocks: &quot;&lt;tab&gt; + space + colon + &lt;tab&gt;&quot; is hard to remember and to type. See <a href="wiki?SimulatingQuoteBlocks">SimulatingQuoteBlocks</a>.
<p></p>
<li> It's hard to remember whether it takes four, five, or <strong><a href="wiki?SixSingleQuotes">SixSingleQuotes</a></strong> to break the <a href="wiki?LinkPattern">LinkPattern</a>.
<p></p>
<li> It can be <strong>hard to distinguish between participants</strong> when more than three or four contribute to a discussion.
<p></p>
<li> The <strong><a href="wiki?TextFormattingRules">TextFormattingRules</a> are incomplete</strong>. The rules do not support some markup features which might be necessary in certain contexts, for example underlining text and <a href="wiki?HtmlTables">HtmlTables</a>.
<p></p>
</OL>
<hr>
<p></p>
<strong>Alternatives</strong>
<p></p>
<UL>
<li> See <a href="wiki?WikiStyleSheet">WikiStyleSheet</a>. Wikis with this system can turn their &amp;lt;br&amp;gt; back into &lt;br&gt;, so you can add custom tags as you need them, not all <a href="wiki?BigDesignUpFront">BigDesignUpFront</a>.
<p></p>
<li> Add a <a href="wiki?WysiWyg">WysiWyg</a> Java editor to the edit page. However, this creates problems:
<UL>
<li> It won't be powerful enough for some users
<li> People have to learn yet another editor
<li> Some folks disable Java
<li> Some folks don't install Java in the first place
<li> Some browsers <em>can't use</em> Java: <a href="wiki?LynxBrowser">LynxBrowser</a>, <a href="wiki?WebTv">WebTv</a> (though the <a href="wiki?WebTv">WebTv</a> users at Wiki are probably few to zero)
<p></p>
</UL>
<li> Add <a href="wiki?WysiWyg">WysiWyg</a> functionality on the server using web browser Rich Text Controls for basic functions, like Epoz, <a href="http://mjablonski.freezope.org/epoz/test.html/edit" rel="nofollow">http://mjablonski.freezope.org/epoz/test.html/edit</a> which works with <a href="http://zope.org" rel="nofollow">http://zope.org</a> and <a href="http://plone.org" rel="nofollow">http://plone.org</a>, but apparently not yet <a href="http://zwiki.org" rel="nofollow">http://zwiki.org</a>, 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 <a href="wiki?WikiSyntax">WikiSyntax</a> instead of HTML, or allow multiple formats in your wiki server (best idea). See <a href="http://betterdifferent.com/software/superwiki" rel="nofollow">http://betterdifferent.com/software/superwiki</a> for more ideas.
<p></p>
<li> Allow people to type either HTML or <a href="wiki?WikiSyntax">WikiSyntax</a>, 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 <a href="wiki?XmlBasedWiki">XmlBasedWiki</a>.
<p></p>
<li> Use HTML as THE syntax for the Wiki system. There are a few Wikis and <a href="wiki?WikiLikeThing">WikiLikeThing</a><strong></strong>s that simply work with HTML instead. <a href="wiki?MassMind">MassMind</a> is one example, and there must be others.
<p></p>
</UL>
<hr>
<p></p>
<strong>Another View</strong>
<p></p>
Maybe the consistent desire we see to put BigBracketedTag<a href="wiki?edit=BigBracketedTag" rel="nofollow">?</a><strong></strong>s into <a href="wiki?WikiWiki">WikiWiki</a> <a href="wiki?MarkupLanguage">MarkupLanguage</a> is because the <a href="wiki?TextFormattingRules">TextFormattingRules</a> are unnatural to the user. I find it hard to believe that it's because it's not powerful enough.
<p></p>
I put my thoughts on a new set of <a href="wiki?TextFormattingRules">TextFormattingRules</a> on <a href="wiki?TextFormattingRulesRevised">TextFormattingRulesRevised</a>. -- <a href="wiki?MattBehrens">MattBehrens</a>
<p></p>
<hr>
<p></p>
<strong>HTML Semantic View</strong>
<p></p>
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). -- <a href="wiki?CortlandHaws">CortlandHaws</a>
<p></p>
In that spirit Wiki <a href="wiki?TextFormattingRules">TextFormattingRules</a> totally breaks this goal allowing bold, underline, italic, etc instead of only &lt;strong&gt;&lt;/strong&gt; or &lt;em&gt;&lt;/em&gt; etc. IMHO Wiki <a href="wiki?TextFormattingRules">TextFormattingRules</a> is more about presentation than about semantic. So always IMHO all answers to the question at the top of this document are completely nonsense. -- <a href="wiki?BrunoBeaufils">BrunoBeaufils</a>
<p></p>
<hr>
<p></p>
&quot;Is it any more intuitive to type two single quotes than &lt;i&gt;? People are familiar with HTML. Wiki forces them to learn new <a href="wiki?TextFormattingRules">TextFormattingRules</a>.&quot;
<p></p>
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. -- <a href="wiki?MikeSmith">MikeSmith</a>
<p></p>
<em>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.</em>
<p></p>
<p></p>
(Possibly move to <a href="wiki?AlternativeTextFormattingRules">AlternativeTextFormattingRules</a>?)
<p></p>
<hr>
<p></p>
Someone wrote, &quot;Wiki's <a href="wiki?TextFormattingRules">TextFormattingRules</a> were designed to <a href="wiki?DoTheSimplestThingThatCouldPossiblyWork">DoTheSimplestThingThatCouldPossiblyWork</a>&quot; - 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 &lt;li&gt; tags (maybe with a preceding &lt;ol&gt; if it's the first one), and all that dreck. -- <a href="wiki?BillTrost">BillTrost</a>
<p></p>
<em>While that would be simple to implement, it wouldn't &quot;work&quot; 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 <a href="wiki?WikiWiki">WikiWiki</a>.</em>
<p></p>
<em>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.</em>
<p></p>
<hr>
<p></p>
Wiki's <a href="wiki?TextFormattingRules">TextFormattingRules</a> 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.
<p></p>
<em>Instead of worrying about a GoodLookingPage<a href="wiki?edit=GoodLookingPage" rel="nofollow">?</a>, concentrate on just making a GoodPage<a href="wiki?edit=GoodPage" rel="nofollow">?</a>.</em>
<p></p>
The fact that Wiki supports <a href="wiki?MarkUp">MarkUp</a> 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<a href="wiki?edit=GoodLookingPage" rel="nofollow">?</a>/GoodPage<a href="wiki?edit=GoodPage" rel="nofollow">?</a>) are not mutually exclusive, rather they are often the same goal. If part of the <a href="wiki?WikiNature">WikiNature</a> 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 &quot;Web Log Traffic Analysis&quot; 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.
<p></p>
<em>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</em> 
<p></p>
First of all, aesthetic choices are important. The choice to not allow a &quot;bewildering mess of multiple fonts, colors, etc&quot; is a purely aesthetic choice.
<p></p>
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. <em>(If your language reads left-to-right; not all do.)</em> 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.
<p></p>
Lastly, perhaps it is the lack of presentation capabilities which is the reason the <a href="wiki?MarkUp">MarkUp</a> 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 <a href="wiki?WikiClones">WikiClones</a> (a good example is <a href="http://en.wikipedia.org/wiki/Biological_cell" rel="nofollow">http://en.wikipedia.org/wiki/Biological_cell</a>) is a testament to the need for wikis with more capabilities than this site's software offers currently.
<p></p>
<hr>
There are wikis that do HTML including <a href="wiki?JavaScript">JavaScript</a> (make them instances of <a href="wiki?WikiWithProgrammableContent">WikiWithProgrammableContent</a>), e.g. <a href="wiki?FoxWiki">FoxWiki</a>.
<p></p>
<hr>
Admittedly, <a href="wiki?WikiWiki">WikiWiki</a> <a href="wiki?MarkupLanguage">MarkupLanguage</a> (see <a href="wiki?TextFormattingRules">TextFormattingRules</a>) may not be the perfect way to achieve <a href="wiki?WikiZen">WikiZen</a>, but it's much closer to it than HTML. Don't you think?
<p></p>
<DL>
<dt> <dd>I for one have been thinking about that... I think HTML is much more powerful and intuitive [<a href="wiki?WuWei">WuWei</a>], and I think that if you simply strip out all the &lt;script&gt;'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. <a href="wiki?WikiNature">WikiNature</a> -- <a href="wiki?SeanPalmer">SeanPalmer</a>
<p></p>
<dt> <dd><em>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). -- <a href="wiki?JohnDouglasPorter">JohnDouglasPorter</a></em>
<p></p>
</DL>
On the other hand, HTML, like word processors, intermix typesetting with content. Consider XML, instead. See <a href="http://ricardo.ecn.wfu.edu/~cottrell/wp.html" rel="nofollow">http://ricardo.ecn.wfu.edu/~cottrell/wp.html</a>, with 
<a href="http://www.goems.com/~sds/data.html" rel="nofollow">http://www.goems.com/~sds/data.html</a> as an introduction.
-- <a href="wiki?DouglasAuclair">DouglasAuclair</a>
<p></p>
<DL>
<dt> <dd>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: &lt;IFRAME SRC=&quot;hi&quot;&gt; will cause all text following it to be hidden since the &lt;/IFRAME&gt; is omitted. PS the markup variation used by <a href="wiki?WikiPedia">WikiPedia</a> is far superior to the markup used here. -- RobertLee<a href="wiki?edit=RobertLee" rel="nofollow">?</a>
<p></p>
<dt> <dd>XML is not a <strong>data storage</strong> language. This is a big and common mistake that lead to <a href="wiki?XmlDatabase">XmlDatabase</a><strong></strong>s. You can call XML a <strong>DataRepresentationLanguage<a href="wiki?edit=DataRepresentationLanguage" rel="nofollow">?</a></strong>. 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 <a href="wiki?RelationalModel">RelationalModel</a> enthusiasts, that defended that <a href="wiki?RelationalDatabases">RelationalDatabases</a> would be the most effective way to store and retrieve data. Later, in the 90s, new application requirements, like <a href="wiki?MultiMedia">MultiMedia</a> , have boosted the development of <a href="wiki?ObjectOrientedDatabase">ObjectOrientedDatabase</a><strong></strong>s, which lost the battle for commercial acceptance to ExtendedRelationalDatabase<a href="wiki?edit=ExtendedRelationalDatabase" rel="nofollow">?</a> or ObjectRelationalDatabase<a href="wiki?edit=ObjectRelationalDatabase" rel="nofollow">?</a><strong></strong>s. The widespread acceptance of XML has, somewhat, lead to the idea that could be useful to store data as XML. ExtendedRelationalDatabase<a href="wiki?edit=ExtendedRelationalDatabase" rel="nofollow">?</a><strong></strong>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.
<p></p>
</DL>
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?!
<p></p>
<hr>
<p></p>
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 &quot;escape&quot; to html in Wiki when needed. Also, I wish reliance on tabs was yet more reduced in wiki. -- <a href="wiki?AnonymousDonor">AnonymousDonor</a>
<p></p>
Some <a href="wiki?WikiEngines">WikiEngines</a> like <a href="wiki?PhpWiki">PhpWiki</a>/<a href="wiki?ErfurtWiki">ErfurtWiki</a> (and certainly a lot others) allow to enable html markup in certain pages, so whenever needed you can enable it (page flags or via &quot;escape&quot;). 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: <a href="http://wikifeatures.wiki.taoriver.net/moin.cgi/CssMarkup" rel="nofollow">http://wikifeatures.wiki.taoriver.net/moin.cgi/CssMarkup</a> may be a superior idea if you only want to style a page (CSS means no security problem but has more power).
<p></p>
<hr>
<p></p>
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 &quot;slightly&quot; richer format.
<p></p>
From what I gather from the comments, wiki is used to allow people to share formatted text with each other. Isn't that why <a href="wiki?WordPerfect">WordPerfect</a> 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<a href="wiki?edit=WordPad" rel="nofollow">?</a> 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.
<p></p>
<strong>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?</strong>
<p></p>
-- PuckPuck<a href="wiki?edit=PuckPuck" rel="nofollow">?</a>
<p></p>
<em>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. -- <a href="wiki?AnonymousDonor">AnonymousDonor</a></em>
<p></p>
<hr>
<p></p>
<em>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</em>
<p></p>
<hr>
<p></p>
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 &lt;A NAME=&quot;three&quot;&gt;1&lt;/A&gt;? Since Wiki wouldn't take a numeral 3 as a anchor, I had to use text (thus the &quot;3|three&quot;...uck!). What garbage!
<p></p>
The concept of having a web page that could easily be scribbled on is great. But the implementation...
<p></p>
<hr>
<p></p>
In the non-IT corporate environment, requiring <a href="wiki?TextFormattingRules">TextFormattingRules</a> is a non-starter. J6P users have no interest in learning either HTML markup *or* wiki markup.
<p></p>
For our corporate intranet <a href="wiki?WikiClone">WikiClone</a>, I took another approach: we use the TinyMCE rich text (<a href="wiki?JavaScript">JavaScript</a>-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<a href="wiki?edit=FreeTextBox" rel="nofollow">?</a>, FCKEditor, and a custom rich-text control, but TinyMCE has given us the best results so far in both MSIE and Gecko-based browsers).
<p></p>
We still support a few <a href="wiki?TextFormattingRules">TextFormattingRules</a>: double-equals for headings, dashes for HRs, auto-linking of web URIs and email addresses, and three WikiLinkName<a href="wiki?edit=WikiLinkName" rel="nofollow">?</a> formats (run together w/ or w/o underscores, all-uppercase, and inside double-brackets).
<p></p>
-- RichardTallent<a href="wiki?edit=RichardTallent" rel="nofollow">?</a>
<p></p>
<hr>
<p></p>
Contributors: PuckPuck<a href="wiki?edit=PuckPuck" rel="nofollow">?</a>, <a href="wiki?SunirShah">SunirShah</a>, <a href="wiki?RobertDiFalco">RobertDiFalco</a>, <a href="wiki?GlennVanderburg">GlennVanderburg</a>, <a href="wiki?BrianEwins">BrianEwins</a>, <a href="wiki?MattBehrens">MattBehrens</a>, <a href="wiki?CurtisBartley">CurtisBartley</a>, <a href="wiki?TedNeward">TedNeward</a>, <a href="wiki?JoeyKelly">JoeyKelly</a>, RichardTallent<a href="wiki?edit=RichardTallent" rel="nofollow">?</a>, and several <a href="wiki?AnonymousDonor">AnonymousDonor</a><strong></strong>s
<p></p>
<hr>
See <a href="wiki?WabiSabi">WabiSabi</a>, <a href="wiki?WikiPhilosophyFaq">WikiPhilosophyFaq</a>
<p></p>
<hr>
<a href="wiki?CategoryWiki">CategoryWiki</a> <a href="wiki?CategoryWikiEditing">CategoryWikiEditing</a>
</div>
</form>
<hr>
View edit of <a href=quickDiff?WhyDoesntWikiDoHtml rel="nofollow">December 30, 2012</a>
or <a href="wiki?FindPage">FindPage</a> with title or text search<br>
<link rel="alternate" type="application/wiki" title="Edit this page!" href="wiki?edit=WhyDoesntWikiDoHtml"/>

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
_uacct = "UA-2377314-2";
_udn="c2.com"; 
urchinTracker();
</script>

</body>

No comments: