Relocated from FlexWikiPad. -- CraigAndera

Check out the ThreeWikiFormats topic which relates to this content.

I'm wondering whether it's possible to replace Wiki's presentation rules with plain HTML so that we will not need to remember the formatting rules. For example, replace the wikiedit.aspx with FreeTextBox 2.0. -- AlexDong

• How about using the Wikipedia editpad? It comes closer to what we need. See an example of what I mean -- WouterCX

What you propose would pretty much defeat the entire purpose of wiki - to have an easy-to-use formatting language for quickly creating pages. HTML is complicated relative to the formatting rules. However, it may be that I'm misinterpreting what you're saying, and you're proposing being able to mix HTML syntax with wiki formatting. I'm still not sure I think that's a good idea - we're already going a bit nuts creating advanced syntax that only a very technical person could understand. -- CraigAndera

It would be gracious to recognize HTML, and pass it through to output - I don't see this would defeat any purpose of Wiki (rather, enhance it - see an elegant example of passing HTML thru structured text at http://www.zwiki.org/TextFormattingRules). At the limit, this would allow someone to create something in, say, Word and directly upload or cut/paste it, only to make minor edits inside of existing encoded text to integrate it into the Wiki.

Currently there is a problem - irregularity. For example, try to effect a heading change in a table - renders either as bold

||This was supposed to be a table, with a bold header||

or as tabulated exclamation text:

So long as existing format behaves irregularly, I think its asking much to "pass on" HTML codes to output. First focus on predictable output of the existing markup rules, a matter of internal structure I think. -- YarkoT

So here's my promary objection... A number of efforts are underway to build non-browser-based user interfaces for accessing FlexWiki content. Browsers are great because of their ubiquity, but they jst don't provide a high-powered, interactive experience they way client-side software can. The things you can express in the FlexWiki formatting language are all sufficiently abstract that they could be translated into a variety of different display surfaces/languages. If we allow HTML into the Wiki content then there's no way to do this translation.

YarkoT mentioned errors in the formatting processor for FlexWiki and I'll certainly agree that there are bugs. However, the right thing to do (in my mind) is to fix those bugs

Now, with that said... HTML is clearly ubiquitous and we just don't have a good solution to the problem of GettingMailIntoWiki or GettingWordDocumentsIntoWiki. Those tools create HTML and that's just they way it's going to be. One solution that I've considered is allowing FlexWiki to support MultiplePageTypes: specifically, Wiki topics, HTML, etc. I can imagine a world in which you have Wiki topics (which can be rendered in various way on different rendering platforms) and HTML pages that just plain need to be rendered using an HTML display engine -- but you wouldn't get any Wiki ness mixed in with the HTML.

-- DavidOrnstein

Word2003 (Office2003) acknowledges XML; so does OpenOffice (you should try it, it's great). So do some UML Modeling tools. HTML is a subset of XML. Now, if I consider this, then the whole issue of display engine goes away. Replace with this: "Recognize major text-represented syntaxes." Now, let Wiki structured text (or, for that matter - since the format rules vary among wiki implementations anayway - any plugin pre-processor) run as a heierarchy:

If the input rules are:

  Textual passed encoding (reasonable - just look at SOAP, etc.);

and constraint is that

  3rd layer processing must take textual (Wiki processed) input 

that being necessary constraint if doing "pass-thru" of text. The consequence (not unlike current situations) is that for some outputs, this will require a "driver" (like for a printer). Only thing left is what output will come from Wiki. HTML? XHTML?

I think HTML at some standard can be followed (extended) by general XML supoprt (office 2003 compatibility).

That leaves just (what my behavior of header formatting example shows) good definitions of "what is defined as 'beginning of line'" so that 1st and 2nd pass modules don't step untowardly on each other within a pass. Viola!

As for "Wikiness" mixed with HTML - design responsibility and boundaries come to mind. What do I want a Wiki processor to assume about the form of the input? As little as possible. What actions do I want it perform on the input? Well defined, and well constrained ones ("if you can't do good, then do no harm"); to take a deliberate non-destructive approach to input. Where not possible, then intentionally so: "We are not XML safe - don't expect your XML to be useful if input here."

And multiple page types? Well, at some level that's desireable, but I wouldn't want to do "easy Wiki Markups" in JPEG or FLASH - I'd rather take a strict "pass thru" rule on that (that is, I'll mark your doc type, but completely leave it alone - pass it for rendering only). Anyway, they don't meet my "text-only" input rule. But I can special case them for display (I hate special casing stuff - do it as little as possible!).

Done! (Your mileage may vary ) Having lots of fun here, people. Thanks for FlexWiki! -- YarkoT

I'm starting to understand what you mean. I guess I initially was thinking more like, "Any HTML tags are allowed" rather than "Let's use an XML/HTML-like syntax for some things, like tables." I find the latter far more palatable.

As I'm working on FlexWikiPad, I'm particularly interested in the idea of making the rendering engine a bit more reusable. I'd like to see something along the lines of what you mention, although in my case, I'd be even more interested if the output one of those layers was tokenized in a formal way. If I could get handed an abstract description of the input, that would be useful. Especially if it was done in such a way that it could be run against the raw wiki input (as FlexWikiPad only changes typeface - it never transforms what you type). This would also have the benefit of allowing us to emit an XML serialization of the page, which is going to be useful in a lot of ways. -- CraigAndera

There you go, Craig! Now it starts to sound like defined/supported doc types are just a Wiki way of identifying your input, if you should have a formal one (like XML from Word, or HTML of some version). And this gets interesting. Do you think this is doable?

Now - if I could plop flexWiki inside something like a DNN, use DNN membership & access control - there's a useful community publishing concept (if results generate XML Office2003 output). All those OpenSource forums on asp.net could sure take advantage of that for generating docs (among others). Just formalized tiering, clean separation of layers, interface definitions, really, would allow that... I should get a snapshot of FlexWiki to look at 'in my spare time' -- YarkoT

To be honest, I have no idea how doable it is. Certainly, it's something we could accomplish with some level of effort. Also, I'm a big fan of writing code after you know where you're going, so I think this may be a project to tackle once we have more than one consumer of the data. Which is to say, when FlexWikiPad is in a usable state, and has enough people hammering on it to enable us to form a consensus around what the commonalities (if any) are. But I think that will be fairly soon - I expect to release a pretty functional beta of FlexWikiPad sometime in the next three weeks - it has been coming along quite nicely. -- CraigAndera

To start with, I've created an extra (true/false) key in the Web.config file, RemoveHTMLTags, and in the source I put an if-then around the part where html tags are filtered (i.e. < changed to &lt; and > changed to &gt;). That way, I can choose whether to use HTML tags or not. Next thing I will do is to make an option in Web.config to disable those %^$#(!*! smileys that popup in my text where I don't want them to... . -- WouterCX

Why not apply the same solution as in PHP and ASP? I mean: Microsoft ASP uses <% and %> to denote start of code / end of code, before the <% and after the %> everything is interpreted as HTML. The same as in PHP: <?php and ?>. Why not make a new start/end tag: <wiki| and |wiki> or, to stay in the XML syntax: <wiki> </wiki>. Everything between <wiki> and </wiki> will be translated by the wiki engine, everything before and after the tags will be formatted by the browser. That way, you would even be compliant with XML. See this example. -- WouterCX

I think there are two scenarios which havve been overlooked here so far. Embedding HTML in a Wiki starts to look like a must for us. The two scenarios we do face are:

* Objects. See, stuff like videos and other things that should appear in the page are simply not doable right now. When working on pages that contain information that can not be shown as simple image in the best way, a Wiki totally fails right now.

* Borders. We would like to embedd some advertising in a Wiki of ours - basically using a banner exchange to drive more traffic to our site. Sadly, banners are Html, and right now we talk of writing a small C# dll JUST to show some static HTML.

In general, optionally allowing HTML just seems like the best thing for me. -- ThomasTomiczek

What about a simple wiki markup way to insert an iframe or an include that would render into a div. The source of the iframe or include would html. This would be only a small wiki feature, prevent intermingling of markup types, and allow complete freedom of html + js in the referenced file. --BrianTosch

I like the idea above by WouterCX. Why can't we just read between <wiki> and </wiki> parse as it does today to produce the HTML and then combine it with everything else in the .wiki file? This would allow me to leverage the quick syntax and also embed an object like a video. A second less elegant option would be to allow two different files...the original .wiki in wiki format and then also a .whtml file and merge them in the output stream. --Eric

Above, the unsolved problems GettingMailIntoWiki and GettingWordDocumentsIntoWiki were mentioned. This are big, practical problems for efficient use of wiki in a corporate environment. Adding html pass-through in some form would address them and would eliminate countless other roadblocks in one fell swoop.

I don't think html-pass-thru would "defeat the purpose of wiki" as I define it, which is "to enable the absolutely lowest friction way to create collaborative websites."

Not being able to paste in a color-coded email thread as a way to document how we arrived at a decision is HUGE friction! We should absolutely strongly encourage the much friendly wiki syntax for writing original content in a wiki. Maybe we should provide tools (stylesheets) for html to wiki syntax conversion... but that is not a 100% solution. Wiki is way easier than html, but let's not throw the baby out with the bathwater.

As to the objection above about html being a stumbling block for ongoing efforts to "build non-browser-based user interfaces for accessing FlexWiki content".

• The unsolved problems of GettingMailIntoWiki and GettingWordDocumentsIntoWiki are much bigger stumbling blocks to the success and proliferation of wiki than not having a windows GUI.
• GUI controls to display html in a windows app, or convert html to rtf, etc. are available... it is easy to render html in a windows app.

The folks at TWiki seem to have made the pragmatic compromise, and to me it seems a good one. See http://twiki.org/cgi-bin/view/TWiki/TextFormattingRules#HTML_and_TWiki_Usability. FlexWiki rocks! -- CaseyMullen