FrontPage SiteMap RecentChanges RecentNearChanges HowTo Blog RSS
United Arab Emirates, National Day, Laos, National Day

VisibleMarkup

This is a solution for WYSIWYG editing, alternative to JavaScript-based, complicated interactive editors. Instead of making the edit mode look similar to the presented page, the presentation of the page can be made similar to the raw text of the page.

The idea is to not remove the “markup characters”, like “[[” or “*” when rendering the page to html, but style them so that they are visible, but not obtrusive instead (ex. make them light gray on a white page). Of course that’s not possible with all markup rules (links with an alternate text would be hard), but at least a limited subset of commonly used markup can be treated this way.

This has several benefits:

There are also some disadvantages:

This is an idea I had some time ago. As far as I know, it was only tried on my toy wiki engine, but I think it might have some potential, especially in teaching new users how to wiki. What do you think?

Gmail uses a similar idea in it’s chat thing. You can put * around a word and they will first be displayed normally, then after a fraction of a second, they will disappear and the word will be bold. Smileys are also replaced this way, and in addition, the smiley is an animated gif that does the transformation from the ascii “sideways” form to the coloured, upright form. And if you pass your mouse over it, it does the transition again, so you can see how to create it. Nifty.

This seems to align with WikiNature:

Output should suggest the input required.

I think that WikiWords are so popular (despite many bad things about them) precisely because they are WYSIWYG in the same way the VisibleMarkup is. Also the well-accepted markup for bullet lists is as close to their rendered look as possible (at least for the 1st level lists, but they are the most common). I wonder what’s the reason behind using “’” for ephasis though, when there is a well-accepted standard of using asterisks, both in e-mail and news. I experimented a little with the idea on Yarnball Wiki.

is there a possibility to tell the browser to replace a section with an editable raw text, if you click in (the left margin of) this section?

  • would look
    • like
      • this
[new:sigi:2006-08-26 03:12 UTC]
is there a possibility to tell the browser to replace a section with an *editable* raw text,
if you click in (the left margin of) this section?
* would look
** like
*** _this_

This reminds me of the “pretty printing” formatters for most programming languages. They also are careful to preserve every marking character of the original source code.

I like it. Current trends seem to be towards the production of ever-more-complex items. So people are discouraged from creating anything, because hand-made items look so very primitive compared to store-bought plastic-wrapped versions.

I am all in favor of anything that makes it easier for people to learn how to do it themselves – even when the result may not appear as polished and “professional” as some of the alternatives.

Sometimes primitive-appearing items function better than hi-tech alternatives. For example: Morse code is faster than text messaging. Jotting things down on a Hipster PAA is faster than entering them into an electronic PDA. Whole-wheat bread has more vitamins and fiber than white bread. Etc.

Um… Forgive me for launching into an unrelated rant. Again. :-).

@sigi – yes, it’s basically section editing, with the preview of the rest of document displayed both over and under the edit box. As such, it suffers all technical difficulties with section editing – similar to those of PurpleNumbers.

I think the best solution would be to have syntax highlighting and clickable links directly in the textarea. Of course that’s not possible with plain textareas, but can be done using the same technology as the “WYSIWYG” javascript editors. Only much simplier, as you don’t want all the MS Word features in it.

But this is all bells and whistles, as with VisibleMarkup you are not relying on technology to do WYSIWYG – you have it also in Lynx.

perhaps we may design quite a new wiki markup language, which only consists of square brackets (good for high lightning) . each page has a list with the meaning of the brackets (same sequence as in the page) . if you click on a bracket, you can edit the content of this bracket . if you are in the edit modus and you click on a bracket, a little box opens with the cursor in it and you can define the markup function of the bracket .

then the example above would look like

[[sigi]is there a possibility to tell the browser to replace a section with an [editable] raw text,
if you click in (the left margin of) this section?[would look[like[this]]]]
list: [new [header [bold [list [list [list & underlined

or in pretty printing (the markup-ed version is quite the same)

[[sigi]
 is there a possibility to tell the browser to replace
 a section with an [editable] raw text, if you click in
 (the left margin of) this section?
  [would look
   [like
    [this]]]]

What a horrible user interface, full of modes. Looks almost as bad as Lisp ;).

But jokes aside, using different syntax for different elements makes it simplier both for the computer to highlight, and for the human to read/write. We don’t need the generality of Lisp in wiki markup – and this generality comes at a cost. So why should we pay for it if we don’t need it?

But personally, I like the approach of some experimental wiki I saw (can’t recall the name now) in which you don’t put the urls in the text, but put a small marker, like [1] in there, and fill in the urls in a separate form. This allows you to focus on writing, not looking for the page address in the middle of thougt.

ya! True. This is a major drawback on wiki-witing. You “think” edit mode. You take ages to fill in url’s before continuing a thought. With EditableTitles you would fix the links in the preview. Afterwards.

LocalNames are even better solution of this problem.

We do have CommunityLocalNames on this site…

Not sure now that this page really fits the topic of this wiki, I think will ultimately move it all to wiki features wiki.

Just for the record, JSPwiki has a java-applet-based editor with syntax higlighting, and Zim desktop wiki (standalone application) uses a similar technique of replacing certain markup with rendered equivalents as you type (doesn’t make the markup visible though).

Have you thought about making the stars in indented lists visible, somehow? Perhaps make the ones leading up to the final ones really faint, and using some CSS-foo to make bullet points display like the stars?

Though I’m not sure if it’s really possible…

Bullet points w/ images… [1] If you want to get around graphic content, perhaps there’s a way to smoosh in an XMB or something?

Not sure how to do the multiple stars, for multiple levels of indentation.

Though, here’s an idea: Make an icon that is two stars, overlapping, for two levels of depth, and then an icon that is three stars, overlapping, for three levels of depth, ..?

This page is quite welcome on WikiFeatures, though, by my book, at least. We have been known to talk about wiki, and wiki features here, for some time: See the ancient and venerable CategoryWikiTechnology, which I would categorize this page as.

Making the bullets into stars is certainly possible with CSS2, not with CSS1 thought (at least not without using graphics).

The followoing style snippet should do the trick for 3 levels of nesting:

ul > li:before {display:marker;content: "*"}
ul ul > li:before {content:"**"}
ul ul ul > li:before {content:"***"}

The example is available (temporarily only) at http://sheep.art.pl/misc/asterisks.html (in addition it has the asterisks styled somewhat and the default list bullets removed).

EditNearLinks: PatrickAnderson WikiWords JavaScript

Languages: