MeatballWiki | RecentChanges | Random Page | Indices | Categories

Why not allow Raw HTML in MeatballWiki. (Its a trivial patch to suppress wiki-specific formatting and implicit links, when a page starts with <HTML> or something like that). With Raw HTML you automatically get scripting capability.). Of cause we could impose additional security measures on this feature. Communities like Google:MySpace already allow Gadgets on the profile pages of their members. As alternative WikiEngine Builders could integrate [Wikipedia:WikiGadgets] -- FridemarPache



Other Comments

We can provide an HTML subset. That gives most of the advantages (of familiarity) without the drawbacks of hypermedia.

Existing practice

What can we learn from these?


needs to be adapted to the intro, which itself needs actualisation, responding to the current (2009) trend of a socially programmable Web.

Speaking of multimedia, I added <EMBED/> to UseModWiki in an afternoon. Perl's a lot more forgiving to people with Carpal Tunnel Syndrome than Java, so I hacked it in. (It's something we need on the Intranet). I really like the idea of &StoreRaw(). It made my life easier. I guess now I'm going to have to submit patches along with feature requests, eh? -- SunirShah

What we're debating is another TechnologySolution vs. CommunitySolution.


Long before I learned about wikis, I worked up a first-token of line dot-coded system (Hy-Dyn, for Hypertext Dynamic -- delusions of grandeur are always with us...) for getting HTML markup into submissions via textarea boxes. It was macro-ish, and look much like nroff mark-up. The codes were transmuted into HTML for display by the Hy-Dyn Perl engine. I even had a two-way Hy-Dyn-VAX Document filter. Such a system would gain the formatting of HTML without the security concerns. A technology solution to lubricate community solutions? -- JerryMuelver

The Case of the Advogato Virus

Recently AdvoGato was subjected to what was termed the [Advogato Virus] which exploited the (inadvertent) use of raw HTML in the name fields of users. The virus was essentially a blob of raw HTML and script in the name field of a person's profile. Upon visiting an infected person's profile, the scripted virus would launch an IFRAME and alter the reader's profile on Advogato to also include the virus. Although even most experts probably don't think of intrasite infection as a problem, and some users may think that running scripts inside the sandbox of a browser is safe (although that would be foolish), raw HTML enables any number of clever attacks on the unsuspecting reader. It's far easier to build a syntax constructively (i.e. from the ground up) than by exclusion (i.e. by "sanitizing" raw HTML) as it's much easier to prove formally.

CategoryCase html<table border=1000> <td style ="{position: fixed; width:100}">sdf</td><td>sdfsdfsdf</td>

When I worked on a wiki on HTML, I had a go at the sanitizing option anyway. Since I agree that allowing the full set of layout-options of HTML allows pages to get ugly and heavy-loaded with fonts and colors, I guess a HTML-wiki could do without the iframe and script tags altogether. Events and suspicious src="javascript fragments are filtered out also. If you might now more dangerous HTML contstructions, please let me know. -- StijnSanders

From a basic user perspective

My need as a basic user is probably to be seen from the community side. Everyday I need to produce content that will be sent to wikis, forums (like phpbb2), email, blogs or attached doc file depending on their use and goal. I am just tired of using different tag format and editors for each different tool, specialy when one same content has to be used and reproduced in different format for different medias for different purposes (example: a wiki + a forum). My dream would be to play with a universal text editor that would provide the main editorial functions such as text formating, tables, image insertion. Is it too much to ask for? -- Jean-Fran├žois (JeanFrancoisNoubel?)

No, the answer is plain text. -- AlexSchroeder

One workaround I seem to be using more and more is reStructured Text. When I type it into systems that don't understand it, it looks like highly readable plain text, and so it has most of the benefits of using plain text. See Wiki:ReStructuredText, ["A ReStructuredText Primer"], CommunityWiki:PlainText, Wiki:PowerOfPlainText. -- DavidCary

''moved from InterMap, part of a discussion of a PublicallyEditableInterMap

Possible consequences of browsing arbitrary HTML include:

The usual first response to these flaws is to suggest disabling features like Java, Javascript, etc. Unfortunately, the users who have old browsers are probably less likely to disable these options. --CliffordAdams (who doesn't visit MetaBaby anymore because of these issues)


MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions