From f264b14280b341a750b9c94bfc8f09740dd25b95 Mon Sep 17 00:00:00 2001
From: Vincent Balat <vincent.balat@vblt.org>
Date: Sat, 6 Jun 2026 12:25:33 +0200
Subject: [PATCH 1/2] Translate the tutorial manual from wikicreole to wodoc
 .mld

Both versions (tutos/8.0, tutos/dev) translated in place with `wodoc convert
--odoc-refs`, keeping the doc in the main branch (no wikidoc branch). The old
.wiki sources are removed (recoverable from git history); menu.wiki is kept as
the sidebar navigation source (parsed by gen-manual-nav.py, same as eliom).

The themed site is built from these .mld by ocsigen.github.io's wodoc/tuto/
build.sh. Verified: content section headings identical to the live site on all
pages (8.0 60/60, dev 61/61).
---
 .../{application.wiki => application.mld}     | 886 ++++++++--------
 .../{basics-server.wiki => basics-server.mld} | 592 ++++++-----
 tutos/8.0/manual/{basics.wiki => basics.mld}  | 988 ++++++++++--------
 .../{custom-conf.wiki => custom-conf.mld}     |  26 +-
 .../{hash-password.wiki => hash-password.mld} |  12 +-
 ...te-a-cryptographically-safe-identifier.mld |   3 +
 ...e-a-cryptographically-safe-identifier.wiki |   3 -
 .../how-does-a-page-s-source-code-look.mld    |  81 ++
 .../how-does-a-page-s-source-code-look.wiki   |  81 --
 tutos/8.0/manual/how-to-add-a-div.mld         |  25 +
 tutos/8.0/manual/how-to-add-a-div.wiki        |  25 -
 tutos/8.0/manual/how-to-add-a-favicon.mld     |  16 +
 tutos/8.0/manual/how-to-add-a-favicon.wiki    |  16 -
 .../manual/how-to-add-a-javascript-script.mld |  30 +
 .../how-to-add-a-javascript-script.wiki       |  30 -
 tutos/8.0/manual/how-to-add-a-list.mld        |  70 ++
 tutos/8.0/manual/how-to-add-a-list.wiki       |  70 --
 ...to-add-a-select-or-other-form-element.mld} |  26 +-
 tutos/8.0/manual/how-to-add-an-image.mld      |  46 +
 tutos/8.0/manual/how-to-add-an-image.wiki     |  46 -
 .../8.0/manual/how-to-add-css-stylesheet.mld  |  45 +
 .../8.0/manual/how-to-add-css-stylesheet.wiki |  45 -
 ...o-attach-ocaml-values-to-dom-elements.mld} |  12 +-
 ...s-to-the-html-nodes-sent-to-the-client.mld |   3 +
 ...-to-the-html-nodes-sent-to-the-client.wiki |   3 -
 tutos/8.0/manual/how-to-build-js-object.mld   |  13 +
 tutos/8.0/manual/how-to-build-js-object.wiki  |  13 -
 ...server-side-function-from-client-side.mld} |  28 +-
 ...to-call-an-ocaml-function-from-js-code.mld |   3 +
 ...o-call-an-ocaml-function-from-js-code.wiki |   3 -
 ...ki => how-to-compile-my-ocsigen-pages.mld} |  28 +-
 ...onfigure-and-launch-the-ocsigen-server.mld |  23 +
 ...nfigure-and-launch-the-ocsigen-server.wiki |  23 -
 ...ding-on-data-entered-on-previous-ones.mld} |   6 +-
 ...a-current-page-without-knowing-its-url.mld |  11 +
 ...-current-page-without-knowing-its-url.wiki |  11 -
 ...> how-to-detect-channel-disconnection.mld} |  26 +-
 ...-side-state-for-the-process-is-closed.mld} |   8 +-
 ...iki => how-to-do-links-to-other-pages.mld} |   6 +-
 ...ow-to-implement-a-notification-system.mld} |  63 +-
 ...belonging-to-a-form-towards-a-service.mld} |  10 +-
 ...all-sessions-for-one-user-or-all-tabs.mld} |   6 +-
 ...e-browser-window-has-the-focus-or-not.mld} |   6 +-
 .../how-to-make-hello-world-in-ocsigen.mld    |  49 +
 .../how-to-make-hello-world-in-ocsigen.wiki   |  56 -
 ...n.wiki => how-to-make-page-a-skeleton.mld} |  28 +-
 .../manual/how-to-make-responsive-css.mld}    |   8 +-
 ...-the-server-and-insert-it-in-the-page.mld} |  18 +-
 ...vice-that-decides-itself-what-to-send.mld} |   8 +-
 ....wiki => how-to-register-session-data.mld} |  44 +-
 ...r-without-stopping-the-client-process.mld} |  12 +-
 .../manual/how-to-send-file-download.mld}     |   4 +-
 ...pload.wiki => how-to-send-file-upload.mld} |  12 +-
 ...-or-other-attributes-to-html-elements.mld} |  48 +-
 ...w-to-stop-default-behaviour-of-events.mld} |  12 +-
 ...et-parameters-or-parameters-in-the-url.mld |  88 ++
 ...t-parameters-or-parameters-in-the-url.wiki |  88 --
 ...e.wiki => how-to-write-a-json-service.mld} |  16 +-
 ...rite-forms.wiki => how-to-write-forms.mld} |  38 +-
 .../how-to-write-titles-and-paragraphs.mld    |  34 +
 .../how-to-write-titles-and-paragraphs.wiki   |  34 -
 tutos/8.0/manual/{html.wiki => html.mld}      | 106 +-
 .../{interaction.wiki => interaction.mld}     | 671 ++++++------
 tutos/8.0/manual/intro.mld                    | 139 +++
 tutos/8.0/manual/intro.wiki                   | 157 ---
 tutos/8.0/manual/{lwt.wiki => lwt.mld}        | 124 +--
 .../8.0/manual/{macaque.wiki => macaque.mld}  |  78 +-
 tutos/8.0/manual/{misc.wiki => misc.mld}      | 141 +--
 .../mobile.wiki => 8.0/manual/mobile.mld}     |  32 +-
 tutos/8.0/manual/{music.wiki => music.mld}    |  20 +-
 .../{ocsipersist.wiki => ocsipersist.mld}     |  24 +-
 .../manual/{pictures.wiki => pictures.mld}    |  53 +-
 ...diaplayer.wiki => reactivemediaplayer.mld} | 163 +--
 tutos/8.0/manual/{rest.wiki => rest.mld}      | 180 ++--
 tutos/8.0/manual/start.mld                    | 111 ++
 tutos/8.0/manual/start.wiki                   | 109 --
 .../manual/{tutoreact.wiki => tutoreact.mld}  | 522 ++++-----
 .../{tutowidgets.wiki => tutowidgets.mld}     | 212 ++--
 .../{application.wiki => application.mld}     | 886 ++++++++--------
 .../{basics-server.wiki => basics-server.mld} | 592 ++++++-----
 tutos/dev/manual/{basics.wiki => basics.mld}  | 988 ++++++++++--------
 .../{custom-conf.wiki => custom-conf.mld}     |  26 +-
 .../{hash-password.wiki => hash-password.mld} |  12 +-
 ...te-a-cryptographically-safe-identifier.mld |   3 +
 ...e-a-cryptographically-safe-identifier.wiki |   3 -
 .../how-does-a-page-s-source-code-look.mld    |  81 ++
 .../how-does-a-page-s-source-code-look.wiki   |  81 --
 tutos/dev/manual/how-to-add-a-div.mld         |  25 +
 tutos/dev/manual/how-to-add-a-div.wiki        |  25 -
 tutos/dev/manual/how-to-add-a-favicon.mld     |  16 +
 tutos/dev/manual/how-to-add-a-favicon.wiki    |  16 -
 .../manual/how-to-add-a-javascript-script.mld |  30 +
 .../how-to-add-a-javascript-script.wiki       |  30 -
 tutos/dev/manual/how-to-add-a-list.mld        |  70 ++
 tutos/dev/manual/how-to-add-a-list.wiki       |  70 --
 ...to-add-a-select-or-other-form-element.mld} |  26 +-
 tutos/dev/manual/how-to-add-an-image.mld      |  46 +
 tutos/dev/manual/how-to-add-an-image.wiki     |  46 -
 .../dev/manual/how-to-add-css-stylesheet.mld  |  45 +
 .../dev/manual/how-to-add-css-stylesheet.wiki |  45 -
 ...o-attach-ocaml-values-to-dom-elements.mld} |  12 +-
 ...s-to-the-html-nodes-sent-to-the-client.mld |   3 +
 ...-to-the-html-nodes-sent-to-the-client.wiki |   3 -
 tutos/dev/manual/how-to-build-js-object.mld   |  13 +
 tutos/dev/manual/how-to-build-js-object.wiki  |  13 -
 ...server-side-function-from-client-side.mld} |  28 +-
 ...to-call-an-ocaml-function-from-js-code.mld |   3 +
 ...o-call-an-ocaml-function-from-js-code.wiki |   3 -
 ...ki => how-to-compile-my-ocsigen-pages.mld} |  32 +-
 ...onfigure-and-launch-the-ocsigen-server.mld |  23 +
 ...nfigure-and-launch-the-ocsigen-server.wiki |  23 -
 ...ding-on-data-entered-on-previous-ones.mld} |   6 +-
 ...a-current-page-without-knowing-its-url.mld |  11 +
 ...-current-page-without-knowing-its-url.wiki |  11 -
 ...> how-to-detect-channel-disconnection.mld} |  24 +-
 ...-side-state-for-the-process-is-closed.mld} |   6 +-
 ...iki => how-to-do-links-to-other-pages.mld} |   6 +-
 ...ow-to-implement-a-notification-system.mld} |  63 +-
 ...belonging-to-a-form-towards-a-service.mld} |  10 +-
 ...all-sessions-for-one-user-or-all-tabs.mld} |   6 +-
 ...e-browser-window-has-the-focus-or-not.mld} |   6 +-
 .../how-to-make-hello-world-in-ocsigen.mld    |  49 +
 .../how-to-make-hello-world-in-ocsigen.wiki   |  56 -
 ...n.wiki => how-to-make-page-a-skeleton.mld} |  28 +-
 .../manual/how-to-make-responsive-css.mld}    |   8 +-
 ...-the-server-and-insert-it-in-the-page.mld} |  18 +-
 ...vice-that-decides-itself-what-to-send.mld} |   8 +-
 ....wiki => how-to-register-session-data.mld} |  44 +-
 ...r-without-stopping-the-client-process.mld} |  12 +-
 .../manual/how-to-send-file-download.mld}     |   4 +-
 ...pload.wiki => how-to-send-file-upload.mld} |  12 +-
 ...-or-other-attributes-to-html-elements.mld} |  48 +-
 ...w-to-stop-default-behaviour-of-events.mld} |  12 +-
 ...et-parameters-or-parameters-in-the-url.mld |  88 ++
 ...t-parameters-or-parameters-in-the-url.wiki |  88 --
 ...e.wiki => how-to-write-a-json-service.mld} |  16 +-
 ...rite-forms.wiki => how-to-write-forms.mld} |  38 +-
 .../how-to-write-titles-and-paragraphs.mld    |  34 +
 .../how-to-write-titles-and-paragraphs.wiki   |  34 -
 tutos/dev/manual/{html.wiki => html.mld}      | 106 +-
 .../{interaction.wiki => interaction.mld}     | 671 ++++++------
 tutos/dev/manual/intro.mld                    | 139 +++
 tutos/dev/manual/intro.wiki                   | 157 ---
 tutos/dev/manual/{lwt.wiki => lwt.mld}        | 124 +--
 .../dev/manual/{macaque.wiki => macaque.mld}  |  78 +-
 tutos/dev/manual/migration.mld                | 138 +++
 tutos/dev/manual/migration.wiki               | 134 ---
 tutos/dev/manual/{misc.wiki => misc.mld}      | 141 +--
 .../mobile.wiki => dev/manual/mobile.mld}     |  32 +-
 tutos/dev/manual/{music.wiki => music.mld}    |  20 +-
 .../{ocsipersist.wiki => ocsipersist.mld}     |  24 +-
 .../manual/{pictures.wiki => pictures.mld}    |  53 +-
 ...diaplayer.wiki => reactivemediaplayer.mld} | 163 +--
 tutos/dev/manual/{rest.wiki => rest.mld}      | 180 ++--
 tutos/dev/manual/start.mld                    | 111 ++
 tutos/dev/manual/start.wiki                   | 109 --
 .../manual/{tutoreact.wiki => tutoreact.mld}  | 522 ++++-----
 .../{tutowidgets.wiki => tutowidgets.mld}     | 212 ++--
 158 files changed, 7272 insertions(+), 6812 deletions(-)
 rename tutos/8.0/manual/{application.wiki => application.mld} (51%)
 rename tutos/8.0/manual/{basics-server.wiki => basics-server.mld} (52%)
 rename tutos/8.0/manual/{basics.wiki => basics.mld} (52%)
 rename tutos/8.0/manual/{custom-conf.wiki => custom-conf.mld} (86%)
 rename tutos/8.0/manual/{hash-password.wiki => hash-password.mld} (73%)
 create mode 100644 tutos/8.0/manual/how-do-i-create-a-cryptographically-safe-identifier.mld
 delete mode 100644 tutos/8.0/manual/how-do-i-create-a-cryptographically-safe-identifier.wiki
 create mode 100644 tutos/8.0/manual/how-does-a-page-s-source-code-look.mld
 delete mode 100644 tutos/8.0/manual/how-does-a-page-s-source-code-look.wiki
 create mode 100644 tutos/8.0/manual/how-to-add-a-div.mld
 delete mode 100644 tutos/8.0/manual/how-to-add-a-div.wiki
 create mode 100644 tutos/8.0/manual/how-to-add-a-favicon.mld
 delete mode 100644 tutos/8.0/manual/how-to-add-a-favicon.wiki
 create mode 100644 tutos/8.0/manual/how-to-add-a-javascript-script.mld
 delete mode 100644 tutos/8.0/manual/how-to-add-a-javascript-script.wiki
 create mode 100644 tutos/8.0/manual/how-to-add-a-list.mld
 delete mode 100644 tutos/8.0/manual/how-to-add-a-list.wiki
 rename tutos/8.0/manual/{how-to-add-a-select-or-other-form-element.wiki => how-to-add-a-select-or-other-form-element.mld} (61%)
 create mode 100644 tutos/8.0/manual/how-to-add-an-image.mld
 delete mode 100644 tutos/8.0/manual/how-to-add-an-image.wiki
 create mode 100644 tutos/8.0/manual/how-to-add-css-stylesheet.mld
 delete mode 100644 tutos/8.0/manual/how-to-add-css-stylesheet.wiki
 rename tutos/{dev/manual/how-to-attach-ocaml-values-to-dom-elements.wiki => 8.0/manual/how-to-attach-ocaml-values-to-dom-elements.mld} (52%)
 create mode 100644 tutos/8.0/manual/how-to-attach-ocaml-values-to-the-html-nodes-sent-to-the-client.mld
 delete mode 100644 tutos/8.0/manual/how-to-attach-ocaml-values-to-the-html-nodes-sent-to-the-client.wiki
 create mode 100644 tutos/8.0/manual/how-to-build-js-object.mld
 delete mode 100644 tutos/8.0/manual/how-to-build-js-object.wiki
 rename tutos/{dev/manual/how-to-call-a-server-side-function-from-client-side.wiki => 8.0/manual/how-to-call-a-server-side-function-from-client-side.mld} (52%)
 create mode 100644 tutos/8.0/manual/how-to-call-an-ocaml-function-from-js-code.mld
 delete mode 100644 tutos/8.0/manual/how-to-call-an-ocaml-function-from-js-code.wiki
 rename tutos/8.0/manual/{how-to-compile-my-ocsigen-pages.wiki => how-to-compile-my-ocsigen-pages.mld} (52%)
 create mode 100644 tutos/8.0/manual/how-to-configure-and-launch-the-ocsigen-server.mld
 delete mode 100644 tutos/8.0/manual/how-to-configure-and-launch-the-ocsigen-server.wiki
 rename tutos/8.0/manual/{how-to-create-form-wizard-sequence-of-pages-depending-on-data-entered-on-previous-ones.wiki => how-to-create-form-wizard-sequence-of-pages-depending-on-data-entered-on-previous-ones.mld} (96%)
 create mode 100644 tutos/8.0/manual/how-to-create-link-to-a-current-page-without-knowing-its-url.mld
 delete mode 100644 tutos/8.0/manual/how-to-create-link-to-a-current-page-without-knowing-its-url.wiki
 rename tutos/8.0/manual/{how-to-detect-channel-disconnection.wiki => how-to-detect-channel-disconnection.mld} (78%)
 rename tutos/8.0/manual/{how-to-detect-on-client-side-that-the-server-side-state-for-the-process-is-closed.wiki => how-to-detect-on-client-side-that-the-server-side-state-for-the-process-is-closed.mld} (59%)
 rename tutos/8.0/manual/{how-to-do-links-to-other-pages.wiki => how-to-do-links-to-other-pages.mld} (91%)
 rename tutos/8.0/manual/{how-to-implement-a-notification-system.wiki => how-to-implement-a-notification-system.mld} (61%)
 rename tutos/8.0/manual/{how-to-insert-raw-form-elements-not-belonging-to-a-form-towards-a-service.wiki => how-to-insert-raw-form-elements-not-belonging-to-a-form-towards-a-service.mld} (57%)
 rename tutos/8.0/manual/{how-to-iterate-on-all-sessions-for-one-user-or-all-tabs.wiki => how-to-iterate-on-all-sessions-for-one-user-or-all-tabs.mld} (87%)
 rename tutos/{dev/manual/how-to-know-whether-the-browser-window-has-the-focus-or-not.wiki => 8.0/manual/how-to-know-whether-the-browser-window-has-the-focus-or-not.mld} (77%)
 create mode 100644 tutos/8.0/manual/how-to-make-hello-world-in-ocsigen.mld
 delete mode 100644 tutos/8.0/manual/how-to-make-hello-world-in-ocsigen.wiki
 rename tutos/8.0/manual/{how-to-make-page-a-skeleton.wiki => how-to-make-page-a-skeleton.mld} (54%)
 rename tutos/{dev/manual/how-to-make-responsive-css.wiki => 8.0/manual/how-to-make-responsive-css.mld} (73%)
 rename tutos/8.0/manual/{how-to-make-the-client-side-program-get-an-html-element-from-the-server-and-insert-it-in-the-page.wiki => how-to-make-the-client-side-program-get-an-html-element-from-the-server-and-insert-it-in-the-page.mld} (64%)
 rename tutos/8.0/manual/{how-to-register-a-service-that-decides-itself-what-to-send.wiki => how-to-register-a-service-that-decides-itself-what-to-send.mld} (74%)
 rename tutos/8.0/manual/{how-to-register-session-data.wiki => how-to-register-session-data.mld} (61%)
 rename tutos/8.0/manual/{how-to-send-a-file-to-server-without-stopping-the-client-process.wiki => how-to-send-a-file-to-server-without-stopping-the-client-process.mld} (82%)
 rename tutos/{dev/manual/how-to-send-file-download.wiki => 8.0/manual/how-to-send-file-download.mld} (68%)
 rename tutos/8.0/manual/{how-to-send-file-upload.wiki => how-to-send-file-upload.mld} (91%)
 rename tutos/{dev/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.wiki => 8.0/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.mld} (57%)
 rename tutos/{dev/manual/how-to-stop-default-behaviour-of-events.wiki => 8.0/manual/how-to-stop-default-behaviour-of-events.mld} (61%)
 create mode 100644 tutos/8.0/manual/how-to-use-get-parameters-or-parameters-in-the-url.mld
 delete mode 100644 tutos/8.0/manual/how-to-use-get-parameters-or-parameters-in-the-url.wiki
 rename tutos/8.0/manual/{how-to-write-a-json-service.wiki => how-to-write-a-json-service.mld} (62%)
 rename tutos/8.0/manual/{how-to-write-forms.wiki => how-to-write-forms.mld} (72%)
 create mode 100644 tutos/8.0/manual/how-to-write-titles-and-paragraphs.mld
 delete mode 100644 tutos/8.0/manual/how-to-write-titles-and-paragraphs.wiki
 rename tutos/8.0/manual/{html.wiki => html.mld} (56%)
 rename tutos/8.0/manual/{interaction.wiki => interaction.mld} (68%)
 create mode 100644 tutos/8.0/manual/intro.mld
 delete mode 100644 tutos/8.0/manual/intro.wiki
 rename tutos/8.0/manual/{lwt.wiki => lwt.mld} (57%)
 rename tutos/8.0/manual/{macaque.wiki => macaque.mld} (69%)
 rename tutos/8.0/manual/{misc.wiki => misc.mld} (83%)
 rename tutos/{dev/manual/mobile.wiki => 8.0/manual/mobile.mld} (58%)
 rename tutos/8.0/manual/{music.wiki => music.mld} (69%)
 rename tutos/8.0/manual/{ocsipersist.wiki => ocsipersist.mld} (79%)
 rename tutos/8.0/manual/{pictures.wiki => pictures.mld} (84%)
 rename tutos/8.0/manual/{reactivemediaplayer.wiki => reactivemediaplayer.mld} (64%)
 rename tutos/8.0/manual/{rest.wiki => rest.mld} (76%)
 create mode 100644 tutos/8.0/manual/start.mld
 delete mode 100644 tutos/8.0/manual/start.wiki
 rename tutos/8.0/manual/{tutoreact.wiki => tutoreact.mld} (68%)
 rename tutos/8.0/manual/{tutowidgets.wiki => tutowidgets.mld} (69%)
 rename tutos/dev/manual/{application.wiki => application.mld} (51%)
 rename tutos/dev/manual/{basics-server.wiki => basics-server.mld} (52%)
 rename tutos/dev/manual/{basics.wiki => basics.mld} (52%)
 rename tutos/dev/manual/{custom-conf.wiki => custom-conf.mld} (86%)
 rename tutos/dev/manual/{hash-password.wiki => hash-password.mld} (73%)
 create mode 100644 tutos/dev/manual/how-do-i-create-a-cryptographically-safe-identifier.mld
 delete mode 100644 tutos/dev/manual/how-do-i-create-a-cryptographically-safe-identifier.wiki
 create mode 100644 tutos/dev/manual/how-does-a-page-s-source-code-look.mld
 delete mode 100644 tutos/dev/manual/how-does-a-page-s-source-code-look.wiki
 create mode 100644 tutos/dev/manual/how-to-add-a-div.mld
 delete mode 100644 tutos/dev/manual/how-to-add-a-div.wiki
 create mode 100644 tutos/dev/manual/how-to-add-a-favicon.mld
 delete mode 100644 tutos/dev/manual/how-to-add-a-favicon.wiki
 create mode 100644 tutos/dev/manual/how-to-add-a-javascript-script.mld
 delete mode 100644 tutos/dev/manual/how-to-add-a-javascript-script.wiki
 create mode 100644 tutos/dev/manual/how-to-add-a-list.mld
 delete mode 100644 tutos/dev/manual/how-to-add-a-list.wiki
 rename tutos/dev/manual/{how-to-add-a-select-or-other-form-element.wiki => how-to-add-a-select-or-other-form-element.mld} (61%)
 create mode 100644 tutos/dev/manual/how-to-add-an-image.mld
 delete mode 100644 tutos/dev/manual/how-to-add-an-image.wiki
 create mode 100644 tutos/dev/manual/how-to-add-css-stylesheet.mld
 delete mode 100644 tutos/dev/manual/how-to-add-css-stylesheet.wiki
 rename tutos/{8.0/manual/how-to-attach-ocaml-values-to-dom-elements.wiki => dev/manual/how-to-attach-ocaml-values-to-dom-elements.mld} (52%)
 create mode 100644 tutos/dev/manual/how-to-attach-ocaml-values-to-the-html-nodes-sent-to-the-client.mld
 delete mode 100644 tutos/dev/manual/how-to-attach-ocaml-values-to-the-html-nodes-sent-to-the-client.wiki
 create mode 100644 tutos/dev/manual/how-to-build-js-object.mld
 delete mode 100644 tutos/dev/manual/how-to-build-js-object.wiki
 rename tutos/{8.0/manual/how-to-call-a-server-side-function-from-client-side.wiki => dev/manual/how-to-call-a-server-side-function-from-client-side.mld} (52%)
 create mode 100644 tutos/dev/manual/how-to-call-an-ocaml-function-from-js-code.mld
 delete mode 100644 tutos/dev/manual/how-to-call-an-ocaml-function-from-js-code.wiki
 rename tutos/dev/manual/{how-to-compile-my-ocsigen-pages.wiki => how-to-compile-my-ocsigen-pages.mld} (50%)
 create mode 100644 tutos/dev/manual/how-to-configure-and-launch-the-ocsigen-server.mld
 delete mode 100644 tutos/dev/manual/how-to-configure-and-launch-the-ocsigen-server.wiki
 rename tutos/dev/manual/{how-to-create-form-wizard-sequence-of-pages-depending-on-data-entered-on-previous-ones.wiki => how-to-create-form-wizard-sequence-of-pages-depending-on-data-entered-on-previous-ones.mld} (96%)
 create mode 100644 tutos/dev/manual/how-to-create-link-to-a-current-page-without-knowing-its-url.mld
 delete mode 100644 tutos/dev/manual/how-to-create-link-to-a-current-page-without-knowing-its-url.wiki
 rename tutos/dev/manual/{how-to-detect-channel-disconnection.wiki => how-to-detect-channel-disconnection.mld} (80%)
 rename tutos/dev/manual/{how-to-detect-on-client-side-that-the-server-side-state-for-the-process-is-closed.wiki => how-to-detect-on-client-side-that-the-server-side-state-for-the-process-is-closed.mld} (67%)
 rename tutos/dev/manual/{how-to-do-links-to-other-pages.wiki => how-to-do-links-to-other-pages.mld} (91%)
 rename tutos/dev/manual/{how-to-implement-a-notification-system.wiki => how-to-implement-a-notification-system.mld} (61%)
 rename tutos/dev/manual/{how-to-insert-raw-form-elements-not-belonging-to-a-form-towards-a-service.wiki => how-to-insert-raw-form-elements-not-belonging-to-a-form-towards-a-service.mld} (57%)
 rename tutos/dev/manual/{how-to-iterate-on-all-sessions-for-one-user-or-all-tabs.wiki => how-to-iterate-on-all-sessions-for-one-user-or-all-tabs.mld} (87%)
 rename tutos/{8.0/manual/how-to-know-whether-the-browser-window-has-the-focus-or-not.wiki => dev/manual/how-to-know-whether-the-browser-window-has-the-focus-or-not.mld} (77%)
 create mode 100644 tutos/dev/manual/how-to-make-hello-world-in-ocsigen.mld
 delete mode 100644 tutos/dev/manual/how-to-make-hello-world-in-ocsigen.wiki
 rename tutos/dev/manual/{how-to-make-page-a-skeleton.wiki => how-to-make-page-a-skeleton.mld} (54%)
 rename tutos/{8.0/manual/how-to-make-responsive-css.wiki => dev/manual/how-to-make-responsive-css.mld} (73%)
 rename tutos/dev/manual/{how-to-make-the-client-side-program-get-an-html-element-from-the-server-and-insert-it-in-the-page.wiki => how-to-make-the-client-side-program-get-an-html-element-from-the-server-and-insert-it-in-the-page.mld} (64%)
 rename tutos/dev/manual/{how-to-register-a-service-that-decides-itself-what-to-send.wiki => how-to-register-a-service-that-decides-itself-what-to-send.mld} (74%)
 rename tutos/dev/manual/{how-to-register-session-data.wiki => how-to-register-session-data.mld} (61%)
 rename tutos/dev/manual/{how-to-send-a-file-to-server-without-stopping-the-client-process.wiki => how-to-send-a-file-to-server-without-stopping-the-client-process.mld} (82%)
 rename tutos/{8.0/manual/how-to-send-file-download.wiki => dev/manual/how-to-send-file-download.mld} (68%)
 rename tutos/dev/manual/{how-to-send-file-upload.wiki => how-to-send-file-upload.mld} (91%)
 rename tutos/{8.0/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.wiki => dev/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.mld} (57%)
 rename tutos/{8.0/manual/how-to-stop-default-behaviour-of-events.wiki => dev/manual/how-to-stop-default-behaviour-of-events.mld} (61%)
 create mode 100644 tutos/dev/manual/how-to-use-get-parameters-or-parameters-in-the-url.mld
 delete mode 100644 tutos/dev/manual/how-to-use-get-parameters-or-parameters-in-the-url.wiki
 rename tutos/dev/manual/{how-to-write-a-json-service.wiki => how-to-write-a-json-service.mld} (62%)
 rename tutos/dev/manual/{how-to-write-forms.wiki => how-to-write-forms.mld} (72%)
 create mode 100644 tutos/dev/manual/how-to-write-titles-and-paragraphs.mld
 delete mode 100644 tutos/dev/manual/how-to-write-titles-and-paragraphs.wiki
 rename tutos/dev/manual/{html.wiki => html.mld} (56%)
 rename tutos/dev/manual/{interaction.wiki => interaction.mld} (68%)
 create mode 100644 tutos/dev/manual/intro.mld
 delete mode 100644 tutos/dev/manual/intro.wiki
 rename tutos/dev/manual/{lwt.wiki => lwt.mld} (57%)
 rename tutos/dev/manual/{macaque.wiki => macaque.mld} (69%)
 create mode 100644 tutos/dev/manual/migration.mld
 delete mode 100644 tutos/dev/manual/migration.wiki
 rename tutos/dev/manual/{misc.wiki => misc.mld} (83%)
 rename tutos/{8.0/manual/mobile.wiki => dev/manual/mobile.mld} (58%)
 rename tutos/dev/manual/{music.wiki => music.mld} (69%)
 rename tutos/dev/manual/{ocsipersist.wiki => ocsipersist.mld} (79%)
 rename tutos/dev/manual/{pictures.wiki => pictures.mld} (84%)
 rename tutos/dev/manual/{reactivemediaplayer.wiki => reactivemediaplayer.mld} (64%)
 rename tutos/dev/manual/{rest.wiki => rest.mld} (76%)
 create mode 100644 tutos/dev/manual/start.mld
 delete mode 100644 tutos/dev/manual/start.wiki
 rename tutos/dev/manual/{tutoreact.wiki => tutoreact.mld} (68%)
 rename tutos/dev/manual/{tutowidgets.wiki => tutowidgets.mld} (69%)

diff --git a/tutos/8.0/manual/application.wiki b/tutos/8.0/manual/application.mld
similarity index 51%
rename from tutos/8.0/manual/application.wiki
rename to tutos/8.0/manual/application.mld
index cc12891e..d2c83151 100644
--- a/tutos/8.0/manual/application.wiki
+++ b/tutos/8.0/manual/application.mld
@@ -1,45 +1,49 @@
-<<header| =Writing a client/server Eliom application >>
+{%wodoc:header%}
+{0 Writing a client/server Eliom application}
+{%wodoc:end%}
 
-In this chapter, we will write a [[site:graffiti/|collaborative
-drawing application]]. It is a client/server web application
+In this chapter, we will write a {{:../graffiti/}collaborative
+drawing application}. It is a client/server web application
 displaying an area where users can draw using the mouse, and see what
 other users are drawing at the same time and in real-time.
 
 This tutorial is a good starting point if you want a step-by-step
 introduction to Eliom programming.
 
-<<webonly| The final eliom code is available
-[[https://github.com/ocsigen/graffiti/tree/master/simple|for download]].
->>
+ The final eliom code is available
+{{:https://github.com/ocsigen/graffiti/tree/master/simple}for download}.
 
-<<|outline target="documentation">>
 
-==@@id="basics"@@ Basics==
+
+
+{1:basics Basics}
 
 If not already done, install Eliom first:
-{{{
+{v
 opam install ocsipersist-sqlite eliom ocsigen-ppx-rpc
-}}}
+v}
 
-To get started, we recommend using <<a_manual project="eliom"
-chapter="workflow-distillery"|Eliom distillery>>, a program which
+To get started, we recommend using {{:../eliom/workflow-distillery.html}Eliom distillery}, a program which
 creates scaffolds for Eliom projects. The following command creates a
-very simple project called {{{graffiti}}} in the directory
-{{{graffiti}}}:
+very simple project called [graffiti] in the directory
+[graffiti]:
 
-<<code language="shell"|
+{@shell[
 $ eliom-distillery -name graffiti -template client-server.basic -target-directory graffiti
->>
+]}
 
-===My first page===
+{2 My first page}
 
-<<concepts|Services\\Configuration file\\Static validation of HTML>>
+{%wodoc:aside class="concepts"%}{b Concepts}
+
+Services{%html:<br/>%}Configuration file{%html:<br/>%}Static validation of HTML{%wodoc:end%}
 
 Our web application consists of a single page for now. Let's start by
 creating a very basic page. We define the service that will implement
 this page by the following declaration:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 open%server Eliom_content.Html.D (* provides functions to create HTML nodes *)
 
 let%server main_service =
@@ -55,23 +59,25 @@ let%server () =
         (html
            (head (title (txt "Page title")) [])
            (body [h1 [txt "Graffiti"]])))
->>
+]}
 
-Annotations {{{%server}}} tells the compiler that the code is going to be executed
+Annotations [%server] tells the compiler that the code is going to be executed
 on the server (see later).
 
-Replace the content of file {{{graffiti.eliom}}} by the above lines and run:
+Replace the content of file [graffiti.eliom] by the above lines and run:
 
-<<code language="shell"|
+{@shell[
 $ make test.byte
->>
+]}
+
+This will compile your application and run [ocsigenserver].
 
-This will compile your application and run {{{ocsigenserver}}}.
+Your page is now available at URL {{:http://localhost:8080/graff}[http://localhost:8080/graff]}.
 
-Your page is now available at URL [[http://localhost:8080/graff|{{{http://localhost:8080/graff}}}]].
+
+{%wodoc:aside class="concept"%}{b Concept: Services}
 
 
-<<concept title="Services"|
 
 Unlike typical web programming techniques (CGI, PHP,~ ...), with Eliom
 you do not need to write one file per URL. The application can be
@@ -79,84 +85,88 @@ split into multiple files as per the developer's style. What matters
 is that you eventually produce a single module (*.cmo or *.cma) for
 the whole website.
 
-The module <<a_api project="eliom" subproject="server" | module Eliom_service >> allows to
-create new entry points to your web site, called //services//. In
+The module {!Eliom_service} allows to
+create new entry points to your web site, called {e services}. In
 general, services are attached to a URL and generate a web page.
 Services are represented by OCaml values, through which you must
 register a function that will generate a page.
 
-The {{{~path}}} parameter corresponds to the URL where you want to
+The [~path] parameter corresponds to the URL where you want to
 attach your service. It is a list of strings.  The value
-<<code-inline|["foo"; "bar"]>> corresponds to the URL
-<<code-inline|foo/bar>>.  <<code-inline|["dir"; ""]>> corresponds to
-the URL <<code-inline|dir/>> (that is: the default page of the
-directory <<code-inline|dir>>).
+{[["foo"; "bar"]]} corresponds to the URL
+{[foo/bar]}.  {[["dir"; ""]]} corresponds to
+the URL {[dir/]} (that is: the default page of the
+directory {[dir]}).
+
+{%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: Configuration file}
 
->>
 
-<<concept title="Configuration file"|
 
 In the directory of the project created by the Eliom-distillery, you
-can find the file {{{graffiti.conf.in}}}. This file is used in
-conjunction with the variables in {{{Makefile.options}}} to generate
-the {{{ocsigenserver}}} configuration file.
+can find the file [graffiti.conf.in]. This file is used in
+conjunction with the variables in [Makefile.options] to generate
+the [ocsigenserver] configuration file.
 
-Once you start up your application via {{{make test.byte}}}, the
+Once you start up your application via [make test.byte], the
 configuration file becomes available at
-{{{local/etc/graffiti/graffiti-test.conf}}}. It contains various
+[local/etc/graffiti/graffiti-test.conf]. It contains various
 directives for Ocsigen server (port, log files, extensions to be
-loaded, etc.), taken from {{{Makefile.options}}}, and something like:
+loaded, etc.), taken from [Makefile.options], and something like:
 
-{{{
+{v
 <host>
   <static dir="static" />
   <eliommodule module="/path_to/graffiti.cma" />
   <eliom />
 </host>
-}}}
+v}
 
-{{{<eliommodule ... />}}} asks the server to load Eliom module
-{{{graffiti.cma}}}, containing the Eliom application,
+[<eliommodule ... />] asks the server to load Eliom module
+[graffiti.cma], containing the Eliom application,
 at startup and attach it to this host (and site).
 
-Extensions {{{<static ... />}}} (staticmod) and {{{<eliom />}}}
+Extensions [<static ... />] (staticmod) and [<eliom />]
 are called successively:
-* If they exist, files from the directory <<code-inline|
-  /path_to/graffiti/static >> will be served,
-* Otherwise, Server will try to generate pages with Eliom
-  ({{{<eliom />}}}),
-* Otherwise it will generate a 404 (Not found) error (default).
+- If they exist, files from the directory {[
+  /path_to/graffiti/static ]} will be served,
+- Otherwise, Server will try to generate pages with Eliom
+  ([<eliom />]),
+- Otherwise it will generate a 404 (Not found) error (default).
+
+{%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: Static validation of HTML}
 
->>
 
-<<concept title="Static validation of HTML" id="tyxml"|
 
 There are several ways to create pages for Eliom.  You can generate
 pages as strings (as in other web frameworks). However, it is
 preferable to generate HTML in a way that provides compile-time HTML
 correctness guarantees. This tutorial achieves this by using the
-module <<a_api project="eliom" subproject="server" | module Eliom_content.Html.D >>,
-which is implemented using the <<a_manual project="tyxml" |TyXML>>
+module {!Eliom_content.Html.D},
+which is implemented using the {{:../tyxml/.html}TyXML}
 library.  The module defines a construction function for each HTML
 tag.
 
-//Note that it is also possible to use the usual HTML syntax directly
- in OCaml, cf.  <<a_api project="tyxml" | module Pa_tyxml >>.//
+{e Note that it is also possible to use the usual HTML syntax directly
+ in OCaml, cf.  {!Pa_tyxml}.}
 
-The TyXML library (and thus <<a_api project="eliom" subproject="server" | module
-Eliom_content.Html.D >>) is very strict and compels you to respect
+The TyXML library (and thus {!module
+Eliom_content.Html.D}) is very strict and compels you to respect
 HTML standard (with some limitations). For example if you write:
 
-<<code language="ocaml"|
+{@ocaml[
 (html
    (head (title (txt "")) [txt ""])
    (body [txt "Hallo"]))
->>
+]}
 
 You will get an error message similar to the following, referring to
 the end of line 2:
 
-{{{
+{v
 Error: This expression has type ([> `TXT ] as 'a) Html.elt
        but an expression was expected of type
          Html_types.head_content_fun Html.elt
@@ -169,89 +179,72 @@ Error: This expression has type ([> `TXT ] as 'a) Html.elt
            | `Script
            | `Style ]
        The second variant type does not allow tag(s) `TXT
-}}}
+v}
 
-where <<a_api project="tyxml" | type Html_types.head_content_fun >>
-is the type of content allowed inside {{{<head>}}} ({{{<base>}}},
-{{{<command>}}}, {{{<link>}}}, {{{<meta>}}}, etc.). Notice that
-{{{`TXT}}} (i.e. raw text) is not included in this polymorphic
-variant type, which means that {{{<head>}}} cannot contain raw text.
+where {!Html_types.head_content_fun}
+is the type of content allowed inside [<head>] ([<base>],
+[<command>], [<link>], [<meta>], etc.). Notice that
+[`TXT] (i.e. raw text) is not included in this polymorphic
+variant type, which means that [<head>] cannot contain raw text.
 
 Most functions take as parameter the list representing its contents.
-See other examples below. Each of them take an optional {{{?a}}}
+See other examples below. Each of them take an optional [?a]
 parameter for optional HTML attributes.
 Mandatory HTML attributes correspond to mandatory OCaml parameters.
 See below for examples.
 
-<<|
-**Another example:** In HTML, some tags cannot be empty. For example
-{{{<table>}}}must contain at least one row. To enforce this, function
-<<a_api project="tyxml" text="Html.table"| val Html.F.table ~>>
-takes two parameters: the first one is the first row, while
-the second one is a list containing all the other rows (same thing for
-{{{<tr>}}}, {{{<form>}}}, {{{<select>}}}, ...). This prevents tables
-of zero rows, and thus ensures that the W3C recommendation is met.
 
-//Strict typing of HTML may initially seem tedious, but in fact it is
-very easy to get used to.  It actually saves a significant amount of
-debugging time as you will never have to bother about the validity of
-pages afterwards.//
 
-A more detailed introduction to the construction of HTML5 tree is
-available in the <<a_api project="tyxml" text="TyXML reference API" |
-module Html.F ~>>.
+{%wodoc:end%}
 
->>
+{%wodoc:aside class="concept"%}{b Concept: Lwt}
 
->>
 
-<<concept title="Lwt"|
 
-**Important warning:** All the functions you write must be written in
+{b Important warning:} All the functions you write must be written in
 a cooperative manner using Lwt. Lwt is a convenient way to implement
 concurrent programs in OCaml, and is now also widely used for
 applications unrelated to Ocsigen.
 
-For now we will just use the {{{Lwt.return}}} function as above.  We
+For now we will just use the [Lwt.return] function as above.  We
 will come back to Lwt programming later. You can also have a look at
-the <<a_manual project="lwt"|Lwt programming guide>>.
+the {{:../lwt/.html}Lwt programming guide}.
+
+{%wodoc:end%}
 
->>
+{2 Execute parts of the program on the client}
 
-===Execute parts of the program on the client===
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-<<concepts|
-Service sending an application\\
-Client and server code\\
-Compiling a Web application with server and client parts\\
-Calling JavaScript methods with Js_of_ocaml\\
->>
 
-To create our first service, we used the function <<a_api
-project="eliom" subproject="server" | val Eliom_registration.Html.create>>, as
+Service sending an application{%html:<br/>%}
+Client and server code{%html:<br/>%}
+Compiling a Web application with server and client parts{%html:<br/>%}
+Calling JavaScript methods with Js_of_ocaml{%html:<br/>%}
+{%wodoc:end%}
+
+To create our first service, we used the function {!Eliom_registration.Html.create}, as
 all we wanted to do was return HTML. But we actually want a service
 that corresponds to a full application with client and server
 parts. To do so, we need to create our own registration module by
-using the functor {{{Eliom_registration.App}}}:
+using the functor [Eliom_registration.App]:
+
 
-<<|BB
-  This is a bit fast, especially if you just came to Ocsigen. The following
-  questions popped into my mind: What is an Eliom application? What's its
-  motivation, what comprises it and how does is work?
->>
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 module Graffiti_app =
   Eliom_registration.App (struct
       let application_name = "graffiti"
       let global_data_path = None
     end)
->>
+]}
 
-It is now possible to use module {{{Graffiti_app}}} for registering our main
-service (now at URL {{{/}}}):
+It is now possible to use module [Graffiti_app] for registering our main
+service (now at URL [/]):
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server main_service =
   Eliom_service.create
     ~path:(Eliom_service.Path [""])
@@ -265,38 +258,41 @@ let%server () =
         (html
            (head (title (txt "Graffiti")) [])
            (body [h1 [txt "Graffiti"]]) ) )
->>
+]}
 
 We can now add some OCaml code to be executed by the browser. For this
 purpose, Eliom provides a syntax extension to distinguish between
 server and client code in the same file. We start by a very basic
 program, that will display a message to the user by calling the
-JavaScript function {{{alert}}}. Add the following lines to the
+JavaScript function [alert]. Add the following lines to the
 program:
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client _ = Eliom_lib.alert "Hello!"
->>
+]}
+
+After running again [make test.byte], and visiting
+{{:http://localhost:8080/}http://localhost:8080/}, the browser will load the file
+[graffiti.js], and open an alert-box.
 
-After running again {{{make test.byte}}}, and visiting
-[[http://localhost:8080/]], the browser will load the file
-{{{graffiti.js}}}, and open an alert-box.
+{%wodoc:aside class="concept"%}{b Concept: Splitting the code into server and client parts}
 
-<<concept title="Splitting the code into server and client parts"|
 
-At the very toplevel of your source file (i.e. //not// inside modules
+
+At the very toplevel of your source file (i.e. {e not} inside modules
 or other server- /client-parts), you can use the following constructs
 to indicate which side the code should run on.
 
-* {{{ let%client }}}, {{{ let%server }}}, {{{ let%shared }}}: same as
+- [let%client], [let%server], [let%shared]: same as
   above for a single definition.
-* other syntaxes like {{{ module%server }}}, {{{ open%client }}},
-  {{{ type%shared }}} ...
-* {{{ [%%client ... ] }}}: the list of enclosed definitions is
-  client-only code (similarly for {{{ [%%server ... ] }}}). With
-  {{{ [%%shared ... ] }}}, the code is used both on the server and client.
-* {{{ [%%client.start] }}}, {{{ [%%server.start] }}},
-  {{{ [%%shared.start] }}}: these set the default location for all
+- other syntaxes like [module%server], [open%client],
+  [type%shared] ...
+- [[%%client ... ]]: the list of enclosed definitions is
+  client-only code (similarly for [[%%server ... ]]). With
+  [[%%shared ... ]], the code is used both on the server and client.
+- [[%%client.start]], [[%%server.start]],
+  [[%%shared.start]]: these set the default location for all
   definitions that follow, and which do not use the preceding
   constructs.
 
@@ -304,81 +300,89 @@ If no location is specified, the code is assumed to be for the server.
 
 The above constructs are implemented by means of PPX, OCaml's new
 mechanism for implementing syntax extensions. See
-<<a_api project="eliom" subproject="ppx"|module Ppx_eliom>> for details.
+{!Ppx_eliom} for details.
 
-**Client parts are executed once, when the client side process is
-launched.** The client process is not restarted after each page
+{b Client parts are executed once, when the client side process is
+launched.} The client process is not restarted after each page
 change.
 
-The Makefile created by {{{eliom-distillery}}} automatically splits the
+The Makefile created by [eliom-distillery] automatically splits the
 code into client and server parts, compiles the server part as usual,
 and compile the client part to a JavaScript program using
-{{{js_of_ocaml}}}.
+[js_of_ocaml].
+
+ {%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: Client values on the server}
 
- >>
 
-<<concept title="Client values on the server"|
 
 Additionally, it is possible to create client values within the server
 code by the following quotation:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
   [%client (expr : typ) ]
->>
+]}
 
-where {{{typ}}} is the type of an expression {{{expr}}} on the client.
+where [typ] is the type of an expression [expr] on the client.
 Note, that such a client value is abstract on the server, but becomes
 concrete, once it is received by the client.
 
-(The {{{typ}}} can be ommitted if it can be inferred from the usage of
+(The [typ] can be ommitted if it can be inferred from the usage of
 the client value in the server code.)
 
-**Client values are executed on the client after the service
-returns.** You can use client values when a service wants to ask the
+{b Client values are executed on the client after the service
+returns.} You can use client values when a service wants to ask the
 client to run something, for example binding some event handler on
 some element produced by the service.
 
->>
+{%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: Js_of_ocaml}
+
 
-<<concept title="Js_of_ocaml"|
 
 The client-side parts of the program are compiled to JavaScript by
-{{{js_of_ocaml}}}. (Technically, {{{js_of_ocaml}}} compiles OCaml
-bytecode to JavaScript.)  It is easy <<a_manual project="js_of_ocaml"
-chapter="bindings"|to bind JavaScript libraries>> so that OCaml
+[js_of_ocaml]. (Technically, [js_of_ocaml] compiles OCaml
+bytecode to JavaScript.)  It is easy {{:../js_of_ocaml/bindings.html}to bind JavaScript libraries} so that OCaml
 programs can call JavaScript functions. In the example, we are using
-the <<a_api project="js_of_ocaml" | module Js_of_ocaml.Dom_html >> module, which
+the {!Js_of_ocaml.Dom_html} module, which
 is a binding that allows the manipulation of an HTML page.
 
 Js_of_ocaml is using a syntax extension to call JavaScript methods:
-* {{{obj##m a b c}}} to call the method {{{m}}} of object {{{obj}}}
-  with parameters {{{a}}}, {{{b}}}, {{{c}}},
-* {{{obj##.m}}} to get a property,
-* {{{obj##.m := e}}} to set a property, and
-* {{{new%js constr a b c}}} to call a JavaScript constructor.
+- [obj##m a b c] to call the method [m] of object [obj]
+  with parameters [a], [b], [c],
+- [obj##.m] to get a property,
+- [obj##.m := e] to set a property, and
+- [new%js constr a b c] to call a JavaScript constructor.
 
 More information can be found in the Js_of_ocaml manual, in module
-<<a_api project="js_of_ocaml" subproject="js_of_ocaml-ppx"| module Ppx_js >>.
+{!Ppx_js}.
+
+{%wodoc:end%}
 
->>
+{2 Accessing server side variables on client side code}
 
-===Accessing server side variables on client side code===
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-<<concepts|
-Executing client side code after loading a page\\
-Sharing server side values\\
-Converting an HTML value to a portion of page (a.k.a. Dom node)\\
+
+Executing client side code after loading a page{%html:<br/>%}
+Sharing server side values{%html:<br/>%}
+Converting an HTML value to a portion of page (a.k.a. Dom node){%html:<br/>%}
 Manipulating HTML node 'by reference'
->>
+{%wodoc:end%}
 
 The client side process is not strictly separated from the server
 side.  We can access some server variables from the client code. For
 instance:
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 open%client Js_of_ocaml
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 
 let%server count = ref 0
 
@@ -402,110 +406,88 @@ let%server () =
          (html
             (head (title (txt "Graffiti")) [])
             (body [h1 [txt @@ text c]])))
->>
+]}
 
-Here, we are increasing the reference {{{count}}} each time the page
+Here, we are increasing the reference [count] each time the page
 is accessed. When the page is loaded and the document is in-place, the
-client program initializes the value inside {{{ [%client ... ] }}},
+client program initializes the value inside [[%client ... ]],
 and thus triggers an alert window. More specifically, the variable
-{{{c}}}, in the scope of the client value on the server is made
-available to the client value using the syntax extension {{{~%c}}}. In
-doing so, the server side value {{{c}}} is displayed in a message box
+[c], in the scope of the client value on the server is made
+available to the client value using the syntax extension [~%c]. In
+doing so, the server side value [c] is displayed in a message box
 on the client.
 
 
-<<concept
+{%wodoc:aside class="concept"%}{b Concept: Injections: Using server side values in client code}
+
 
-  title="Injections: Using server side values in client code" |
 
   Client side code can reference copies of server side values using
-  the {{{~%variable}}} syntax.  Values sent that way are weakly type
+  the [~%variable] syntax.  Values sent that way are weakly type
   checked: the name of the client side type must match the server side
   one. If you define a type and want it to be available on both sides,
-  declare it in {{{ [%%shared ... ]}}}. The Eliom manual provides more
-  information on the <<a_api project="eliom" subproject="ppx"
-  text="Eliom's syntax extension"|module Ppx_eliom>> and
-  its <<a_manual project="eliom" chapter="workflow-compilation"
-  fragment="compilation"|compilation process>>.
+  declare it in [[%%shared ... ]]. The Eliom manual provides more
+  information on the {{!Ppx_eliom}Eliom's syntax extension} and
+  its {{:../eliom/workflow-compilation.html#compilation}compilation process}.
 
-  The value of an injection into a {{{ let%client }}}
+  The value of an injection into a [let%client]
   section is sent only once when starting the application in the
   browser. In contrast, the
   values of injections into client values which are created during a
   request are sent alongside the next response.
 
->>
+{%wodoc:end%}
 
-<<|BB/BS This only applies to elements created by Html.F
-It is possible to send almost any type of values that way, but keep in
-mind that sent values are //copies// of server side ones. For HTML
-elements, this is not always the expected behaviour. Considering the
-following piece of code, the {{{onload}}} event handler won't do
-anything noticeable because we added the {{{<div>some text</div>}}} to
-a copy of the {{{<body>}}} element. Hence, the actual page's
-{{{<body>}}} is not modified.
 
-<<code language="ocaml" class="server"|
-let%server main_service =
-  Eliom_service.create
-    ~path:(Eliom_service.Path [""])
-    ~meth:(Eliom_service.Get Eliom_parameter.unit)
-    ()
 
-let%server () =
-  Graffiti_app.register ~service:main_service
-    (fun () () ->
-      let container = body [h1 [txt "Graffiti"]] in
-      Eliom_service.onload {{
-        Html.Manip.appendChild %container (div [txt "some text"]);
-      }}
-      Lwt.return
-        (html
-           (head (title (txt "Graffiti")) [])
-           (container) ) )
->>
 
+{1:graffiti Collaborative drawing application}
+
+{2 Drawing on a canvas}
 
-==@@id="graffiti"@@ Collaborative drawing application==
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-===Drawing on a canvas===
 
-<<concepts|
 
 Canvas
 
->>
+{%wodoc:end%}
 
 We now want to draw something on the page using an HTML canvas. The
 drawing primitive is defined in the client-side function called
-{{{draw}}} that just draws a line between two given points in a canvas.
+[draw] that just draws a line between two given points in a canvas.
 
 To start our collaborative drawing application, we define another
-client-side function {{{ init_client }}}, which just draws a single
+client-side function [init_client], which just draws a single
 line for now.
 
 Here is the (full) new version of the program:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 open%server Eliom_content
 open%server Eliom_content.Html.D
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 open%client Js_of_ocaml
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 module%server Graffiti_app =
   Eliom_registration.App (
     struct
       let application_name = "graffiti"
       let global_data_path = None
     end)
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server width  = 700
 let%server height = 400
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client draw ctx ((r, g, b), size, (x1, y1), (x2, y2)) =
   let color = CSS.Color.string_of_t (CSS.Color.rgb r g b) in
   ctx##.strokeStyle := (Js.string color);
@@ -514,8 +496,9 @@ let%client draw ctx ((r, g, b), size, (x1, y1), (x2, y2)) =
   ctx##(moveTo (float x1) (float y1));
   ctx##(lineTo (float x2) (float y2));
   ctx##stroke
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server canvas_elt =
   Html.D.canvas ~a:[Html.D.a_width width; Html.D.a_height height]
     [Html.D.txt "your browser doesn't support canvas"]
@@ -525,15 +508,17 @@ let%server page () =
      (head (title (txt "Graffiti")) [])
      (body [h1 [txt "Graffiti"];
             canvas_elt])
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client init_client () =
   let canvas = Eliom_content.Html.To_dom.of_canvas ~%canvas_elt in
   let ctx = canvas##(getContext (Dom_html._2d_)) in
   ctx##.lineCap := Js.string "round";
   draw ctx ((0, 0, 0), 12, (10, 10), (200, 100))
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server main_service =
   Eliom_service.create
     ~path:(Eliom_service.Path ["graff"])
@@ -547,60 +532,66 @@ let%server () =
        (* Cf. section "Client side side-effects on the server" *)
        let _ = [%client (init_client () : unit) ] in
        Lwt.return (page ()))
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: JavaScript datatypes in OCaml}
 
-<<concept
 
-  title="JavaScript datatypes in OCaml"|
 
-  Here we use the function <<a_api project="js_of_ocaml" | val
-  Js_of_ocaml.Js.string>> from Js_of_ocaml's library to convert an OCaml string
+  Here we use the function {!val
+  Js_of_ocaml.Js.string} from Js_of_ocaml's library to convert an OCaml string
   into a JS string.
 
->>
+{%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: Client side side-effect on the server}
+
 
-<<concept title="Client side side-effect on the server" |
 
   If a client value
   is created while processing a request, it will be evaluated on the
   client once it receives the response and the document is created;
   the corresponding side effects are then executed.
   For example, the line
-  <<code language="ocaml"|
+  {@ocaml[
     let _ = [%client (init_client () : unit) ] in
     ...
-  >>
+  ]}
 
   creates a client value for the sole purpose of performing side
   effects on the client.  The client value can also be named (as
-  opposed to ignored via {{{_}}}), thus enabling server-side
-  manipulation of client-side values (see below). >>
+  opposed to ignored via [_]), thus enabling server-side
+  manipulation of client-side values (see below). {%wodoc:end%}
+
+{2 Single user drawing application}
 
-===Single user drawing application===
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-<<concepts|
-Lwt\\
+
+Lwt{%html:<br/>%}
 Mouse events with Lwt
->>
+{%wodoc:end%}
 
 We now want to catch mouse events to draw lines with the mouse like
-with the //brush// tools of any classical drawing application. One
+with the {e brush} tools of any classical drawing application. One
 solution would be to mimic typical JavaScript code in OCaml; for
-example by using the function <<a_api project="js_of_ocaml"| val
-Js_of_ocaml.Dom_events.listen >> that is the Js_of_ocaml's equivalent of
-{{{addEventListener}}}. However, this solution is at least as verbose
+example by using the function {!val
+Js_of_ocaml.Dom_events.listen} that is the Js_of_ocaml's equivalent of
+[addEventListener]. However, this solution is at least as verbose
 as the JavaScript equivalent, hence not satisfactory. Js_of_ocaml's
 library provides a much easier way to do that with the help of Lwt.
 
 To use this, add the following line on top of your file:
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 open%client Js_of_ocaml_lwt
->>
+]}
 
-Then, replace the {{{init_client}}} of the previous example by the
+Then, replace the [init_client] of the previous example by the
 following piece of code, then compile and draw!
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client init_client () =
 
   let canvas = Eliom_content.Html.To_dom.of_canvas ~%canvas_elt in
@@ -631,253 +622,259 @@ let%client init_client () =
          Lwt.pick
            [mousemoves Dom_html.document (fun x _ -> line x);
             let%lwt ev = mouseup Dom_html.document in line ev]))
->>
+]}
 
-We use two references {{{x}}} and {{{y}}} to record the last mouse
-position.  The function {{{set_coord}}} updates those references from
-mouse event data.  The function {{{compute_line}}} computes the
+We use two references [x] and [y] to record the last mouse
+position.  The function [set_coord] updates those references from
+mouse event data.  The function [compute_line] computes the
 coordinates of a line from the initial (old) coordinates to the new
 coordinates--the event data sent as a parameter.
 
 The last four lines of code implement the event-handling loop.  They
-can be read as follows: for each {{{mousedown}}} event on the canvas,
-do {{{set_coord}}}, then {{{line}}} (this will draw a dot), then
-behave as the {{{first}}} of the two following lines that terminates:
+can be read as follows: for each [mousedown] event on the canvas,
+do [set_coord], then [line] (this will draw a dot), then
+behave as the [first] of the two following lines that terminates:
 
-* For each mousemove event on the document, call {{{line}}} (never
+- For each mousemove event on the document, call [line] (never
   terminates)
-* If there is a mouseup event on the document, call {{{line}}}.
+- If there is a mouseup event on the document, call [line].
+
+{%wodoc:aside class="concept"%}{b Concept: More on Lwt}
+
 
-<<concept title="More on Lwt" id="lwt"|
 
 Functions in Eliom and Js_of_ocaml which do not implement just a
 computation or direct side effect, but rather wait for user activity,
 or file system access, or need a unforseeable amount of time to return
-are defined //with Lwt//; instead of returning a value of type {{{a}}}
-they return an Lwt thread of type {{{a Lwt.t}}}.
+are defined {e with Lwt}; instead of returning a value of type [a]
+they return an Lwt thread of type [a Lwt.t].
 
 The only way to use the result of such functions (ones that return
-values in the //Lwt monad//), is to use {{{Lwt.bind}}}.
+values in the {e Lwt monad}), is to use [Lwt.bind].
 
-<<code language="ocaml"|
+{@ocaml[
 Lwt.bind : 'a Lwt.t -> ('a -> 'b Lwt.t) -> 'b Lwt.t
->>
+]}
 
 It is convenient to define an infix operator like this:
-<<code language="ocaml"| let (~>>=) = Lwt.bind>>
+{@ocaml[ let (>>=) = Lwt.bind]}
 
 Then the code
 
-<<code language="ocaml"| f () ~>>= fun x -> >>
+{@ocaml[ f () >>= fun x -> ]}
 
 is conceptually similar to
 
-<<code language="ocaml"| let x = f () in>>
+{@ocaml[ let x = f () in]}
 
 but only for functions returning a value in the Lwt monad.
 
 For more clarity, there is a syntax extension for Lwt, defining
-{{{let%lwt}}} to be used instead of {{{let}}} for Lwt functions:
-<<code language="ocaml"| let%lwt x = f () in>>
+[let%lwt] to be used instead of [let] for Lwt functions:
+{@ocaml[ let%lwt x = f () in]}
 
-{{{Lwt.return}}} creates a terminated thread from a value: <<code
-language="ocaml"| Lwt.return : 'a -> 'a Lwt.t>> Use it when you must
+[Lwt.return] creates a terminated thread from a value: {@ocaml[ Lwt.return : 'a -> 'a Lwt.t]} Use it when you must
 return something in the Lwt monad (for example in a service handler,
-or often after a {{{Lwt.bind}}}).
+or often after a [Lwt.bind]).
 
-=====Why Lwt?=====
+{4 Why Lwt?}
 
 An Eliom application is a cooperative program, as the server must be
 able to handle several requests at the same time.  Ocsigen is using
 cooperative threading instead of the more widely used preemptive
 threading paradigm. It means that no scheduler will interrupt your
 functions whenever it wants. Switching from one thread to another is
-done only when there is a //cooperation point//.
+done only when there is a {e cooperation point}.
 
-We will use the term //cooperative functions// to identify functions
+We will use the term {e cooperative functions} to identify functions
 implemented in cooperative way, that is: if something takes
 (potentially a long) time to complete (for example reading a value
 from a database), they insert a cooperation point to let other threads
 run.  Cooperative functions return a value in the Lwt monad
-(that is, a value of type {{{'a Lwt.t}}} for some type {{{'a}}}).
+(that is, a value of type ['a Lwt.t] for some type ['a]).
 
-{{{Lwt.bind}}} and {{{Lwt.return}}} do not introduce cooperation points.
+[Lwt.bind] and [Lwt.return] do not introduce cooperation points.
 
-In our example, the function {{{Lwt_js_events.mouseup}}} may introduce
+In our example, the function [Lwt_js_events.mouseup] may introduce
 a cooperation point, because it is unforseeable when this event
 happens. That's why it returns a value in the Lwt monad.
 
 Using cooperative threads has a huge advantage: given that you know
-precisely where the cooperation points are, //you need very few
-mutexes// and you have //very low risk of deadlocks//!
+precisely where the cooperation points are, {e you need very few
+mutexes} and you have {e very low risk of deadlocks}!
 
 Using Lwt is very easy and does not cause trouble, provided you never
-use //blocking functions// (non-cooperative functions).  //Blocking
-functions can cause the entre server to hang!// Remember:
+use {e blocking functions} (non-cooperative functions).  {e Blocking
+functions can cause the entre server to hang!} Remember:
 
-* Use the functions from module {{{Lwt_unix}}} instead of module
- {{{Unix}}},
-* Use cooperative database libraries (like PG'Ocaml for Lwt),
-* If you want to use a non-cooperative function, detach it in another
-  preemptive thread using <<a_api project="lwt" | val
-  Lwt_preemptive.detach >>,
-* If you want to launch a long-running computation, manually insert
-  cooperation points using {{{Lwt_unix.yield}}},
-* {{{Lwt.bind}}} does not introduce any cooperation point.
+- Use the functions from module [Lwt_unix] instead of module
+ [Unix],
+- Use cooperative database libraries (like PG'Ocaml for Lwt),
+- If you want to use a non-cooperative function, detach it in another
+  preemptive thread using {!val
+  Lwt_preemptive.detach},
+- If you want to launch a long-running computation, manually insert
+  cooperation points using [Lwt_unix.yield],
+- [Lwt.bind] does not introduce any cooperation point.
 
->> <<| END "encadre" >>
+{%wodoc:end%} 
 
-<<concept
+{%wodoc:aside class="concept"%}{b Concept: Handling events with Lwt}
 
-  title="Handling events with Lwt"|
 
-  Module <<a_api project="js_of_ocaml" subproject="js_of_ocaml-lwt"| module Js_of_ocaml_lwt.Lwt_js_events>>
+
+  Module {!Js_of_ocaml_lwt.Lwt_js_events}
   allows easily defining event listeners using Lwt.  For example,
-  <<a_api project="js_of_ocaml" subproject="js_of_ocaml-lwt"| val Js_of_ocaml_lwt.Lwt_js_events.click >> takes a
+  {!Js_of_ocaml_lwt.Lwt_js_events.click} takes a
   DOM element and returns an Lwt thread that will wait until a click
   occures on this element.
 
-  Functions with an ending "s" (<<a_api project="js_of_ocaml" subproject="js_of_ocaml-lwt"| val
-  Js_of_ocaml_lwt.Lwt_js_events.clicks >>, <<a_api project="js_of_ocaml" subproject="js_of_ocaml-lwt"| val
-  Js_of_ocaml_lwt.Lwt_js_events.mousedowns >>, ...) start again waiting after the
+  Functions with an ending "s" ({!val
+  Js_of_ocaml_lwt.Lwt_js_events.clicks}, {!val
+  Js_of_ocaml_lwt.Lwt_js_events.mousedowns}, ...) start again waiting after the
   handler terminates.
 
-  <<a_api project="lwt" | val Lwt.pick >> behaves as the first thread
+  {!Lwt.pick} behaves as the first thread
   in the list to terminate, and cancels the others.
 
->>
+{%wodoc:end%}
+
+{2 Collaborative drawing application}
 
-===Collaborative drawing application===
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-<<concepts|Client server communication >>
+Client server communication {%wodoc:end%}
 
 In order to see what other users are drawing, we now want to do the
 following:
 
-* Send the coordinates to the server when the user draw a line, then
-* Dispatch the coordinates to all connected users.
+- Send the coordinates to the server when the user draw a line, then
+- Dispatch the coordinates to all connected users.
 
 We first declare a type, shared by the server and the client,
 describing the color (as RGB values) and coordinates of drawn lines.
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 type%shared messages =
     ((int * int * int) * int * (int * int) * (int * int))
     [@@deriving json]
->>
+]}
 
-We annotate the type declaration with {{{[@@deriving json]}}} to allow
+We annotate the type declaration with [[@@deriving json]] to allow
 type-safe deserialization of this type. Eliom forces you to use this
 in order to avoid server crashes if a client sends corrupted data.
 This is defined using a JSON plugin for
-[[https://github.com/whitequark/ppx_deriving|ppx_deriving]], which you
+{{:https://github.com/whitequark/ppx_deriving}ppx_deriving}, which you
 need to install. You need to do that for each type of data sent by the
 client to the server.  This annotation can only be added on types
 containing exclusively basic types, or other types annotated with
-{{{[@@deriving json]}}}.
+[[@@deriving json]].
 
 Then we create an Eliom bus to broadcast drawing events to all client
-with the function <<a_api project="eliom" subproject="server"| val
-Eliom_bus.create >>. This function take as parameter the type of
+with the function {!val
+Eliom_bus.create}. This function take as parameter the type of
 values carried by the bus.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server bus = Eliom_bus.create [%json: messages]
->>
+]}
 
 To write draw commands into the bus, we just replace the function
-{{{line}}} in {{{init_client}}} by:
+[line] in [init_client] by:
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let line ev =
   let v = compute_line ev in
   let _ = Eliom_bus.write ~%bus v in
   draw ctx v;
   Lwt.return ()
 in
->>
+]}
 
 Finally, to interpret the draw orders read on the bus, we add the
-following line at the end of function {{{init_client}}}:
+following line at the end of function [init_client]:
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
   Lwt.async (fun () ->
     Lwt_stream.iter (draw ctx) (Eliom_bus.stream ~%(bus : (messages, messages) Eliom_bus.t)))
->>
+]}
 
 Now you can try the program using two browser windows to see that the
 lines are drawn on both windows.
 
-<<concept
+{%wodoc:aside class="concept"%}{b Concept: Communication channels}
+
 
-  title="Communication channels"|
 
   Eliom provides multiple ways for the server to send unsolicited data
   to the client:
 
-* Module <<a_api project="eliom" subproject="server" | module Eliom_notif >>
-  (or <<a_api project="ocsigen-start" subproject="server" | module Os_notif >>
+- Module {!Eliom_notif}
+  (or {!Os_notif}
   if you are using Ocsigen Start) provides a very simple way to send messages to
   clients. It's probably the solution you will use most of the times.
-* You can use <<a_api project="eliom" subproject="server"
-  | type Eliom_bus.t >> instead, as in this example, in the particular case
+- You can use {!Eliom_bus.t} instead, as in this example, in the particular case
   when you need to broadcast data to all connected clients. Buses are
   broadcasting channels where
-  client and server can participate (see also <<a_api project="eliom"
-  subproject="client" | type Eliom_bus.t >> in the client
+  client and server can participate (see also {!Eliom_bus.t} in the client
   API).
-* <<a_api project="eliom" subproject="server" | module
-  Eliom_react >> allows sending
-  [[http://erratique.ch/software/react/doc/React|React events]] from
+- {!module
+  Eliom_react} allows sending
+  {{:http://erratique.ch/software/react/doc/React}React events} from
   the server to the client, and conversely.
-* <<a_api project="eliom" subproject="server" | type
-  Eliom_comet.Channel.t >> are one-way communication channels
-  allowing finer-grained control. It allows sending <<a_api
-  project="lwt" | module Lwt_stream >> to the client.
-  {{{Eliom_react}}} and {{{Eliom_bus}}} are implemented over
-  {{{Eliom_comet}}}.
+- {!type
+  Eliom_comet.Channel.t} are one-way communication channels
+  allowing finer-grained control. It allows sending {!Lwt_stream} to the client.
+  [Eliom_react] and [Eliom_bus] are implemented over
+  [Eliom_comet].
 
-  It is possible to control the idle behaviour with module <<a_api
-  project="eliom" subproject="client" | module
-  Eliom_comet.Configuration >>.
+  It is possible to control the idle behaviour with module {!module
+  Eliom_comet.Configuration}.
 
->>
+{%wodoc:end%}
 
-===Color and size of the brush===
+{2 Color and size of the brush}
 
-<<concepts|
-Widgets with Ocsigen Toolkit\\
-Functional Reactive Programming\\
->>
+{%wodoc:aside class="concepts"%}{b Concepts}
+
+
+Widgets with Ocsigen Toolkit{%html:<br/>%}
+Functional Reactive Programming{%html:<br/>%}
+{%wodoc:end%}
 
 In this section, we add a color picker and slider to choose the size
 of the brush. For the colorpicker we used a widget available in
-<<a_manual project="ocsigen-toolkit" chapter="intro"|Ocsigen Toolkit>>.
+{{:../ocsigen-toolkit/intro.html}Ocsigen Toolkit}.
 
 To install Ocsigen Toolkit, do:
-{{{
+{v
 opam install ocsigen-toolkit
-}}}
+v}
 
-Add package {{{ocsigen-toolkit.server}}} to the {{{libraries}}} section of your {{{dune}}} file, and {{{ocsigen-toolkit.client}}} to the {{{libraries}}} section of your {{{client/dune}}} file.
+Add package [ocsigen-toolkit.server] to the [libraries] section of your [dune] file, and [ocsigen-toolkit.client] to the [libraries] section of your [client/dune] file.
 
-{{{
+{v
   (libraries ... ocsigen-toolkit.server)
-}}}
-{{{
+v}
+{v
   (libraries ... ocsigen-toolkit.client)
-}}}
+v}
 
-In {{{Makefile.options}}}, created by Eliom's distillery, add
-{{{ocsigen-toolkit.server}}} to the {{{SERVER_PACKAGES}}}.
+In [Makefile.options], created by Eliom's distillery, add
+[ocsigen-toolkit.server] to the [SERVER_PACKAGES].
 This will be used to regenerate Ocsigen Server's configuration file.
-<<code language="makefile"|
+{@makefile[
 SERVER_PACKAGES := ... ocsigen-toolkit.server
->>
+]}
 
-To create the widget, we replace {{{page}}} by :
+To create the widget, we replace [page] by :
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server page () =
   let colorpicker, cp_sig =
     Ot_color_picker.make ~a:[Html.D.a_class ["colorpicker"]] ()
@@ -889,11 +886,12 @@ let%server page () =
                    ; canvas_elt
                    ; colorpicker])
   , cp_sig )
->>
+]}
 
-Replace the registration of {{{main_service}}} by:
+Replace the registration of [main_service] by:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server () =
   Graffiti_app.register ~service:main_service
     (fun () () ->
@@ -901,13 +899,14 @@ let%server () =
       let page, cp_sig = page () in
        let _ = [%client (init_client ~cp_sig:~%cp_sig () : unit) ] in
        Lwt.return page)
->>
+]}
 
 We subsequently add a simple HTML slider to change the size of the
-brush. Near the {{{canvas_elt}}} definition, simply add the following
+brush. Near the [canvas_elt] definition, simply add the following
 code:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server slider =
   Eliom_content.Html.D.Form.input
     ~a:
@@ -917,9 +916,9 @@ let%server slider =
       ; Html.D.a_input_max (`Number 80)
       ; Html.D.a_value "22" ]
     ~input_type:`Range Html.D.Form.int
->>
+]}
 
-{{{Form.int}}} is a typing information telling that this input takes
+[Form.int] is a typing information telling that this input takes
 an integer value. This kind of input can only be associated to
 services taking an integer as parameter.
 
@@ -927,10 +926,11 @@ We then add the slider to the page body, between the canvas and
 the colorpicker.
 
 To change the size and the color of the brush, we add parameter
-{{{~cp_sig}}} to {{{init_client}}} and modify
-function {{{compute_line}}}:
+[~cp_sig] to [init_client] and modify
+function [compute_line]:
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client init_client ~cp_sig () =
 ...
   let compute_line ev =
@@ -944,13 +944,13 @@ let%client init_client ~cp_sig () =
     (rgb, size, (oldx, oldy), (!x, !y))
   in
 ...
->>
+]}
 
 Finally, we need to add a stylesheet in the headers of our page
-with function <<a_api project="eliom" subproject="server"|
-val Eliom_tools.D.css_link>>:
+with function {!Eliom_tools.D.css_link}:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server page () =
   let colorpicker, cp_sig =
     Ot_color_picker.make ~a:[Html.D.a_class ["colorpicker"]] ()
@@ -972,41 +972,40 @@ let%server page () =
              () ])
       (body [canvas_elt; slider; colorpicker])
   , cp_sig )
->>
+]}
 
 
 You need to install the corresponding stylesheets and images into your
 project. The stylesheet files should go to the directory
-{{{static/css}}}.
-Download file {{{graffiti.css}}} from <<a_file
-  src="tutorial/static/css/graffiti.css"|here>>.
-Copy file {{{ot_color_picker.css}}} from directory
-{{{~/.opam/<version>/share/ocsigen-toolkit/css}}} into {{{static/css}}}.
+[static/css].
+Download file [graffiti.css] from {{:files/tutorial/static/css/graffiti.css}here}.
+Copy file [ot_color_picker.css] from directory
+[~/.opam/<version>/share/ocsigen-toolkit/css] into [static/css].
+
+You can then test your application ([make test.byte]).
 
-You can then test your application ({{{make test.byte}}}).
+{%wodoc:aside class="concept"%}{b Concept: Ocsigen Toolkit}
 
-<<concept
 
-  title="Ocsigen Toolkit" |
 
   Ocsigen Toolkit is a Js_of_ocaml library providing useful
   client-server widgets
   for your Eliom applications. You can use it for building complex
   user interfaces. The full documentation is available
-  (<<a_manual project="ocsigen-toolkit" |Ocsigen Toolkit>>).
+  ({{:../ocsigen-toolkit/.html}Ocsigen Toolkit}).
 
->>
+{%wodoc:end%}
 
-<<concept
+{%wodoc:aside class="concept"%}{b Concept: Functional Reactive Programming}
 
-  title="Functional Reactive Programming" |
 
-  Ocsigen Toolkit is using //Functional Reactive Programming// to
+
+  Ocsigen Toolkit is using {e Functional Reactive Programming} to
   simplify and automatize page changes, through Daniel Bünzli's
   React library.
 
-  For example, {{{Ot_color_picker.make}}} returns both the element
-  and a //reactive signal// on which you can bind other computations
+  For example, [Ot_color_picker.make] returns both the element
+  and a {e reactive signal} on which you can bind other computations
   or other page elements, that would be updated automatically when
   the signal value changes.
 
@@ -1014,34 +1013,37 @@ You can then test your application ({{{make test.byte}}}).
   from server side, through module Eliom_shared.
 
   This basic program does not show the full power of reactive
-  programming, however. See [[wiki:manual/tutoreact|this tutorial]]
+  programming, however. See {{:wiki:manual/tutoreact}this tutorial}
   for a better introduction to reactive programming with Eliom.
 
->>
+{%wodoc:end%}
+
+{2:initial-image Sending the initial image}
 
-===@@Id="initial-image"@@ Sending the initial image===
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-<<concepts|Services sending other data types>>
+Services sending other data types{%wodoc:end%}
 
 To finish the first part of the tutorial, we want to save the current
 drawing on server side and send the current image when a new user
 arrives. To do that, we will use the
-[[https://github.com/Chris00/ocaml-cairo|Cairo binding]] for OCaml.
+{{:https://github.com/Chris00/ocaml-cairo}Cairo binding} for OCaml.
 
 For using Cairo, first, make sure that it is installed (it is
-available as {{{cairo2}}} via OPAM). Second, add it to the
-{{{libraries}}} section in your {{{dune}}} file.
+available as [cairo2] via OPAM). Second, add it to the
+[libraries] section in your [dune] file.
 
 Second, add it to the SERVER_PACKAGES in your Makefile.options:
-<<code language="makefile"|
+{@makefile[
 SERVER_PACKAGES := ... cairo2
->>
+]}
 
-The {{{draw_server}}} function below is the equivalent of the
-{{{draw}}} function on the server side and the {{{image_string}}}
+The [draw_server] function below is the equivalent of the
+[draw] function on the server side and the [image_string]
 function outputs the PNG image in a string.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server draw_server, image_string =
   let rgb_ints_to_floats (r, g, b) =
     float r /. 255., float g /. 255., float b /. 255.
@@ -1068,11 +1070,12 @@ let%server draw_server, image_string =
       Buffer.contents b )
 
 let%server _ = Lwt_stream.iter draw_server (Eliom_bus.stream bus)
->>
+]}
 
 We also define a service that sends the picture:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server imageservice =
   Eliom_service.create
     ~path:(Eliom_service.Path ["image"])
@@ -1082,39 +1085,40 @@ let%server imageservice =
 let%server () =
   Eliom_registration.String.register ~service:imageservice
     (fun () () -> Lwt.return (image_string (), "image/png"))
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Eliom_registration}
 
-<<concept
 
-  title="Eliom_registration"|
 
-  The module {{{Eliom_registration}}} defines several modules with
+  The module [Eliom_registration] defines several modules with
   registration and creation functions for a variety of data types.
-  We have already seen {{{Eliom_registration.Html}}} and {{{Eliom_registration.App}}}.
-  The module {{{Eliom_registration.String}}} sends arbitrary byte output
+  We have already seen [Eliom_registration.Html] and [Eliom_registration.App].
+  The module [Eliom_registration.String] sends arbitrary byte output
   (represented by an OCaml string). The handler function must return
   a pair consisting of the content and the content-type.
 
   There are also several other output modules, for example:
 
-* {{{Eliom_registration.File}}} to send static files
-* {{{Eliom_registration.Redirection}}} to create a redirection towards another page
-* {{{Eliom_registration.Any}}} to create services that decide late what
+- [Eliom_registration.File] to send static files
+- [Eliom_registration.Redirection] to create a redirection towards another page
+- [Eliom_registration.Any] to create services that decide late what
 they want to send
-* {{{Eliom_registration.Ocaml}}} to send any OCaml data to be used in a
+- [Eliom_registration.Ocaml] to send any OCaml data to be used in a
 client side program
-* {{{Eliom_registration.Action}}} to create service with no output
+- [Eliom_registration.Action] to create service with no output
 (the handler function just performs a side effect on the server)
 and reload the current page (or not). We will see an example of actions
 in the next chapter.
 
->>
+{%wodoc:end%}
 
 We now want to load the initial image once the canvas is created.  Add
 the following lines just after the creation of the canvas context
-in {{{init_client}}}:
+in [init_client]:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 (* The initial image: *)
 let img = Eliom_content.Html.To_dom.of_img
     (img ~alt:"canvas"
@@ -1123,48 +1127,46 @@ let img = Eliom_content.Html.To_dom.of_img
 in
 img##.onload := Dom_html.handler (fun _ev ->
   ctx##drawImage img 0. 0.; Js._false);
->>
+]}
 
-As we are now using {{{Eliom_content.Html.D}}} in both client and server sections,
+As we are now using [Eliom_content.Html.D] in both client and server sections,
 we need to open it in a shared section:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 open%shared Eliom_content.Html.D
->>
+]}
 
 Finally, we can add a new canvas where we would draw a visualisation of the
 current size  of the brush. The complete code of this application
-can be found [[https://github.com/ocsigen/graffiti/tree/master/simple|here]].
+can be found {{:https://github.com/ocsigen/graffiti/tree/master/simple}here}.
 
-The {{{Makefile}}} from the distillery automatically adds
-the packages defined in {{{SERVER_PACKAGES}}} as an extension in your
-configuration file {{{local/etc/graffiti/graffiti-test.conf}}}:
+The [Makefile] from the distillery automatically adds
+the packages defined in [SERVER_PACKAGES] as an extension in your
+configuration file [local/etc/graffiti/graffiti-test.conf]:
 
-<<code language="xml"|
+{@xml[
 <extension findlib-package="cairo2" />
->>
+]}
 
 The first version of the program is now complete.
 
-<<div class="exercices"|
+{%wodoc:div class="exercices"%}
 
-====Exercises====
+{3 Exercises}
 
-* Add a button that allows download the current
+- Add a button that allows download the current
   image, and saving it to the hard disk (reuse the service
-  {{{imageservice}}}).
-  <<|BB
-    Wrapping my head around the huge oclosure-API offhanded is very hard. A
-    hint on how to register a click-listener with the button would help.
-  >>
-* Add a button with a color picker to select a color from the
+  [imageservice]).
+  
+- Add a button with a color picker to select a color from the
   drawing. Pressing the button changes the mouse cursor, and disables
   current mouse events until the next mouse click event on the
   document.  Then the color palette changes to the color of the pixel
-  clicked.  (Use the function {{{Dom_html.pixel_get}}}).
+  clicked.  (Use the function [Dom_html.pixel_get]).
 
->>
+{%wodoc:end%}
 
 If you want to continue learning client-server programming with Eliom
 and build your first application, we suggest to read
-[[wiki:manual/start|the tutorial about Ocsigen Start]].
+{{:wiki:manual/start}the tutorial about Ocsigen Start}.
diff --git a/tutos/8.0/manual/basics-server.wiki b/tutos/8.0/manual/basics-server.mld
similarity index 52%
rename from tutos/8.0/manual/basics-server.wiki
rename to tutos/8.0/manual/basics-server.mld
index 4c948a20..994270c8 100644
--- a/tutos/8.0/manual/basics-server.wiki
+++ b/tutos/8.0/manual/basics-server.mld
@@ -1,4 +1,4 @@
-=Server-side website programming guide=
+{0 Server-side website programming guide}
 
 While Eliom is well known for its unique client-server programming
 model, it is also perfectly suited to programming more traditional
@@ -14,26 +14,30 @@ sessions or continuation-based Web programming.
 Programming with Eliom will make your website ready for future
 evolutions by allowing you to introduce progressively client-side
 features like event handlers, fully in OCaml. You will even be able to
-turn your website into a [[basics|distributed client-server Web app]],
+turn your website into a {{:basics.html}distributed client-server Web app},
 and even a mobile app if needed in the future, without having to rewrite
 anything.
 
-<<outline| <<header| **Table of contents** >> >>
 
-<<section class="docblock" |
-<<header |==OCaml==>>
 
-This programming guide assumes you know the //OCaml// language.
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 OCaml}
+{%wodoc:end%}
+
+This programming guide assumes you know the {e OCaml} language.
 Many resources and books are available online.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Lwt==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Lwt}
+{%wodoc:end%}
 
-//Lwt// is a concurrent programming library for OCaml, initially written
+{e Lwt} is a concurrent programming library for OCaml, initially written
 by Jérôme Vouillon in 2001 for the
-[[https://github.com/bcpierce00/unison|Unison]] file synchronizer.
+{{:https://github.com/bcpierce00/unison}Unison} file synchronizer.
 It provides an alternative to the more usual preemptive threads approach
 for programming concurrent applications, that avoids most problems of concurrent
 data access and deadlocks.
@@ -41,29 +45,31 @@ It is used by Ocsigen Server and Eliom and has now become one of the
 standard ways to implement concurrent applications in OCaml.
 All your Web sites must be written in Lwt-compatible way!
 
-<<div class="focused"|
-===How it works===
-Instead of calling blocking functions, like {{{Unix.sleep}}}
-or {{{Unix.read}}}, that could block the entire program, replace them
-by their cooperative counterparts ({{{Lwt_unix.sleep}}},
-{{{Lwt_unix.read}}}, etc.). Instead of taking time to execute,
-they always return immediately a //promise// of the result,
-of type {{{'a Lwt.t}}}. This type is abstract, and the only way
-to use the result is to //bind// a function to the promise.
-{{{Lwt.bind p f}}} means: "when promise {{{p}}} is completed, give its result
-to function {{{f}}}".
-
-Syntax {{{let%lwt x = p in e}}} is equivalent to {{{Lwt.bind p (fun x -> e)}}}
+{%wodoc:div class="focused"%}
+{2 How it works}
+Instead of calling blocking functions, like [Unix.sleep]
+or [Unix.read], that could block the entire program, replace them
+by their cooperative counterparts ([Lwt_unix.sleep],
+[Lwt_unix.read], etc.). Instead of taking time to execute,
+they always return immediately a {e promise} of the result,
+of type ['a Lwt.t]. This type is abstract, and the only way
+to use the result is to {e bind} a function to the promise.
+[Lwt.bind p f] means: "when promise [p] is completed, give its result
+to function [f]".
+
+Syntax [let%lwt x = p in e] is equivalent to [Lwt.bind p (fun x -> e)]
 and makes it very natural to sequentialize computations without blocking the rest
 of the program.
->>
+{%wodoc:end%}
 
-To learn Lwt, read this [[lwt|short tutorial]], or its [[wiki("lwt"):|user manual]].
+To learn Lwt, read this {{:lwt.html}short tutorial}, or its {{:../lwt/}user manual}.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Ocsigen Server: A full featured extensible Web server in OCaml==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Ocsigen Server: A full featured extensible Web server in OCaml}
+{%wodoc:end%}
 Ocsigen Server can be used either as a library for you OCaml programs, or as
 an executable, taking its configuration from a file (and with dynamic linking).
 
@@ -72,50 +78,50 @@ to serve static files, Deflatemod to compress the output, Redirectmod to
 configure redirections etc.
 
 Install Ocsigen Server with:
-{{{
+{v
 opam install ocsigenserver
-}}}
+v}
 
-===Use as a library===
+{2 Use as a library}
 
 Let's create a new OCaml project with Dune:
-{{{
+{v
 dune init project mysite
-}}}
+v}
 
 To include a Web server in your OCaml program, just add
-package {{{ocsigenserver}}} to your Dune file, together with all the extensions
-you need. For example, modify file {{{bin/dune}}} like this:
+package [ocsigenserver] to your Dune file, together with all the extensions
+you need. For example, modify file [bin/dune] like this:
 
-{{{
+{v
 (executable
  (public_name mysite)
  (name main)
  (libraries
   ocsigenserver
   ocsigenserver.ext.staticmod))
-}}}
+v}
 
 The following command will launch a server, serving static files from 
-directory {{{static}}}:
-<<code language="ocaml"|
+directory [static]:
+{@ocaml[
 let () = 
   Ocsigen_server.start [ Ocsigen_server.host [Staticmod.run ~dir:"static" ()]]
->>
-Put this in file {{{bin/main.ml}}}, and run {{{dune exec mysite}}}.
+]}
+Put this in file [bin/main.ml], and run [dune exec mysite].
 
-By default, the server runs on port 8080. Create a {{{static}}} directory
+By default, the server runs on port 8080. Create a [static] directory
 with some files and try to fetch them using your Web browser.
 
-===Use as an executable===
-Alternatively, you can run command {{{ocsigenserver}}} with a configuration
+{2 Use as an executable}
+Alternatively, you can run command [ocsigenserver] with a configuration
 file:
-{{{
+{v
 ocsigenserver -c mysite.conf
-}}}
+v}
 
 The following configuration file corresponds to the program above:
-{{{
+{v
 <ocsigen>
   <server>
     <port>8080</port>
@@ -125,27 +131,29 @@ The following configuration file corresponds to the program above:
     </host>
   </server>
 </ocsigen>
-}}}
+v}
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Eliom: Services==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Eliom: Services}
+{%wodoc:end%}
 The following code shows how to create a service that answers
-for requests at URL {{{http://.../aaa/bbb}}}, by invoking an
-Ocaml function {{{f}}} of type:
+for requests at URL [http://.../aaa/bbb], by invoking an
+Ocaml function [f] of type:
 
-<<code language="ocaml" |
+{@ocaml[
 
  f : (string * string) list -> unit -> string Lwt.t
 
->>
+]}
 
-Function {{{f}}} generates HTML as a string, taking as first argument the list
+Function [f] generates HTML as a string, taking as first argument the list
 of URL parameters (GET parameters), and as second argument the list of POST
 parameters (here none).
 
-<<code language="ocaml" |
+{@ocaml[
 
 let f _ () =
   Lwt.return "<html><head><title>Hello world</title></head><body>Welcome</body></html>"
@@ -160,47 +168,49 @@ let () =
   Eliom_registration.Html_text.register
     ~service:myservice
     f
->>
+]}
 
-{{{Eliom_service.Get Eliom_parameter.any}}} means that the service uses the GET HTTP method
-and takes any GET parameter. The first parameter of function {{{f}}} is an association list of GET parameters.
+[Eliom_service.Get Eliom_parameter.any] means that the service uses the GET HTTP method
+and takes any GET parameter. The first parameter of function [f] is an association list of GET parameters.
 
-Module {{{Eliom_registration.Html_text}}} is used to register a service sending
+Module [Eliom_registration.Html_text] is used to register a service sending
 HTML as strings. But we recommend to used typed-HTML instead (see below).
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Compiling==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Compiling}
+{%wodoc:end%}
 
-In this section, we will show how to compile and run a //server-side only// Web site by creating your project manually.
+In this section, we will show how to compile and run a {e server-side only} Web site by creating your project manually.
 
-===Build an executable===
+{2 Build an executable}
 This section shows how to create a static executable for you program
 (without configuration file).
 
 Run the following command:
-{{{
+{v
 opam install ocsipersist-sqlite-config eliom
 dune init project --kind=lib mysite
 cd mysite
-}}}
+v}
 
 Create the directories will we use for data (logs, etc.):
-{{{
+{v
 mkdir -p local/var/log/mysite
 mkdir -p local/var/data/mysite
 mkdir -p local/var/run
-}}}
+v}
 
-Add packages {{{ocsipersist-sqlite}}} and {{{eliom.server}}} to file
-{{{bin/dune}}}, in the "libraries" section.
+Add packages [ocsipersist-sqlite] and [eliom.server] to file
+[bin/dune], in the "libraries" section.
 
-Copy the definition and registration of service {{{myservice}}} at the beginning 
-of file {{{bin/main.ml}}},
-and replace the call to {{{Ocsigen_server.start}}} by the following lines:
+Copy the definition and registration of service [myservice] at the beginning 
+of file [bin/main.ml],
+and replace the call to [Ocsigen_server.start] by the following lines:
 
-<<code language="ocaml"|
+{@ocaml[
 let () = 
   Ocsigen_server.start 
     ~command_pipe:"local/var/run/mysite-cmd"
@@ -211,45 +221,45 @@ let () =
        [ Staticmod.run ~dir:"local/var/www/mysite" ()
        ; Eliom.run () ]
     ]
->>
+]}
 
 Build and execute the program with:
-{{{
+{v
 dune exec mysite
-}}}
+v}
 
-Open URL {{{http://localhost:8080/aaa/bbb}}} with your browser.
+Open URL [http://localhost:8080/aaa/bbb] with your browser.
 
-===Use with ocsigenserver===
+{2 Use with ocsigenserver}
 Alternatively, you can decide to build your Eliom app as a library and 
 load it dynamically into ocsigenserver using a configuration file.
 
-{{{
+{v
 opam install ocsipersist-sqlite-config eliom
 dune init proj --kind=lib mysite
 cd mysite
-}}}
+v}
 
-Add {{{(libraries eliom.server)}}} into file {{{lib/dune}}}.
+Add [(libraries eliom.server)] into file [lib/dune].
 
 Create the directories will we use for data (logs, etc.):
-{{{
+{v
 mkdir -p local/var/log/mysite
 mkdir -p local/var/data/mysite
 mkdir -p local/var/run
-}}}
+v}
 
-Create your {{{.ml}}} files in directory {{{lib}}}.
-For example, copy the definition and registration of service {{{myservice}}} above.
+Create your [.ml] files in directory [lib].
+For example, copy the definition and registration of service [myservice] above.
 
 Compile:
-{{{
+{v
 dune build
-}}}
+v}
 
-Create a configuration file {{{mysite.conf}}}
+Create a configuration file [mysite.conf]
 with this content on your project root directory:
-{{{
+{v
 <ocsigen>
   <server>
     <port>8080</port>
@@ -269,55 +279,48 @@ with this content on your project root directory:
     </host>
   </server>
 </ocsigen>
-}}}
+v}
 Launch the application:
-{{{
+{v
 ocsigenserver -c mysite.conf
-}}}
-Open URL {{{http://localhost:8080/aaa/bbb}}} with your browser.
->>
+v}
+Open URL [http://localhost:8080/aaa/bbb] with your browser.
+{%wodoc:end%}
 
 
-<<section class="docblock" |
-<<header |==TyXML: typing HTML==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 TyXML: typing HTML}
+{%wodoc:end%}
 
 TyXML statically checks that your OCaml functions will never
 generate wrong HTML. For example a program that could generate a paragraph
 containing another paragraph will be rejected at compile time.
 
 Example of use:
-<<code language="ocaml"|
+{@ocaml[
 let open Eliom_content.Html.F in
 html
   (head (title (txt "Ex")) [])
   (body [h1 ~a:[a_id "toto"; a_class ["blah"; "blih"]]
            [txt "Hallo!"]])
->>
+]}
 
-<<|From Eliom > 2.2
-(you can also use <<a_api project="eliom" subproject="server"|val Eliom_tools.F.html> > to ease the creation of the {{{head}}} tag.)
 
-(Eliom_tools.F.head
-    ~title:"Hello"
-    ~css:[["css";"style.css"]]
-    ~js:[["libjs";"mylib.js"];
-         ["libjs";"otherlib.js"]]
-    ())
->>
 
 
-<<div class="focused"|
-===How it works===
+{%wodoc:div class="focused"%}
+{2 How it works}
 
 TyXML builds the page as an OCaml data-structure using a construction function
 for each HTML tag. These functions take as parameters and return nodes
-of type {{{'a elt}}} where {{{'a}}} is a polymorphic variant type added in the
+of type ['a elt] where ['a] is a polymorphic variant type added in the
 module signature to constrain usage (phantom type).
->>
+{%wodoc:end%}
 
-===Example of typing error===
+{2 Example of typing error}
 
-<<code language="ocaml"|
+{@ocaml[
 p [p [txt "Aïe"]]
    ^^^^^^^^^^^^^
 Error: This expression has type
@@ -339,17 +342,19 @@ Error: This expression has type
             ...
             | `Wbr ]
        The second variant type does not allow tag(s) `P
->>
-Read more about TyXML in this [[html|short tutorial]] or in its [[wiki("tyxml"):|user manual]].
+]}
+Read more about TyXML in this {{:html.html}short tutorial} or in its {{:../tyxml/}user manual}.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Eliom: Service returning typed HTML==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Eliom: Service returning typed HTML}
+{%wodoc:end%}
 
-To use typed HTML, just replace module {{{Eliom_registration.Html_text}}}
-by  {{{Eliom_registration.Html}}}:
-<<code language="ocaml" |
+To use typed HTML, just replace module [Eliom_registration.Html_text]
+by  [Eliom_registration.Html]:
+{@ocaml[
 
 let f _ () =
   Lwt.return
@@ -366,73 +371,79 @@ let () =
   Eliom_registration.Html.register
     ~service:myservice
     f
->>
+]}
 
-===Outputs===
+{2 Outputs}
 
 Services can return a typed HTML page as in the example above, but also
 any other kind of result. To choose the return type, use the register function
 from the corresponding submodule of
-<<a_api project="eliom" | module Eliom_registration >>:
-
-<<div id="servicetable"|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Html"| module Eliom_registration.Html >>|@@colspan="3"@@Services returning typed HTML pages|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Html_text"| module Eliom_registration.Html >>|@@colspan="3"@@Services returning untyped HTML pages as strings|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="App"| module Eliom_registration.ELIOM_APPL >>|@@colspan="3"@@Apply this functor to generate registration functions for services belonging to an Eliom client/server application. These services also return typed HTML pages, but Eliom will automatically add the client-side program as a JS file, and all the data needed (values of all injections, etc.)|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Flow"| module Eliom_registration.Flow5 >>|@@colspan="3"@@Services returning portions of HTML pages.|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Action"| module Eliom_registration.Action >>|@@colspan="3"@@Services performing actions (server side effects) with or without reloading the page (e.g. login, logout, payment, modification of user information...)|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Files"| module Eliom_registration.File >>|@@colspan="3"@@Serve files from the server hard drive|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Ocaml"| module Eliom_registration.Ocaml >>|@@colspan="3"@@Services returning OCaml values to be sent to a client side OCaml program (this kind of services is used as low level interface for server functions -- see below)|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="String"| module Eliom_registration.String >>|@@colspan="3"@@Services returning any OCaml string (array of byte)|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Redirection"| module Eliom_registration.Redirection >>|@@colspan="3"@@Services returning an HTTP redirection to another service|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Any"| module Eliom_registration.Any >>|@@colspan="3"@@To be used to make the service chose what it sends. Call function {{{send}}} from the corresponding module to choose the output.|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Customize"| module Eliom_registration.Customize >>|@@colspan="3"@@Apply this functor to define your own registration module|
->>
->>
-
-<<section class="docblock" |
-<<header |==Eliom: Typing page parameters==>>
-
-Instead of taking GET parameters as an untyped {{{string * string}}}
+{!Eliom_registration}:
+
+{%wodoc:div%}
+{t
+ | {{!Eliom_registration.Html}Html} | Services returning typed HTML pages |
+ | {{!Eliom_registration.Html}Html_text} | Services returning untyped HTML pages as strings |
+ | {{!Eliom_registration.ELIOM_APPL}App} | Apply this functor to generate registration functions for services belonging to an Eliom client/server application. These services also return typed HTML pages, but Eliom will automatically add the client-side program as a JS file, and all the data needed (values of all injections, etc.) |
+ | {{!Eliom_registration.Flow5}Flow} | Services returning portions of HTML pages. |
+ | {{!Eliom_registration.Action}Action} | Services performing actions (server side effects) with or without reloading the page (e.g. login, logout, payment, modification of user information...) |
+ | {{!Eliom_registration.File}Files} | Serve files from the server hard drive |
+ | {{!Eliom_registration.Ocaml}Ocaml} | Services returning OCaml values to be sent to a client side OCaml program (this kind of services is used as low level interface for server functions -- see below) |
+ | {{!Eliom_registration.String}String} | Services returning any OCaml string (array of byte) |
+ | {{!Eliom_registration.Redirection}Redirection} | Services returning an HTTP redirection to another service |
+ | {{!Eliom_registration.Any}Any} | To be used to make the service chose what it sends. Call function [send] from the corresponding module to choose the output. |
+ | {{!Eliom_registration.Customize}Customize} | Apply this functor to define your own registration module |
+}
+{%wodoc:end%}
+{%wodoc:end%}
+
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Eliom: Typing page parameters}
+{%wodoc:end%}
+
+Instead of taking GET parameters as an untyped [string * string]
 association list, you can ask Eliom to decode and check parameter types
 automatically.
 
-For example, the following code defines a service at URL {{{/foo}}},
-that will use GET HTTP method, and take one parameter of type {{{string}}},
-named {{{s}}}, and one of type {{{int}}}, named {{{i}}}.
-<<code language="ocaml" class="server"|
+For example, the following code defines a service at URL [/foo],
+that will use GET HTTP method, and take one parameter of type [string],
+named [s], and one of type [int], named [i].
+{%wodoc:@ class=server%}
+{@ocaml[
 let myservice =
   Eliom_service.create
     ~path:(Eliom_service.Path ["foo"])
     ~meth:(Eliom_service.Get (Eliom_parameter.(string "s" ** int "i")))
     ()
->>
+]}
 
 Then register an OCaml function as handler on this service:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let () =
   Eliom_registration.Html.register ~service:myservice
     (fun (s, i) () ->
       Lwt.return
          Eliom_content.Html.F.(html (head (title (txt "")) [])
                                     (body [h1 [txt (s^string_of_int i)]])))
->>
+]}
 
 The handler takes as first parameter the GET page parameters, typed according to
 the parameter specification given while creating the service.
 The second parameter is for POST parameters (see below).
 
-Recompile you program, and to to URL {{{http://localhost:8080/foo?s=hello&i=22}}}
+Recompile you program, and to to URL [http://localhost:8080/foo?s=hello&i=22]
 to see the result.
 
-===Parameters===
+{2 Parameters}
 
-Module <<a_api project="eliom" subproject="server"| module Eliom_parameter>>
+Module {!Eliom_parameter}
 is used to describe the type of service parameters.
 
 Examples:
-<<code language="ocaml"|
+{@ocaml[
 Eliom_parameter.(int "i" ** (string "s" ** bool "b"))
    (* /path?i=42&s=toto&b=on *)
 
@@ -455,114 +466,122 @@ Eliom_parameter.(suffix (int "year" ** int "month"))
 Eliom_parameter.(suffix_prod (int "year" ** int "month") (int "a"))
    (* /path/2012/09?a=4 *)
 
->>
+]}
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Eliom: POST services==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Eliom: POST services}
+{%wodoc:end%}
 
-To define a service with POST parameters, just change the {{{~meth}}} parameter.
+To define a service with POST parameters, just change the [~meth] parameter.
 For example the following example takes the same GET parameters as the service
 above, plus one POST parameter of type string, named "mypostparam".
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 ~meth:(Eliom_service.Post (Eliom_parameter.((string "s" ** int "i"),
                                             (string "mypostparam"))))
->>
+]}
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Eliom: Other kinds of services==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Eliom: Other kinds of services}
+{%wodoc:end%}
 
-The detailed explanation of services can be found in <<a_manual project="eliom" chapter="server-services" |Eliom's manual>>. Here is a summary:
+The detailed explanation of services can be found in {{:../eliom/server-services.html}Eliom's manual}. Here is a summary:
 
-===Pathless services===
+{2 Pathless services}
 
 Pathless services are not identified by the path in the URL,
 but by a name given as parameter, regardless of the path.
 Use this to make a functionality available from all pages
 (for example: log-in or log-out actions, add something in a shopping basket ...).
 The name can be specified manually
-using the {{{~name}}} optional parameter, otherwise, a random name is
+using the [~name] optional parameter, otherwise, a random name is
 generated automatically.
 This is also used to implement server functions (see below).
 If you are programming a client-server Eliom app, you will often prefer
 remote procedure calls (`let%rpc`).
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let pathless_service =
   Eliom_service.create
     ~name:"pathless_example"
     ~path:Eliom_service.No_path
     ~meth:(Eliom_service.Get (Eliom_parameter.(int "i")))
     ()
->>
+]}
 
 More information
-<<a_manual project="eliom" chapter="server-services" fragment="pathless"|in the manual>>.
+{{:../eliom/server-services.html#pathless}in the manual}.
 
-===Attached services===
+{2 Attached services}
 It is also possible to create services identified by both a path and a
 special parameter, using functions
-<<a_api project="eliom" subproject="server"| val Eliom_service.create_attached_get >> or
-<<a_api project="eliom" subproject="server"| val Eliom_service.create_attached_post >>.
-They take a regular service (with a path) as parameter ({{{~fallback}}}).
+{!Eliom_service.create_attached_get} or
+{!Eliom_service.create_attached_post}.
+They take a regular service (with a path) as parameter ([~fallback]).
 
 It is also possible to attach an existing pathless service to the URL of
 another service, with function
-<<a_api project="eliom" subproject="server"| val Eliom_service.attach >>.
+{!Eliom_service.attach}.
 This allows for example to create a link towards a pathless service,
 but on another path.
 
-===External services===
-Use <<a_api project="eliom" subproject="server"| val Eliom_service.extern >> to create
+{2 External services}
+Use {!Eliom_service.extern} to create
 links or forms towards external Web sites as if they were Eliom services.
 
-===Predefined services===
-Use service <<a_api project="eliom" subproject="server" text="(Eliom_service.static_dir ())"| val Eliom_service.static_dir >>
+{2 Predefined services}
+Use service {{!Eliom_service.static_dir}(Eliom_service.static_dir ())}
 to create links towards static files (see example below for images).
 
-Use service <<a_api project="eliom" subproject="server"| val Eliom_service.reload_action >> and its variants to create links or forms towards the current URL (reload the page). From a client section, you can also call <<a_api project="ocsigen-start" subproject="server"| val Os_lib.reload>> to reload the page and restart the client-side program.
+Use service {!Eliom_service.reload_action} and its variants to create links or forms towards the current URL (reload the page). From a client section, you can also call {!Os_lib.reload} to reload the page and restart the client-side program.
 
-<<a_manual project="eliom" chapter="server-services" |Full documentation about services>>, [[interaction|a tutorial about traditional service based Web programming]], API documentation of modules <<a_api project="eliom" subproject="server" | module Eliom_service>> and <<a_api project="eliom" subproject="server" | module Eliom_registration>>.
+{{:../eliom/server-services.html}Full documentation about services}, {{:interaction.html}a tutorial about traditional service based Web programming}, API documentation of modules {!Eliom_service} and {!Eliom_registration}.
 
-This example shows how to insert an image using {{{static_dir}}}:
-<<code language="ocaml"|img
+This example shows how to insert an image using [static_dir]:
+{@ocaml[img
   ~alt:"blip"
   ~src:(Eliom_content.Html.F.make_uri
          (Eliom_service.static_dir ())
          ["dir" ; "image.jpg"])
   ()
->>
+]}
 
->>
+{%wodoc:end%}
 
 
-<<section class="docblock" |
-<<header |==Forms and links==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Forms and links}
+{%wodoc:end%}
 
-Function <<a_api project="eliom" subproject="server" text="Eliom_content.Html.F.a"|val Eliom_form_sigs.LINKS.a>> creates typed links to services with their parameters.
-For example, if {{{home_service}}} expects no parameter
-and {{{other_service}}} expects a string and an optional int:
-<<code language="ocaml"|
+Function {{!Eliom_form_sigs.LINKS.a}Eliom_content.Html.F.a} creates typed links to services with their parameters.
+For example, if [home_service] expects no parameter
+and [other_service] expects a string and an optional int:
+{@ocaml[
 Eliom_content.Html.F.a ~service:home_service [txt "Home"] ()
 Eliom_content.Html.F.a ~service:other_service [txt "Other"] ("hello", Some 4)
->>
+]}
 
-Module <<a_api project="eliom" subproject="server" |module Eliom_content.Html.F>>
+Module {!Eliom_content.Html.F}
 defines the form's elements with the usual typed interface from TyXML.
 Use this for example if you have a client side program and
 want to manipulate the form's content from client side functions
 (for example do a server function call with the form's elements' content).
 
 In contrast,
-module <<a_api project="eliom" subproject="server" text="Eliom_content.Html.F.Form"|module Eliom_content_sigs.LINKS_AND_FORMS.Form>> defines a typed interface
+module {{!Eliom_content_sigs.LINKS_AND_FORMS.Form}Eliom_content.Html.F.Form} defines a typed interface
 for form elements. Use this for links (see above), or if you program traditional
 server-side Web interaction (with or without client-side program). This will statically check that your forms
 match the services. Example:
 
-<<code language="ocaml"|
+{@ocaml[
 let open Eliom_content.Html.F in
 Form.post_form
  ~service:connection_service
@@ -580,111 +599,125 @@ Form.post_form
         Form.input ~input_type:`Submit ~value:"Connect" Form.string
       ]]) ()
 
->>
+]}
 
 As you can see, function
-<<a_api project="eliom" subproject="server" text="Eliom_content.Html.F.Form.post_form"|val Eliom_content_sigs.LINKS_AND_FORMS.Form.post_form>>
+{{!Eliom_content_sigs.LINKS_AND_FORMS.Form.post_form}Eliom_content.Html.F.Form.post_form}
 is used to create a form sending parameters using the POST HTTP method
-(and similarly, <<a_api project="eliom" subproject="server" text="get_form"|val Eliom_content_sigs.LINKS_AND_FORMS.Form.get_form>> for GET method).
+(and similarly, {{!Eliom_content_sigs.LINKS_AND_FORMS.Form.get_form}get_form} for GET method).
 It takes the service as first parameter, and a function that will generate the form.
 This function takes the names of the GET or POST parameters as arguments.
 
 Form elements (like inputs) are also built from using the
-<<a_api project="eliom" subproject="server" text="Eliom_content.Html.F.Form"|module Eliom_content_sigs.LINKS_AND_FORMS.Form>> module.
-They take the names as parameters, and a last parameter (like {{{Form.int}}} or {{{Form.string}}}) to match the expected type.
+{{!Eliom_content_sigs.LINKS_AND_FORMS.Form}Eliom_content.Html.F.Form} module.
+They take the names as parameters, and a last parameter (like [Form.int] or [Form.string]) to match the expected type.
 
->>
+{%wodoc:end%}
 
 
-<<section class="docblock" |
-<<header |==Sessions==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Sessions}
+{%wodoc:end%}
 
-Session data is saved on server side in //Eliom references//.
+Session data is saved on server side in {e Eliom references}.
 
 The following Eliom reference will count the number of visits of a user on a page:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server count_ref =
   Eliom_reference.eref
     ~scope:Eliom_common.default_session_scope
     0 (* default value for everyone *)
->>
+]}
 
 And somewhere in your service handler, increment the counter:
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%lwt count = Eliom_reference.get count_ref in
 Eliom_reference.set count_ref (count + 1);
 Lwt.return ()
->>
+]}
 
-With function <<a_api project="eliom" subproject="server"|val Eliom_reference.eref_from_fun>>,
+With function {!Eliom_reference.eref_from_fun},
 you can create Eliom references without initial value. The initial value is computed for the session
 the first time you use it.
 
 An Eliom reference can be persistant (value saved on hard drive) or volatile (in memory).
 
-===Scopes===
+{2 Scopes}
 Sessions are relative to a browser, and implemented using browser cookies.
-But Eliom allows to create Eliom references with other //scopes// than session:
+But Eliom allows to create Eliom references with other {e scopes} than session:
 
-|<<a_api project="eliom" subproject="server" text="global_scope"| val Eliom_common.global_scope>>|Global value for all the Web server|
-|<<a_api project="eliom" subproject="server" text="site_scope"| val Eliom_common.site_scope>>|Global value for the Eliom app in that subsite of the Web site|
-|<<a_api project="eliom" subproject="server" text="default_group_scope"| val Eliom_common.default_group_scope>>|Value for a group of sessions. For example Ocsigen Start defines a group of session for each user, making it possible to save server side data for all sessions of a user.|
-|<<a_api project="eliom" subproject="server" text="default_session_scope"| val Eliom_common.default_session_scope>>|The usual session data, based on browser cookies|
-|<<a_api project="eliom" subproject="server" text="default_process_scope"| val Eliom_common.default_process_scope>>|Server side data for a given client-side process (a tab of the browser or a mobile app). This is available only with a client-server Eliom app.|
+{t
+ | {{!Eliom_common.global_scope}global_scope} | Global value for all the Web server |
+ | {{!Eliom_common.site_scope}site_scope} | Global value for the Eliom app in that subsite of the Web site |
+ | {{!Eliom_common.default_group_scope}default_group_scope} | Value for a group of sessions. For example Ocsigen Start defines a group of session for each user, making it possible to save server side data for all sessions of a user. |
+ | {{!Eliom_common.default_session_scope}default_session_scope} | The usual session data, based on browser cookies |
+ | {{!Eliom_common.default_process_scope}default_process_scope} | Server side data for a given client-side process (a tab of the browser or a mobile app). This is available only with a client-server Eliom app. |
+}
 
 Applications based on Ocsigen Start use these scopes for user management.
 Session or client process data are discarded when a user logs in or out.
 But Ocsigen Start also defines scopes
-<<a_api project="ocsigen-start" subproject="server"| val Os_session.user_indep_session_scope>>
+{!Os_session.user_indep_session_scope}
 and
-<<a_api project="ocsigen-start" subproject="server"| val Os_session.user_indep_process_scope>>
+{!Os_session.user_indep_process_scope}
 which remain even if a user logs in or out.
 
 When session group is not set (for example the user is not connected),
 you can still use the group session scope: in that case, the group contains only
 one session.
 
->>
+{%wodoc:end%}
 
 
-<<section class="docblock" |
-<<header |==Browser events==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Browser events}
+{%wodoc:end%}
 By default, event handlers on HTML elements are given as OCaml functions,
 but it works only if you have a client-server Eliom program.
 If not, you want to give a javascript expression (as a string) instead.
-To so that, use attributes functions from module {{{Raw}}}. For example
-<<a_api project="eliom" subproject="server"| val Eliom_content.Html.F.Raw.a_onclick>>
+To so that, use attributes functions from module [Raw]. For example
+{!Eliom_content.Html.F.Raw.a_onclick}
 instead of
-<<a_api project="eliom" subproject="server"| val Eliom_content.Html.F.a_onclick>>.
+{!Eliom_content.Html.F.a_onclick}.
 
 Example:
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 Eliom_content.Html.F.(button ~a:[Raw.onclick "alert(\"beep\");"] [txt "click"])
->>
+]}
 
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Database access==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Database access}
+{%wodoc:end%}
 
 You can use your favourite database library with Ocsigen.
 Ocsigen Start's template uses
-[[https://github.com/darioteixeira/pgocaml|PG'OCaml]]
+{{:https://github.com/darioteixeira/pgocaml}PG'OCaml}
 (typed queries for Postgresql using a PPX syntax extension).
 
 Here is an example, taken from Ocsigen Start's demo:
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let get () =
   full_transaction_block (fun dbh ->
     [%pgsql dbh "SELECT lastname FROM ocsigen_start.users"])
->>
+]}
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Continuation-based Web programming==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Continuation-based Web programming}
+{%wodoc:end%}
 
 Eliom allows the dynamic creation of temporary services.
 This is equivalent to a programming pattern known as "continuation-based
@@ -718,91 +751,96 @@ page for this ticket.
 
 To implement temporary services, we usually use pathless or attached
 services (see above). To avoid a memory leak, you can make them temporary using
-optional parameters of the service creation function ({{{?max_use}}} or {{{?timeout}}}).
+optional parameters of the service creation function ([?max_use] or [?timeout]).
 
->>
+{%wodoc:end%}
 
 
-<<section class="docblock" |
-<<header |==Internationalisation==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Internationalisation}
+{%wodoc:end%}
 
-[[https://github.com/besport/ocsigen-i18n|Ocsigen i18n]]
+{{:https://github.com/besport/ocsigen-i18n}Ocsigen i18n}
 is an internationalisation library for your OCaml programs.
 
 Create a .tsv file with, on each line, a key and the text in several languages:
 
-{{{
+{v
 welcome_message Welcome everybody!        Bienvenue à tous !      Benvenuti a tutti !
-}}}
+v}
 
 and Ocsigen i18n will automatically generate functions like this one:
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%shared welcome_message ?(lang = get_language ()) () () =
   match lang with
   | En -> [txt "Welcome everybody!"]
   | Fr -> [txt "Bienvenue à tous !"]
   | It -> [txt "Benvenuti a tutti !"]
->>
+]}
 
 Ocsigen i18n also defines a syntax extension to use these functions:
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
   Eliom_content.Html.F.h1 [%i18n welcome_message]
->>
+]}
 
 Ocsigen i18n offers many other features:
-* Text can be inserted as a TyXML node (as in the example above) or as a string (ex: {{{[%i18n S.welcome_message]}}}),
-* Text can be parametrizable, or contain holes (ex: {{{[%i18n welcome ~capitalize:true ~name:"William"]}}})
-* .tsv file can be split into several modules
+- Text can be inserted as a TyXML node (as in the example above) or as a string (ex: [[%i18n S.welcome_message]]),
+- Text can be parametrizable, or contain holes (ex: [[%i18n welcome ~capitalize:true ~name:"William"]])
+- .tsv file can be split into several modules
 
 Have a look at the
-[[https://github.com/besport/ocsigen-i18n|README file]]
+{{:https://github.com/besport/ocsigen-i18n}README file}
 to see the full documentation,
 and see examples in
-[[https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/demo_i18n.eliom|Ocsigen Start's template]].
+{{:https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/demo_i18n.eliom}Ocsigen Start's template}.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Ocsigen Server==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Ocsigen Server}
+{%wodoc:end%}
 
-//Ocsigen Server// is a full featured Web server.
+{e Ocsigen Server} is a full featured Web server.
 
-It is now based on [[https://github.com/mirage/ocaml-cohttp|Cohttp]].
+It is now based on {{:https://github.com/mirage/ocaml-cohttp}Cohttp}.
 
 It has a powerful
 extension mechanism that makes it easy to plug your own OCaml modules
 for generating pages. Many extensions are already written:
-;<<a_manual project="ocsigenserver" chapter="staticmod"|Staticmod>>
+;{{:../ocsigenserver/staticmod.html}Staticmod}
 :    to serve static files.
-;[[wiki("eliom"):|Eliom]]
+;{{:../eliom/}Eliom}
 :    to create reliable client/server Web applications
      or Web sites in OCaml using advanced high level concepts.
-;<<a_manual project="ocsigenserver" chapter="extendconfiguration"|Extendconfiguration>>
+;{{:../ocsigenserver/extendconfiguration.html}Extendconfiguration}
 :    allows for more options in the configuration file.
-;<<a_manual project="ocsigenserver" chapter="accesscontrol"|Accesscontrol>>
+;{{:../ocsigenserver/accesscontrol.html}Accesscontrol}
 :    restricts access to the sites from the config file (to requests coming from a subnet, containing some headers, etc.).
-;<<a_manual project="ocsigenserver" chapter="authbasic"|Authbasic>>
+;{{:../ocsigenserver/authbasic.html}Authbasic}
 :    restricts access to the sites from the config file using Basic HTTP Authentication.
-;<<a_manual project="ocsigenserver" chapter="cgimod"|CGImod>>
+;{{:../ocsigenserver/cgimod.html}CGImod}
 :    serves CGI scripts. It may also be used to serve PHP through CGI.
-;<<a_manual project="ocsigenserver" chapter="deflatemod"|Deflatemod>>
+;{{:../ocsigenserver/deflatemod.html}Deflatemod}
 :    used to compress data before sending it to the client.
-;<<a_manual project="ocsigenserver" chapter="redirectmod"|Redirectmod>>
+;{{:../ocsigenserver/redirectmod.html}Redirectmod}
 :    sets redirections towards other Web sites from the configuration file.
-;<<a_manual project="ocsigenserver" chapter="revproxy"|Revproxy>>
+;{{:../ocsigenserver/revproxy.html}Revproxy}
 :    a reverse proxy for Ocsigen Server.
       It allows to ask another server to handle the request.
-;<<a_manual project="ocsigenserver" chapter="rewritemod"|Rewritemod>>
+;{{:../ocsigenserver/rewritemod.html}Rewritemod}
 :    changes incoming requests before sending them to other extensions.
-;<<a_manual project="ocsigenserver" chapter="outputfilter"|Outputfilter>>
+;{{:../ocsigenserver/outputfilter.html}Outputfilter}
 :    rewrites some parts of the output before sending it to the client.
-;<<a_manual project="ocsigenserver" chapter="userconf"|Userconf>>
+;{{:../ocsigenserver/userconf.html}Userconf}
 :    allows users to have their own configuration files.
-;<<a_manual project="ocsigenserver" chapter="comet"|Comet>>
+;{{:../ocsigenserver/comet.html}Comet}
 :    facilitates server to client communications.
 
-Ocsigen Server has a <<a_manual project="ocsigenserver"
-chapter="config"|sophisticated configuration>> file mechanism allowing
+Ocsigen Server has a {{:../ocsigenserver/config.html}sophisticated configuration} file mechanism allowing
 complex configurations of sites.
 
->>
+{%wodoc:end%}
diff --git a/tutos/8.0/manual/basics.wiki b/tutos/8.0/manual/basics.mld
similarity index 52%
rename from tutos/8.0/manual/basics.wiki
rename to tutos/8.0/manual/basics.mld
index 51aa5913..d4d4e653 100644
--- a/tutos/8.0/manual/basics.wiki
+++ b/tutos/8.0/manual/basics.mld
@@ -1,4 +1,4 @@
-=Client-server application programming guide=
+{0 Client-server application programming guide}
 
 This tutorial has been tested with Eliom 11.0.0.
 
@@ -7,43 +7,47 @@ with Ocsigen. Use it as your training plan or as a cheat sheet while programming
 
 Depending on your needs, you may not need to learn all this. Ocsigen is
 very flexible and can be used both for Web site programming (see
-[[basics-server|this page]]) or more complex client-server Web apps and
+{{:basics-server.html}this page}) or more complex client-server Web apps and
 their mobile counterparts.
 
 In parallel to the reading of that page,
-we recommend to generate your first [[wiki("ocsigen-start"):|Ocsigen Start]] app to see
-running examples of all these concepts (see [[start|that page]]).
+we recommend to generate your first {{:../ocsigen-start/}Ocsigen Start} app to see
+running examples of all these concepts (see {{:start.html}that page}).
 
-<<div class="quickstart-block"|
-**Too long; didn't read? Get your first app running in 3 minutes:**
-{{{
+{%wodoc:div class="quickstart-block"%}
+{b Too long; didn't read? Get your first app running in 3 minutes:}
+{v
 opam install ocsigen-start
 eliom-distillery -name myapp -template os.pgocaml
 cd myapp
 make db-init && make db-create && make db-schema
 make test.byte
-}}}
-Then open {{{http://localhost:8080}}}. \\
-Requires {{{postgresql}}} and {{{sass}}} (or {{{sassc}}}).
-Read the [[start|detailed instructions]] if needed.
->>
+v}
+Then open [http://localhost:8080]. {%html:<br/>%}
+Requires [postgresql] and [sass] (or [sassc]).
+Read the {{:start.html}detailed instructions} if needed.
+{%wodoc:end%}
 
-<<outline| <<header| **Table of contents** >> >>
 
-<<section class="docblock" |
-<<header |==OCaml==>>
 
-This programming guide assumes you know the //OCaml// language.
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 OCaml}
+{%wodoc:end%}
+
+This programming guide assumes you know the {e OCaml} language.
 Many resources and books are available online.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Lwt==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Lwt}
+{%wodoc:end%}
 
-//Lwt// is a concurrent programming library for OCaml, initially written
+{e Lwt} is a concurrent programming library for OCaml, initially written
 by Jérôme Vouillon in 2001 for the
-[[https://github.com/bcpierce00/unison|Unison]] file synchronizer.
+{{:https://github.com/bcpierce00/unison}Unison} file synchronizer.
 It provides an alternative to the more usual preemptive threads approach
 for programming concurrent applications, that avoids most problems of concurrent
 data access and deadlocks.
@@ -51,29 +55,31 @@ It is used by Ocsigen Server and Eliom and has now become one of the
 standard ways to implement concurrent applications in OCaml.
 All your Web sites must be written in Lwt-compatible way!
 
-<<div class="focused"|
-===How it works===
-Instead of calling blocking functions, like {{{Unix.sleep}}}
-or {{{Unix.read}}}, that could block the entire program, replace them
-by their cooperative counterparts ({{{Lwt_unix.sleep}}},
-{{{Lwt_unix.read}}}, etc.). Instead of taking time to execute,
-they always return immediately a //promise// of the result,
-of type {{{'a Lwt.t}}}. This type is abstract, and the only way
-to use the result is to //bind// a function to the promise.
-{{{Lwt.bind p f}}} means: "when promise {{{p}}} is completed, give its result
-to function {{{f}}}".
-
-Syntax {{{let%lwt x = p in e}}} is equivalent to {{{Lwt.bind p (fun x -> e)}}}
+{%wodoc:div class="focused"%}
+{2 How it works}
+Instead of calling blocking functions, like [Unix.sleep]
+or [Unix.read], that could block the entire program, replace them
+by their cooperative counterparts ([Lwt_unix.sleep],
+[Lwt_unix.read], etc.). Instead of taking time to execute,
+they always return immediately a {e promise} of the result,
+of type ['a Lwt.t]. This type is abstract, and the only way
+to use the result is to {e bind} a function to the promise.
+[Lwt.bind p f] means: "when promise [p] is completed, give its result
+to function [f]".
+
+Syntax [let%lwt x = p in e] is equivalent to [Lwt.bind p (fun x -> e)]
 and makes it very natural to sequentialize computations without blocking the rest
 of the program.
->>
+{%wodoc:end%}
 
-To learn Lwt, read this [[lwt|short tutorial]], or its [[wiki("lwt"):|user manual]].
+To learn Lwt, read this {{:lwt.html}short tutorial}, or its {{:../lwt/}user manual}.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Ocsigen Server: A full featured extensible Web server in OCaml==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Ocsigen Server: A full featured extensible Web server in OCaml}
+{%wodoc:end%}
 Ocsigen Server can be used either as a library for you OCaml programs, or as
 an executable, taking its configuration from a file (and with dynamic linking).
 
@@ -82,50 +88,50 @@ to serve static files, Deflatemod to compress the output, Redirectmod to
 configure redirections etc.
 
 Install Ocsigen Server with:
-{{{
+{v
 opam install ocsigenserver
-}}}
+v}
 
-===Use as a library===
+{2 Use as a library}
 
 Let's create a new OCaml project with Dune:
-{{{
+{v
 dune init project mysite
-}}}
+v}
 
 To include a Web server in your OCaml program, just add
-package {{{ocsigenserver}}} to your Dune file, together with all the extensions
-you need. For example, modify file {{{bin/dune}}} like this:
+package [ocsigenserver] to your Dune file, together with all the extensions
+you need. For example, modify file [bin/dune] like this:
 
-{{{
+{v
 (executable
  (public_name mysite)
  (name main)
  (libraries
   ocsigenserver
   ocsigenserver.ext.staticmod))
-}}}
+v}
 
 The following command will launch a server, serving static files from 
-directory {{{static}}}:
-<<code language="ocaml"|
+directory [static]:
+{@ocaml[
 let () = 
   Ocsigen_server.start [ Ocsigen_server.host [Staticmod.run ~dir:"static" ()]]
->>
-Put this in file {{{bin/main.ml}}}, and run {{{dune exec mysite}}}.
+]}
+Put this in file [bin/main.ml], and run [dune exec mysite].
 
-By default, the server runs on port 8080. Create a {{{static}}} directory
+By default, the server runs on port 8080. Create a [static] directory
 with some files and try to fetch them using your Web browser.
 
-===Use as an executable===
-Alternatively, you can run command {{{ocsigenserver}}} with a configuration
+{2 Use as an executable}
+Alternatively, you can run command [ocsigenserver] with a configuration
 file:
-{{{
+{v
 ocsigenserver -c mysite.conf
-}}}
+v}
 
 The following configuration file corresponds to the program above:
-{{{
+{v
 <ocsigen>
   <server>
     <port>8080</port>
@@ -135,50 +141,43 @@ The following configuration file corresponds to the program above:
     </host>
   </server>
 </ocsigen>
-}}}
+v}
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==TyXML: typing HTML==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 TyXML: typing HTML}
+{%wodoc:end%}
 
 TyXML statically checks that your OCaml functions will never
 generate wrong HTML. For example a program that could generate a paragraph
 containing another paragraph will be rejected at compile time.
 
 Example of use:
-<<code language="ocaml"|
+{@ocaml[
 let open Eliom_content.Html.D in
 html
   (head (title (txt "Ex")) [])
   (body [h1 ~a:[a_id "toto"; a_class ["blah"; "blih"]]
            [txt "Hallo!"]])
->>
+]}
 
-<<|From Eliom > 2.2
-(you can also use <<a_api project="eliom" subproject="server"|val Eliom_tools.D.html> > to ease the creation of the {{{head}}} tag.)
 
-(Eliom_tools.F.head
-    ~title:"Hello"
-    ~css:[["css";"style.css"]]
-    ~js:[["libjs";"mylib.js"];
-         ["libjs";"otherlib.js"]]
-    ())
->>
 
 
-<<div class="focused"|
-===How it works===
+{%wodoc:div class="focused"%}
+{2 How it works}
 
 TyXML builds the page as an OCaml data-structure using a construction function
 for each HTML tag. These functions take as parameters and return nodes
-of type {{{'a elt}}} where {{{'a}}} is a polymorphic variant type added in the
+of type ['a elt] where ['a] is a polymorphic variant type added in the
 module signature to constrain usage (phantom type).
->>
+{%wodoc:end%}
 
-===Example of typing error===
+{2 Example of typing error}
 
-<<code language="ocaml"|
+{@ocaml[
 p [p [txt "Aïe"]]
    ^^^^^^^^^^^^^
 Error: This expression has type
@@ -200,72 +199,78 @@ Error: This expression has type
             ...
             | `Wbr ]
        The second variant type does not allow tag(s) `P
->>
-Read more about TyXML in this [[html|short tutorial]] or in its [[wiki("tyxml"):|user manual]].
+]}
+Read more about TyXML in this {{:html.html}short tutorial} or in its {{:../tyxml/}user manual}.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Eliom: Services==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Eliom: Services}
+{%wodoc:end%}
 
-Pages are generated by //services//.
+Pages are generated by {e services}.
 Eliom provides a very simple (yet extremely powerful) service creation and identification mechanism.
 
-To create a service, call <<a_api project="eliom" subproject="server"| val Eliom_service.create>>.
-For example, the following code defines a service at URL {{{/foo}}},
-that will use GET HTTP method, and take one parameter of type {{{string}}},
-named {{{myparam}}}, and one of type {{{int}}}, named {{{i}}}.
-<<code language="ocaml" class="server"|
+To create a service, call {!Eliom_service.create}.
+For example, the following code defines a service at URL [/foo],
+that will use GET HTTP method, and take one parameter of type [string],
+named [myparam], and one of type [int], named [i].
+{%wodoc:@ class=server%}
+{@ocaml[
 let myservice =
   Eliom_service.create
     ~path:(Eliom_service.Path ["foo"])
     ~meth:(Eliom_service.Get (Eliom_parameter.(string "myparam" ** int "i")))
     ()
->>
+]}
 
 Then register an OCaml function as handler on this service:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let () =
   Eliom_registration.Html.register ~service:myservice
     (fun (myparam, _i) () ->
       Lwt.return
          Eliom_content.Html.F.(html (head (title (txt "")) [])
                                     (body [h1 [txt myparam]])))
->>
+]}
 
 The handler takes as first parameter the GET page parameters, typed according to
 the parameter specification given while creating the service.
 The second parameter is for POST parameters (see below).
 
-===Outputs===
+{2 Outputs}
 
 Services can return a typed HTML page as in the example above, but also
 any other kind of result. To choose the return type, use the register function
 from the corresponding submodule of
-<<a_api project="eliom" | module Eliom_registration >>:
-
-<<div id="servicetable"|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Html"| module Eliom_registration.Html >>|@@colspan="3"@@Services returning typed HTML pages|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Html_text"| module Eliom_registration.Html >>|@@colspan="3"@@Services returning untyped HTML pages as strings|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="App"| module Eliom_registration.ELIOM_APPL >>|@@colspan="3"@@Apply this functor to generate registration functions for services belonging to an Eliom client/server application. These services also return typed HTML pages, but Eliom will automatically add the client-side program as a JS file, and all the data needed (values of all injections, etc.)|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Flow"| module Eliom_registration.Flow5 >>|@@colspan="3"@@Services returning portions of HTML pages.|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Action"| module Eliom_registration.Action >>|@@colspan="3"@@Services performing actions (server side effects) with or without reloading the page (e.g. login, logout, payment, modification of user information...)|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Files"| module Eliom_registration.File >>|@@colspan="3"@@Serve files from the server hard drive|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Ocaml"| module Eliom_registration.Ocaml >>|@@colspan="3"@@Services returning OCaml values to be sent to a client side OCaml program (this kind of services is used as low level interface for server functions -- see below)|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="String"| module Eliom_registration.String >>|@@colspan="3"@@Services returning any OCaml string (array of byte)|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Redirection"| module Eliom_registration.Redirection >>|@@colspan="3"@@Services returning an HTTP redirection to another service|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Any"| module Eliom_registration.Any >>|@@colspan="3"@@To be used to make the service chose what it sends. Call function {{{send}}} from the corresponding module to choose the output.|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Customize"| module Eliom_registration.Customize >>|@@colspan="3"@@Apply this functor to define your own registration module|
->>
-
-===Parameters===
-
-Module <<a_api project="eliom" subproject="server"| module Eliom_parameter>>
+{!Eliom_registration}:
+
+{%wodoc:div%}
+{t
+ | {{!Eliom_registration.Html}Html} | Services returning typed HTML pages |
+ | {{!Eliom_registration.Html}Html_text} | Services returning untyped HTML pages as strings |
+ | {{!Eliom_registration.ELIOM_APPL}App} | Apply this functor to generate registration functions for services belonging to an Eliom client/server application. These services also return typed HTML pages, but Eliom will automatically add the client-side program as a JS file, and all the data needed (values of all injections, etc.) |
+ | {{!Eliom_registration.Flow5}Flow} | Services returning portions of HTML pages. |
+ | {{!Eliom_registration.Action}Action} | Services performing actions (server side effects) with or without reloading the page (e.g. login, logout, payment, modification of user information...) |
+ | {{!Eliom_registration.File}Files} | Serve files from the server hard drive |
+ | {{!Eliom_registration.Ocaml}Ocaml} | Services returning OCaml values to be sent to a client side OCaml program (this kind of services is used as low level interface for server functions -- see below) |
+ | {{!Eliom_registration.String}String} | Services returning any OCaml string (array of byte) |
+ | {{!Eliom_registration.Redirection}Redirection} | Services returning an HTTP redirection to another service |
+ | {{!Eliom_registration.Any}Any} | To be used to make the service chose what it sends. Call function [send] from the corresponding module to choose the output. |
+ | {{!Eliom_registration.Customize}Customize} | Apply this functor to define your own registration module |
+}
+{%wodoc:end%}
+
+{2 Parameters}
+
+Module {!Eliom_parameter}
 is used to describe the type of service parameters.
 
 Examples:
-<<code language="ocaml"|
+{@ocaml[
 Eliom_parameter.(int "i" ** (string "s" ** bool "b"))
    (* /path?i=42&s=toto&b=on *)
 
@@ -288,23 +293,24 @@ Eliom_parameter.(suffix (int "year" ** int "month"))
 Eliom_parameter.(suffix_prod (int "year" ** int "month") (int "a"))
    (* /path/2012/09?a=4 *)
 
->>
+]}
 
-===POST services===
+{2 POST services}
 
-To define a service with POST parameters, just change the {{{~meth}}} parameter.
+To define a service with POST parameters, just change the [~meth] parameter.
 For example the following example takes the same GET parameters as the service
 above, plus one POST parameter of type string, named "mypostparam".
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 ~meth:(Eliom_service.Post (Eliom_parameter.((string "myparam" ** int "i"),
                                             (string "mypostparam"))))
->>
+]}
 
-===Pathless services===
+{2 Pathless services}
 
 Pathless services are not identified by the path in the URL,
 but by a name given as parameter. This name can be specified manually
-using the {{{~name}}} optional parameter, otherwise, a random name is
+using the [~name] optional parameter, otherwise, a random name is
 generated automatically.
 This is used to implement server functions (see below).
 If you are programming a client-server Eliom app, you will probably prefer server functions.
@@ -312,72 +318,75 @@ If you are using traditional service based Web programming,
 use this to make a functionality available from all pages
 (for example: log-in or log-out actions, add something in a shopping basket ...).
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let pathless_service =
   Eliom_service.create
     ~name:"pathless_example"
     ~path:Eliom_service.No_path
     ~meth:(Eliom_service.Get (Eliom_parameter.(int "i")))
     ()
->>
+]}
 
 More information
-<<a_manual project="eliom" chapter="server-services" fragment="pathless"|in the manual>>.
+{{:../eliom/server-services.html#pathless}in the manual}.
 
-===External services===
-Use <<a_api project="eliom" subproject="server"| val Eliom_service.extern >> to create
+{2 External services}
+Use {!Eliom_service.extern} to create
 links or forms towards external Web sites as if they were Eliom services.
 
-===Predefined services===
-Use service <<a_api project="eliom" subproject="server" text="(Eliom_service.static_dir ())"| val Eliom_service.static_dir >>
+{2 Predefined services}
+Use service {{!Eliom_service.static_dir}(Eliom_service.static_dir ())}
 to create links towards static files (see example below for images).
 
-Use service <<a_api project="eliom" subproject="server"| val Eliom_service.reload_action >> and its variants to create links or forms towards the current URL (reload the page). From a client section, you can also call <<a_api project="ocsigen-start" subproject="server"| val Os_lib.reload>> to reload the page and restart the client-side program.
+Use service {!Eliom_service.reload_action} and its variants to create links or forms towards the current URL (reload the page). From a client section, you can also call {!Os_lib.reload} to reload the page and restart the client-side program.
 
-<<a_manual project="eliom" chapter="server-services" |Full documentation about services>>, [[interaction|a tutorial about traditional service based Web programming]], API documentation of modules <<a_api project="eliom" subproject="server" | module Eliom_service>> and <<a_api project="eliom" subproject="server" | module Eliom_registration>>.
+{{:../eliom/server-services.html}Full documentation about services}, {{:interaction.html}a tutorial about traditional service based Web programming}, API documentation of modules {!Eliom_service} and {!Eliom_registration}.
 
-This example shows how to insert an image using {{{static_dir}}}:
-<<code language="ocaml"|img
+This example shows how to insert an image using [static_dir]:
+{@ocaml[img
   ~alt:"blip"
   ~src:(Eliom_content.Html.F.make_uri
          (Eliom_service.static_dir ())
          ["dir" ; "image.jpg"])
   ()
->>
+]}
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Compiling==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Compiling}
+{%wodoc:end%}
 
-In this section, we will show how to compile and run a //server-side only// Web site by creating your project manually.
+In this section, we will show how to compile and run a {e server-side only} Web site by creating your project manually.
 
-===Build an executable===
+{2 Build an executable}
 This section shows how to create a static executable for you program
 (without configuration file).
 
 Run the following commands:
-{{{
+{v
 opam install ocsipersist-sqlite-config eliom
 dune init project --kind=executable mysite
 cd mysite
-}}}
+v}
 
 Create the directories will we use for data (logs, etc.):
-{{{
+{v
 mkdir -p local/var/log/mysite
 mkdir -p local/var/data/mysite
 mkdir -p local/var/run
-}}}
+v}
 
-Add packages {{{ocsipersist-sqlite}}} and {{{eliom.server}}} to file
-{{{bin/dune}}}, in the "libraries" section.
+Add packages [ocsipersist-sqlite] and [eliom.server] to file
+[bin/dune], in the "libraries" section.
 
-Copy the definition and registration of service {{{myservice}}} at the beginning 
-of file {{{bin/main.ml}}},
-and replace the call to {{{Ocsigen_server.start}}} by the following lines:
+Copy the definition and registration of service [myservice] at the beginning 
+of file [bin/main.ml],
+and replace the call to [Ocsigen_server.start] by the following lines:
 
-<<code language="ocaml"|
+{@ocaml[
 let () = 
   Ocsigen_server.start 
     ~command_pipe:"local/var/run/mysite-cmd"
@@ -389,45 +398,45 @@ let () =
        [ Staticmod.run ~dir:"local/var/www/mysite" ()
        ; Eliom.run () ]
     ]
->>
+]}
 
 Build and execute the program with:
-{{{
+{v
 dune exec mysite
-}}}
+v}
 
-Open URL {{{http://localhost:8080/foo?myparam=Hello&i=27}}} with your browser.
+Open URL [http://localhost:8080/foo?myparam=Hello&i=27] with your browser.
 
-===Use with ocsigenserver===
+{2 Use with ocsigenserver}
 Alternatively, you can decide to build your Eliom app as a library and 
 load it dynamically into ocsigenserver using a configuration file.
 
-{{{
+{v
 opam install ocsipersist-sqlite-config eliom
 dune init project --kind=lib mysite
 cd mysite
-}}}
+v}
 
-Add {{{(libraries eliom.server)}}} into file {{{lib/dune}}}.
+Add [(libraries eliom.server)] into file [lib/dune].
 
-Create your {{{.ml}}} files in directory {{{lib}}}.
-For example, copy the definition and registration of service {{{myservice}}} above.
+Create your [.ml] files in directory [lib].
+For example, copy the definition and registration of service [myservice] above.
 
 Create the directories will we use for data (logs, etc.):
-{{{
+{v
 mkdir -p local/var/log/mysite
 mkdir -p local/var/data/mysite
 mkdir -p local/var/run
-}}}
+v}
 
 Compile:
-{{{
+{v
 dune build
-}}}
+v}
 
-Create a configuration file {{{mysite.conf}}}
+Create a configuration file [mysite.conf]
 with this content on your project root directory:
-{{{
+{v
 <ocsigen>
   <server>
     <port>8080</port>
@@ -447,88 +456,94 @@ with this content on your project root directory:
     </host>
   </server>
 </ocsigen>
-}}}
+v}
 Launch the application:
-{{{
+{v
 ocsigenserver -c mysite.conf
-}}}
-Open URL {{{http://localhost:8080/foo?myparam=Hello&i=27}}} with your browser.
->>
+v}
+Open URL [http://localhost:8080/foo?myparam=Hello&i=27] with your browser.
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Forms and links==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Forms and links}
+{%wodoc:end%}
 
-Functions <<a_api project="eliom" subproject="server" text="Eliom_content.Html.F.a"|val Eliom_form_sigs.LINKS.a>> and
-<<a_api project="eliom" subproject="server" text="D.a"|val Eliom_form_sigs.LINKS.a>>
+Functions {{!Eliom_form_sigs.LINKS.a}Eliom_content.Html.F.a} and
+{{!Eliom_form_sigs.LINKS.a}D.a}
 create typed links to services with their parameters.
-For example, if {{{home_service}}} expects no parameter
-and {{{other_service}}} expects a string and an optional int:
-<<code language="ocaml"|
+For example, if [home_service] expects no parameter
+and [other_service] expects a string and an optional int:
+{@ocaml[
 Eliom_content.Html.D.a ~service:home_service [txt "Home"] ()
 Eliom_content.Html.D.a ~service:other_service [txt "Other"] ("hello", Some 4)
->>
+]}
 
-Modules <<a_api project="eliom" subproject="server" |module Eliom_content.Html.F>> and
-<<a_api project="eliom" subproject="server" text="D"|module Eliom_content.Html.D>>
+Modules {!Eliom_content.Html.F} and
+{{!Eliom_content.Html.D}D}
 define the form's elements with the usual typed interface from TyXML.
 Use this for example if you have a client side program and
 want to manipulate the form's content from client side functions
 (for example do a server function call with the form's elements' content).
 
 In contrast,
-modules <<a_api project="eliom" subproject="server" text="Eliom_content.Html.F.Form"|module Eliom_content_sigs.LINKS_AND_FORMS.Form>> and
-<<a_api project="eliom" subproject="server" text="D.Form"|module Eliom_content_sigs.LINKS_AND_FORMS.Form>>
+modules {{!Eliom_content_sigs.LINKS_AND_FORMS.Form}Eliom_content.Html.F.Form} and
+{{!Eliom_content_sigs.LINKS_AND_FORMS.Form}D.Form}
 define a typed interface
 for form elements. Use this for links (see above), or if you program traditional
 server-side Web interaction (with or without client-side program). This will statically check that your forms
 match the services. See more information in the
-<<a_manual project="tuto" chapter="basics-server"|server-side programming manual>>.
+{{:../tuto/basics-server.html}server-side programming manual}.
 
->>
-<<section class="docblock" |
-<<header |==Js_of_ocaml==>>
+{%wodoc:end%}
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Js_of_ocaml}
+{%wodoc:end%}
 
-//Js_of_ocaml// is a compiler of OCaml bytecode to JavaScript,
+{e Js_of_ocaml} is a compiler of OCaml bytecode to JavaScript,
 allowing to run Ocaml programs in a Web browser.
 Its key features are the following:
-* The whole language, and most of the standard library are supported.
-* You can use a standard installation of OCaml to compile your programs. In particular, you do not have to recompile a library to use it with Js_of_ocaml.
-* It comes with a library to interface with the browser API.
+- The whole language, and most of the standard library are supported.
+- You can use a standard installation of OCaml to compile your programs. In particular, you do not have to recompile a library to use it with Js_of_ocaml.
+- It comes with a library to interface with the browser API.
 
-**WebAssembly:** OCaml programs can also be compiled to WebAssembly using
-//wasm_of_ocaml//. Eliom provides automatic browser detection: if WebAssembly
+{b WebAssembly:} OCaml programs can also be compiled to WebAssembly using
+{e wasm_of_ocaml}. Eliom provides automatic browser detection: if WebAssembly
 is supported, the WASM version is loaded, otherwise it falls back to JavaScript.
 
 Interaction with Javascript can be done:
-* either with untyped function calls (module {{{Js.Unsafe}}}),
-* or you can generate an interface just by writing an annotated {{{.mli}}}
-using [[https://github.com/LexiFi/gen_js_api|Gen_js_api]],
-* or you use a syntax extension to generate typed calls, using a
-{{{.mli}}} file describing Javascript objects
+- either with untyped function calls (module [Js.Unsafe]),
+- or you can generate an interface just by writing an annotated [.mli]
+using {{:https://github.com/LexiFi/gen_js_api}Gen_js_api},
+- or you use a syntax extension to generate typed calls, using a
+[.mli] file describing Javascript objects
 with OCaml class types as phantom types.
 
 The latter is used for the default Javascript library. Here is how it works:
 
-|{{{obj##.m}}}|access a JS property (has type {{{u}}} when {{{obj : <m : u prop> Js.t}}})|
-|{{{obj##.m := e}}}|change a JS property (when {{{obj : <m : u prop> Js.t}}} and {{{e:u}}})|
-|{{{obj##m e_1 ... e_n}}}|call a JS method (has type {{{u}}} when {{{obj : <m : t_1 -> ... -> t_n -> u meth; ..> Js.t}}} and {{{e_i : t_i}}})|
-|{{{new%js constr e1 ... en}}}|create a JS object (has type {{{u Js.t}}} when {{{constr : (t_1 -> ... -> t_n -> u Js.t) Js.constr}}} and {{{e_i : t_i}}})|
+{t
+ | [obj##.m] | access a JS property (has type [u] when [obj : <m : u prop> Js.t]) |
+ | [obj##.m := e] | change a JS property (when [obj : <m : u prop> Js.t] and [e:u]) |
+ | [obj##m e_1 ... e_n] | call a JS method (has type [u] when [obj : <m : t_1 -> ... -> t_n -> u meth; ..> Js.t] and [e_i : t_i]) |
+ | [new%js constr e1 ... en] | create a JS object (has type [u Js.t] when [constr : (t_1 -> ... -> t_n -> u Js.t) Js.constr] and [e_i : t_i]) |
+}
 
-Module <<a_api project="js_of_ocaml" |module Js_of_ocaml.Js>>
+Module {!Js_of_ocaml.Js}
 defines the base JS types and conversion functions from/to OCaml types.
-Example: {{{Js.Opt}}} to take into account nullable values, {{{Js.Optdef}}} for undefined values,
-or functions like {{{Js.to_string}}} and {{{Js.string}}} for consersions to and from
+Example: [Js.Opt] to take into account nullable values, [Js.Optdef] for undefined values,
+or functions like [Js.to_string] and [Js.string] for consersions to and from
 OCaml strings.
 
-Use modules <<a_api project="js_of_ocaml" |module Js_of_ocaml.Dom>>
-and <<a_api project="js_of_ocaml" |module Js_of_ocaml.Dom_html>>
+Use modules {!Js_of_ocaml.Dom}
+and {!Js_of_ocaml.Dom_html}
 to interact with the DOM, or more specifically with HTML.
 
 You can test Js_of_ocaml online in this
-[[https://ocsigen.org/js_of_ocaml/latest/manual/files/toplevel/index.html|Toplevel running in the browser]]
+{{:https://ocsigen.org/js_of_ocaml/latest/manual/files/toplevel/index.html}Toplevel running in the browser}
 
-===Examples===
-<<code language="ocaml"|
+{2 Examples}
+{@ocaml[
 # Dom_html.document;;
 - : Js_of_ocaml.Dom_html.document Js_of_ocaml__.Js.t = <abstr>
 # Dom_html.document##.body;;
@@ -568,55 +583,59 @@ val fsth3 :
 - : unit = ()
 # Firebug.console##log (Dom_html.document##.body);;
 - : unit = ()
->>
+]}
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==HTML: Functional and DOM semantics==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 HTML: Functional and DOM semantics}
+{%wodoc:end%}
 
-===DOM nodes and TyXML/Eliom_content nodes===
+{2 DOM nodes and TyXML/Eliom_content nodes}
 
-Functions [[https://ocsigen.org/js_of_ocaml/latest/api/js_of_ocaml-tyxml/Js_of_ocaml_tyxml/Tyxml_cast_sigs/module-type-OF/index.html|{{{Eliom_content.Html.To_dom.of_element}}}, {{{Eliom_content.Html.To_dom.of_div}}}, etc.]]
+Functions {{:https://ocsigen.org/js_of_ocaml/latest/api/js_of_ocaml-tyxml/Js_of_ocaml_tyxml/Tyxml_cast_sigs/module-type-OF/index.html}[Eliom_content.Html.To_dom.of_element], [Eliom_content.Html.To_dom.of_div], etc.}
 help to convert TyXML/Eliom_content nodes into the DOM/js_of_ocaml counterparts.
 
-Module <<a_api project="eliom" subproject="client"|module Eliom_content.Html.Manip>>
+Module {!Eliom_content.Html.Manip}
 allows direct manipulation of TyXML nodes without conversion (only for D nodes)
 (see for example
-<<a_api project="eliom" subproject="client"|val Eliom_content.Html.Manip.appendChild>>,
-<<a_api project="eliom" subproject="client"|val Eliom_content.Html.Manip.removeSelf>>
-<<a_api project="eliom" subproject="client"|val Eliom_content.Html.Manip.Class.add>>).
+{!Eliom_content.Html.Manip.appendChild},
+{!Eliom_content.Html.Manip.removeSelf}
+{!Eliom_content.Html.Manip.Class.add}).
 
 
-===F or D===
+{2 F or D}
 
 Eliom uses TyXML to create several kinds of nodes:
 
-Module <<a_api project="eliom" subproject="server"| module Eliom_content.Html.F>>
+Module {!Eliom_content.Html.F}
 will create functional values representing
-your nodes. On client side, calling {{{Eliom_content.Html.To_dom.of_element}}}
+your nodes. On client side, calling [Eliom_content.Html.To_dom.of_element]
 on these nodes will create a new DOM node.
 
-Module <<a_api project="eliom" subproject="server"| module Eliom_content.Html.D>>
+Module {!Eliom_content.Html.D}
 will automatically insert an id in the
 attributes of the node, to label a precise instance of the node in the DOM.
-On client side, calling {{{Eliom_content.Html.To_dom.of_element}}}
+On client side, calling [Eliom_content.Html.To_dom.of_element]
 on these nodes will return the actual version of the nodes that are currently
 in the page.
 
 In a client server Eliom app,
-you probably always want to use {{{Eliom_content.Html.D}}}
+you probably always want to use [Eliom_content.Html.D]
 each time you want to bind events on
-an element (and more generally if you need to inject this element using {{{~%}}}).
+an element (and more generally if you need to inject this element using [~%]).
 
 
-Read more about {{{Eliom_content.Html}}} (D or F?) in
-<<a_manual project="eliom" chapter="clientserver-html"|this manual page>>.
+Read more about [Eliom_content.Html] (D or F?) in
+{{:../eliom/clientserver-html.html}this manual page}.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Eliom: client-server apps==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Eliom: client-server apps}
+{%wodoc:end%}
 
 Eliom can transform OCaml into a multi-tier language, allowing one to
 implement (both the server and client parts of) a distributed application
@@ -632,12 +651,12 @@ In a mobile app, all pages are usually generated on the client.
 One of the key features of Eliom is that it allows
 one to mix traditional Web interactions (URLs, forms, links,
 bookmarks, back button) with dynamic client side features. In
-particular, the client-side program **does not stop** when the user
+particular, the client-side program {b does not stop} when the user
 clicks on a link, sends a form, or presses the back button--yet the user
 can still save bookmarks on pages! This opens up a wide field of new
 possibilities.
 
-===Sections===
+{2 Sections}
 
 Eliom statically generates two programs from the same set of OCaml files:
 one compiled to native code (or bytecode) to be executed on the server,
@@ -646,30 +665,34 @@ in the browser.
 
 PPX annotations allow you to split the code into these two programs:
 
-|{{{ let%shared ... = ... }}}|Code to be included in both the client and server apps|
-|{{{ let%client ... = ... }}}|Code to be included in client app only|
-|{{{ let%server ... = ... }}}|Code to be included in server app only|
+{t
+ | [let%shared ... = ...] | Code to be included in both the client and server apps |
+ | [let%client ... = ...] | Code to be included in client app only |
+ | [let%server ... = ...] | Code to be included in server app only |
+}
 
-Same for {{{module%shared}}}, {{{open%shared}}}, {{{type%shared}}} etc.
+Same for [module%shared], [open%shared], [type%shared] etc.
 
-@@class="centered"@@{{@@class="img-col-width-400"@@files/tutorial/client-server.svg|Client-server build system}}
+{%wodoc:@ class="centered"%}{%wodoc:img class="img-col-width-400" src="files/tutorial/client-server.svg" alt="Client-server build system"%}
 
-===Client values===
+{2 Client values}
 Fragments of client code can be included in server (or shared) sections.
 
 Example:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
   button ~a:[a_onclick [%client fun ev -> ... ]] [ ... ]
->>
+]}
 
-The syntax is {{{[%client (<value> : <type>)]}}}.
+The syntax is [[%client (<value> : <type>)]].
 Type annotation is almost always required.
 
 These client fragments can be manipulated as server side OCaml values:
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server x : int Eliom_client_value.t = [%client 1 + 3 ]
->>
+]}
 
 If such section is reached while generating a page on server side,
 the client-side code will be executed when the page is displayed.
@@ -681,71 +704,76 @@ If such section is reached during module initialization on the server
 (global client section), it will be executed on client side everytime
 a new client side program is launched.
 
-The tutorial [[tutowidgets|Client-Server Widgets]]
+The tutorial {{:tutowidgets.html}Client-Server Widgets}
 shows how client values can be manipulated
 on server side.
 
-===Injections===
+{2 Injections}
 
 Server side values can be injected in client code by prefixing
-them with {{{~%}}} as in this example:
-<<code language="ocaml" class="server"|
+them with [~%] as in this example:
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server ... =
   ...
   let x = ... in
   [%client[ ... ~%x ... ]]
   ...
->>
+]}
 The value will automatically be sent with the page by Eliom.
 
 It is possible to combine injections and client-values:
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server x : int Eliom_client_value.t = [%client 1 + 3 ]
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client c : int = 3 + ~%x
->>
+]}
 
-===Calling server side functions from the client===
+{2 Calling server side functions from the client}
 
 Eliom makes it possible to call server side OCaml functions from your
 client-side program. You must export these functions explicitly,
 and declare the type of their parameters. Example:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc g (i : int) : string Lwt.t =
   Lwt.return (string_of_int (i + Random.int 1000))
->>
+]}
 
 Warning: type annotations are mandatory here
 so that the ppx can automatically inject the right conversion functions.
 These functions are generated automatically by
-[[https://github.com/ocsigen/deriving|Deriving]], as long as it knows
+{{:https://github.com/ocsigen/deriving}Deriving}, as long as it knows
 a deriver for each subtype. To create a deriver for your own types
-just append {{{[@@deriving json]}}} after your type declaration. Example:
+just append [[@@deriving json]] after your type declaration. Example:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 type%shared t = A | B
 [@@deriving json]
->>
+]}
 
-[[http://ocsigen.org/js_of_ocaml/latest/manual/ppx-deriving|More documentation about the JSON deriver]].
+{{:http://ocsigen.org/js_of_ocaml/latest/manual/ppx-deriving}More documentation about the JSON deriver}.
 
-<<div class="focused"|
-===How it works===
+{%wodoc:div class="focused"%}
+{2 How it works}
 
 The following picture shows two examples of requests:
-* First, the browser asks for a new page, and the server generates the page
-* then the user clicks on a link in the page, and the page is generated by the client-side program (because the service is registered on both sides). In this example, while generating the page, the client does a RPC to the server.
+- First, the browser asks for a new page, and the server generates the page
+- then the user clicks on a link in the page, and the page is generated by the client-side program (because the service is registered on both sides). In this example, while generating the page, the client does a RPC to the server.
 
 In both cases (first request or RPC), the server returns the expected value, but also the value of injections and an order for the client-side program to execute the client-values met during te server-side computation.
 
-@@class="centered"@@{{@@class="img-col-width-400"@@files/tutorial/client-server-req.svg|Example of requests}}
+{%wodoc:@ class="centered"%}{%wodoc:img class="img-col-width-400" src="files/tutorial/client-server-req.svg" alt="Example of requests"%}
 
-Tip 1: You can avoid waiting for the RPC to return by using a spinner from Ocsigen Toolkit (see module <<a_api project="ocsigen-toolkit" subproject="server"|module Ot_spinner>>). Thus, the client-side generated page will be displayed without delay.
+Tip 1: You can avoid waiting for the RPC to return by using a spinner from Ocsigen Toolkit (see module {!Ot_spinner}). Thus, the client-side generated page will be displayed without delay.
 
 Tip 2: To delay the execution of a client fragment after the page is actually displayed, you might want to use function
-<<a_api project="ocsigen-toolkit" subproject="client"|val Ot_nodeready.nodeready>> from Ocsigen Toolkit.
+{!Ot_nodeready.nodeready} from Ocsigen Toolkit.
 
 Regardless of the construction used and their combination, there is
 only one communication from server to client, when the Web page is
@@ -766,25 +794,30 @@ that will insert in the currently generated page some instruction to
 ask the client-side program to call the corresponding functions.
 Their arguments (injections) are serialized at the same time by the
 server-side program and also inserted in the generated page.
->>
+{%wodoc:end%}
 
-===Example===
+{2 Example}
 This section shows a typical example of client-server code: call a function
 when user clicks on a page element. Take time to analyse this example,
 as most of your code will probably be very similar.
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 open%client Js_of_ocaml
 open%client Js_of_ocaml_lwt
-open%client Eliom_content.Html>>
-<<code language="ocaml" class="shared"|open%shared Eliom_content.Html.F>>
-<<code language="ocaml" class="server"|let%server theservice =
+open%client Eliom_content.Html]}
+{%wodoc:@ class=shared%}
+{@ocaml[open%shared Eliom_content.Html.F]}
+{%wodoc:@ class=server%}
+{@ocaml[let%server theservice =
   Eliom_service.create
     ~path:["ex"]
     ~meth:(Eliom_service.Get Eliom_parameter.unit)
-    ()>>
-<<code language="ocaml" class="client"|let%client theservice = ~%theservice>>
-<<code language="ocaml" class="shared"|
+    ()]}
+{%wodoc:@ class=client%}
+{@ocaml[let%client theservice = ~%theservice]}
+{%wodoc:@ class=shared%}
+{@ocaml[
 
 let%shared () =
   My_app.register ~service:theservice (fun () () ->
@@ -802,23 +835,25 @@ let%shared () =
       in
       Lwt.return (html (head (title (txt "Example")) [])
                        (body [h1 [txt aa]; b])))
->>
+]}
 
 Service handlers and service registration
 are usually written in shared sections to enable
 page generation on both sides.
 
-* Examples of client sections, injections or server functions can be found in
+- Examples of client sections, injections or server functions can be found in
 the demo included in
-[[https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/demo_rpc.eliom|Ocsigen-Start's app template]].
-* [[application|This page]] is a step by step introduction to client-server programming with Eliom for beginners.
-* [[tutowidgets|This one]] is a quick introduction for more experienced OCaml developers.
-* Comprehensive documentation on client-server programming can be found in
-<<a_manual project="eliom" page="intro"|Eliom's user manual>>.
->>
-
-<<section class="docblock" |
-<<header |==Compiling a client-server app==>>
+{{:https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/demo_rpc.eliom}Ocsigen-Start's app template}.
+- {{:application.html}This page} is a step by step introduction to client-server programming with Eliom for beginners.
+- {{:tutowidgets.html}This one} is a quick introduction for more experienced OCaml developers.
+- Comprehensive documentation on client-server programming can be found in
+{{:../eliom/.html}Eliom's user manual}.
+{%wodoc:end%}
+
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Compiling a client-server app}
+{%wodoc:end%}
 
 Compiling a client-server app requires a dedicated build system,
 which will separate server-side and client-side code, compile each side,
@@ -832,348 +867,382 @@ It also provides user management (create an account, recover lost password, etc.
 If you plan to build an app with these features, Ocsigen Start is a good basis.
 
 Install Ocsigen Start:
-{{{
+{v
 opam install ocsigen-start
-}}}
+v}
 Then:
-{{{
+{v
 eliom-distillery -template os.pgocaml -name myapp
-}}}
+v}
 It contains by default some code examples that you can remove or adapt to your own needs.
-Have a look at the {{{README}}} file.
+Have a look at the [README] file.
 
 If you don't want to use Ocsigen Start, you can use one of the basic templates:
-{{{
+{v
 eliom-distillery -template app.exe -name myapp
-}}}
+v}
 (to build a static executable without config file)
 or
-{{{
+{v
 eliom-distillery -template app.lib -name myapp
-}}}
+v}
 (to build your app as a library that will be loaded dynamically in Ocsigen Server using a config file).
 
-Have a look at the {{{README}}} file.
+Have a look at the [README] file.
 
 If these templates are not available, you are probably using an old version of Eliom.
-Try to upgrade, or use old template names (see {{{eliom-distillery -list-templates}}}).
+Try to upgrade, or use old template names (see [eliom-distillery -list-templates]).
 
->>
+{%wodoc:end%}
 
 
-<<section class="docblock" |
-<<header |==Sessions==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Sessions}
+{%wodoc:end%}
 
-Session data is saved on server side in //Eliom references//.
+Session data is saved on server side in {e Eliom references}.
 
 The following Eliom reference will count the number of visits of a user on a page:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server count_ref =
   Eliom_reference.eref
     ~scope:Eliom_common.default_session_scope
     0 (* default value for everyone *)
->>
+]}
 
 And somewhere in your service handler, increment the counter:
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%lwt count = Eliom_reference.get count_ref in
 Eliom_reference.set count_ref (count + 1);
 Lwt.return ()
->>
+]}
 
-With function <<a_api project="eliom" subproject="server"|val Eliom_reference.eref_from_fun>>,
+With function {!Eliom_reference.eref_from_fun},
 you can create Eliom references without initial value. The initial value is computed for the session
 the first time you use it.
 
 An Eliom reference can be persistant (value saved on hard drive) or volatile (in memory).
 
-===Scopes===
+{2 Scopes}
 Sessions are relative to a browser, and implemented using browser cookies.
-But Eliom allows to create Eliom references with other //scopes// than session:
+But Eliom allows to create Eliom references with other {e scopes} than session:
 
-|<<a_api project="eliom" subproject="server" text="global_scope"| val Eliom_common.global_scope>>|Global value for all the Web server|
-|<<a_api project="eliom" subproject="server" text="site_scope"| val Eliom_common.site_scope>>|Global value for the Eliom app in that subsite of the Web site|
-|<<a_api project="eliom" subproject="server" text="default_group_scope"| val Eliom_common.default_group_scope>>|Value for a group of sessions. For example Ocsigen Start defines a group of session for each user, making it possible to save server side data for all sessions of a user.|
-|<<a_api project="eliom" subproject="server" text="default_session_scope"| val Eliom_common.default_session_scope>>|The usual session data, based on browser cookies|
-|<<a_api project="eliom" subproject="server" text="default_process_scope"| val Eliom_common.default_process_scope>>|Server side data for a given client-side process (a tab of the browser or a mobile app).|
+{t
+ | {{!Eliom_common.global_scope}global_scope} | Global value for all the Web server |
+ | {{!Eliom_common.site_scope}site_scope} | Global value for the Eliom app in that subsite of the Web site |
+ | {{!Eliom_common.default_group_scope}default_group_scope} | Value for a group of sessions. For example Ocsigen Start defines a group of session for each user, making it possible to save server side data for all sessions of a user. |
+ | {{!Eliom_common.default_session_scope}default_session_scope} | The usual session data, based on browser cookies |
+ | {{!Eliom_common.default_process_scope}default_process_scope} | Server side data for a given client-side process (a tab of the browser or a mobile app). |
+}
 
 Applications based on Ocsigen Start use these scopes for user management.
 Session or client process data are discarded when a user logs in or out.
 But Ocsigen Start also defines scopes
-<<a_api project="ocsigen-start" subproject="server"| val Os_session.user_indep_session_scope>>
+{!Os_session.user_indep_session_scope}
 and
-<<a_api project="ocsigen-start" subproject="server"| val Os_session.user_indep_process_scope>>
+{!Os_session.user_indep_process_scope}
 which remain even if a user logs in or out.
 
 When session group is not set (for example the user is not connected),
 you can still use the group session scope: in that case, the group contains only
 one session.
 
->>
+{%wodoc:end%}
 
 
-<<section class="docblock" |
-<<header |==Browser events==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Browser events}
+{%wodoc:end%}
 
-Attributes like {{{a_onclick}}} in module {{{Eliom_content.Html.D}}} or {{{F}}}
+Attributes like [a_onclick] in module [Eliom_content.Html.D] or [F]
 take a client side function as parameter:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 button ~a:[a_onclick [%client fun ev -> ... ]] [ ... ]
->>
+]}
 
-Module {{{Lwt_js_events}}} of Js_of_ocaml defines a way to bind browser events
+Module [Lwt_js_events] of Js_of_ocaml defines a way to bind browser events
 using Lwt promises.
 
 For example,
-the following code will wait for a click on element {{{d}}} before continuing:
-<<code language="ocaml" class="client"|
+the following code will wait for a click on element [d] before continuing:
+{%wodoc:@ class=client%}
+{@ocaml[
 let%lwt ev = Lwt_js_events.click (Eliom_content.Html.To_dom.of_element ~%d) in
 ...
->>
+]}
 
-Functions like {{{Lwt_js_events.clicks}}} or {{{Lwt_js_events.mousedowns}}}
+Functions like [Lwt_js_events.clicks] or [Lwt_js_events.mousedowns]
 (ending with "s")
 will call the function given as second parameter
-**for each** {{{click}}} or {{{mousedown}}} events
+{b for each} [click] or [mousedown] events
 on their first parameter.
 
-For example, the following code (inspired from [[https://ocsigen.org/tuto/latest/manual/application|this tutorial]])
-will wait for all {{{mousedown}}} events on the canvas,
-then for each {{{mousemove}}} event on the document,
-it will call function {{{f}}}, until {{{mouseup}}} is triggered.
-(See <<a_api project="lwt"| val Lwt.pick>>)
-<<code language="ocaml" class="client"|
+For example, the following code (inspired from {{:https://ocsigen.org/tuto/latest/manual/application}this tutorial})
+will wait for all [mousedown] events on the canvas,
+then for each [mousemove] event on the document,
+it will call function [f], until [mouseup] is triggered.
+(See {!Lwt.pick})
+{%wodoc:@ class=client%}
+{@ocaml[
 let open Lwt_js_events in
 Lwt.async (mousedowns
             (Eliom_content.Html.To_dom.of_element ~%canvas)
             (fun ev _ ->
                Lwt.pick [mousemoves Dom_html.document f;
                          mouseup Dom_html.document]))
->>
->>
+]}
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Ocsigen Toolkit==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Ocsigen Toolkit}
+{%wodoc:end%}
 
 Ocsigen Toolkit defines several widgets that can be generated either
 on server or clide sides. Have look at
-[[wiki("ocsigen-start"):demo/|Ocsigen Start's demo app]]
-(or the [[https://play.google.com/store/apps/details?id=com.osdemo.mobile|corresponding Android app]])
+{{:../ocsigen-start/demo/}Ocsigen Start's demo app}
+(or the {{:https://play.google.com/store/apps/details?id=com.osdemo.mobile}corresponding Android app})
 to see them in action: carousel, drawer menu, date or time picker, color picker,
 pull to refresh feature for mobile apps, etc.
 
 For example module
-<<a_api project="ocsigen-toolkit" subproject="server"|module Ot_spinner>>
+{!Ot_spinner}
 implements a widgets that you can use to display a spinner (or fake elements)
 when some parts of your page take time to appear.
 It can be used in shared sections and gives you precise control
 of the delays and the feeling of responsiveness of your app.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Ocsigen Start==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Ocsigen Start}
+{%wodoc:end%}
 
-//Ocsigen-start// is a library and a template of Eliom application,
+{e Ocsigen-start} is a library and a template of Eliom application,
 with many common features like
 user registration, login box, notification system, etc.
 
 It also provides a demo of many features presented in this page.
-A [[wiki("ocsigen-start"):demo/|live version]] is accessible online.
-Read [[start|this page]] to create your first Ocsigen Start
+A {{:../ocsigen-start/demo/}live version} is accessible online.
+Read {{:start.html}this page} to create your first Ocsigen Start
 app and take time to study the code of each example.
 
 User management features are fully usable in production and
 will save you from implementing account creation, activation links
 or password recovery yourself.
-Module <<a_api project="ocsigen-start" subproject="server"|module Os_current_user>>
+Module {!Os_current_user}
 gives you information about current user
 from anywhere in your program.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Database access==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Database access}
+{%wodoc:end%}
 
 You can use your favourite database library with Ocsigen.
 Ocsigen Start's template uses
-[[https://github.com/darioteixeira/pgocaml|PG'OCaml]]
+{{:https://github.com/darioteixeira/pgocaml}PG'OCaml}
 (typed queries for Postgresql using a PPX syntax extension).
 
 Here is an example, taken from Ocsigen Start's demo:
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let get () =
   full_transaction_block (fun dbh ->
     [%pgsql dbh "SELECT lastname FROM ocsigen_start.users"])
->>
+]}
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Server to client communication==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Server to client communication}
+{%wodoc:end%}
 
 Modules
-<<a_api project="eliom" subproject="server"| module Eliom_notif>>
+{!Eliom_notif}
 and
-<<a_api project="ocsigen-start" subproject="server"| module Os_notif>>
+{!Os_notif}
 define the simplest interface to enable server to client communication
 (the second one being aware of Ocsigen Start users).
 
-<<div class="focused"|
-===How it works===
+{%wodoc:div class="focused"%}
+{2 How it works}
 Say you want to receive the messages for one or more chat rooms.
 First, define your notification module:
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 module%server Notif = Os_notif.Make_Simple (struct
   type key = int64 (* the chat room ids *)
   type notification = string (* the type of messages *)
 end)
->>
+]}
 
 If you want to be notified when there is a new message in a chat room, call function
-{{{Notif.listen}}} (server side) on the chat room id.
+[Notif.listen] (server side) on the chat room id.
 
 If you want to send a message in a chat room, call function
-{{{Notif.notify}}} (server side) with the chat room id and the message as parameters.
+[Notif.notify] (server side) with the chat room id and the message as parameters.
 
-On client side, {{{~%(Notif.client_ev ())}}} is a React event of type
-{{{(key, notif) React.E.t}}}. Use it to receive the messages.
->>
+On client side, [~%(Notif.client_ev ())] is a React event of type
+[(key, notif) React.E.t]. Use it to receive the messages.
+{%wodoc:end%}
 
-Have a look at a [[https://ocsigen-1.inria.fr/ocsigen-start/demo/demo-notif|running example]] in Ocsigen Start's demo
-([[https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/demo_notif.eliom|source]]).
+Have a look at a {{:https://ocsigen-1.inria.fr/ocsigen-start/demo/demo-notif}running example} in Ocsigen Start's demo
+({{:https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/demo_notif.eliom}source}).
 
 Eliom has other communication modules:
-* <<a_api project="eliom" subproject="server"| module Eliom_bus>> defines a communication bus,
+- {!Eliom_bus} defines a communication bus,
 that you can use to share information with other client processes
-(see an example [[application|here]]).
-* <<a_api project="eliom" subproject="server"| module Eliom_react>> defines client-server React events.
-* <<a_api project="eliom" subproject="server"| module Eliom_comet>> is lower level interface for
+(see an example {{:application.html}here}).
+- {!Eliom_react} defines client-server React events.
+- {!Eliom_comet} is lower level interface for
 server to client communication.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Internationalisation==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Internationalisation}
+{%wodoc:end%}
 
-[[https://github.com/besport/ocsigen-i18n|Ocsigen i18n]]
+{{:https://github.com/besport/ocsigen-i18n}Ocsigen i18n}
 is an internationalisation library for your OCaml programs.
 
 Create a .tsv file with, on each line, a key and the text in several languages:
 
-{{{
+{v
 welcome_message Welcome everybody!        Bienvenue à tous !      Benvenuti a tutti !
-}}}
+v}
 
 and Ocsigen i18n will automatically generate functions like this one:
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%shared welcome_message ?(lang = get_language ()) () () =
   match lang with
   | En -> [txt "Welcome everybody!"]
   | Fr -> [txt "Bienvenue à tous !"]
   | It -> [txt "Benvenuti a tutti !"]
->>
+]}
 
 Ocsigen i18n also defines a syntax extension to use these functions:
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
   Eliom_content.Html.F.h1 [%i18n welcome_message]
->>
+]}
 
 Ocsigen i18n offers many other features:
-* Text can be inserted as a TyXML node (as in the example above) or as a string (ex: {{{[%i18n S.welcome_message]}}}),
-* Text can be parametrizable, or contain holes (ex: {{{[%i18n welcome ~capitalize:true ~name:"William"]}}})
-* .tsv file can be split into several modules
+- Text can be inserted as a TyXML node (as in the example above) or as a string (ex: [[%i18n S.welcome_message]]),
+- Text can be parametrizable, or contain holes (ex: [[%i18n welcome ~capitalize:true ~name:"William"]])
+- .tsv file can be split into several modules
 
 Have a look at the
-[[https://github.com/besport/ocsigen-i18n|README file]]
+{{:https://github.com/besport/ocsigen-i18n}README file}
 to see the full documentation,
 and see examples in
-[[https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/demo_i18n.eliom|Ocsigen Start's template]].
+{{:https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/demo_i18n.eliom}Ocsigen Start's template}.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Reactive programming==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Reactive programming}
+{%wodoc:end%}
 
-Eliom allows to insert //reactive nodes// in pages, that is, nodes which are automatically
+Eliom allows to insert {e reactive nodes} in pages, that is, nodes which are automatically
 updated when the values on which they depend change.
 
-This is based on the [[https://erratique.ch/software/react|React]] library by Daniel Bünzli,
-which implements //Functional Reactive Programming//.
+This is based on the {{:https://erratique.ch/software/react}React} library by Daniel Bünzli,
+which implements {e Functional Reactive Programming}.
 
-<<div class="focused"|
-===Functional Reactive Programming principle===
+{%wodoc:div class="focused"%}
+{2 Functional Reactive Programming principle}
 
-Function {{{React.S.create}}} creates a signal and a function to change its value:
-<<code language="ocaml" class="client"|
+Function [React.S.create] creates a signal and a function to change its value:
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client mysignal, set_mysignal = React.S.create 0
->>
+]}
 
-Functions like {{{React.S.map}}} or {{{React.S.l2}}} create new signals
+Functions like [React.S.map] or [React.S.l2] create new signals
 from one (resp. two) input signals.
 They are updated automatically when their input signals change.
 For example, we can can define the same value as a string signal and as TyXML node signal:
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client s_string = React.S.map string_of_int mysignal
 let%client s_p = React.S.map (fun v -> p [txt v]) s_string
->>
+]}
 
->>
+{%wodoc:end%}
 
-===Reactive nodes===
+{2 Reactive nodes}
 
 Insert a (client side) reactive node in a page using function
-<<a_api project="eliom" subproject="server"| val Eliom_content.Html.R.node >>:
+{!Eliom_content.Html.R.node}:
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client f () =
   let open Eliom_content.Html in
   F.div [ R.node s_p ]
->>
+]}
 
-===Reactive node content===
+{2 Reactive node content}
 
 Module
-<<a_api project="eliom" subproject="server"|module Eliom_content.Html.R >>
+{!Eliom_content.Html.R}
 also defines all TyXML nodes,
 which take reactive content as parameter.
 
-For example {{{Eliom_content.Html.R.txt}}} takes
-a value of type {{{string React.S.t}}} as parameter (string signal).
+For example [Eliom_content.Html.R.txt] takes
+a value of type [string React.S.t] as parameter (string signal).
 
 Instead of taking a list signal as parameter, functions like
-{{{div}}} or {{{p}}} of module {{{Eliom_content.Html.R}}}
+[div] or [p] of module [Eliom_content.Html.R]
 take a parameter of type
-[[https://github.com/ocsigen/reactiveData|Eliom_content.Html.F.elt ReactiveData.Rlist.t]].
+{{:https://github.com/ocsigen/reactiveData}Eliom_content.Html.F.elt ReactiveData.Rlist.t}.
 This enables incremental update of the content
 (usually, appending an element at the end of the list,
 without having to redraw the whole list).
-See an example with {{{ReactiveData}}} in [[tutoreact|this tutorial]].
+See an example with [ReactiveData] in {{:tutoreact.html}this tutorial}.
 
-Node attributes can also be reactive. For example if {{{s}}} has type {{{string list React.S.t}}},
-you can write {{{Eliom_content.Html.F.div ~a:[R.a_class s] []}}}.
+Node attributes can also be reactive. For example if [s] has type [string list React.S.t],
+you can write [Eliom_content.Html.F.div ~a:[R.a_class s] []].
 
-===Client-server reactive programming===
+{2 Client-server reactive programming}
 
 Reactive nodes can be created in server or shared sections.
 To do that, use module
-<<a_api project="eliom" subproject="server"| module Eliom_shared.React >>
-instead of the usual {{{React}}} module.
-On client side, this module behaves like {{{React}}}.
+{!Eliom_shared.React}
+instead of the usual [React] module.
+On client side, this module behaves like [React].
 But when executed on server side, it will generate non reactive values,
 that will automatically become reactive on the client.
 
 Full example:
-<<code language="ocaml" class="server"|let%server theservice =
+{%wodoc:@ class=server%}
+{@ocaml[let%server theservice =
   Eliom_service.create
     ~path:["ex"]
     ~meth:(Eliom_service.Get Eliom_parameter.unit)
-    ()>>
-<<code language="ocaml" class="client"|let%client theservice = ~%theservice>>
-<<code language="ocaml" class="client"|open%client Js_of_ocaml_lwt>>
-<<code language="ocaml" class="shared"|open%shared Eliom_content.Html.F
+    ()]}
+{%wodoc:@ class=client%}
+{@ocaml[let%client theservice = ~%theservice]}
+{%wodoc:@ class=client%}
+{@ocaml[open%client Js_of_ocaml_lwt]}
+{%wodoc:@ class=shared%}
+{@ocaml[open%shared Eliom_content.Html.F
 
 let%shared () =
   My_app.register ~service:theservice (fun () () ->
@@ -1197,18 +1266,20 @@ let%shared () =
            (head (title (txt s)) [])
            (body [h1 [txt s];
                   p [Eliom_content.Html.R.txt s_string]])))
->>
+]}
 
-Function {{{Eliom_shared.React.S.map}}} (and {{{Eliom_shared.React.S.l2}}}, etc)
-takes a //shared function// as parameter (syntax {{{@@class="shared"@@[%shared f]}}}).
+Function [Eliom_shared.React.S.map] (and [Eliom_shared.React.S.l2], etc)
+takes a {e shared function} as parameter (syntax [@@class="shared"@@[%shared f]]).
 This can be seen as a couple containing both the server a client side implementation
 of the function.
 
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Mobile apps==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Mobile apps}
+{%wodoc:end%}
 Applications can run on any Web browser or mobile device (iOS, Android, ...),
 thus eliminating the need for one custom version per platform.
 
@@ -1217,58 +1288,59 @@ Your CSS must be fully responsive to adapt to all screen sizes.
 Ocsigen Start's template comes with a Makefile which will automatically
 download the required NPM modules for Cordova and build your Android or iOS
 apps.
-Read the [[https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/README.md|README]] file
+Read the {{:https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/README.md}README} file
 to learn how to do that.
 
 Download
-[[https://play.google.com/store/apps/details?id=com.osdemo.mobile|Ocsigen Start's demo app]]
+{{:https://play.google.com/store/apps/details?id=com.osdemo.mobile}Ocsigen Start's demo app}
 from Google Play store to see an example.
-[[https://www.besport.com/news|Be Sport]] mobile apps are also generated like this (available in
-[[https://play.google.com/store/apps/details?id=com.besport.www.mobile|Google Play Store]]
-and [[https://apps.apple.com/fr/app/be-sport/id1104216922|Apple app store]]).
->>
+{{:https://www.besport.com/news}Be Sport} mobile apps are also generated like this (available in
+{{:https://play.google.com/store/apps/details?id=com.besport.www.mobile}Google Play Store}
+and {{:https://apps.apple.com/fr/app/be-sport/id1104216922}Apple app store}).
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Ocsigen Server==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Ocsigen Server}
+{%wodoc:end%}
 
-//Ocsigen Server// is a full featured Web server.
+{e Ocsigen Server} is a full featured Web server.
 
-It is now based on [[https://github.com/mirage/ocaml-cohttp|Cohttp]].
+It is now based on {{:https://github.com/mirage/ocaml-cohttp}Cohttp}.
 
 It has a powerful
 extension mechanism that makes it easy to plug your own OCaml modules
 for generating pages. Many extensions are already written:
-;<<a_manual project="ocsigenserver" chapter="staticmod"|Staticmod>>
+;{{:../ocsigenserver/staticmod.html}Staticmod}
 :    to serve static files.
-;[[wiki("eliom"):|Eliom]]
+;{{:../eliom/}Eliom}
 :    to create reliable client/server Web applications
      or Web sites in OCaml using advanced high level concepts.
-;<<a_manual project="ocsigenserver" chapter="extendconfiguration"|Extendconfiguration>>
+;{{:../ocsigenserver/extendconfiguration.html}Extendconfiguration}
 :    allows for more options in the configuration file.
-;<<a_manual project="ocsigenserver" chapter="accesscontrol"|Accesscontrol>>
+;{{:../ocsigenserver/accesscontrol.html}Accesscontrol}
 :    restricts access to the sites from the config file (to requests coming from a subnet, containing some headers, etc.).
-;<<a_manual project="ocsigenserver" chapter="authbasic"|Authbasic>>
+;{{:../ocsigenserver/authbasic.html}Authbasic}
 :    restricts access to the sites from the config file using Basic HTTP Authentication.
-;<<a_manual project="ocsigenserver" chapter="cgimod"|CGImod>>
+;{{:../ocsigenserver/cgimod.html}CGImod}
 :    serves CGI scripts. It may also be used to serve PHP through CGI.
-;<<a_manual project="ocsigenserver" chapter="deflatemod"|Deflatemod>>
+;{{:../ocsigenserver/deflatemod.html}Deflatemod}
 :    used to compress data before sending it to the client.
-;<<a_manual project="ocsigenserver" chapter="redirectmod"|Redirectmod>>
+;{{:../ocsigenserver/redirectmod.html}Redirectmod}
 :    sets redirections towards other Web sites from the configuration file.
-;<<a_manual project="ocsigenserver" chapter="revproxy"|Revproxy>>
+;{{:../ocsigenserver/revproxy.html}Revproxy}
 :    a reverse proxy for Ocsigen Server.
       It allows to ask another server to handle the request.
-;<<a_manual project="ocsigenserver" chapter="rewritemod"|Rewritemod>>
+;{{:../ocsigenserver/rewritemod.html}Rewritemod}
 :    changes incoming requests before sending them to other extensions.
-;<<a_manual project="ocsigenserver" chapter="outputfilter"|Outputfilter>>
+;{{:../ocsigenserver/outputfilter.html}Outputfilter}
 :    rewrites some parts of the output before sending it to the client.
-;<<a_manual project="ocsigenserver" chapter="userconf"|Userconf>>
+;{{:../ocsigenserver/userconf.html}Userconf}
 :    allows users to have their own configuration files.
-;<<a_manual project="ocsigenserver" chapter="comet"|Comet>>
+;{{:../ocsigenserver/comet.html}Comet}
 :    facilitates server to client communications.
 
-Ocsigen Server has a <<a_manual project="ocsigenserver"
-chapter="config"|sophisticated configuration>> file mechanism allowing
+Ocsigen Server has a {{:../ocsigenserver/config.html}sophisticated configuration} file mechanism allowing
 complex configurations of sites.
 
->>
+{%wodoc:end%}
diff --git a/tutos/8.0/manual/custom-conf.wiki b/tutos/8.0/manual/custom-conf.mld
similarity index 86%
rename from tutos/8.0/manual/custom-conf.wiki
rename to tutos/8.0/manual/custom-conf.mld
index 95c24c00..56e12642 100644
--- a/tutos/8.0/manual/custom-conf.wiki
+++ b/tutos/8.0/manual/custom-conf.mld
@@ -1,16 +1,18 @@
-=Custom configuration options=
-<<concepts |Custom configuration options>>
+{0 Custom configuration options}
+{%wodoc:aside class="concepts"%}{b Concepts}
+
+Custom configuration options{%wodoc:end%}
 
 It is not convenient to have to edit the code to change some
 configurations, like the location where are saved the favorite
 images in the Graffiti tutorial
-(see: [[wiki:pictures|Saving favorite pictures]]).
+(see: {{:wiki:pictures}Saving favorite pictures}).
 Fortunately Ocsigen provides a mechanism to extend its
 configuration file.
 
-==Basic interface==
+{1 Basic interface}
 
-<<code language="ocaml"|
+{@ocaml[
 let static_dir =
   match Eliom_config.get_config () with
     | [Simplexmlparser.Element
@@ -22,27 +24,27 @@ let static_dir =
     | _ ->
       raise (Ocsigen_extensions.Error_in_config_file
                ("Unexpected content inside config"))
->>
+]}
 
 This will add a mandatory child to the eliom tag in the
 configuration file:
-{{{
+{v
 <eliom module="path/to/your/module.cma">
   <staticdir>/tmp/static</staticdir>
 </eliom>
-}}}
+v}
 
 
-==New interface==
+{1 New interface}
 
 From Eliom 4.0 it is much easier to define configuration file extension.
-Have a look at module <<a_api project="eliom" subproject="server"|module Eliom_config>>.
+Have a look at module {!Eliom_config}.
 For instance, here is how you can add an element "<ldap>"
 in the configuration file to store a list of LDAP servers your application
 interacts with.
 
 
-<<code language="ocaml"|
+{@ocaml[
 
 (** An LDAP server is characterized by an host and a port. *)
 type ldap_configuration = {
@@ -86,4 +88,4 @@ let ldap_configuration = Ocsigen_extensions.Configuration.(
 
 let _ = Eliom_config.parse_config [ldap_configuration]
 
->>
+]}
diff --git a/tutos/8.0/manual/hash-password.wiki b/tutos/8.0/manual/hash-password.mld
similarity index 73%
rename from tutos/8.0/manual/hash-password.wiki
rename to tutos/8.0/manual/hash-password.mld
index cf16a095..d662e2ed 100644
--- a/tutos/8.0/manual/hash-password.wiki
+++ b/tutos/8.0/manual/hash-password.mld
@@ -1,13 +1,13 @@
-=Protecting your passwords=
+{0 Protecting your passwords}
 
 For protecting the user passwords or other sensitive data,
 we can use
-[[http://ocaml-safepass.forge.ocamlcore.org/|ocaml-safepass]].
+{{:http://ocaml-safepass.forge.ocamlcore.org/}ocaml-safepass}.
 
 We can now write the encrypted password in our database
-(using <<a_api project="ocsigenserver"| type Ocsipersist.table >>
+(using {!Ocsipersist.table}
 in this example) as follow:
-<<code language="ocaml"|
+{@ocaml[
 let table =
   Ocsipersist.Polymorphic.open_table "users"
 
@@ -20,8 +20,8 @@ let add_user username password =
       | Not_found ->
         Ocsipersist.Polymorphic.add table username
           (Bcrypt.hash password, email)
-        ~>>= fun () ->
+        >>= fun () ->
         Lwt.return true
       | e -> Lwt.fail e
     )
->>
+]}
diff --git a/tutos/8.0/manual/how-do-i-create-a-cryptographically-safe-identifier.mld b/tutos/8.0/manual/how-do-i-create-a-cryptographically-safe-identifier.mld
new file mode 100644
index 00000000..6a445df8
--- /dev/null
+++ b/tutos/8.0/manual/how-do-i-create-a-cryptographically-safe-identifier.mld
@@ -0,0 +1,3 @@
+{0 How do I create a cryptographically safe identifier?}
+
+{!Ocsigen_lib.make_cryptographic_safe_string}
diff --git a/tutos/8.0/manual/how-do-i-create-a-cryptographically-safe-identifier.wiki b/tutos/8.0/manual/how-do-i-create-a-cryptographically-safe-identifier.wiki
deleted file mode 100644
index c592482a..00000000
--- a/tutos/8.0/manual/how-do-i-create-a-cryptographically-safe-identifier.wiki
+++ /dev/null
@@ -1,3 +0,0 @@
-== How do I create a cryptographically safe identifier? ==
-
-<<a_api project="ocsigenserver"| val  Ocsigen_lib.make_cryptographic_safe_string>>
diff --git a/tutos/8.0/manual/how-does-a-page-s-source-code-look.mld b/tutos/8.0/manual/how-does-a-page-s-source-code-look.mld
new file mode 100644
index 00000000..e1ac3868
--- /dev/null
+++ b/tutos/8.0/manual/how-does-a-page-s-source-code-look.mld
@@ -0,0 +1,81 @@
+{0 How does a client-server app source code look like?}
+
+{2 Eliom client-server applications}
+
+Eliom client-server applications are running in your browser for a {{:../eliom/clientserver-applications.html}certain lifetime} and consist of one or several pages/URLs.
+An application has its associated js file, which must have the same name ({{:../manual/how-to-compile-my-ocsigen-pages}generated automatically by the default makefile} and added automatically by Eliom in the page).
+
+For example, we define an application called {e example}:
+{@ocaml[
+module Example =
+  Eliom_registration.App
+    (struct
+      let application_name = "example"
+     end)
+]}
+
+{2 Eliom Services}
+
+Pages are generated by {e services}. Here is how to define a service:
+
+{@ocaml[
+let main =
+  Eliom_service.create
+    ~path:(Eliom_service.Path [])
+    ~meth:(Eliom_service.Get unit)
+    ()
+]}
+
+The path is a list of string corresponding to the url. Here, the list is empty because it's the main page.
+
+If, for example, the list is ["hello";"world"], the page will be accessed using the address:
+{[http://website.com/hello/world/]}
+
+More information about parameters: {{:wiki:manual/how-to-use-get-parameters-or-parameters-in-the-url}How to use GET parameters (parameters in the URL)?}
+
+Now that our service has been declared, we associate to it an OCaml function that will generate the page. We call this {e service registration}. If the service belongs to the application, we use the registrations functions from module [Example] defined above.
+
+{@ocaml[
+let _ =
+  Example.register
+    ~service:main
+    (fun () () ->
+      Lwt.return ...)
+]}
+
+The third parameter is the function that will be called to generate the page.
+This function takes two parameters, corresponding respectively to GET and POST parameters. Here both are [()] because the service does not take any parameter. The function returns an element of type html (using Lwt).
+
+
+{2 Page Content}
+
+The content of Eliom application pages is made using functions.
+The {b html function} takes two parameters:
+head and body, which are also functions that takes parameters coresponding to their content.
+
+{@ocaml[
+(html
+           (head (title (txt "Page Title")) [])
+           (body [p [txt "Hello World!"]])))
+]}
+
+Most of the elements functions take a list of other elements as a parameter.
+
+{%wodoc:img src="http://public.db0.fr/dev/ocsigen/html.png" alt="ast"%}
+
+Validity of HTML is checked at compile time, which means that a program
+that may generate a page that does not respect the recommendations of the
+W3C will be rejected at compile time.
+
+{2 Download full code}
+
+{e Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.}
+
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/page/example.eliom}Read the full code}
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto}Download and try this example}
+
+
+{2 Links}
+
+- {{:../eliom/server-services.html}About services}
+- {{:../tyxml/.html}About html generation}
diff --git a/tutos/8.0/manual/how-does-a-page-s-source-code-look.wiki b/tutos/8.0/manual/how-does-a-page-s-source-code-look.wiki
deleted file mode 100644
index 09ea6d20..00000000
--- a/tutos/8.0/manual/how-does-a-page-s-source-code-look.wiki
+++ /dev/null
@@ -1,81 +0,0 @@
-=How does a client-server app source code look like?=
-
-=== Eliom client-server applications
-
-Eliom client-server applications are running in your browser for a <<a_manual project="eliom" chapter="clientserver-applications"|certain lifetime>> and consist of one or several pages/URLs.
-An application has its associated js file, which must have the same name ([[site:manual/how-to-compile-my-ocsigen-pages|generated automatically by the default makefile]] and added automatically by Eliom in the page).
-
-For example, we define an application called //example//:
-<<code language="ocaml"|
-module Example =
-  Eliom_registration.App
-    (struct
-      let application_name = "example"
-     end)
->>
-
-=== Eliom Services
-
-Pages are generated by //services//. Here is how to define a service:
-
-<<code language="ocaml"|
-let main =
-  Eliom_service.create
-    ~path:(Eliom_service.Path [])
-    ~meth:(Eliom_service.Get unit)
-    ()
->>
-
-The path is a list of string corresponding to the url. Here, the list is empty because it's the main page.
-
-If, for example, the list is ["hello";"world"], the page will be accessed using the address:
-<<code|http://website.com/hello/world/>>
-
-More information about parameters: [[wiki:manual/how-to-use-get-parameters-or-parameters-in-the-url|How to use GET parameters (parameters in the URL)?]]
-
-Now that our service has been declared, we associate to it an OCaml function that will generate the page. We call this //service registration//. If the service belongs to the application, we use the registrations functions from module {{{Example}}} defined above.
-
-<<code language="ocaml"|
-let _ =
-  Example.register
-    ~service:main
-    (fun () () ->
-      Lwt.return ...)
->>
-
-The third parameter is the function that will be called to generate the page.
-This function takes two parameters, corresponding respectively to GET and POST parameters. Here both are {{{()}}} because the service does not take any parameter. The function returns an element of type html (using Lwt).
-
-
-=== Page Content
-
-The content of Eliom application pages is made using functions.
-The **html function** takes two parameters:
-head and body, which are also functions that takes parameters coresponding to their content.
-
-<<code language="ocaml"|
-(html
-           (head (title (txt "Page Title")) [])
-           (body [p [txt "Hello World!"]])))
->>
-
-Most of the elements functions take a list of other elements as a parameter.
-
-{{http://public.db0.fr/dev/ocsigen/html.png|ast}}
-
-Validity of HTML is checked at compile time, which means that a program
-that may generate a page that does not respect the recommendations of the
-W3C will be rejected at compile time.
-
-=== Download full code
-
-//Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.//
-
-* [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/page/example.eliom|Read the full code]]
-* [[https://github.com/db0company/Ocsigen-Quick-Howto|Download and try this example]]
-
-
-=== Links
-
-* <<a_manual project="eliom" chapter="server-services"|About services>>
-* <<a_manual project="tyxml"|About html generation>>
diff --git a/tutos/8.0/manual/how-to-add-a-div.mld b/tutos/8.0/manual/how-to-add-a-div.mld
new file mode 100644
index 00000000..e1d9ef6b
--- /dev/null
+++ b/tutos/8.0/manual/how-to-add-a-div.mld
@@ -0,0 +1,25 @@
+{0 How to add a div?}
+
+{@ocaml[
+div ~a:[a_class ["firstclass"; "secondclass"]] [txt "Hello!"]
+]}
+
+{b Required parameter}: list containing other elements
+(Details of available elements in type
+{!Html_types.flow5}).
+
+{b Optional parameter} for attributes "a" ({{:wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements}How to set and id, classes or other attributes to HTML elements?}).
+
+{2 Download full code}
+
+{e Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.}
+
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/elements/example.eliom}Read the full code}
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto}Download and try this example}
+
+{2 Links}
+
+- Modules {!Eliom_content.Html.D} and
+  {!Eliom_content.Html.F}
+  (HTML5 Elements)
+- signature {!Html_sigs.T} (Element attributes)
diff --git a/tutos/8.0/manual/how-to-add-a-div.wiki b/tutos/8.0/manual/how-to-add-a-div.wiki
deleted file mode 100644
index b97d53da..00000000
--- a/tutos/8.0/manual/how-to-add-a-div.wiki
+++ /dev/null
@@ -1,25 +0,0 @@
-=How to add a div?=
-
-<<code language='ocaml'|
-div ~a:[a_class ["firstclass"; "secondclass"]] [txt "Hello!"]
->>
-
-**Required parameter**: list containing other elements
-(Details of available elements in type
-<<a_api project="tyxml"|type Html_types.flow5>>).
-
-**Optional parameter** for attributes "a" ([[wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements|How to set and id, classes or other attributes to HTML elements?]]).
-
-=== Download full code
-
-//Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.//
-
-* [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/elements/example.eliom|Read the full code]]
-* [[https://github.com/db0company/Ocsigen-Quick-Howto|Download and try this example]]
-
-=== Links
-
-* Modules <<a_api project="eliom" subproject="server"|module Eliom_content.Html.D>> and
-  <<a_api project="eliom" subproject="server"|module Eliom_content.Html.F>>
-  (HTML5 Elements)
-* signature <<a_api project="tyxml"|module Html_sigs.T>> (Element attributes)
diff --git a/tutos/8.0/manual/how-to-add-a-favicon.mld b/tutos/8.0/manual/how-to-add-a-favicon.mld
new file mode 100644
index 00000000..13710144
--- /dev/null
+++ b/tutos/8.0/manual/how-to-add-a-favicon.mld
@@ -0,0 +1,16 @@
+{0 How to add a Favicon?}
+
+A favicon is a file of type "ico" which contain a picture of size 16x16px. It is the picture that you can ususally see next to the title of the page on a browser.
+
+{%wodoc:img src="http://public.db0.fr/dev/ocsigen/favicon.png" alt="favicon for Ocsigen.org"%}
+
+By default, all browsers look for a file [favicon.ico]
+at the root of the website:
+{[ http://website.com/favicon.ico]}
+
+Just put the file at the root of the static directory set in the configuration file.
+
+{2 Links}
+
+- {{:../ocsigenserver/staticmod.html}Configuring Ocsigen Server for serving static files}
+- {{:http://www.favicon.cc/}An example of a favicon generator}
diff --git a/tutos/8.0/manual/how-to-add-a-favicon.wiki b/tutos/8.0/manual/how-to-add-a-favicon.wiki
deleted file mode 100644
index f8f76df9..00000000
--- a/tutos/8.0/manual/how-to-add-a-favicon.wiki
+++ /dev/null
@@ -1,16 +0,0 @@
-=How to add a Favicon?=
-
-A favicon is a file of type "ico" which contain a picture of size 16x16px. It is the picture that you can ususally see next to the title of the page on a browser.
-
-{{http://public.db0.fr/dev/ocsigen/favicon.png|favicon for Ocsigen.org}}
-
-By default, all browsers look for a file {{{favicon.ico}}}
-at the root of the website:
-<<code| http://website.com/favicon.ico>>
-
-Just put the file at the root of the static directory set in the configuration file.
-
-=== Links
-
-* <<a_manual project="ocsigenserver" chapter="staticmod"|Configuring Ocsigen Server for serving static files>>
-* [[http://www.favicon.cc/|An example of a favicon generator]]
diff --git a/tutos/8.0/manual/how-to-add-a-javascript-script.mld b/tutos/8.0/manual/how-to-add-a-javascript-script.mld
new file mode 100644
index 00000000..3813c1eb
--- /dev/null
+++ b/tutos/8.0/manual/how-to-add-a-javascript-script.mld
@@ -0,0 +1,30 @@
+{0 How to add a JavaScript script?}
+
+If you have client-side programs on your website, you can use Eliom's client-server features, that will compile client-side parts to JS using {b Ocsigen Js_of_ocaml}, and automatically include the script in the page. But in some cases you may also want to include external JS scripts yourself.
+
+{2 Include the script on the html header}
+
+Javascript scripts are included in the header using the {b js_script} function (defined in {!Eliom_content.Html.D}).
+
+{@ocaml[
+open Eliom_content.Html.D (* for make_uri an js_script *)
+
+js_script
+     ~uri:(make_uri (Eliom_service.static_dir ())
+              ["hello.js"])
+     ()
+]}
+This function has 2 parameters: the file path and unit.
+
+The file path is generated using the {b make_uri} function (from {!Eliom_content.Html.D} module). This function creates the relative URL string using the static directory (which is a service) configured in the configuration file and the given list.
+
+Insert this piece of code on the list given in parameter to the {b head} function.
+
+Or you can use:
+{!Eliom_tools.F.head}
+
+{2 Call an external function}
+
+Have a look at
+{{:../js_of_ocaml/bindings.html}this page of Js_of_ocaml's manual}
+to understand how to call JS function from your OCaml program.
diff --git a/tutos/8.0/manual/how-to-add-a-javascript-script.wiki b/tutos/8.0/manual/how-to-add-a-javascript-script.wiki
deleted file mode 100644
index f4e81951..00000000
--- a/tutos/8.0/manual/how-to-add-a-javascript-script.wiki
+++ /dev/null
@@ -1,30 +0,0 @@
-=How to add a JavaScript script?=
-
-If you have client-side programs on your website, you can use Eliom's client-server features, that will compile client-side parts to JS using **Ocsigen Js_of_ocaml**, and automatically include the script in the page. But in some cases you may also want to include external JS scripts yourself.
-
-=== Include the script on the html header
-
-Javascript scripts are included in the header using the **js_script** function (defined in <<a_api project="eliom" subproject="server"| module Eliom_content.Html.D>>).
-
-<<code language="ocaml"|
-open Eliom_content.Html.D (* for make_uri an js_script *)
-
-js_script
-     ~uri:(make_uri (Eliom_service.static_dir ())
-              ["hello.js"])
-     ()
->>
-This function has 2 parameters: the file path and unit.
-
-The file path is generated using the **make_uri** function (from <<a_api project="eliom" subproject="server"| module Eliom_content.Html.D>> module). This function creates the relative URL string using the static directory (which is a service) configured in the configuration file and the given list.
-
-Insert this piece of code on the list given in parameter to the **head** function.
-
-Or you can use:
-<<a_api project="eliom" subproject="server"|val Eliom_tools.F.head>>
-
-=== Call an external function
-
-Have a look at
-<<a_manual project="js_of_ocaml" chapter="bindings"|this page of Js_of_ocaml's manual>>
-to understand how to call JS function from your OCaml program.
diff --git a/tutos/8.0/manual/how-to-add-a-list.mld b/tutos/8.0/manual/how-to-add-a-list.mld
new file mode 100644
index 00000000..3154f369
--- /dev/null
+++ b/tutos/8.0/manual/how-to-add-a-list.mld
@@ -0,0 +1,70 @@
+{0 How to add lists in a page?}
+
+{3 Simple list and ordered list}
+
+{4 Simple list}
+
+{@ocaml[
+  ul
+    [li [txt "first item"];
+     li [txt "second item"];
+     li [txt "third item"];
+     li [txt "fourth item"]]
+]}
+
+
+{4 Ordered list}
+
+{@ocaml[
+  ol
+    [li [txt "first item"];
+     li [txt "second item"]]
+]}
+
+{b Required parameter}: list containing {b li} elements ({{:../tyxml/api/Html_types#TYPEli_attrib}Details of li content}).
+
+{b Optional parameter} for attributes "a" ({{:wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements}How to set and id, classes or other attributes to HTML elements?}).
+
+{3 Definition list}
+
+{@ocaml[
+  dl
+    [((dt [txt "Banana"], []),
+      (dd [txt "An elongated curved fruit"], []));
+     ((dt [txt "Orange"], []),
+      (dd [txt "A globose, reddish-yellow, edible fruit"],
+       [dd [txt "A color between yellow and red"]]));
+     ((dt [txt "Kiwi"], []),
+      (dd [txt "Egg-sized green fruit from China"], []))]
+]}
+
+This kind of list contains definitions.
+
+{b Required parameter}:
+A list of pair of:
+- A pair containing:
+- The first element of type dt
+- A list of elements of type dt
+- Another pair containing:
+- The first element of type dd
+- A list of elements of type dd
+
+Details:
+- {{:../tyxml/api/Html_types#TYPEphrasing}dd content}
+- {{:../tyxml/api/Html_types#TYPEflow5}dt content}
+
+{b Optional parameter} for attributes "a" ({{:wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements}How to set and id, classes or other attributes to HTML elements?}).
+
+{2 Download full code}
+
+{e Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.}
+
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/elements/example.eliom}Read the full code}
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto}Download and try this example}
+
+{2 Links}
+
+- Modules {!Eliom_content.Html.D} and
+  {!Eliom_content.Html.F}
+  (HTML5 Elements)
+- signature {!Html_sigs.T} (Element attributes)
diff --git a/tutos/8.0/manual/how-to-add-a-list.wiki b/tutos/8.0/manual/how-to-add-a-list.wiki
deleted file mode 100644
index 82ab452d..00000000
--- a/tutos/8.0/manual/how-to-add-a-list.wiki
+++ /dev/null
@@ -1,70 +0,0 @@
-=How to add lists in a page?=
-
-==== Simple list and ordered list
-
-===== Simple list
-
-<<code language='ocaml'|
-  ul
-    [li [txt "first item"];
-     li [txt "second item"];
-     li [txt "third item"];
-     li [txt "fourth item"]]
->>
-
-
-===== Ordered list
-
-<<code language='ocaml'|
-  ol
-    [li [txt "first item"];
-     li [txt "second item"]]
->>
-
-**Required parameter**: list containing **li** elements ([[site:tyxml/api/Html_types#TYPEli_attrib|Details of li content]]).
-
-**Optional parameter** for attributes "a" ([[wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements|How to set and id, classes or other attributes to HTML elements?]]).
-
-==== Definition list
-
-<<code language='ocaml'|
-  dl
-    [((dt [txt "Banana"], []),
-      (dd [txt "An elongated curved fruit"], []));
-     ((dt [txt "Orange"], []),
-      (dd [txt "A globose, reddish-yellow, edible fruit"],
-       [dd [txt "A color between yellow and red"]]));
-     ((dt [txt "Kiwi"], []),
-      (dd [txt "Egg-sized green fruit from China"], []))]
->>
-
-This kind of list contains definitions.
-
-**Required parameter**:
-A list of pair of:
-* A pair containing:
-** The first element of type dt
-** A list of elements of type dt
-* Another pair containing:
-** The first element of type dd
-** A list of elements of type dd
-
-Details:
-* [[site:tyxml/api/Html_types#TYPEphrasing|dd content]]
-* [[site:tyxml/api/Html_types#TYPEflow5|dt content]]
-
-**Optional parameter** for attributes "a" ([[wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements|How to set and id, classes or other attributes to HTML elements?]]).
-
-=== Download full code
-
-//Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.//
-
-* [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/elements/example.eliom|Read the full code]]
-* [[https://github.com/db0company/Ocsigen-Quick-Howto|Download and try this example]]
-
-=== Links
-
-* Modules <<a_api project="eliom" subproject="server"|module Eliom_content.Html.D>> and
-  <<a_api project="eliom" subproject="server"|module Eliom_content.Html.F>>
-  (HTML5 Elements)
-* signature <<a_api project="tyxml"|module Html_sigs.T>> (Element attributes)
diff --git a/tutos/8.0/manual/how-to-add-a-select-or-other-form-element.wiki b/tutos/8.0/manual/how-to-add-a-select-or-other-form-element.mld
similarity index 61%
rename from tutos/8.0/manual/how-to-add-a-select-or-other-form-element.wiki
rename to tutos/8.0/manual/how-to-add-a-select-or-other-form-element.mld
index 1587abf9..34924117 100644
--- a/tutos/8.0/manual/how-to-add-a-select-or-other-form-element.wiki
+++ b/tutos/8.0/manual/how-to-add-a-select-or-other-form-element.mld
@@ -1,8 +1,8 @@
-=How to add a select (or other form element)?=
+{0 How to add a select (or other form element)?}
 
-=== In forms towards Eliom services:
+{2 In forms towards Eliom services:}
 
-<<code language='ocaml'|
+{@ocaml[
 open Eliom_content
 
 Html.D.Form.select ~name:select_name
@@ -20,23 +20,23 @@ Html.D.Form.select ~name:select_name
          [([a_disabled `Disabled], "Juliette", None, false);
           ([], "Alice", None, true);
           ([], "Germaine", Some (txt "Bob's mother"), false)]))]
->>
+]}
 
-=== Basic HTML5 elements without Eliom services
+{2 Basic HTML5 elements without Eliom services}
 For example if you want to use them with client side event handler.
 
-<<code language='ocaml'|
+{@ocaml[
 open Eliom_content.Html.D
 
 Raw.select [option (txt "hello");
             option ~a:[a_value "a"; a_selected `Selected] (txt "cool")]
->>
+]}
 
 
-=== Links
+{2 Links}
 
-* [[wiki:manual/how-to-write-forms|How to write forms]]
-* <<a_manual project="eliom" chapter="server-links"|Eliom forms and links>>
-* API
-  <<a_api project="eliom" subproject="server"|module Eliom_content.Html.D.Form>>
-* signature <<a_api project="tyxml"|module Html_sigs.T>> (Element attributes)
+- {{:wiki:manual/how-to-write-forms}How to write forms}
+- {{:../eliom/server-links.html}Eliom forms and links}
+- API
+  {!Eliom_content.Html.D.Form}
+- signature {!Html_sigs.T} (Element attributes)
diff --git a/tutos/8.0/manual/how-to-add-an-image.mld b/tutos/8.0/manual/how-to-add-an-image.mld
new file mode 100644
index 00000000..a7fdf896
--- /dev/null
+++ b/tutos/8.0/manual/how-to-add-an-image.mld
@@ -0,0 +1,46 @@
+{0 How to add an image?}
+
++ Internal image
+
+{@ocaml[
+  img ~alt:("Ocsigen Logo")
+      ~src:(make_uri
+              ~service:(Eliom_service.static_dir ())
+              ["ocsigen_logo.png"])
+    ()
+
+]}
+
++ External image
+
+{@ocaml[
+  img ~alt:("Ocsigen Logo")
+      ~src:(Xml.uri_of_string ("http://website.com/image.png"))
+    ()
+]}
+
+
+The function {b img} has 3 parameters:
+- {b alt}: A description of the image
+- {b src}: the URL of the image
+- unit
+
+For an internal image, the file path is generated using the {b make_uri} function. This function creates the relative URL string using the static directory configured in the configuration file and the given list.
+
+For an external image, you must convert the string url into uri using the {b uri_of_string} function. You can also create an {{:../eliom/server-services.html#unregistrable_services}external service}.
+
+{2 Download full code}
+
+{e Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.}
+
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/elements/example.eliom}Read the full code}
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto}Download and try this example}
+
+{2 Links}
+
+- Modules {!Eliom_content.Html.D} and
+  {!Eliom_content.Html.F}
+  (HTML5 Elements)
+- The {!Html_sigs.T.img} element
+- {{:http://en.wikipedia.org/wiki/Alt_attribute}Alt attribute}
+- signature {!Html_sigs.T} (Element attributes)
diff --git a/tutos/8.0/manual/how-to-add-an-image.wiki b/tutos/8.0/manual/how-to-add-an-image.wiki
deleted file mode 100644
index 8c7144c1..00000000
--- a/tutos/8.0/manual/how-to-add-an-image.wiki
+++ /dev/null
@@ -1,46 +0,0 @@
-=How to add an image?=
-
-#### Internal image
-
-<<code language='ocaml'|
-  img ~alt:("Ocsigen Logo")
-      ~src:(make_uri
-              ~service:(Eliom_service.static_dir ())
-              ["ocsigen_logo.png"])
-    ()
-
->>
-
-#### External image
-
-<<code language='ocaml'|
-  img ~alt:("Ocsigen Logo")
-      ~src:(Xml.uri_of_string ("http://website.com/image.png"))
-    ()
->>
-
-
-The function **img** has 3 parameters:
-* **alt**: A description of the image
-* **src**: the URL of the image
-* unit
-
-For an internal image, the file path is generated using the **make_uri** function. This function creates the relative URL string using the static directory configured in the configuration file and the given list.
-
-For an external image, you must convert the string url into uri using the **uri_of_string** function. You can also create an <<a_manual project="eliom" chapter="server-services" fragment="unregistrable_services"|external service>>.
-
-=== Download full code
-
-//Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.//
-
-* [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/elements/example.eliom|Read the full code]]
-* [[https://github.com/db0company/Ocsigen-Quick-Howto|Download and try this example]]
-
-=== Links
-
-* Modules <<a_api project="eliom" subproject="server"|module Eliom_content.Html.D>> and
-  <<a_api project="eliom" subproject="server"|module Eliom_content.Html.F>>
-  (HTML5 Elements)
-* The <<a_api project="tyxml"|val Html_sigs.T.img>> element
-* [[http://en.wikipedia.org/wiki/Alt_attribute|Alt attribute]]
-* signature <<a_api project="tyxml"|module Html_sigs.T>> (Element attributes)
diff --git a/tutos/8.0/manual/how-to-add-css-stylesheet.mld b/tutos/8.0/manual/how-to-add-css-stylesheet.mld
new file mode 100644
index 00000000..c2e44e11
--- /dev/null
+++ b/tutos/8.0/manual/how-to-add-css-stylesheet.mld
@@ -0,0 +1,45 @@
+{0 How to add a CSS stylesheet?}
+
+{e Warning: css_link and make_uri come from Eliom_content.Html.D module. This module is opened for each piece of code}
+
+CSS stylesheet are included in the header using the {b css_link} function.
+
+{@ocaml[
+css_link
+     ~uri:(make_uri (Eliom_service.static_dir ())
+              ["css";"style.css"])
+     ()
+]}
+This function has 2 parameters: the file path and unit.
+
+The file path is generated using the {b make_uri} function. This function creates the relative URL string using the static directory configured in the configuration file and the given list.
+
+{2 Where?}
+
+Insert this piece of code on the list given in parameter to the {b head} function:
+
+{@ocaml[
+  (html
+     (head (title (txt "Page Title"))
+        [css_link ~uri:(make_uri (Eliom_service.static_dir ())
+	        	  ["css";"style.css"]) ()])
+     (body [p [txt "Hello World!"]]))))
+]}
+
+Or you can use:
+{!Eliom_tools.F.head}
+
+
+
+{2 Download full code}
+
+{e Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.}
+
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/css/example.eliom}Read the full code}
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto}Download and try this example}
+
+{2 Links}
+
+- {{:../eliom/misc.html}About images, css and javascript}
+- {!Eliom_content.Html.D.make_uri}
+- {{:../ocsigenserver/staticmod.html}Configuring Ocsigen Server for serving static files}
diff --git a/tutos/8.0/manual/how-to-add-css-stylesheet.wiki b/tutos/8.0/manual/how-to-add-css-stylesheet.wiki
deleted file mode 100644
index 0a8b9741..00000000
--- a/tutos/8.0/manual/how-to-add-css-stylesheet.wiki
+++ /dev/null
@@ -1,45 +0,0 @@
-=How to add a CSS stylesheet?=
-
-//Warning: css_link and make_uri come from Eliom_content.Html.D module. This module is opened for each piece of code//
-
-CSS stylesheet are included in the header using the **css_link** function.
-
-<<code language="ocaml"|
-css_link
-     ~uri:(make_uri (Eliom_service.static_dir ())
-              ["css";"style.css"])
-     ()
->>
-This function has 2 parameters: the file path and unit.
-
-The file path is generated using the **make_uri** function. This function creates the relative URL string using the static directory configured in the configuration file and the given list.
-
-=== Where?
-
-Insert this piece of code on the list given in parameter to the **head** function:
-
-<<code language="ocaml"|
-  (html
-     (head (title (txt "Page Title"))
-        [css_link ~uri:(make_uri (Eliom_service.static_dir ())
-	        	  ["css";"style.css"]) ()])
-     (body [p [txt "Hello World!"]]))))
->>
-
-Or you can use:
-<<a_api project="eliom" subproject="server"|val Eliom_tools.F.head>>
-
-
-
-=== Download full code
-
-//Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.//
-
-* [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/css/example.eliom|Read the full code]]
-* [[https://github.com/db0company/Ocsigen-Quick-Howto|Download and try this example]]
-
-=== Links
-
-* <<a_manual project="eliom" chapter="misc"|About images, css and javascript>>
-* <<a_api project="eliom" subproject="server" |val Eliom_content.Html.D.make_uri>>
-* <<a_manual project="ocsigenserver" chapter="staticmod"|Configuring Ocsigen Server for serving static files>>
diff --git a/tutos/dev/manual/how-to-attach-ocaml-values-to-dom-elements.wiki b/tutos/8.0/manual/how-to-attach-ocaml-values-to-dom-elements.mld
similarity index 52%
rename from tutos/dev/manual/how-to-attach-ocaml-values-to-dom-elements.wiki
rename to tutos/8.0/manual/how-to-attach-ocaml-values-to-dom-elements.mld
index 797c11d2..b0297293 100644
--- a/tutos/dev/manual/how-to-attach-ocaml-values-to-dom-elements.wiki
+++ b/tutos/8.0/manual/how-to-attach-ocaml-values-to-dom-elements.mld
@@ -1,14 +1,14 @@
-=How to attach OCaml values to DOM elements?=
+{0 How to attach OCaml values to DOM elements?}
 
 It is often convenient to attach OCaml values to certain elements of
 the page. There are several ways to achieve this.
 
-* The first possibility is to use DATA attributes (for example if the
+- The first possibility is to use DATA attributes (for example if the
   page is generated on server side).
-* Alternatively, you can add a new property to the element using the
-  {{{##.}}} syntax.
-  ** You can create a new class type with the new property
+- Alternatively, you can add a new property to the element using the
+  [##.] syntax.
+- You can create a new class type with the new property
      (that can be either an OCaml value or a JS value), possibly
      inheriting from the type of the DOM element, and create an
      (unsafe) coercion function for this type; or simply
-  ** Create getter and setter functions to add the new property.
+- Create getter and setter functions to add the new property.
diff --git a/tutos/8.0/manual/how-to-attach-ocaml-values-to-the-html-nodes-sent-to-the-client.mld b/tutos/8.0/manual/how-to-attach-ocaml-values-to-the-html-nodes-sent-to-the-client.mld
new file mode 100644
index 00000000..989a6120
--- /dev/null
+++ b/tutos/8.0/manual/how-to-attach-ocaml-values-to-the-html-nodes-sent-to-the-client.mld
@@ -0,0 +1,3 @@
+{0 How to attach OCaml values to the HTML nodes sent to the client?}
+
+Use module {!Eliom_content.Html.Custom_data}.
diff --git a/tutos/8.0/manual/how-to-attach-ocaml-values-to-the-html-nodes-sent-to-the-client.wiki b/tutos/8.0/manual/how-to-attach-ocaml-values-to-the-html-nodes-sent-to-the-client.wiki
deleted file mode 100644
index f8c82a92..00000000
--- a/tutos/8.0/manual/how-to-attach-ocaml-values-to-the-html-nodes-sent-to-the-client.wiki
+++ /dev/null
@@ -1,3 +0,0 @@
-== How to attach OCaml values to the HTML nodes sent to the client?
-
-Use module <<a_api project="eliom" subproject="server"|module Eliom_content.Html.Custom_data>>.
diff --git a/tutos/8.0/manual/how-to-build-js-object.mld b/tutos/8.0/manual/how-to-build-js-object.mld
new file mode 100644
index 00000000..d6035f90
--- /dev/null
+++ b/tutos/8.0/manual/how-to-build-js-object.mld
@@ -0,0 +1,13 @@
+{0 How to build js object?}
+
+Use syntax [new%js]:
+
+Example:
+
+{@ocaml[
+let get_timestamp () =
+  let date = new%js Js.date_now in
+  int_of_float (Js.to_float (date##getTime))
+]}
+
+More details in documentation: {{!Js_of_ocaml.Js.constr}Js object constructor}
diff --git a/tutos/8.0/manual/how-to-build-js-object.wiki b/tutos/8.0/manual/how-to-build-js-object.wiki
deleted file mode 100644
index 7d68c627..00000000
--- a/tutos/8.0/manual/how-to-build-js-object.wiki
+++ /dev/null
@@ -1,13 +0,0 @@
-=How to build js object?=
-
-Use syntax {{{new%js}}}:
-
-Example:
-
-<<code language="ocaml"|
-let get_timestamp () =
-  let date = new%js Js.date_now in
-  int_of_float (Js.to_float (date##getTime))
->>
-
-More details in documentation: <<a_api project="js_of_ocaml" text="Js object constructor"|val Js_of_ocaml.Js.constr>>
diff --git a/tutos/dev/manual/how-to-call-a-server-side-function-from-client-side.wiki b/tutos/8.0/manual/how-to-call-a-server-side-function-from-client-side.mld
similarity index 52%
rename from tutos/dev/manual/how-to-call-a-server-side-function-from-client-side.wiki
rename to tutos/8.0/manual/how-to-call-a-server-side-function-from-client-side.mld
index ae2a580a..79598f08 100644
--- a/tutos/dev/manual/how-to-call-a-server-side-function-from-client-side.wiki
+++ b/tutos/8.0/manual/how-to-call-a-server-side-function-from-client-side.mld
@@ -1,36 +1,38 @@
-=How to call a server-side function from client-side?=
+{0 How to call a server-side function from client-side?}
 
 It is possible to call server-side functions from client-side.
 For security reasons, these functions must first
 be declared explicitly as RPCs (with the type of their
 argument).
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc f (x : int) : string Lwt.t = ...
 ...
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 [%client ... f 4 ... ]
->>
+]}
 
-The syntax is provided by opam package {{{ocsigen-ppx-rpc}}}.
+The syntax is provided by opam package [ocsigen-ppx-rpc].
 
-The server-side function ({{{f}}} in the example) needs to return a
+The server-side function ([f] in the example) needs to return a
 Lwt value.
 
 Server functions are just syntactic sugar for pathless services
 returning OCaml values.
 
-Note that you need to install {{{ppx_deriving}}}, and load our JSON
-{{{ppx_deriving}}} plugin in your project. The plugin is available as
-the Ocamlfind package {{{js_of_ocaml.deriving.ppx}}}.
+Note that you need to install [ppx_deriving], and load our JSON
+[ppx_deriving] plugin in your project. The plugin is available as
+the Ocamlfind package [js_of_ocaml.deriving.ppx].
 
 If the function takes a more complex type, this type must have been
-declared with {{{ppx_deriving}}}. For example,
+declared with [ppx_deriving]. For example,
 
-<<code language="ocaml"|
+{@ocaml[
 type t = int * string [@@deriving json]
->>
+]}
 
 Our infrastructure provides server-side data validation of the data
 sent, and prevents malformed data from crashing the server.
diff --git a/tutos/8.0/manual/how-to-call-an-ocaml-function-from-js-code.mld b/tutos/8.0/manual/how-to-call-an-ocaml-function-from-js-code.mld
new file mode 100644
index 00000000..5ef9e8a1
--- /dev/null
+++ b/tutos/8.0/manual/how-to-call-an-ocaml-function-from-js-code.mld
@@ -0,0 +1,3 @@
+{0 How to call an OCaml function from JS code?}
+
+Have a look at function {!Js_of_ocaml.Js.wrap_callback}
diff --git a/tutos/8.0/manual/how-to-call-an-ocaml-function-from-js-code.wiki b/tutos/8.0/manual/how-to-call-an-ocaml-function-from-js-code.wiki
deleted file mode 100644
index 50adfdd1..00000000
--- a/tutos/8.0/manual/how-to-call-an-ocaml-function-from-js-code.wiki
+++ /dev/null
@@ -1,3 +0,0 @@
-=How to call an OCaml function from JS code?=
-
-Have a look at function <<a_api project="js_of_ocaml" |val Js_of_ocaml.Js.wrap_callback>>
diff --git a/tutos/8.0/manual/how-to-compile-my-ocsigen-pages.wiki b/tutos/8.0/manual/how-to-compile-my-ocsigen-pages.mld
similarity index 52%
rename from tutos/8.0/manual/how-to-compile-my-ocsigen-pages.wiki
rename to tutos/8.0/manual/how-to-compile-my-ocsigen-pages.mld
index 65485504..ed648129 100644
--- a/tutos/8.0/manual/how-to-compile-my-ocsigen-pages.wiki
+++ b/tutos/8.0/manual/how-to-compile-my-ocsigen-pages.mld
@@ -1,41 +1,41 @@
-=How to compile my Ocsigen pages?=
+{0 How to compile my Ocsigen pages?}
 
-=== Eliom distillery
+{2 Eliom distillery}
 
 Eliom-distillery will help you to build your client-server application
 using Eliom.
 It comes with several templates ("client-server.basic", "os.pgocaml",
 and more to come  ...).
 
-{{{
+{v
 $ eliom-distillery -name <name> -template client-server.basic [-target-directory <dir>]
-}}}
+v}
 
 Eliom distillery will also create a default configuration file for Ocsigen
 Server.
 
 More information on Eliom distillery in
-<<a_manual project="eliom" subproject="server" chapter="workflow-distillery"|Eliom's manual>>.
+{{:../eliom/workflow-distillery.html}Eliom's manual}.
 
 More information on how client-server Eliom project are compiled on
-<<a_manual project="eliom" subproject="server" chapter="workflow-compilation"|this page>>.
+{{:../eliom/workflow-compilation.html}this page}.
 
 If you don't need client-server features, the compilation process is very
-simple and without surprise. Compile with {{{ocamlc}}} or {{{ocamlopt}}}
-using {{{ocamlfind}}}, with package {{{eliom.server}}}.
+simple and without surprise. Compile with [ocamlc] or [ocamlopt]
+using [ocamlfind], with package [eliom.server].
 You will have to create your configuration file manually.
 But you can still use Eliom distillery, which will make easier the inclusion
 of client side features, later.
 
 
-=== Compilation details
+{2 Compilation details}
 
-* **eliomdep** helps you handle dependencies of eliom files
-* **eliomc** compile server-side eliom files (and ml files too)
-* **js_of_eliom** compile client-side eliom files
+- {b eliomdep} helps you handle dependencies of eliom files
+- {b eliomc} compile server-side eliom files (and ml files too)
+- {b js_of_eliom} compile client-side eliom files
 
 Read manuals for mor information about these compilers.
 
-=== Links
+{2 Links}
 
-* <<a_manual project="eliom" chapter="workflow-compilation" |Full documentation about Ocsigen compilation>>
+- {{:../eliom/workflow-compilation.html}Full documentation about Ocsigen compilation}
diff --git a/tutos/8.0/manual/how-to-configure-and-launch-the-ocsigen-server.mld b/tutos/8.0/manual/how-to-configure-and-launch-the-ocsigen-server.mld
new file mode 100644
index 00000000..6021acab
--- /dev/null
+++ b/tutos/8.0/manual/how-to-configure-and-launch-the-ocsigen-server.mld
@@ -0,0 +1,23 @@
+{0 How to configure and launch the Ocsigen Server?}
+
+{2 Default configuration file}
+
+- Eliom distillery is generating a configuration file
+- If you want to create it yourself, you can have a look at the default configuration file provided with the installation of Ocsigen (usually [/etc/ocsigenserver/ocsigenserver.conf.sample]).
+- Change the port by the network port number you want your website to work on. The port {b 80} is the port used by http by default but you need to be the administrator of your server to use it.
+- Adapt paths.
+- Change other parameters that suit your needs using the {{:../ocsigenserver/config.html}configuration file documentation}.
+
+{2 Your own configuration file}
+
+Have a look at the {{:../ocsigenserver/config.html}configuration file full documentation}.
+
+{2 Launch the server}
+
+{[
+ocsigenserver -c your_config_file.conf
+]}
+
+{2 Links}
+
+- More information about this command or the configuration file in {{:../ocsigenserver/.html}Ocsigen Server's manual}.
diff --git a/tutos/8.0/manual/how-to-configure-and-launch-the-ocsigen-server.wiki b/tutos/8.0/manual/how-to-configure-and-launch-the-ocsigen-server.wiki
deleted file mode 100644
index 84ae6fca..00000000
--- a/tutos/8.0/manual/how-to-configure-and-launch-the-ocsigen-server.wiki
+++ /dev/null
@@ -1,23 +0,0 @@
-=How to configure and launch the Ocsigen Server?=
-
-=== Default configuration file
-
-* Eliom distillery is generating a configuration file
-* If you want to create it yourself, you can have a look at the default configuration file provided with the installation of Ocsigen (usually {{{/etc/ocsigenserver/ocsigenserver.conf.sample}}}).
-* Change the port by the network port number you want your website to work on. The port **80** is the port used by http by default but you need to be the administrator of your server to use it.
-* Adapt paths.
-* Change other parameters that suit your needs using the <<a_manual project="ocsigenserver" chapter="config"|configuration file documentation>>.
-
-=== Your own configuration file
-
-Have a look at the <<a_manual project="ocsigenserver" chapter="config"|configuration file full documentation>>.
-
-=== Launch the server
-
-<<code |
-ocsigenserver -c your_config_file.conf
->>
-
-=== Links
-
-* More information about this command or the configuration file in <<a_manual project="ocsigenserver"|Ocsigen Server's manual>>.
diff --git a/tutos/8.0/manual/how-to-create-form-wizard-sequence-of-pages-depending-on-data-entered-on-previous-ones.wiki b/tutos/8.0/manual/how-to-create-form-wizard-sequence-of-pages-depending-on-data-entered-on-previous-ones.mld
similarity index 96%
rename from tutos/8.0/manual/how-to-create-form-wizard-sequence-of-pages-depending-on-data-entered-on-previous-ones.wiki
rename to tutos/8.0/manual/how-to-create-form-wizard-sequence-of-pages-depending-on-data-entered-on-previous-ones.mld
index 617ae882..8e448a4a 100644
--- a/tutos/8.0/manual/how-to-create-form-wizard-sequence-of-pages-depending-on-data-entered-on-previous-ones.wiki
+++ b/tutos/8.0/manual/how-to-create-form-wizard-sequence-of-pages-depending-on-data-entered-on-previous-ones.mld
@@ -1,4 +1,4 @@
-=How to create a form wizard (sequence of pages depending on data entered on previous ones)?=
+{0 How to create a form wizard (sequence of pages depending on data entered on previous ones)?}
 
 The solution to implement wizard-like forms (that is a sequence of pages
 depending on data entered on previous ones) is to create dynamically new
@@ -15,7 +15,7 @@ To prevent memory leaks, use a timeout for these dynamic coservices.
 The scope of these service can be session or global for the site (as coservice
 identifiers are cryptographically safe).
 
-<<code language="ocaml"|
+{@ocaml[
 open Eliom_content.Html.F
 
 (* -------------------------------------------------------- *)
@@ -85,4 +85,4 @@ let calc_i_handler i () =
 let () =
   Eliom_registration.Html.register calc   calc_handler;
   Eliom_registration.Html.register calc_i calc_i_handler
->>
+]}
diff --git a/tutos/8.0/manual/how-to-create-link-to-a-current-page-without-knowing-its-url.mld b/tutos/8.0/manual/how-to-create-link-to-a-current-page-without-knowing-its-url.mld
new file mode 100644
index 00000000..83ecd924
--- /dev/null
+++ b/tutos/8.0/manual/how-to-create-link-to-a-current-page-without-knowing-its-url.mld
@@ -0,0 +1,11 @@
+{0 How to create a link to the current page (without knowing its URL)?}
+
+Void coservices are here for that:
+{@ocaml[
+a ~service:Eliom_service.reload_action
+  [txt "Click to reload"] ();
+]}
+
+More information in
+{{:../eliom/server-services.html#void}Eliom's manual}, and API documentation of
+{!Eliom_service.reload_action}.
diff --git a/tutos/8.0/manual/how-to-create-link-to-a-current-page-without-knowing-its-url.wiki b/tutos/8.0/manual/how-to-create-link-to-a-current-page-without-knowing-its-url.wiki
deleted file mode 100644
index 69e2973d..00000000
--- a/tutos/8.0/manual/how-to-create-link-to-a-current-page-without-knowing-its-url.wiki
+++ /dev/null
@@ -1,11 +0,0 @@
-=How to create a link to the current page (without knowing its URL)?=
-
-Void coservices are here for that:
-<<code language="ocaml"|
-a ~service:Eliom_service.reload_action
-  [txt "Click to reload"] ();
->>
-
-More information in
-<<a_manual project="eliom" chapter="server-services" fragment="void"|Eliom's manual>>, and API documentation of
-<<a_api project="eliom" subproject="server"|val Eliom_service.reload_action>>.
diff --git a/tutos/8.0/manual/how-to-detect-channel-disconnection.wiki b/tutos/8.0/manual/how-to-detect-channel-disconnection.mld
similarity index 78%
rename from tutos/8.0/manual/how-to-detect-channel-disconnection.wiki
rename to tutos/8.0/manual/how-to-detect-channel-disconnection.mld
index 23c419d8..e217b823 100644
--- a/tutos/8.0/manual/how-to-detect-channel-disconnection.wiki
+++ b/tutos/8.0/manual/how-to-detect-channel-disconnection.mld
@@ -1,24 +1,24 @@
-=How to detect channel disconnection
+{0 How to detect channel disconnection}
 
-==Question
+{1 Question}
 
  Is there a way to detect that some Eliom_comet channel became
  disconnected? I would like to warn the user if the server becomes
  unreachable.
 
-==Answer
+{1 Answer}
 
 If you are using Ocsigen-start, you probably have nothing to do.
 Ocsigen-start will monitor the life of sessions and close the process
 when needed.
 
 If you are not using Ocsigen-start, you must catch exceptions
-{{{Eliom_comet.Channel_full}}},
-{{{Eliom_comet.Channel_closed}}} (and {{{Eliom_comet.Process_closed}}}
-on Eliom < 5). Have a look at module {{{Os_comet}}} in
+[Eliom_comet.Channel_full],
+[Eliom_comet.Channel_closed] (and [Eliom_comet.Process_closed]
+on Eliom < 5). Have a look at module [Os_comet] in
 Ocsigen-start.
 
-//explanation pasted from Ocsigen mailing list, 2014-08-06://
+{e explanation pasted from Ocsigen mailing list, 2014-08-06:}
 
 I assume that you want to know that from client side (it is also
 possible to know that on server side).
@@ -28,11 +28,11 @@ information through an exception when you try to read from the
 Lwt_stream. The different exceptions you have to handle depending on the
 case are:
 
-;{{{Eliom_comet.Channel_full}}}
+;[Eliom_comet.Channel_full]
 :For global channel. Those are never closed on server side and are not attached to a particular session. The server maintains a limited buffer of previous values to avoid memory leak. If a client reconnects to the network and too many messages have been sent to the channel since its last update, it will receive that exception.
-;{{{Eliom_comet.Process_closed}}} (Eliom < 5)
+;[Eliom_comet.Process_closed] (Eliom < 5)
 :For a channel associated to a client process. If the process is explicitly closed on the server, the server is rebooted, it timed out, ...
-;{{{Eliom_comet.Channel_closed}}}
+;[Eliom_comet.Channel_closed]
 :The channel was not maintained alive on the server (garbage collected).
 
 Usually it is just simpler to not distinguish and just catch all those
@@ -44,12 +44,12 @@ is to map your channel through Lwt_stream.map_exn and handle the
 exceptions at that point.
 
 Depending on your case the strategies I would recommend would be either:
-* If you maintain a global state between the client and the server, it
+- If you maintain a global state between the client and the server, it
 is usualy easier to rebuild it from scratch than to rebuild only the
 missing parts: i.e. the braindead/failure proof solution is to reload
 the complete contents
-{{{(Eliom_client.exit_to ~service.Eliom_service.reload_action () ())}}}.
-* If you only want to follow a stream of events and missing a few in the
+[(Eliom_client.exit_to ~service.Eliom_service.reload_action () ())].
+- If you only want to follow a stream of events and missing a few in the
 middle isn't a problem, you can just provides a Caml service that sends
 a channel, and when your channel disconnects, you just fetch a new one.
 (You may have to use Lwt_stream.concat to do the plumbing)
diff --git a/tutos/8.0/manual/how-to-detect-on-client-side-that-the-server-side-state-for-the-process-is-closed.wiki b/tutos/8.0/manual/how-to-detect-on-client-side-that-the-server-side-state-for-the-process-is-closed.mld
similarity index 59%
rename from tutos/8.0/manual/how-to-detect-on-client-side-that-the-server-side-state-for-the-process-is-closed.wiki
rename to tutos/8.0/manual/how-to-detect-on-client-side-that-the-server-side-state-for-the-process-is-closed.mld
index d2dde172..f368dddf 100644
--- a/tutos/8.0/manual/how-to-detect-on-client-side-that-the-server-side-state-for-the-process-is-closed.wiki
+++ b/tutos/8.0/manual/how-to-detect-on-client-side-that-the-server-side-state-for-the-process-is-closed.mld
@@ -1,13 +1,13 @@
-= How to detect on client side that the server side state for the process is closed? =
+{0 How to detect on client side that the server side state for the process is closed?}
 
 If you are using Ocsigen-start, you probably have nothing to do.
 Ocsigen-start will monitor the life of sessions and close the process
 when needed.
 
 If you are not using Ocsigen-start, you must catch exceptions
-{{{Eliom_comet.Channel_full}}},
-{{{Eliom_comet.Channel_closed}}} (and {{{Eliom_comet.Process_closed}}}
+[Eliom_comet.Channel_full],
+[Eliom_comet.Channel_closed] (and [Eliom_comet.Process_closed]
 on Eliom < 5).
 For example, you can use a channel with a different client-process scope
 to warn client processes that the session is closed.
-Have a look at module {{{Os_comet}}} in Ocsigen-start.
+Have a look at module [Os_comet] in Ocsigen-start.
diff --git a/tutos/8.0/manual/how-to-do-links-to-other-pages.wiki b/tutos/8.0/manual/how-to-do-links-to-other-pages.mld
similarity index 91%
rename from tutos/8.0/manual/how-to-do-links-to-other-pages.wiki
rename to tutos/8.0/manual/how-to-do-links-to-other-pages.mld
index 1f220a7d..1b1d8aad 100644
--- a/tutos/8.0/manual/how-to-do-links-to-other-pages.wiki
+++ b/tutos/8.0/manual/how-to-do-links-to-other-pages.mld
@@ -1,8 +1,8 @@
-=How to do links to other pages?=
+{0 How to do links to other pages?}
 
 Examples:
 
-<<code language="ocaml"|
+{@ocaml[
 (* Link to a service without parameter: *)
 Html.D.a ~service:coucou [txt "coucou"] ();
 
@@ -25,4 +25,4 @@ Html.F.Raw.a
   ~a:[a_href (Xml.uri_of_string "http://en.wikipedia.org/wiki/OCaml")]
   [txt "OCaml on wikipedia"]
 
->>
+]}
diff --git a/tutos/8.0/manual/how-to-implement-a-notification-system.wiki b/tutos/8.0/manual/how-to-implement-a-notification-system.mld
similarity index 61%
rename from tutos/8.0/manual/how-to-implement-a-notification-system.wiki
rename to tutos/8.0/manual/how-to-implement-a-notification-system.mld
index 31e4ee08..d3b2d634 100644
--- a/tutos/8.0/manual/how-to-implement-a-notification-system.wiki
+++ b/tutos/8.0/manual/how-to-implement-a-notification-system.mld
@@ -1,46 +1,47 @@
-=How to implement a notification system?=
+{0 How to implement a notification system?}
 
 The easiest way for the server to send notifications to the client is
-to use module <<a_api project="ocsigen-start"|module Os_notif>> from
+to use module {!Os_notif} from
 Ocsigen-start (OS), but it requires to use OS's user management
 system. If you are not using OS, we recommend to get inspiration from
 the code of this module, to implement your notification system
 conveniently and without memory leak.
 
-== With {{{Os_notif}}}
+{1 With [Os_notif]}
 
 For each type of data on which you want to receive updates,
-instanciate functor {{{Os_notif.Make_Simple}}} on server side:
+instanciate functor [Os_notif.Make_Simple] on server side:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 module My_notif = Os_notif.Make_Simple (struct
   type key = ... (* The type of the identifier of the data we want listen on. *)
   type notification = ... (* The type of the notifications that will be sent *)
 end)
->>
+]}
 
-To declare that you are listening on one piece of data {{{i}}},
-call {{{My_notif.listen i}}}.
+To declare that you are listening on one piece of data [i],
+call [My_notif.listen i].
 
-To notify all the clients listening on data {{{i}}},
-call {{{My_notif.notify i (fun userid_o -> Lwt.return (Some notif))}}}.
-{{{userid_o}}} is the id of the user who will be notified,
-if he is connected ({{{None}}} otherwise).
+To notify all the clients listening on data [i],
+call [My_notif.notify i (fun userid_o -> Lwt.return (Some notif))].
+[userid_o] is the id of the user who will be notified,
+if he is connected ([None] otherwise).
 This make possible to customize the notifications.
-Return {{{None}}} if you don't want him to be notified.
+Return [None] if you don't want him to be notified.
 
 For more information, have a look at
-<<a_manual project="tutorial" chapter="tutoreact"|the tutorial
-about client-server reactive applications>>.
+{{:tutoreact.html}the tutorial
+about client-server reactive applications}.
 
 
 
-== Without {{{Os_notif}}} (manual implementation)
+{1 Without [Os_notif] (manual implementation)}
 
 If you want the user to receive notifications from the server
 (for example: "you have a new message"), first create a channel, and
-register it in an Eliom reference of scope {{{`Client_process}}}:
-<<code language="ocaml"|
+register it in an Eliom reference of scope [`Client_process]:
+{@ocaml[
 let channel_ref =
   Eliom_reference.Volatile.eref_from_fun
     ~scope:Eliom_common.default_process_scope
@@ -49,11 +50,11 @@ let channel_ref =
        let c = Eliom_comet.Channel.create s in
        (c, notify)
     )
->>
+]}
 
 On client side, listen on this channel. To do that, execute this code
 (on server side) during the service that will start the client process:
-<<code language="ocaml"|
+{@ocaml[
 let (channel, _) = Eliom_reference.Volatile.get channel_ref in
 let _ =
   [%client
@@ -65,22 +66,22 @@ let _ =
   ]
 in
 ...
->>
+]}
 
-And call function {{{notify}}} on the channel (from server side)
+And call function [notify] on the channel (from server side)
 when you want to notify the client.
 
-To get back the {{{notify}}} functions for one user, you may want to
-[[how-to-iterate-on-all-sessions-for-one-user-or-all-tabs|iterate on all client process states]].
+To get back the [notify] functions for one user, you may want to
+{{:how-to-iterate-on-all-sessions-for-one-user-or-all-tabs.html}iterate on all client process states}.
 To do that, create a session group for each user
-(see [[how-to-register-session-data|How to register session data]]).
+(see {{:how-to-register-session-data.html}How to register session data}).
 Here we suppose that the session group name is the user_id, as a string.
 Then iterate on all sessions from this group, and on all client processes
 for each session.
 
 For example:
 
-<<code language="ocaml"|
+{@ocaml[
 
 let notify user_id v =
   (* We get the session group state for this user: *)
@@ -99,12 +100,12 @@ let notify user_id v =
           let (_, notify) = Eliom_reference.Volatile.Ext.get state channel_ref in
           notify (Some v)))
 
->>
+]}
 
-//Warning://      If you do not call the iterators during
+{e Warning:}      If you do not call the iterators during
       a request or during the initialisation phase of the Eliom module,
-      you must provide the extra parameter {{{?sitedata}}},
-      that you can get by calling {{{Eliom_request_info.get_sitedata}}}
+      you must provide the extra parameter [?sitedata],
+      that you can get by calling [Eliom_request_info.get_sitedata]
       during the initialisation phase of the Eliom module.
 
-Have a look at the implementation of {{{Os_notif}}} for more details.
+Have a look at the implementation of [Os_notif] for more details.
diff --git a/tutos/8.0/manual/how-to-insert-raw-form-elements-not-belonging-to-a-form-towards-a-service.wiki b/tutos/8.0/manual/how-to-insert-raw-form-elements-not-belonging-to-a-form-towards-a-service.mld
similarity index 57%
rename from tutos/8.0/manual/how-to-insert-raw-form-elements-not-belonging-to-a-form-towards-a-service.wiki
rename to tutos/8.0/manual/how-to-insert-raw-form-elements-not-belonging-to-a-form-towards-a-service.mld
index 83848a48..aa9a0656 100644
--- a/tutos/8.0/manual/how-to-insert-raw-form-elements-not-belonging-to-a-form-towards-a-service.wiki
+++ b/tutos/8.0/manual/how-to-insert-raw-form-elements-not-belonging-to-a-form-towards-a-service.mld
@@ -1,20 +1,20 @@
-=How to insert "raw" form elements (not belonging to a form towards a service)?=
+{0 How to insert "raw" form elements (not belonging to a form towards a service)?}
 
 Eliom redefines most forms elements (inputs, textareas, checkboxes, etc.)
 to make possible to check the type of the form w.r.t. the type of the service.
 
 If you don't want that (for example if you want to use it only from a client side program),
 you can use "raw form elements" (that is, basic tyxml elements), using
-module [[wiki("eliom"):api/server/Eliom_content.Html.D.Raw|{{{Eliom_content.Html.D.Raw}}}]]
-(or [[wiki("eliom"):api/server/Eliom_content.Html.F.Raw|{{{Eliom_content.Html.F.Raw}}}]]).
+module {{:../eliom/api/server/Eliom_content.Html.D.Raw}[Eliom_content.Html.D.Raw]}
+(or {{:../eliom/api/server/Eliom_content.Html.F.Raw}[Eliom_content.Html.F.Raw]}).
 
 Example:
 
-<<code language='ocaml'|
+{@ocaml[
 {{{
 open Eliom_content.Html.D
 
 Raw.textarea (txt "blah")
 
 }}}
->>
+]}
diff --git a/tutos/8.0/manual/how-to-iterate-on-all-sessions-for-one-user-or-all-tabs.wiki b/tutos/8.0/manual/how-to-iterate-on-all-sessions-for-one-user-or-all-tabs.mld
similarity index 87%
rename from tutos/8.0/manual/how-to-iterate-on-all-sessions-for-one-user-or-all-tabs.wiki
rename to tutos/8.0/manual/how-to-iterate-on-all-sessions-for-one-user-or-all-tabs.mld
index be9755d0..dbb68dcc 100644
--- a/tutos/8.0/manual/how-to-iterate-on-all-sessions-for-one-user-or-all-tabs.wiki
+++ b/tutos/8.0/manual/how-to-iterate-on-all-sessions-for-one-user-or-all-tabs.mld
@@ -1,10 +1,10 @@
-=How to iterate on all session belonging to the same user, or all tabs?=
+{0 How to iterate on all session belonging to the same user, or all tabs?}
 
 You must create a session group for each user, then iterate on all
 the sessions from this group, and possibly on all client processes
 for each session:
 
-<<code language="ocaml"|
+{@ocaml[
 
   (* We get the session group state for this user: *)
   let state =
@@ -22,4 +22,4 @@ for each session:
         (fun state ->
           let a = Eliom_reference.Volatile.Ext.get state my_ref in
           ...)))
->>
+]}
diff --git a/tutos/dev/manual/how-to-know-whether-the-browser-window-has-the-focus-or-not.wiki b/tutos/8.0/manual/how-to-know-whether-the-browser-window-has-the-focus-or-not.mld
similarity index 77%
rename from tutos/dev/manual/how-to-know-whether-the-browser-window-has-the-focus-or-not.wiki
rename to tutos/8.0/manual/how-to-know-whether-the-browser-window-has-the-focus-or-not.mld
index f8383288..d0b15bcf 100644
--- a/tutos/dev/manual/how-to-know-whether-the-browser-window-has-the-focus-or-not.wiki
+++ b/tutos/8.0/manual/how-to-know-whether-the-browser-window-has-the-focus-or-not.mld
@@ -1,8 +1,8 @@
-=How to know whether the browser window has the focus or not?=
+{0 How to know whether the browser window has the focus or not?}
 
 Example:
 
-<<code language="ocaml"|
+{@ocaml[
 
 let has_focus = ref true
 
@@ -13,4 +13,4 @@ let _ =
   async (fun () -> blurs (Js.Unsafe.coerce (Dom_html.window))
     (fun _ _ -> has_focus := false; Lwt.return ()));
 
->>
+]}
diff --git a/tutos/8.0/manual/how-to-make-hello-world-in-ocsigen.mld b/tutos/8.0/manual/how-to-make-hello-world-in-ocsigen.mld
new file mode 100644
index 00000000..78930bda
--- /dev/null
+++ b/tutos/8.0/manual/how-to-make-hello-world-in-ocsigen.mld
@@ -0,0 +1,49 @@
+{0 How to make a "hello world" in Ocsigen?}
+
+Here it is! The famous "{b Hello World}" for a client/server Eliom application:
+
+{2 }
+
+{@ocaml[
+open Eliom_content
+open Html.D
+open Eliom_parameter
+
+module Example =
+  Eliom_registration.App
+    (struct
+      let application_name = "example"
+     end)
+
+let main =
+  Eliom_service.create
+    ~path:(Eliom_service.Path [])
+    ~meth:(Eliom_service.Get unit)
+    ()
+
+let _ =
+
+  Example.register
+    ~service:main
+    (fun () () ->
+      Lwt.return
+	(html
+	   (head (title (txt "Hello World of Ocsigen")) [])
+	   (body [h1 [txt "Hello World!"];
+		  p [txt "Welcome to my first Ocsigen website."]])))
+
+]}
+
+{2 }
+
+- To {e understand} this code, have a look at
+{{:wiki:manual/how-does-a-page-s-source-code-look}How does a page's source code look?}
+- Or directly continue by compiling this code:
+{{:wiki:manual/how-to-compile-my-ocsigen-pages}How to compile my Ocsigen pages?}
+
+
+
+{2 Links}
+
+- {{:wiki:manual/application}Tutorial to write a client/server application}
+- {{:wiki:manual/interaction}Tutorial to write a server side web site}
diff --git a/tutos/8.0/manual/how-to-make-hello-world-in-ocsigen.wiki b/tutos/8.0/manual/how-to-make-hello-world-in-ocsigen.wiki
deleted file mode 100644
index 1522d87e..00000000
--- a/tutos/8.0/manual/how-to-make-hello-world-in-ocsigen.wiki
+++ /dev/null
@@ -1,56 +0,0 @@
-=How to make a "hello world" in Ocsigen?=
-
-Here it is! The famous "**Hello World**" for a client/server Eliom application:
-
-===
-
-<<code language="ocaml"|
-open Eliom_content
-open Html.D
-open Eliom_parameter
-
-module Example =
-  Eliom_registration.App
-    (struct
-      let application_name = "example"
-     end)
-
-let main =
-  Eliom_service.create
-    ~path:(Eliom_service.Path [])
-    ~meth:(Eliom_service.Get unit)
-    ()
-
-let _ =
-
-  Example.register
-    ~service:main
-    (fun () () ->
-      Lwt.return
-	(html
-	   (head (title (txt "Hello World of Ocsigen")) [])
-	   (body [h1 [txt "Hello World!"];
-		  p [txt "Welcome to my first Ocsigen website."]])))
-
->>
-
-===
-
-* To //understand// this code, have a look at
-[[wiki:manual/how-does-a-page-s-source-code-look|How does a page's source code look?]]
-* Or directly continue by compiling this code:
-[[wiki:manual/how-to-compile-my-ocsigen-pages|How to compile my Ocsigen pages?]]
-
-<<|
-=== Download full code
-
-//Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.//
-
-* [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/page/example.eliom|Read the full code]]
-* [[https://github.com/db0company/Ocsigen-Quick-Howto|Download and try this example]]
->>
-
-=== Links
-
-* [[wiki:manual/application|Tutorial to write a client/server application]]
-* [[wiki:manual/interaction|Tutorial to write a server side web site]]
diff --git a/tutos/8.0/manual/how-to-make-page-a-skeleton.wiki b/tutos/8.0/manual/how-to-make-page-a-skeleton.mld
similarity index 54%
rename from tutos/8.0/manual/how-to-make-page-a-skeleton.wiki
rename to tutos/8.0/manual/how-to-make-page-a-skeleton.mld
index aa190ef6..3d996af5 100644
--- a/tutos/8.0/manual/how-to-make-page-a-skeleton.wiki
+++ b/tutos/8.0/manual/how-to-make-page-a-skeleton.mld
@@ -1,46 +1,36 @@
-=How to make a page skeleton?=
+{0 How to make a page skeleton?}
 
-=== The same header for all your pages
+{2 The same header for all your pages}
 
 When your site will grow, you will have several different services for pages which will often contain the same header information.
 
 A great solution to avoid code copy-pasting of this recurrent information is to make a page skeleton function:
 
-<<code language="ocaml"|
+{@ocaml[
 let skeleton body_content =
   Lwt.return
     (html
        (head (title (txt "Page Title")) [])
        (body body_content)))
->>
+]}
 
 So when you define your pages, you just call this skeleton with the content of the page as an argument:
 
-<<code language="ocaml"|
+{@ocaml[
   Example.register ~service:main
     (fun () () -> skeleton [p [txt "Hello World!"]])
->>
+]}
 
 
 This method can also be adapted to add elements on all your pages, like a header, a footer and a menu.
 
-Module <<a_api project="eliom"  subproject="server"| module Eliom_tools >> has a predefined function
+Module {!Eliom_tools} has a predefined function
 for this:
 
-<<code language="ocaml"|
+{@ocaml[
 Eliom_tools.D.html
   ~title:"ex"
   ~css:[["css"; "ex.css"]]
   (body [h2 [txt "Welcome to Ocsigen!"]]
->>
+]}
 
-<<|The following example is more complete.
-
-
-=== Download full code
-
-//Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.//
-
-* [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/skeleton/example.eliom|Read the full code]]
-* [[https://github.com/db0company/Ocsigen-Quick-Howto|Download and try this example]]
->>
\ No newline at end of file
diff --git a/tutos/dev/manual/how-to-make-responsive-css.wiki b/tutos/8.0/manual/how-to-make-responsive-css.mld
similarity index 73%
rename from tutos/dev/manual/how-to-make-responsive-css.wiki
rename to tutos/8.0/manual/how-to-make-responsive-css.mld
index 3f173245..54df225c 100644
--- a/tutos/dev/manual/how-to-make-responsive-css.wiki
+++ b/tutos/8.0/manual/how-to-make-responsive-css.mld
@@ -1,13 +1,13 @@
-=How to make reponsive CSS with ocsigen?=
+{0 How to make reponsive CSS with ocsigen?}
 
 The best way to do that is to make one general css sheet plus three css sheets, small, medium and large screen using media queries, a feature introduced in CSS3.
 
 Write theses lines in your css sheets:
 
-<<code language="css"|
+{@css[
 @media only screen and (max-device-width: 480px)
 @media only screen and (min-device-width: 481px) and (max-device-width: 768px)
 @media only screen and (min-device-width: 769px)
->>
+]}
 
-You can find more information about making responsive websites with media queries on [[http://www.w3schools.com/css/css_rwd_mediaqueries.asp|W3schools.com]]
+You can find more information about making responsive websites with media queries on {{:http://www.w3schools.com/css/css_rwd_mediaqueries.asp}W3schools.com}
diff --git a/tutos/8.0/manual/how-to-make-the-client-side-program-get-an-html-element-from-the-server-and-insert-it-in-the-page.wiki b/tutos/8.0/manual/how-to-make-the-client-side-program-get-an-html-element-from-the-server-and-insert-it-in-the-page.mld
similarity index 64%
rename from tutos/8.0/manual/how-to-make-the-client-side-program-get-an-html-element-from-the-server-and-insert-it-in-the-page.wiki
rename to tutos/8.0/manual/how-to-make-the-client-side-program-get-an-html-element-from-the-server-and-insert-it-in-the-page.mld
index 0a6bd41b..c4b1805b 100644
--- a/tutos/8.0/manual/how-to-make-the-client-side-program-get-an-html-element-from-the-server-and-insert-it-in-the-page.wiki
+++ b/tutos/8.0/manual/how-to-make-the-client-side-program-get-an-html-element-from-the-server-and-insert-it-in-the-page.mld
@@ -1,18 +1,20 @@
-=How to make the client side program get an HTML element from the server and insert it in the page?=
+{0 How to make the client side program get an HTML element from the server and insert it in the page?}
 
 A very convenient way to do that is to use RPCs :
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc get_mydiv (() : unit) : _ Lwt.t = div [ ... ]
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 [%client
   ...
   let%lwt mydiv = get_mydiv () in
   Dom.appendChild parent (To_dom.of_element mydiv)
   ...
 ]
->>
+]}
 
 Server functions take exactly one parameter.
 
@@ -20,11 +22,11 @@ RPCs are just syntactic sugar for pathless services
 returning OCaml values.
 
 The type of the function parameter must have been declared with the
-JSON module of {{{ppx_deriving}}} (which needs to be manually
+JSON module of [ppx_deriving] (which needs to be manually
 installed). This enables server-side data validation.
 
 example:
 
-<<code language="ocaml"|
+{@ocaml[
 type t = int * string [@@deriving json]
->>
+]}
diff --git a/tutos/8.0/manual/how-to-register-a-service-that-decides-itself-what-to-send.wiki b/tutos/8.0/manual/how-to-register-a-service-that-decides-itself-what-to-send.mld
similarity index 74%
rename from tutos/8.0/manual/how-to-register-a-service-that-decides-itself-what-to-send.wiki
rename to tutos/8.0/manual/how-to-register-a-service-that-decides-itself-what-to-send.mld
index 88547879..ebfcd664 100644
--- a/tutos/8.0/manual/how-to-register-a-service-that-decides-itself-what-to-send.wiki
+++ b/tutos/8.0/manual/how-to-register-a-service-that-decides-itself-what-to-send.mld
@@ -1,10 +1,10 @@
-=How to register a service that decides itself what to send?=
+{0 How to register a service that decides itself what to send?}
 
-Use <<a_api project="eliom"| module Eliom_registration.Any >>.
+Use {!Eliom_registration.Any}.
 
 In the following example, we send an Html page or a redirection:
 
-<<code language="ocaml"|
+{@ocaml[
 let send_any =
   Eliom_registration.Any.create
     ~path:(Eliom_service.Path ["any"])
@@ -18,4 +18,4 @@ let send_any =
             (body [p [txt "Hello."]]))
      else
        Eliom_registration.Redirection.send other_service)
->>
+]}
diff --git a/tutos/8.0/manual/how-to-register-session-data.wiki b/tutos/8.0/manual/how-to-register-session-data.mld
similarity index 61%
rename from tutos/8.0/manual/how-to-register-session-data.wiki
rename to tutos/8.0/manual/how-to-register-session-data.mld
index 1f19ed9d..93e1f40f 100644
--- a/tutos/8.0/manual/how-to-register-session-data.wiki
+++ b/tutos/8.0/manual/how-to-register-session-data.mld
@@ -1,7 +1,7 @@
-=How to register session data?=
+{0 How to register session data?}
 
-It is very easy to register session data using //Eliom references//.
-Just create an Eliom reference of //scope// session and its value
+It is very easy to register session data using {e Eliom references}.
+Just create an Eliom reference of {e scope} session and its value
 will be different for each session (one session = one browser process).
 
 But most of the time, what we want is to store data for one user,
@@ -10,7 +10,7 @@ for one user together, by creating a group of sessions.
 The name of the group may be for example the user id.
 
 To create a session group, open the session by doing something like:
-<<code language="ocaml"|
+{@ocaml[
 let open_session login password =
   let%lwt b = check_password login password in
   if b
@@ -19,56 +19,56 @@ let open_session login password =
       (Int64.to_string (get_userid login))
   else ...
 
->>
+]}
 
 If you want to store user data,
 just create a global Eliom reference of scope group:
-<<code language="ocaml"|
+{@ocaml[
 
 let myref =
   Eliom_reference.Volatile.eref
     ~scope:Eliom_common.default_group_scope
     None
 
->>
+]}
 
 And during a request, set this reference:
-<<code language="ocaml"|
+{@ocaml[
 
   ...
   Eliom_reference.Volatile.set myref (Some "user data")
 
->>
+]}
 
 The value of this reference is different for each user:
-<<code language="ocaml"|
+{@ocaml[
 
   Eliom_reference.Volatile.get myref
 
->>
+]}
 
-It is possible to create //persistent// Eliom references (see module
-<<a_api project="eliom" subproject="server"|module Eliom_reference>>).
+It is possible to create {e persistent} Eliom references (see module
+{!Eliom_reference}).
 
-==Other scopes==
+{1 Other scopes}
 If you want to store server side data for one browser (one session),
-use scope {{{Eliom_common.default_session_scope}}}.
+use scope [Eliom_common.default_session_scope].
 
 If you want to store server side data for one tab of your browser (one client process),
-use scope {{{Eliom_common.default_process_scope}}} (available only if you
+use scope [Eliom_common.default_process_scope] (available only if you
 have a client-server Eliom application).
 
 If you want to store server side data during one request,
-use scope {{{Eliom_common.request_scope}}}.
+use scope [Eliom_common.request_scope].
 
-==Persistent references==
+{1 Persistent references}
 
 Module
-<<a_api project="eliom" subproject="server"|module Eliom_reference>>
+{!Eliom_reference}
 also defines an interface for persistent references, that will survive
 if you restart the server.
 
-==Links
+{1 Links}
 
-* <<a_manual project="eliom" chapter="server-state"|More information on session data>>
-* module <<a_api project="eliom" subproject="server"|module Eliom_reference>>
+- {{:../eliom/server-state.html}More information on session data}
+- module {!Eliom_reference}
diff --git a/tutos/8.0/manual/how-to-send-a-file-to-server-without-stopping-the-client-process.wiki b/tutos/8.0/manual/how-to-send-a-file-to-server-without-stopping-the-client-process.mld
similarity index 82%
rename from tutos/8.0/manual/how-to-send-a-file-to-server-without-stopping-the-client-process.wiki
rename to tutos/8.0/manual/how-to-send-a-file-to-server-without-stopping-the-client-process.mld
index 1413a46e..53a23a35 100644
--- a/tutos/8.0/manual/how-to-send-a-file-to-server-without-stopping-the-client-process.wiki
+++ b/tutos/8.0/manual/how-to-send-a-file-to-server-without-stopping-the-client-process.mld
@@ -1,15 +1,15 @@
-=How to send a file to the server without stopping the client process?=
+{0 How to send a file to the server without stopping the client process?}
 
 This requires Eliom ≥ 3.1.
 
 Due to security reasons, browsers have limitations on sending files.
 But if the file is chosen by the user through an input file element,
-there is a way to send it to the server. You can't use the {{{server_function}}}
-or {{{let%rpc}}} syntax for this, but you can use
-{{{Eliom_client.call_caml_service}}}.
+there is a way to send it to the server. You can't use the [server_function]
+or [let%rpc] syntax for this, but you can use
+[Eliom_client.call_caml_service].
 
 Example:
-<<code language="ocaml"|
+{@ocaml[
 
 [%%client
 open Js_of_ocaml
@@ -45,4 +45,4 @@ let%client upload_pic_form () =
                     file)))));
   [txt "Upload a picture:"; file; submit_elt]
 
->>
+]}
diff --git a/tutos/dev/manual/how-to-send-file-download.wiki b/tutos/8.0/manual/how-to-send-file-download.mld
similarity index 68%
rename from tutos/dev/manual/how-to-send-file-download.wiki
rename to tutos/8.0/manual/how-to-send-file-download.mld
index 5f7304b9..b2d47b1d 100644
--- a/tutos/dev/manual/how-to-send-file-download.wiki
+++ b/tutos/8.0/manual/how-to-send-file-download.mld
@@ -1,7 +1,7 @@
-=How to send a file (download)?=
+{0 How to send a file (download)?}
 
 To serve file, you can use Ocsigen Server's module staticmod.
 But it is also possible to ask Eliom to send files using module
-<<a_api project="eliom" subproject="server"|module Eliom.Registration.File>>,
+{!Eliom_registration.File},
 for example if you want Eliom to perform some privacy checks before sending,
 or if the answer is not always a file.
\ No newline at end of file
diff --git a/tutos/8.0/manual/how-to-send-file-upload.wiki b/tutos/8.0/manual/how-to-send-file-upload.mld
similarity index 91%
rename from tutos/8.0/manual/how-to-send-file-upload.wiki
rename to tutos/8.0/manual/how-to-send-file-upload.mld
index f4e57fca..334f0750 100644
--- a/tutos/8.0/manual/how-to-send-file-upload.wiki
+++ b/tutos/8.0/manual/how-to-send-file-upload.mld
@@ -1,6 +1,6 @@
-=How to send a file (upload)?=
+{0 How to send a file (upload)?}
 
-To upload a file, use {{{Eliom_parameter.file}}} as service parameter type.
+To upload a file, use [Eliom_parameter.file] as service parameter type.
 
 Ocsigen server will save the file at a temporary location and keep it
 there during the request.  Then the file will be removed.  You must
@@ -8,7 +8,7 @@ link it somewhere else on the disk yourself if you want to keep it.
 
 Be careful also to set the right option in Ocsigen server's configuration file.
 For example:
-<<code|
+{[
 <ocsigen>
   <server>
     <uploaddir>/var/www/tmp</uploaddir>
@@ -16,10 +16,10 @@ For example:
     <maxrequestbodysize>100MB</maxrequestbodysize>
   </server>
 </ocsigen>
->>
+]}
 
 Example with Eliom_content.Html.D module opened:
-<<code language="ocaml"|
+{@ocaml[
 
 let upload = Eliom_service.create
     ~path:(Eliom_service.Path ["upload"])
@@ -60,4 +60,4 @@ let uploadform =
         (html
            (head (title (txt "form")) [])
            (body [f])))
->>
+]}
diff --git a/tutos/dev/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.wiki b/tutos/8.0/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.mld
similarity index 57%
rename from tutos/dev/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.wiki
rename to tutos/8.0/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.mld
index 7bad37ac..a3fbe1de 100644
--- a/tutos/dev/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.wiki
+++ b/tutos/8.0/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.mld
@@ -1,67 +1,67 @@
-=How to set and id, classes or other attributes to HTML elements?=
+{0 How to set and id, classes or other attributes to HTML elements?}
 
 Mandatory element attributes are given as OCaml named parameters to
 constructions function.
 
-Optional element attributes are added using the optional OCaml parameter "**?a**" which is more or less available for every HTML5 elements. This parameter is taking a list of attributes compatible with the element.
+Optional element attributes are added using the optional OCaml parameter "{b ?a}" which is more or less available for every HTML5 elements. This parameter is taking a list of attributes compatible with the element.
 
-<<code language="ocaml" |
+{@ocaml[
   div ~a:[a_class ["red";"shadow"];
         a_id "the_div";
         a_onclick {{ fun ev -> Dom_html.window##alert(Js.string "hello") }}]
     [txt "I'm a div with two classes to describe me (red and shadow), ";
      txt "an id to make me unique and an action when you click me."]
->>
+]}
 
-=== Id
+{2 Id}
 The id attribute specifies a unique id for an HTML element (the value must be unique within the HTML document).
 
-The id attribute is mostly used to set a style in a style sheet for a particular element, and by JavaScript (via the HTML DOM) to manipulate the element with the specific id. With Eliom client-server apps, you do usually not need to set ids manually for that purpose: just use injections ({{{%v}}}) to refer to a node {{{v}}} created on server side.
+The id attribute is mostly used to set a style in a style sheet for a particular element, and by JavaScript (via the HTML DOM) to manipulate the element with the specific id. With Eliom client-server apps, you do usually not need to set ids manually for that purpose: just use injections ([%v]) to refer to a node [v] created on server side.
 
-Attribute "id" is created by function {{{a_id}}}, taking the value of the attribute as parameter:
-<<code language="ocaml" |~a:[a_id "identifier"]>>
+Attribute "id" is created by function [a_id], taking the value of the attribute as parameter:
+{@ocaml[~a:[a_id "identifier"]]}
 
-=== Classes
+{2 Classes}
 The class attribute specifies one or more classnames for an element.
 
 The class attribute is mostly used to point to a class in a style sheet. However, it can also be used by a JavaScript (via the HTML DOM) to make changes to HTML elements with a specified class.
 
 An element can have several classes. Class attribute is
-generated by function {{{a_class}}}, that takes a list of strings.
-<<code language="ocaml" |~a:[a_class ["blue_button"; "small"]]>>
+generated by function [a_class], that takes a list of strings.
+{@ocaml[~a:[a_class ["blue_button"; "small"]]]}
 
-=== Style
+{2 Style}
 
 The style attribute specifies an inline style for an element. The style attribute will override any style set globally, e.g. styles specified in the header of the page.
 
 Using this attribute to stylish elements is not a good practice.
 You should rather use
-[[wiki:manual/how-to-add-css-stylesheet|an external CSS file]].
+{{:wiki:manual/how-to-add-css-stylesheet}an external CSS file}.
 
 Its parameter is a string.
-<<code language="ocaml" |~a:[a_style "color: pink; padding: 10px;"]>>
+{@ocaml[~a:[a_style "color: pink; padding: 10px;"]]}
 
-=== Title
+{2 Title}
 
 The title attribute specifies extra information about an element. The information is most often shown as a tooltip text when the mouse moves over the element.
 
 Its parameter is a string.
-<<code language="ocaml" |~a:[a_title "Lorem ipsum dolor sit amet."]>>
+{@ocaml[~a:[a_title "Lorem ipsum dolor sit amet."]]}
 
-=== Events
+{2 Events}
 
 Some attributes allow you to do something when the user do an action. They are many available actions since HTML5.
 
 Its argument is an Eliom event handler, that is a client-side function
 taking the JS event as parameter:
-<<code language="ocaml" |~a:[a_onclick {{ fun ev -> Dom_html.window##alert(Js.string "hello") }}]>>
+{@ocaml[~a:[a_onclick {{ fun ev -> Dom_html.window##alert(Js.string "hello") }}]]}
 
-However, we recommend to use <<a_api project="js_of_ocaml" subproject="js_of_ocaml-lwt"|module Js_of_ocaml_lwt.Lwt_js_events>> rather than these elements to set event handlers.
+However, we recommend to use {!Js_of_ocaml_lwt.Lwt_js_events} rather than these elements to set event handlers.
 
 
-=== Links
+{2 Links}
 
-* Type <<a_api project="tyxml"|type Html_types.base_attrib>> (attributes available for every element)
-* signature <<a_api project="tyxml"|module Html_sigs.T>> (Element attributes)
-* [[http://www.w3schools.com/html/default.asp|W3Schools HTML5 reference]]
-* [[http://www.w3schools.com/html5/html5_ref_eventattributes.asp|Events attributes]]
+- Type {!Html_types.base_attrib} (attributes available for every element)
+- signature {!Html_sigs.T} (Element attributes)
+- {{:http://www.w3schools.com/html/default.asp}W3Schools HTML5 reference}
+- {{:http://www.w3schools.com/html5/html5_ref_eventattributes.asp}Events attributes}
diff --git a/tutos/dev/manual/how-to-stop-default-behaviour-of-events.wiki b/tutos/8.0/manual/how-to-stop-default-behaviour-of-events.mld
similarity index 61%
rename from tutos/dev/manual/how-to-stop-default-behaviour-of-events.wiki
rename to tutos/8.0/manual/how-to-stop-default-behaviour-of-events.mld
index f5215454..a1a54069 100644
--- a/tutos/dev/manual/how-to-stop-default-behaviour-of-events.wiki
+++ b/tutos/8.0/manual/how-to-stop-default-behaviour-of-events.mld
@@ -1,8 +1,8 @@
-=How to stop default behaviour of events?=
+{0 How to stop default behaviour of events?}
 
 Example:
 
-<<code language="ocaml"|
+{@ocaml[
 
 (** Disable Js event with stopping propagation during capture phase **)
 let disable_event event html_elt =
@@ -13,9 +13,9 @@ let disable_event event html_elt =
 
 
 disable_event Dom_html.Event.dragstart Dom_html.document
->>
+]}
 
-* event is a Dom_html.Event\\
-* html_elt is the target
+- event is a Dom_html.Event{%html:<br/>%}
+- html_elt is the target
 
-More details in documentation: <<a_api project="js_of_ocaml" |val Js_of_ocaml.Dom.preventDefault>>
+More details in documentation: {!Js_of_ocaml.Dom.preventDefault}
diff --git a/tutos/8.0/manual/how-to-use-get-parameters-or-parameters-in-the-url.mld b/tutos/8.0/manual/how-to-use-get-parameters-or-parameters-in-the-url.mld
new file mode 100644
index 00000000..ff5968c8
--- /dev/null
+++ b/tutos/8.0/manual/how-to-use-get-parameters-or-parameters-in-the-url.mld
@@ -0,0 +1,88 @@
+{0 How to use GET parameters (parameters in the URL)?}
+
+Pages are generated by services.
+
+Funcrions to create services using GET HTTP method take
+two mandatory parameters: [~path] and [~get_params].
+
+{2 path}
+
+This argument is a {b list of string}, corresponding to the URL where your page service can be found.
+
+For example, if you want your page to be accessed via this URL:
+{@ocaml[http://website.com/a/b/c]}
+You must provide this path:
+{@ocaml[    ~path:["a";"b";"c"]]}
+
+This parameter can also be an {b empty list}. It means that the service page will be accessed via this URL:
+{[http://website.com/]}
+
+{2 get_params}
+
+Eliom chooses the service automatically w.r.t. this path and parameter
+given (among other criteria).
+It decodes parameters automatically and checks their types.
+
+Description of parameters (names and types) is done using module
+{!Eliom_parameter}.
+We recommend to open this module (at the beginning of your file, or locally).
+
+{3 Syntax for several parameters}
+
+- {b No parameter}
+{@ocaml[~get_params:unit]}
+
+- {b One parameter}
+{@ocaml[~get_params:(int "id")]}
+
+- {b More parameters}
+{@ocaml[~get_params:(string "name" ** int "age" ** bool "graduate")]}
+
+{3 Types of parameters}
+
+- {b Common types}: {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L121}string}, {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L122}int}, {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L123}int32}, {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L124}float}, {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L125}bool}
+- {b Some other types}: {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L126}optional values}, {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L158}any parameter}, {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L187}list}, {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L211}your own type}.
+
+- See more information on parameters in {{:../eliom/server-params.html}Eliom manual} and API documentation of module {!Eliom_parameter}.
+
+{3 Get these parameters}
+
+On service registration, parameters can be retrieved as a parameter of the function:
+{@ocaml[
+Example.register ~service:the_service
+    (fun parameters () -> ...)
+]}
+
+- {b No parameter}
+{@ocaml[    (fun () () -> ...)]}
+
+- {b One parameter}
+{@ocaml[    (fun a () -> ...)]}
+
+- {b Several parameters}
+
+Operator [**] is left associative:
+{@ocaml[    (fun (a, (b, (c, d)))) () -> ...)]}
+
+{2 Parameters in the path}
+
+Sometimes you may want to take parameters from the path,
+for example to improve readability of URLs. E.g. [http://blah.com/archive/2014/2/] or [http://blah.com/user/toto/].
+
+To do that, add a parameter of type {b suffix} in {b get_params}:
+{[~get_params:(suffix (string "username"))]}
+
+
+{2 Download full code}
+
+{e Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.}
+
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom}Read the full code}
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto}Download and try this example (parameters)}
+
+{2 Links}
+
+- Manual: {{:../eliom/server-params.html}Parameters}
+- Manual: {{:../eliom/server-services.html}Services}
+- API: {!Eliom_parameter}
+- API: {!Eliom_service}
diff --git a/tutos/8.0/manual/how-to-use-get-parameters-or-parameters-in-the-url.wiki b/tutos/8.0/manual/how-to-use-get-parameters-or-parameters-in-the-url.wiki
deleted file mode 100644
index 609916a9..00000000
--- a/tutos/8.0/manual/how-to-use-get-parameters-or-parameters-in-the-url.wiki
+++ /dev/null
@@ -1,88 +0,0 @@
-=How to use GET parameters (parameters in the URL)?
-
-Pages are generated by services.
-
-Funcrions to create services using GET HTTP method take
-two mandatory parameters: {{{~path}}} and {{{~get_params}}}.
-
-=== path
-
-This argument is a **list of string**, corresponding to the URL where your page service can be found.
-
-For example, if you want your page to be accessed via this URL:
-<<code language='ocaml'|http://website.com/a/b/c>>
-You must provide this path:
-<<code language='ocaml'|    ~path:["a";"b";"c"]>>
-
-This parameter can also be an **empty list**. It means that the service page will be accessed via this URL:
-<<code|http://website.com/>>
-
-=== get_params
-
-Eliom chooses the service automatically w.r.t. this path and parameter
-given (among other criteria).
-It decodes parameters automatically and checks their types.
-
-Description of parameters (names and types) is done using module
-<<a_api project="eliom" subproject="server"|module Eliom_parameter>>.
-We recommend to open this module (at the beginning of your file, or locally).
-
-==== Syntax for several parameters
-
-* **No parameter**
-<<code language='ocaml'|~get_params:unit>>
-
-* **One parameter**
-<<code language='ocaml'|~get_params:(int "id")>>
-
-* **More parameters**
-<<code language='ocaml'|~get_params:(string "name" ** int "age" ** bool "graduate")>>
-
-==== Types of parameters
-
-* **Common types**: [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L121|string]], [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L122|int]], [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L123|int32]], [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L124|float]], [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L125|bool]]
-* **Some other types**: [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L126|optional values]], [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L158|any parameter]], [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L187|list]], [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L211|your own type]].
-
-* See more information on parameters in <<a_manual project="eliom" chapter="server-params"|Eliom manual>> and API documentation of module <<a_api project="eliom" subproject="server"|module Eliom_parameter>>.
-
-==== Get these parameters
-
-On service registration, parameters can be retrieved as a parameter of the function:
-<<code language='ocaml'|
-Example.register ~service:the_service
-    (fun parameters () -> ...)
->>
-
-* **No parameter**
-<<code language='ocaml'|    (fun () () -> ...)>>
-
-* **One parameter**
-<<code language='ocaml'|    (fun a () -> ...)>>
-
-* **Several parameters**
-
-Operator {{{**}}} is left associative:
-<<code language='ocaml'|    (fun (a, (b, (c, d)))) () -> ...)>>
-
-=== Parameters in the path
-
-Sometimes you may want to take parameters from the path,
-for example to improve readability of URLs. E.g. {{{http://blah.com/archive/2014/2/}}} or {{{http://blah.com/user/toto/}}}.
-
-To do that, add a parameter of type **suffix** in **get_params**:
-<<code|~get_params:(suffix (string "username"))>>
-
-
-=== Download full code
-
-//Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.//
-
-* [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom|Read the full code]]
-* [[https://github.com/db0company/Ocsigen-Quick-Howto|Download and try this example (parameters)]]
-
-=== Links
-
-* Manual: <<a_manual project="eliom" chapter="server-params"|Parameters>>
-* Manual: <<a_manual project="eliom" chapter="server-services"|Services>>
-* API: <<a_api project="eliom" subproject="server"|module Eliom_parameter>>
-* API: <<a_api project="eliom" subproject="server"|module Eliom_service>>
diff --git a/tutos/8.0/manual/how-to-write-a-json-service.wiki b/tutos/8.0/manual/how-to-write-a-json-service.mld
similarity index 62%
rename from tutos/8.0/manual/how-to-write-a-json-service.wiki
rename to tutos/8.0/manual/how-to-write-a-json-service.mld
index 87768dd6..e418c096 100644
--- a/tutos/8.0/manual/how-to-write-a-json-service.wiki
+++ b/tutos/8.0/manual/how-to-write-a-json-service.mld
@@ -1,10 +1,10 @@
-=How to write a JSON service?=
+{0 How to write a JSON service?}
 
 *If you want to communicate with a client side Eliom program, you do not need to serialize yourself your data to JSON. Serialization/Deserialization of any OCaml type is done automatically by Eliom. Just use OCaml services (or, simpler: server functions and call the function from your OCaml client side program).
-*If you want to use your own JSON format, you need to have your own serialisation function to JSON (or for example to use some OCaml library like [[http://mjambon.com/yojson.html|yojson]] to generate JSON). In that case, you can register your service using {{{Eliom_registration.String}}} instead of {{{Eliom_registration.Html}}} (see example below). The handler function must return the JSON value as a string, and a the content-type.
-*It is even possible to define yourself your own registration module, to be used instead of {{{Eliom_registration.String}}}. Thus, you can use an OCaml representation of the JSON value (and you don't call the serializer yourself). Have a look on how modules like {{{Eliom_registration.String}}} are implemented to know how to do that.
+*If you want to use your own JSON format, you need to have your own serialisation function to JSON (or for example to use some OCaml library like {{:http://mjambon.com/yojson.html}yojson} to generate JSON). In that case, you can register your service using [Eliom_registration.String] instead of [Eliom_registration.Html] (see example below). The handler function must return the JSON value as a string, and a the content-type.
+*It is even possible to define yourself your own registration module, to be used instead of [Eliom_registration.String]. Thus, you can use an OCaml representation of the JSON value (and you don't call the serializer yourself). Have a look on how modules like [Eliom_registration.String] are implemented to know how to do that.
 
-<<code language="ocaml"|
+{@ocaml[
 
 let my_json_service =
   Eliom_service.create
@@ -18,8 +18,8 @@ let _ =
     (fun () () ->
       Lwt.return ("{text:'something'}", "application/json"))
 
->>
+]}
 
-**Comments:** \\
-If you want to get result from a Database, it could already be in JSON format. \\
-Anyway, you probably do not need to pretty-print JSON yourself. \\
+{b Comments:} {%html:<br/>%}
+If you want to get result from a Database, it could already be in JSON format. {%html:<br/>%}
+Anyway, you probably do not need to pretty-print JSON yourself. {%html:<br/>%}
diff --git a/tutos/8.0/manual/how-to-write-forms.wiki b/tutos/8.0/manual/how-to-write-forms.mld
similarity index 72%
rename from tutos/8.0/manual/how-to-write-forms.wiki
rename to tutos/8.0/manual/how-to-write-forms.mld
index 96f4cb83..9440e907 100644
--- a/tutos/8.0/manual/how-to-write-forms.wiki
+++ b/tutos/8.0/manual/how-to-write-forms.mld
@@ -1,22 +1,22 @@
-=How to write forms?=
+{0 How to write forms?}
 
-=== To write an HTML form towards an Eliom service
+{2 To write an HTML form towards an Eliom service}
 
 Just as we do for links, we provide form-building functions that call
 Eliom services in a safe manner. These functions are provided in the
 module
-<<a_api project="eliom" subproject="server" | module Eliom_content.Html.D.Form >> (and
-<<a_api project="eliom" subproject="server" | module Eliom_content.Html.F.Form >>).
+{!Eliom_content.Html.D.Form} (and
+{!Eliom_content.Html.F.Form}).
 The functions
-<<a_api project="eliom" subproject="server" | val Eliom_content.Html.D.Form.get_form >> and
-<<a_api project="eliom" subproject="server" | val Eliom_content.Html.D.Form.post_form >>
-accept a function (named {{{create_form}}} in our example below)
+{!Eliom_content.Html.D.Form.get_form} and
+{!Eliom_content.Html.D.Form.post_form}
+accept a function (named [create_form] in our example below)
 which is responsible for generating the content from
 appropriately-typed parameter names.
 
 Here a complete example.
 
-<<code language="ocaml"|
+{@ocaml[
 [%%shared
   open Eliom_parameter
   open Eliom_content.Html.D
@@ -77,34 +77,34 @@ let%server form_handler =
 let%server () =
   Eliom_registration.Html.register ~service:form_result_service form_result_handler;
   Eliom_registration.Html.register ~service:form_service form_handler
->>
+]}
 
 As shown in the example,
-<<a_api project="eliom" subproject="server" | module Eliom_content.Html.D.Form >>
+{!Eliom_content.Html.D.Form}
 provides functions for generating the various widgets, e.g.,
-<<a_api project="eliom" subproject="server" | val Eliom_content.Html.D.Form.input >>.
+{!Eliom_content.Html.D.Form.input}.
 These functions need to be called with a "type" argument (e.g.,
-<<a_api project="eliom" subproject="server" | val Eliom_content.Html.D.Form.int >>)
+{!Eliom_content.Html.D.Form.int})
 that matches the type of the corresponding parameter name.
 
 POST forms may also take get parameters, as last argument of function
-{{{post_form}}}:
+[post_form]:
 
-<<code language="ocaml"|
+{@ocaml[
 Eliom_content.Html.D.Form.post_form
   my_service_with_get_and_post
   (fun my_string ->
     p [txt "Write a string: ";
        Form.input ~input_type:`Text ~name:my_string Form.string])
   222
->>
+]}
 
-=== Raw forms
+{2 Raw forms}
 
 There is also a raw interface to write basic forms without Eliom,
 using standard tyxml constructors.
 
-Use module [[wiki("eliom"):api/server/Eliom_content.Html.D.Raw|Eliom_content.Html.D.Raw]].
+Use module {{:../eliom/api/server/Eliom_content.Html.D.Raw}Eliom_content.Html.D.Raw}.
 
-===Links
-* [[wiki:manual/how-to-add-a-select-or-other-form-element|How to write a select (or other form element)?]]
+{2 Links}
+- {{:wiki:manual/how-to-add-a-select-or-other-form-element}How to write a select (or other form element)?}
diff --git a/tutos/8.0/manual/how-to-write-titles-and-paragraphs.mld b/tutos/8.0/manual/how-to-write-titles-and-paragraphs.mld
new file mode 100644
index 00000000..151c2382
--- /dev/null
+++ b/tutos/8.0/manual/how-to-write-titles-and-paragraphs.mld
@@ -0,0 +1,34 @@
+{0 How to write titles and paragrahs?}
+
++ Titles
+
+{@ocaml[
+h3 [txt "Hello world"]
+]}
+
+There are 6 types of titles: h1, h2, h3, h4, h5 and h6. h1 is the largest and h6 is the smallest.
+
++ Pagragraph
+
+{@ocaml[
+p [txt "Some text, blah blah blah"]
+]}
+
+{b Required parameter}: list containing other elements (content: {!Html_types.flow5} elements).
+
+{b Optional parameter} for attributes "a" ({{:wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements}How to set and id, classes or other attributes to HTML elements?}).
+
+{2 Download full code}
+
+{e Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.}
+
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/elements/example.eliom}Read the full code}
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto}Download and try this example}
+
+{2 Links}
+
+- Modules {!Eliom_content.Html.D} and
+  {!Eliom_content.Html.F}
+  (HTML5 Elements)
+- The {!Html_sigs.T.h1} element
+- signature {!Html_sigs.T} (Element attributes)
diff --git a/tutos/8.0/manual/how-to-write-titles-and-paragraphs.wiki b/tutos/8.0/manual/how-to-write-titles-and-paragraphs.wiki
deleted file mode 100644
index b056b7c0..00000000
--- a/tutos/8.0/manual/how-to-write-titles-and-paragraphs.wiki
+++ /dev/null
@@ -1,34 +0,0 @@
-=How to write titles and paragrahs?=
-
-#### Titles
-
-<<code language='ocaml'|
-h3 [txt "Hello world"]
->>
-
-There are 6 types of titles: h1, h2, h3, h4, h5 and h6. h1 is the largest and h6 is the smallest.
-
-#### Pagragraph
-
-<<code language='ocaml'|
-p [txt "Some text, blah blah blah"]
->>
-
-**Required parameter**: list containing other elements (content: <<a_api project="tyxml"|type Html_types.flow5>> elements).
-
-**Optional parameter** for attributes "a" ([[wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements|How to set and id, classes or other attributes to HTML elements?]]).
-
-=== Download full code
-
-//Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.//
-
-* [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/elements/example.eliom|Read the full code]]
-* [[https://github.com/db0company/Ocsigen-Quick-Howto|Download and try this example]]
-
-=== Links
-
-* Modules <<a_api project="eliom" subproject="server"|module Eliom_content.Html.D>> and
-  <<a_api project="eliom" subproject="server"|module Eliom_content.Html.F>>
-  (HTML5 Elements)
-* The <<a_api project="tyxml"|val Html_sigs.T.h1>> element
-* signature <<a_api project="tyxml"|module Html_sigs.T>> (Element attributes)
diff --git a/tutos/8.0/manual/html.wiki b/tutos/8.0/manual/html.mld
similarity index 56%
rename from tutos/8.0/manual/html.wiki
rename to tutos/8.0/manual/html.mld
index 758d8efd..1a3a2fc1 100644
--- a/tutos/8.0/manual/html.wiki
+++ b/tutos/8.0/manual/html.mld
@@ -1,4 +1,6 @@
-<<header| = HTML in 5 minutes >>
+{%wodoc:header%}
+{0 HTML in 5 minutes}
+{%wodoc:end%}
 
 The Tyxml library makes it possible to type-check HTML pages.
 This means that your Ocsigen program will never generate pages
@@ -6,55 +8,55 @@ which do not follow the recommendations from the W3C.
 For example a program that could generate a page with a paragraph
 inside another paragraph will be rejected at compile time.
 
-== Typed HTML
+{1 Typed HTML}
 
-=== Tags
+{2 Tags}
 
 Tyxml (or modules obtained by applying Tyxml functor,
-like {{{Eliom_content.Html.D}}}) defines a contructor function
+like [Eliom_content.Html.D]) defines a contructor function
 for each HTML tag, and for each attribute.
 
 Example:
 
-<<code language="ocaml"|
+{@ocaml[
    html
      (head (title (txt "Hello")) [])
      (body [ h1 [txt "Hello"] ;
              p [txt "Blah"] ])
->>
+]}
 
-As tag {{{<html>}}} contains a tag {{{<head>}}} and {{{<body>}}},
-function {{{html}}} takes two parameters:
+As tag [<html>] contains a tag [<head>] and [<body>],
+function [html] takes two parameters:
 
-<<code language="ocaml"|
+{@ocaml[
 val html : [`Head] elt -> [`Body] elt -> [`Html] elt
->>
+]}
 
-The only way to create a value of type {{{[`Head] elt}}} is to use
-function {{{head}}},
-and the only way to create a value of type {{{[`Body] elt}}} is to use
-function {{{body}}}.
+The only way to create a value of type [[`Head] elt] is to use
+function [head],
+and the only way to create a value of type [[`Body] elt] is to use
+function [body].
 
-As a {{{<title>}}} tag is mandatory inside {{{<head>}}},
-function {{{head}}} takes a {{{[`Title] elt}}} as first argument
-(that can be created using function {{{title}}}),
+As a [<title>] tag is mandatory inside [<head>],
+function [head] takes a [[`Title] elt] as first argument
+(that can be created using function [title]),
 then the list of other children.
 
-Function {{{txt}}} is used to include raw text.
+Function [txt] is used to include raw text.
 
-=== Error messages
+{2 Error messages}
 
 If you write an invalid page, for example:
-<<code language="ocaml"|
+{@ocaml[
 (html
    (head (title (txt "")) [txt ""])
    (body [txt "Hallo"]))
->>
+]}
 
 You will get an error message similar to the following, referring to
 the end of line 2:
 
-{{{
+{v
 Error: This expression has type ([> `TXT ] as 'a) Html.elt
        but an expression was expected of type
          Html_types.head_content_fun Html.elt
@@ -67,49 +69,49 @@ Error: This expression has type ([> `TXT ] as 'a) Html.elt
            | `Script
            | `Style ]
        The second variant type does not allow tag(s) `TXT
-}}}
+v}
 
-where <<a_api project="tyxml" | type Html_types.head_content_fun >>
-is the type of content allowed inside {{{<head>}}} ({{{<base>}}},
-{{{<command>}}}, {{{<link>}}}, {{{<meta>}}}, etc.). Notice that
-{{{`TXT}}} (i.e. raw text) is not included in this polymorphic
-variant type, which means that {{{<head>}}} cannot contain raw text.
+where {!Html_types.head_content_fun}
+is the type of content allowed inside [<head>] ([<base>],
+[<command>], [<link>], [<meta>], etc.). Notice that
+[`TXT] (i.e. raw text) is not included in this polymorphic
+variant type, which means that [<head>] cannot contain raw text.
 
-=== Attributes
+{2 Attributes}
 
-Attributes are given to functions using optional argument {{{?a}}}.
+Attributes are given to functions using optional argument [?a].
 
 Example:
-<<code language="ocaml"|
+{@ocaml[
 div ~a:[a_id "the_id"; a_class ["firstclass"; "secondclass"]]
   [ txt "blah" ]
->>
+]}
 
-== OCaml node and DOM nodes
+{1 OCaml node and DOM nodes}
 
-=== Conversions
+{2 Conversions}
 
 Tyxml builds OCaml nodes. If you are using it server side,
 they are serialized as an XML text before being sent to the browser.
 On client side, if you want to get the DOM node corresponding to
-an OCaml node, use functions from module {{{Eliom_content.Html.To_dom}}},
-for example {{{Eliom_content.Html.To_dom.of_element}}},
-or {{{Eliom_content.Html.To_dom.of_input}}},
-{{{Eliom_content.Html.To_dom.of_textarea}}}, etc.
+an OCaml node, use functions from module [Eliom_content.Html.To_dom],
+for example [Eliom_content.Html.To_dom.of_element],
+or [Eliom_content.Html.To_dom.of_input],
+[Eliom_content.Html.To_dom.of_textarea], etc.
 
-If the node has been created with {{{Eliom_content.Html.F}}}
+If the node has been created with [Eliom_content.Html.F]
 (functional nodes),
 a new DOM node will be created every time you call such a conversion
 function.
 
-If the node has been created with {{{Eliom_content.Html.D}}},
+If the node has been created with [Eliom_content.Html.D],
 the conversion function will return the exact DOM node that exists
 in the page (and always the same one). If this "D" node is created
 server-side, Eliom will automatically add a identifier in the HTML
 page to be able to find it back.
 
 Example:
-<<code language="ocaml"|
+{@ocaml[
 [%%shared
   open Eliom_content.Html
 ]
@@ -120,38 +122,38 @@ let%server create_widget () =
     Lwt.async (fun () ->
       Lwt_js_events.clicks (To_dom.of_element ~%d) (fun _ _ -> ... )) ];
   d
->>
+]}
 
-Here, {{{d}}} must be a "D" node, as I want to bind click events on
+Here, [d] must be a "D" node, as I want to bind click events on
 the actual node (that is already in the page), not create a new one.
 
 Remember to use "D" nodes if you want to use it in a injection
-({{{~%d}}}). If you don't to bother about "D" or "F" nodes, use "D"
+([~%d]). If you don't to bother about "D" or "F" nodes, use "D"
 nodes by default (even if it will generate too much identifiers in the page).
 But remember that, the DOM semantics implies that "D" nodes cannot be
 inserted twice in a page.
 
 
-=== Manip
+{2 Manip}
 
 Module
-<<a_api project="eliom" subproject="client"| module Eliom_content.Html.Manip >>
+{!Eliom_content.Html.Manip}
 makes it possible to manipulate OCaml nodes without conversions
 (add them in a page, replace a node, add as child of another node,
 add a class, etc.).
 
-=== Reactive nodes
+{2 Reactive nodes}
 
 Module
-<<a_api project="eliom" subproject="client"| module Eliom_content.Html.R >>
+{!Eliom_content.Html.R}
 makes it possible to create reactive nodes, that is, nodes that will
 be updated automatically when the data on which they depend change.
 
-It is based on module [[http://erratique.ch/software/react/doc/React|React]],
+It is based on module {{:http://erratique.ch/software/react/doc/React}React},
 which implements functional reactive programming for OCaml.
 
-== More documentation
+{1 More documentation}
 
-Have a look at <<a_manual project="tyxml" chapter="intro"|Tyxml's manual>>
-and <<a_manual project="eliom" chapter="clientserver-html"|Eliom's manual>>
+Have a look at {{:../tyxml/intro.html}Tyxml's manual}
+and {{:../eliom/clientserver-html.html}Eliom's manual}
 for more documentation about HTML manipulation in OCaml.
diff --git a/tutos/8.0/manual/interaction.wiki b/tutos/8.0/manual/interaction.mld
similarity index 68%
rename from tutos/8.0/manual/interaction.wiki
rename to tutos/8.0/manual/interaction.mld
index bcb0fa59..26926714 100644
--- a/tutos/8.0/manual/interaction.wiki
+++ b/tutos/8.0/manual/interaction.mld
@@ -1,13 +1,13 @@
-=Implementing Web Interaction Using Eliom=
+{0 Implementing Web Interaction Using Eliom}
+
+{e The code of this tutorial has been tested with Eliom 6.0.} {%html:<br/>%}
 
-//The code of this tutorial has been tested with Eliom 6.0.// \\
 
-<<|outline target="documentation">>
 
 This chapter of the tutorial explains how to create a small web site
 with several pages, users, sessions, and other elements of classical
 web development.  Then, in
-<<a_manual project="tuto" chapter="misc" |another tutorial>>, we will incorporate the
+{{:../tuto/misc.html}another tutorial}, we will incorporate the
 features of this site into our Graffiti application, to
 demonstrate that we can combine this kind of interaction with client-side
 programs.
@@ -19,19 +19,19 @@ HTML pages.
 We will create a simple web site with one main page and a page for
 each user (assuming we have several users already created).  Then we
 will add a login/connection form. We will also add a registration
-form, in order to learn how to create //dynamically// new services,
+form, in order to learn how to create {e dynamically} new services,
 and why it is very useful.
 
-The [[https://github.com/ocsigen/tutorial/tree/master/files/tutorial/chapter2|full code]]
+The {{:https://github.com/ocsigen/tutorial/tree/master/files/tutorial/chapter2}full code}
 of the program can be downloaded.
 
-==Services==
+{1 Services}
 
-===The main page===
+{2 The main page}
 
 Let's start again from scratch with the following site.
 
-<<code language="ocaml"|
+{@ocaml[
 
 let main_service = Eliom_content.Html.D.(
   Eliom_registration.Html.create
@@ -42,33 +42,35 @@ let main_service = Eliom_content.Html.D.(
         (html (head (title (txt "")) [])
            (body [h1 [txt "Hello"]])))
 )
->>
+]}
 
-Note that we are using {{{Eliom_registration.Html}}}, as we are not building a
+Note that we are using [Eliom_registration.Html], as we are not building a
 client side program for now.
 
-For the same reason, you may want to remove the {{{.eliom}}}-file
+For the same reason, you may want to remove the [.eliom]-file
 generated by the distillery and put the code into an
-{{{.ml}}}-file. But don't forget to add it to the server files in the
-{{{Makefile.options}}}:
+[.ml]-file. But don't forget to add it to the server files in the
+[Makefile.options]:
 
-<<code language="makefile"|
+{@makefile[
 SERVER_FILES := tuto.ml
->>
+]}
+
+{2 Adding a page for each user}
 
-===Adding a page for each user===
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-<<concepts|
 
-Services with parameters\\
+
+Services with parameters{%html:<br/>%}
 Using parts of the path as parameters
 
->>
+{%wodoc:end%}
 
 We will now create a page for each user. To do this, we will create a
 new service, taking the user name as parameter:
 
-<<code language="ocaml"|
+{@ocaml[
 let user_service = Eliom_content.Html.D.(
   Eliom_registration.Html.create
     ~path:(Eliom_service.Path [""])
@@ -78,144 +80,150 @@ let user_service = Eliom_content.Html.D.(
         (html (head (title (txt name)) [])
            (body [h1 [txt name]])))
 )
->>
+]}
 
 Add these lines to the same file, compile, start the server and verify
 that everything is working by trying, for example:
-{{{http://localhost:8080/?name=toto}}}.
+[http://localhost:8080/?name=toto].
+
+{%wodoc:aside class="concept"%}{b Concept: Paths}
+
 
-<<concept title="Paths" |
 
 Note that we are using the same path as the first service.  Eliom will
 automatically call the right service according to the parameters given
 in the request.
 
->>
+{%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: Services with parameters}
+
 
-<<concept title="Services with parameters" |
 
 To define a service that accepts parameters in the URL (GET
 parameters), just add a description of the parameters you want in the
-{{{~meth}}} argument of the {{{Eliom_service.create}}} function. In
-our example, the service is expecting a parameter called {{{name}}},
-of type {{{string}}}.
+[~meth] argument of the [Eliom_service.create] function. In
+our example, the service is expecting a parameter called [name],
+of type [string].
 
 The handler function (function implementing the service) always takes
 two parameters:
 
-* The first one corresponds to GET parameters (in our example, a string).
-* The second one corresponds to parameters that are sent in the body
+- The first one corresponds to GET parameters (in our example, a string).
+- The second one corresponds to parameters that are sent in the body
   of the HTTP request (POST parameters). We will see soon how to make
   services with POST parameters.
 
-The module <<a_api project="eliom" subproject="server" | module Eliom_parameter >>
+The module {!Eliom_parameter}
 defines the possible parameter types. For example if you write:
 
-{{{
+{v
 ~meth:(Eliom_service.Get (Eliom_parameter.int "i"))
-}}}
+v}
 
-Eliom will try to find a parameter called {{{i}}} and to translate it
-into an {{{int}}}.  In that case, the handler function will accept an
-{{{int}}} as the first parameter.
+Eliom will try to find a parameter called [i] and to translate it
+into an [int].  In that case, the handler function will accept an
+[int] as the first parameter.
 
 If you want to accept several parameters, you can do, for example:
 
-{{{
+{v
 ~meth:(Eliom_service.Get Eliom_parameter.(int "i" ** string "s"))
-}}}
+v}
 
-In that case, the handler function takes a pair of type {{{(int * string)}}}.
+In that case, the handler function takes a pair of type [(int * string)].
 
-//Warning:// The operator {{{**}}} is an infix //binary// operator.
+{e Warning:} The operator [**] is an infix {e binary} operator.
 It will always create pairs, and not triples or other tuples.
 
-The module <<a_api project="eliom" subproject="server" | module Eliom_parameter >> also
+The module {!Eliom_parameter} also
 defines other parameter types: for example floats, 64 bits integers,
 sum types, but also more complex types, like sets or lists of values.
 It is also possible to define your own parameter types.
 
->> <<| END "encadre" >>
+{%wodoc:end%} 
 
 For our program, we would prefer to take one part of the URL path as the parameter
 describing the name of the user.
 To achieve this we change the definition of the previous service this way:
 
-<<code language="ocaml"|
+{@ocaml[
 let user_service =
   Eliom_registration.Html.create
     ~path:(Eliom_service.Path ["users"])
     ~meth:(Eliom_service.Get (
       Eliom_parameter.(suffix (string "name"))))
     (fun name () -> ... )
->>
+]}
+
+The user pages are now available at URLs {%wodoc:span class="code"%}~http:~{e localhost:8080/users~}/username{e {%wodoc:end%}.
 
-The user pages are now available at URLs <<span
-class="code"|~http:~//localhost:8080/users~///username//>>.
+{%wodoc:aside class="concept"%}{b Concept: Using parts of the path as page parameters}
 
-<<concept title="Using parts of the path as page parameters" |
 
-The module <<a_api project="eliom" subproject="server" | module Eliom_parameter >> makes
+
+The module {!Eliom_parameter} makes
 it possible to use parts of the path as service (GET) parameters.
 
-In addition to <<a_api project="eliom" subproject="server" | val Eliom_parameter.suffix
->>, there are many other values allowing you to specify your expected
+In addition to {!Eliom_parameter.suffix}, there are many other values allowing you to specify your expected
 parameters: for example, you may access the full suffix as a string,
 as a list of string, or you may want to mix suffix parameters with
 standard GET parameters. You can also accept, as parameters, parts of
-the path that are not a suffix of the path (using <<a_api
-project="eliom" subproject="server" | val Eliom_parameter.const >>).  See more information
-on suffixes in <<a_manual
-project="eliom" chapter="server-params" fragment="suffixes"|Eliom's manual>>.
+the path that are not a suffix of the path (using {!Eliom_parameter.const}).  See more information
+on suffixes in {{:../eliom/server-params.html#suffixes}Eliom's manual}.
 
-//Warning:// Even if it is not displayed in the URL, suffix parameters
+}Warning:{e  Even if it is not displayed in the URL, suffix parameters
 have a parameter name. This allows one to make forms that point to
 those kind of services.  Actually each "suffix service" has an
 equivalent without suffix (which is by default automatically
 redirected towards the suffix version if it is a GET request).
 
->> <<| END "encadre" >>
+{%wodoc:end%} 
+
+{2 Links}
 
-===Links===
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-<<concepts|
-Links \\
+
+Links {%html:<br/>%}
 Database libraries
->>
+{%wodoc:end%}
 
 We now want to add a link on each user page to go back to the main
 page.
 
-Change the handler of {{{user_service}}} into:
+Change the handler of [user_service] into:
 
-<<code language="ocaml"|
+{@ocaml[
 (fun name () -> Lwt.return
   (html
     (head (title (txt name)) [])
     (body [h1 [txt name];
            p [a ~service:main_service [txt "Home"] ()]])))
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Creating hyperlinks}
 
-<<concept title="Creating hyperlinks" |
 
-The function <<a_api project="eliom" subproject="server" | val
-Eliom_content.Html.D.a >> accepts the following parameters:
-* the service
-* the content of the link
-* URL parameters to be given to the service
+
+The function {!val
+Eliom_content.Html.D.a} accepts the following parameters:
+- the service
+- the content of the link
+- URL parameters to be given to the service
 
 Thus, you don't have to know the precise URL of the service you want
 to link to, and if the URL changes, all links will remain valid.
-Using this function has a wonderful consequence: //You will never have
-broken links!//
+Using this function has a wonderful consequence: }You will never have
+broken links!{e 
 
->> <<| END "encadre" >>
+{%wodoc:end%} 
 
-====Links towards services with parameters====
+{3 Links towards services with parameters}
 
-In our example above, the last parameter is {{{()}}} because the
+In our example above, the last parameter is [()] because the
 service does not expect any parameter. If the service expects, for
-example, a pair {{{(int * string)}}}, you must provide a matching
+example, a pair [(int * string)], you must provide a matching
 value as last parameter.  OCaml checks at compile time that the type
 of the parameters in a link corresponds to the type expected by the
 service. Also parameter names are generated
@@ -226,7 +234,7 @@ To show an example of a link with parameters, we will display the list
 of user pages on the main page. Here is the new version of the full
 program:
 
-<<code language="ocaml"|
+{@ocaml[
 
 (* Services *)
 let main_service = Eliom_service.create
@@ -268,81 +276,89 @@ let () = Eliom_content.Html.D.(
            (body [h1 [txt name];
                   p [a ~service:main_service [txt "Home"] ()]])))
 )
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Mutually recursive services}
+
 
-<<concept title="Mutually recursive services" |
 
 As our two services are mutually recursive (the first one contains
 links towards the second one and vice versa), we split the
-{{{create}}} function application in two steps:
+[create] function application in two steps:
 
-* First we create all the services using
-  <<a_api project="eliom" subproject="server" | val Eliom_service.create >>
-  or <<a_api project="eliom" subproject="server" | val Eliom_service.App.service >>
+- First we create all the services using
+  {!Eliom_service.create}
+  or {!Eliom_service.App.service}
   (depending on the type of services you want)
-* Then we register the handlers using the {{{register}}} function from
+- Then we register the handlers using the [register] function from
   the right module.
 
-The function {{{create}}} we previously used is just a shortcut for these two functions (we create the service, then we register the handler).
+The function [create] we previously used is just a shortcut for these two functions (we create the service, then we register the handler).
+
+{%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: Database libraries}
 
->>
 
-<<concept title="Database libraries" |
 
 Ultimately we'll want to use a more sophisticated database module for
 managing user information, which we will write later in this tutorial.
 You can use any OCaml database binding (for example
-[[http://pgocaml.forge.ocamlcore.org/|PGOcaml]] to program
+{{:http://pgocaml.forge.ocamlcore.org/}PGOcaml} to program
 database queries). We will use our own database library called
-[[https://github.com/ocsigen/macaque|Macaque]], which implements typed requests using
-//comprehensions//.
+{{:https://github.com/ocsigen/macaque}Macaque}, which implements typed requests using
+}comprehensions{e .
 
-//Just remember that your query functions must be cooperative with
-Lwt!// For example PGOcaml is now implemented in monadic way, which
+}Just remember that your query functions must be cooperative with
+Lwt!{e  For example PGOcaml is now implemented in monadic way, which
 makes it 100% compatible with Lwt. Macaque (the library we use later
 in this tutorial) is as well.
 
 If your database module is not Lwt-cooperative but is thread-safe (for
-preemptive threads), you can use the <<a_api project="lwt" | val
-Lwt_preemptive.detach >> function to make the blocking function be
+preemptive threads), you can use the {!val
+Lwt_preemptive.detach} function to make the blocking function be
 executed by a separate preemptive thread.
 
->>
+{%wodoc:end%}
+
+{1 Sessions}
+
+{2 Connection service}
 
-==Sessions==
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-===Connection service===
 
-<<concepts|
 
-Services with hidden (POST) parameters\\
+Services with hidden (POST) parameters{%html:<br/>%}
 Fallback service
 
->>
+{%wodoc:end%}
 
 Now we want to add a connection form.  First, we create a service
 for checking the name and password.  Since we don't want the username
-and password to be shown in the URL, we use //hidden parameters//
+and password to be shown in the URL, we use }hidden parameters{e 
 (or POST parameters).  Thus, we need to create a new service taking
 these parameters:
 
-<<code language="ocaml"|
+{@ocaml[
 let connection_service = Eliom_service.create_attached_post
   ~fallback:main_service
   ~post_params:Eliom_parameter.(string "name" ** string "password")
   ()
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Hidden (POST) services}
+
 
-<<concept title="Hidden (POST) services" |
 
 Services using the POST HTTP method are created using the function
-<<a_api project="eliom" subproject="server" | val Eliom_service.create >>
-or <<a_api project="eliom" subproject="server" | val Eliom_service.create_attached_post >>
+{!Eliom_service.create}
+or {!Eliom_service.create_attached_post}
 (depending on what type of service you want to create).
 As you can see, there is a major
 difference from the way we created our previous services.
-Instead of providing a path for the {{{~path}}} argument, we gave a
-//fallback// service. This //fallback// is the service that will be used
+Instead of providing a path for the [~path] argument, we gave a
+}fallback{e  service. This }fallback{e  is the service that will be used
 if the POST parameters are missing (for example, the user sets a bookmark
 on the page and returns later without POST parameters).
 This way, we will not get 404 errors if this occurs.
@@ -352,12 +368,14 @@ and POST parameters. In that case, GET parameters will be in the URL
 and POST parameters will probably come from a form. In HTML, it is not
 possible to mix GET and POST parameters in the same form.
 
-See also [[basics|the cheat-sheet]] for an
+See also {{:basics.html}the cheat-sheet} for an
 comprehensive overview on the different types of services.
 
->>
+{%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: POST or GET?}
+
 
-<<concept title="POST or GET?" |
 
 POST parameters are sent in the body of the HTTP request (whereas GET
 parameters are sent in the URL).  It is important to understand that
@@ -365,21 +383,20 @@ they have very different semantics.
 
 Remember:
 
-* Use GET parameters when you want your page to be bookmarkable.
-* Use POST parameters when you do not want the page to be
+- Use GET parameters when you want your page to be bookmarkable.
+- Use POST parameters when you do not want the page to be
   bookmarkable, for example, because it performs a side effect on the
   server (connecting a user, add something in a database, perform a
   payment, etc.).
 
-//Warning:// Even if POST parameters are not shown in the URL, they
+}Warning:{e  Even if POST parameters are not shown in the URL, they
 are sent as plain text. If you want to transmit private data (like a password),
 you must
-use HTTPS (see <<a_manual project="ocsigenserver" chapter="config" |
-the Ocsigen server manual >>).  >>
+use HTTPS (see {{:../ocsigenserver/config.html}the Ocsigen server manual}).  {%wodoc:end%}
 
 Now we can register a handler for the new service:
 
-<<code language="ocaml"|
+{@ocaml[
   Eliom_registration.Html.register
     ~service:connection_service
     (fun () (name, password) ->
@@ -392,29 +409,31 @@ Now we can register a handler for the new service:
         (html (head (title (txt "")) [])
            (body [h1 [txt message];
                   user_links ()])));
->>
+]}
 
-where {{{check_pwd}}} is defined by:
+where [check_pwd] is defined by:
 
-<<code language="ocaml"|
+{@ocaml[
 let check_pwd name pwd =
   try List.assoc name !users = pwd with Not_found -> false
->>
+]}
+
+{2 Connection form}
+
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-===Connection form===
 
-<<concepts|
 
 Forms
 
->>
+{%wodoc:end%}
 
 For now, we will add the connection form only on the main page of the
 site.
 
 Let's create a function for generating the form:
 
-<<code language="ocaml"|
+{@ocaml[
 let connection_box () = Eliom_content.Html.D.(
   Form.post_form ~service:connection_service
     (fun (name1, name2) ->
@@ -434,62 +453,56 @@ let connection_box () = Eliom_content.Html.D.(
             Form.string
          ]]) ()
 )
->>
+]}
 
 Now, add a call to this function in the handler of the main service
 (for example just before the user links).
 
-<<concept title="Forms" |
+{%wodoc:aside class="concept"%}{b Concept: Forms}
+
+
 
 Form creation is very similar to link creation, using the functions
-<<a_api project="eliom" subproject="server"
-text="val Eliom_content.Html.D.Form.get_form"
-| val Eliom_content_sigs.LINKS_AND_FORMS.Form.get_form >> and
-<<a_api project="eliom" subproject="server"
-text="val Eliom_content.Html.D.Form.post_form"
-| val Eliom_content_sigs.LINKS_AND_FORMS.Form.post_form >>.
+{{!Eliom_content_sigs.LINKS_AND_FORMS.Form.get_form}val Eliom_content.Html.D.Form.get_form} and
+{{!Eliom_content_sigs.LINKS_AND_FORMS.Form.post_form}val Eliom_content.Html.D.Form.post_form}.
 
 The first parameter is the service, and the last parameter (only for
-{{{post_form}}}) is for GET parameters you want sent in the URL, if
+[post_form]) is for GET parameters you want sent in the URL, if
 the fallback of your POST service takes GET parameters.
 
 The only difference is how we write form content: instead of simply
-giving the content as parameter to the {{{get_form}}} or
-{{{post_form}}} functions, you supply a function that creates the form
+giving the content as parameter to the [get_form] or
+[post_form] functions, you supply a function that creates the form
 from the names of the parameters the service is expecting.  Thus, you
 don't need to remember the parameter names you chose while creating
 the service, and you can change them easily without having to update
 every form in your application.
 
 In the example, note that the service is expecting a pair
-{{{(string * string)}}}.  The function given to {{{post_form}}} takes two
+[(string * string)].  The function given to [post_form] takes two
 parameters corresponding to the names of each field.
 
 Functions building widgets, like
-<<a_api project="eliom" subproject="server"
-text="val Eliom_content.Html.D.Form.input"
-| val Eliom_content_sigs.LINKS_AND_FORMS.Form.input >>,
+{{!Eliom_content_sigs.LINKS_AND_FORMS.Form.input}val Eliom_content.Html.D.Form.input},
 expect an argument of type
-<<a_api project="eliom" subproject="server"
-text="type Eliom_content.Html.D.Form.param"
-| type Eliom_content_sigs.LINKS_AND_FORMS.Form.param >>
+{{!Eliom_content_sigs.LINKS_AND_FORMS.Form.param}type Eliom_content.Html.D.Form.param}
 (e.g.,
-{{{ Eliom_content.Html.D.Form.int : int Eliom_content.Html.D.Form.param}}})
+[Eliom_content.Html.D.Form.int : int Eliom_content.Html.D.Form.param])
 specifying the parameter type.  OCaml checks that the name you use
 matches the field.  For example the names above need to be used with
-<<a_api project="eliom" subproject="server"
-text="val Eliom_content.Html.D.Form.string"
-| val Eliom_content_sigs.LINKS_AND_FORMS.Form.string >>.
+{{!Eliom_content_sigs.LINKS_AND_FORMS.Form.string}val Eliom_content.Html.D.Form.string}.
 
->>
+{%wodoc:end%}
+
+{2 Opening a session}
+
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-===Opening a session===
 
-<<concepts|
 
 Session data, Eliom references
 
->>
+{%wodoc:end%}
 
 Now we want to remember that the user is successfully connected.  To do
 that we will set a reference when the user successfully connects, and
@@ -497,14 +510,14 @@ we will restrict the scope of this reference to the session (that is,
 to the browser).
 
 Define your Eliom reference with a default value:
-<<code language="ocaml"|
+{@ocaml[
 let username =
   Eliom_reference.eref ~scope:Eliom_common.default_session_scope None
->>
+]}
 
-Here is the new {{{connection_box}}} function:
+Here is the new [connection_box] function:
 
-<<code language="ocaml"|
+{@ocaml[
 let connection_box () = Eliom_content.Html.D.(
   let%lwt u = Eliom_reference.get username in
   Lwt.return
@@ -529,11 +542,11 @@ let connection_box () = Eliom_content.Html.D.(
                   Form.string
                ]]) ())
 )
->>
+]}
 
 ...~ and replace the registration of the main service and the connection service by:
 
-<<code language="ocaml"|
+{@ocaml[
   Eliom_registration.Html.register
     ~service:main_service
     (fun () () ->
@@ -560,109 +573,119 @@ let connection_box () = Eliom_content.Html.D.(
         (html (head (title (txt "")) [])
            (body [h1 [txt message];
                   user_links ()])));
->>
+]}
+
 
+{%wodoc:aside class="concept"%}{b Concept: Eliom references and extended sessions}
 
-<<concept title="Eliom references and extended sessions" id="eref"|
 
-Session data is stored in what we call //Eliom references//.
+
+Session data is stored in what we call }Eliom references{e .
 It is a type of reference whose value depend on the session the user
 belongs to.
 
 Eliom is making the notion of session much more powerful by adding
-other //scopes// for Eliom references. Instead of limiting the scope
+other }scopes{e  for Eliom references. Instead of limiting the scope
 to a session (that is: one browser), it is also possible to create
 Eliom references with scope
-* "client-side process"
-({{{~scope:Eliom_common.default_process_scope}}}),
-* or "group of sessions" (see
-later) ({{{~scope:Eliom_common.default_group_scope}}}),
-* or "current
-request" ({{{~scope:Eliom_common.request_scope}}})
+- "client-side process"
+([~scope:Eliom_common.default_process_scope]),
+- or "group of sessions" (see
+later) ([~scope:Eliom_common.default_group_scope]),
+- or "current
+request" ([~scope:Eliom_common.request_scope])
 (for example to cache the data during the request,
-or for //actions// to give information to subsequent service -- see below).
+or for }actions{e  to give information to subsequent service -- see below).
 
 Example: Say you want to implement a game, and make possible to have several instances of the game running in several tabs of the browser. Store the score on server side, as a "client side process" Eliom reference.
 
 Example: Grouping all the sessions for one user in a group of session makes possible to share a shopping basket between several devices (your mobile phone and your laptop for example).
 
 An Eliom reference is defined with the function
-{{{Eliom_reference.eref}}}, specifying the scope of this reference
-and the default value. The function {{{Eliom_reference.get}}}
+[Eliom_reference.eref], specifying the scope of this reference
+and the default value. The function [Eliom_reference.get]
 retrieves the value of this reference for the current scope.
 The default value is used for
 all sessions (or client process or group of sessions) for which it has not
-been changed using {{{Eliom_reference.set}}}.
+been changed using [Eliom_reference.set].
 
 By default, Eliom references are kept in memory and will disappear if
 you shut down the server. It is possible, however, to create
-//persistent Eliom references// that will survive even a server
-restart. To do that, add the optional parameter {{{persistent}}} to
-the {{{eref}}} function, with a string value corresponding to the name
+}persistent Eliom references{e  that will survive even a server
+restart. To do that, add the optional parameter [persistent] to
+the [eref] function, with a string value corresponding to the name
 of the table that will contain the values on disk.
 
 You need to rename this table every time you change the type
 of your Eliom reference, otherwise the server will crash (we are using
-OCaml's {{{Marshal}}} module).
+OCaml's [Marshal] module).
 
 It is not possible to create Eliom references containing functions
 (closures), due to limitations in OCaml's serialization mechanism.
 
->> <<| END "encadre" >>
+{%wodoc:end%} 
+
+{2 Display the usual page after connection}
+
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-===Display the usual page after connection===
 
-<<concepts|
 
 Actions
 
->>
+{%wodoc:end%}
 
 As you can see, our connection service is displaying a welcome page
 which is different from the main page in connected mode.  We would
 rather display the same page.  One solution is to call the same
 handler after registering session data.
 
-A cleaner solution is to use an //action//, that is: a service which will
+A cleaner solution is to use an }action{e , that is: a service which will
 just perform a side effect.  Replace the registration
 of the connection service by:
 
-<<code language="ocaml"|
+{@ocaml[
   Eliom_registration.Action.register
     ~service:connection_service
     (fun () (name, password) ->
       if check_pwd name password
       then Eliom_reference.set username (Some name)
       else Lwt.return ());
->>
+]}
 
 Now the main page is displayed after connection.
 
-<<concept title="Actions" |
+{%wodoc:aside class="concept"%}{b Concept: Actions}
+
 
-An //action// is a service that performs a side effect and redisplays
-the current page. The handler function returns {{{()}}}.
 
->>
+An }action{e  is a service that performs a side effect and redisplays
+the current page. The handler function returns [()].
 
-===Putting a connection form on each page===
+{%wodoc:end%}
 
-<<concepts|
+{2 Putting a connection form on each page}
 
-Non-attached coservices\\
+{%wodoc:aside class="concepts"%}{b Concepts}
+
+
+
+Non-attached coservices{%html:<br/>%}
 Redirections
 
->>
+{%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: Non-attached coservices}
+
 
-<<concept title="Non-attached coservices" |
 
 With many web programming frameworks, adding a connection form on each
 page of a site is complicated, and is approached in one of two ways:
 
-* A first solution is similar to what we did for the main service, but
+- A first solution is similar to what we did for the main service, but
   for all services (meaning that each page usually checks the presence
   of POST parameters). This is clumsy.
-* Another solution would be to create a special page on a separate
+- Another solution would be to create a special page on a separate
   path to handle the registration, with some way to do a redirection
   to the page we came from after connection. (Of course we want to
   stay on the same page after sending the connection form!) This is
@@ -670,37 +693,37 @@ page of a site is complicated, and is approached in one of two ways:
 
 With Eliom, this is more straightforward:
 
-* For the connection service, we use a kind of service called
-  //non-attached coservice//, which means that it is not attached to
+- For the connection service, we use a kind of service called
+  }non-attached coservice{e , which means that it is not attached to
   any path in particular. Calling this kind of service will not change
-  the //path// you see in the browser URL bar (just add parameters if
+  the }path{e  you see in the browser URL bar (just add parameters if
   you use the GET method).
-* Use an action to connect the user and redisplay the page
+- Use an action to connect the user and redisplay the page
   corresponding to the current URL.
 
 By default, a random identifier will be generated automatically by
 Eliom for the non-attached coservice. If you want this identifier to
 be fixed, you can specify it yourself while creating the service using
-the {{{?name}}} optional parameter. This identifier is added
+the [?name] optional parameter. This identifier is added
 automatically by Eliom in each form (as hidden field) and link.
 
->>
+{%wodoc:end%}
 
 We transform the connection service into a non_attached coservice,
-to do so we replace the path we specified earlier for the {{{~path}}} parameter:
+to do so we replace the path we specified earlier for the [~path] parameter:
 
-<<code language="ocaml"|
+{@ocaml[
 let connection_service = Eliom_service.create
   ~path:(Eliom_service.No_path)
   ~meth:(Eliom_service.Post (
     Eliom_parameter.unit,
     Eliom_parameter.(string "name" ** string "password")))
   ()
->>
+]}
 
 Now you can add the connection box on user pages.
 
-<<code language="ocaml"|
+{@ocaml[
   Eliom_registration.Html.register
     ~service:user_service
     (fun name () ->
@@ -710,21 +733,22 @@ Now you can add the connection box on user pages.
               (body [h1 [txt name];
 		     cf;
                      p [a ~service:main_service [txt "Home"] ()]])));
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Alternative: register a redirection}
+
 
-<<concept title="Alternative: register a redirection" |
 
 Usually, after sending a POST form, it is good practice to do a
 redirection.  This avoids reposting the data if the user reloads the
 page.
 
-Eliom provides the module <<a_api project="eliom" subproject="server" |
-module Eliom_registration.Redirection >> to register services doing
+Eliom provides the module {!Eliom_registration.Redirection} to register services doing
 redirections.  Such services return a service without parameter.
 
 Example:
 
-<<code language="ocaml"|
+{@ocaml[
 
 let redir_service = Eliom_service.create
     ~path:(Eliom_service.Path ["redir"])
@@ -748,28 +772,24 @@ let () =
   Eliom_registration.Any.register
   ~service:service_to_redirect
   (fun () something -> ..... )
->>
+]}
 
-(If you want to give parameters to the service you return, use <<a_api
-project="eliom" subproject="server" | val Eliom_service.preapply >> ---
-more information in the <<a_manual project="eliom" chapter="server-services"
-fragment="p3preapplied" | Eliom manual >>.)
+(If you want to give parameters to the service you return, use {!Eliom_service.preapply} ---
+more information in the {{:../eliom/server-services.html#p3preapplied}Eliom manual}.)
 
 If you want to do a redirection towards the current page (as in our
-case), use the special service {{{~path}}} parameter <<a_api project="eliom" subproject="server" |
-val Eliom_service.No_path >>, which is some kind of POST
-non-attached coservice without parameter at all.  >>
+case), use the special service [~path] parameter {!Eliom_service.No_path}, which is some kind of POST
+non-attached coservice without parameter at all.  {%wodoc:end%}
 
-===Disconnection===
+{2 Disconnection}
 
 To create a logout/disconnection form, we create another non-attached
 coservice using POST method, and register another action.  We call the
-function <<a_api project="eliom" subproject="server" | val
-Eliom_state.discard >> with scope <<a_api project="eliom" subproject="server"
-| val Eliom_common.default_session_scope >> to remove all session
+function {!val
+Eliom_state.discard} with scope {!Eliom_common.default_session_scope} to remove all session
 data.
 
-<<code language="ocaml"|
+{@ocaml[
 let disconnection_service = Eliom_service.create
   ~path:(Eliom_service.No_path)
   ~meth:(Eliom_service.Post (Eliom_parameter.unit, Eliom_parameter.unit))
@@ -787,11 +807,11 @@ let () =
   Eliom_registration.Action.register
     ~service:disconnection_service
     (fun () () -> Eliom_state.discard ~scope:Eliom_common.default_session_scope ())
->>
+]}
 
 Then add this form in the connection box:
 
-<<code language="ocaml"|
+{@ocaml[
 let connection_box () =
   let%lwt u = Eliom_reference.get username in
   Lwt.return
@@ -799,24 +819,26 @@ let connection_box () =
       | Some s -> div [p [txt "You are connected as "; txt s; ];
                        disconnect_box () ]
       | None -> ...
->>
+]}
+
+{1 Registration of users}
 
-==Registration of users==
+{2 Basic registration form}
+
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-===Basic registration form===
 
-<<concepts|
 
 Attached coservice
 
->>
+{%wodoc:end%}
 
 We now add a registration form to the application.  We create a
-new regular service, attached to the path {{{/registration}}}, that
+new regular service, attached to the path [/registration], that
 displays a registration form, and an action that will add the user to
 the "database":
 
-<<code language="ocaml"|
+{@ocaml[
 let new_user_form_service = Eliom_service.create
   ~path:(Eliom_service.Path ["registration"])
   ~meth:(Eliom_service.Get Eliom_parameter.unit)
@@ -857,11 +879,11 @@ let _ = Eliom_content.Html.D.(
       users := (name, pwd)::!users;
       Lwt.return ())
 )
->>
+]}
 
 Then add the link to this service in the connection box:
 
-<<code language="ocaml"|
+{@ocaml[
 let connection_box () = Eliom_content.Html.D.(
   let%lwt u = Eliom_reference.get username in
   Lwt.return
@@ -877,12 +899,14 @@ let connection_box () = Eliom_content.Html.D.(
                   [txt "Create an account"] ()]]
             )
 )
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Attached coservice}
+
 
-<<concept title="Attached coservice" |
 
 Now we want to return to the main page after account creation.  We are
-using an //attached coservice//, that is, a service that is identified
+using an }attached coservice{e , that is, a service that is identified
 by both the path in the URL and a special coservice number (or name).
 A form to such a service will change the path and send parameters
 together with the coservice identifier (added automatically in an
@@ -894,7 +918,7 @@ may want to distinguish between several services registered at the
 same path (and with same parameters).  That's what attached coservices
 are made for.
 
->>
+{%wodoc:end%}
 
 It looks great, but if we refresh the page after creating an account,
 we can see there is a problem. We are creating the same account over and
@@ -903,27 +927,29 @@ we refresh the page, obviously we don't want that. To solve this issue we will
 implement a dynamically created and registered service with limited lifespan and
 number of uses.
 
-===Registration form with confirmation===
+{2 Registration form with confirmation}
 
-<<concepts|
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-Dynamic registration of services\\
-Session services\\
+
+
+Dynamic registration of services{%html:<br/>%}
+Session services{%html:<br/>%}
 Limited services
 
->>
+{%wodoc:end%}
 
 Now we want to add a confirmation page before actually creating the
-account.  We //replace// the service {{{create_account_service}}} by a
-new POST attached coservice called {{{account_confirmation_service}}}:
+account.  We }replace{e  the service [create_account_service] by a
+new POST attached coservice called [account_confirmation_service]:
 
-<<code language="ocaml"|
+{@ocaml[
 let account_confirmation_service =
   Eliom_service.create_attached_post
     ~fallback:new_user_form_service
     ~post_params:(Eliom_parameter.(string "name" **  string "password"))
     ()
->>
+]}
 
 and we make the account creation form point at this new service.
 
@@ -931,7 +957,7 @@ We register an HTML handler on this service, with the confirmation
 page.  As a side effect, this page will create the actual account
 creation service:
 
-<<code language="ocaml"|
+{@ocaml[
 
   Eliom_registration.Html.register
     ~service:account_confirmation_service
@@ -959,79 +985,83 @@ creation service:
                   txt " ";
                   a ~service:main_service [txt "No"] ()]
               ])));
->>
+]}
 
-Also remove the registration of the {{{create_account_service}}}
+Also remove the registration of the [create_account_service]
 service and modify the user creation form to make it points towards
-{{{account_confirmation_service}}}.
+[account_confirmation_service].
 
 We created dynamically a service with a limited lifespan as specified by the
-{{{?timeout}}} parameter and a limited number of uses of this service defined
-by the {{{?max_use}}} parameter. Now if we refresh the page after creating the
+[?timeout] parameter and a limited number of uses of this service defined
+by the [?max_use] parameter. Now if we refresh the page after creating the
 account, it works as intended.
 
-<<concept title="Dynamic creation of services" |
+{%wodoc:aside class="concept"%}{b Concept: Dynamic creation of services}
+
+
 
 In this example, we are dynamically creating a new service (here a
 coservice that does an action).  This is done by the same
-{{{register}}} function as usual.
+[register] function as usual.
 
 Dynamic creation of new services allows one to create services that
 depend on previous interaction with the user.  Here the
-{{{create_account_service}}} service depends on {{{name}}} and
-{{{pwd}}}, that were previously sent by a form.
+[create_account_service] service depends on [name] and
+[pwd], that were previously sent by a form.
 
 In this simple example, an alternative would have been to send
-{{{name}}} and {{{pwd}}} again to the same service as in the "basic
+[name] and [pwd] again to the same service as in the "basic
 registration form" example. But this solution is not possible when you
 have too much data.
 
-//Saving {{{name}}} and {{{pwd}}} as session data is a wrong
-solution!// If the user duplicates his browser window and fills out
+}Saving [name] and [pwd] as session data is a wrong
+solution!{e  If the user duplicates his browser window and fills out
 the user creation form in both, then the confirmation link must create
 the right account!
 
 A working alternative would have been to generate a random key, and
-associate {{{name}}} and {{{pwd}}} with that key in a database table
+associate [name] and [pwd] with that key in a database table
 on the server. This is the way such kind of web interaction is usually
 implemented. However, Eliom's solution is much simpler.
 
 The ability to register new services dynamically is implemented in few
 web frameworks, even though it simplifies a lot the programmating
 involved with that type of web interaction.  This feature is a variant
-of what is called //continuation based web programming//.  Think about
-it when you want to //create a page that depends on previous
-interaction with the user//. Dynamic registration of services will
+of what is called }continuation based web programming{e .  Think about
+it when you want to }create a page that depends on previous
+interaction with the user{e . Dynamic registration of services will
 automatically record the "history" of the interaction, and make
 possible to use the "back button" or to have several tabs on the same
 site.
 
 Examples of uses:
-* displaying the results of a search
-* programming a "several step form" (when a form points at another
+- displaying the results of a search
+- programming a "several step form" (when a form points at another
   one, etc., like our registration form with confirmation).
 
-On the other hand, if you want to implement a //shopping basket//, you
+On the other hand, if you want to implement a }shopping basket{e , you
 want it to be shared between all tabs of your web site.  To do that,
 you will use session data.
 
-//Warning:// Services are kept in memory. To avoid memory leaks, you
+}Warning:{e  Services are kept in memory. To avoid memory leaks, you
 probably want to put a timeout on your dynamic coservices. Just add
-the optional parameter {{{?timeout}}} to the service creation
+the optional parameter [?timeout] to the service creation
 function.
 
->> <<| END "encadre" >>
+{%wodoc:end%} 
+
+{%wodoc:aside class="concept"%}{b Concept: Session services}
+
 
-<<concept title="Session services" |
 
 Eliom also makes it possible to restrict the scope of services to a
 session, a group of sessions, or even a client side process (if you
 have a client side program running).  It works exactly like the scope
 of Eliom references.  To do that, just add the optional parameter
-{{{~scope}}} to the registration function.  By default, the value is
-{{{Eliom_common.global_scope}}} (visible for everyone).  Other possible
-values: {{{Eliom_common.default_session_scope}}}, {{{Eliom_common.default_group_scope}}},
-or {{{Eliom_common.default_process_scope}}}.
+[~scope] to the registration function.  By default, the value is
+[Eliom_common.global_scope] (visible for everyone).  Other possible
+values: [Eliom_common.default_session_scope], [Eliom_common.default_group_scope],
+or [Eliom_common.default_process_scope].
 
 It is possible to register again for a session, tab or group, services
 that have already been registered with public (site) visibility.  In
@@ -1040,32 +1070,34 @@ then group services, and finally site services.  This makes possible
 to register specialized versions of a service for one user, for
 example when she logs in.
 
->>
+{%wodoc:end%}
+
+{1 A few enhancements}
+
+{2 Displaying a "wrong password" message}
 
-==A few enhancements==
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-===Displaying a "wrong password" message===
 
-<<concepts|
 Scope "request"
->>
+{%wodoc:end%}
 
 In the current version, our web site fails silently when the password
 is wrong.  Let's improve this behavior by displaying an error message.
 To do that, we need to pass information to the service occurring after
 the action. We record this information in an Eliom reference with
-scope {{{Eliom_common.request_scope}}}.
+scope [Eliom_common.request_scope].
 
 Define an Eliom reference:
 
-<<code language="ocaml"|
+{@ocaml[
 let wrong_pwd =
   Eliom_reference.eref ~scope:Eliom_common.request_scope false
->>
+]}
 
 Modify the connection box this way:
 
-<<code language="ocaml"|
+{@ocaml[
 let connection_box () = Eliom_content.Html.D.(
   let%lwt u = Eliom_reference.get username in
   let%lwt wp = Eliom_reference.get wrong_pwd in
@@ -1094,37 +1126,39 @@ let connection_box () = Eliom_content.Html.D.(
         else div l
     )
 )
->>
+]}
 
-...~ and modify the {{{connection_service}}} handler:
+...~ and modify the [connection_service] handler:
 
-<<code language="ocaml"|
+{@ocaml[
   Eliom_registration.Action.register
     ~service:connection_service
     (fun () (name, password) ->
       if check_pwd name password
       then Eliom_reference.set username (Some name)
       else Eliom_reference.set wrong_pwd true);
->>
+]}
 
-===Sending 404 errors for non-existing users===
+{2 Sending 404 errors for non-existing users}
 
-<<concepts|
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-Sending 404\\
-{{{Eliom_registration.Any}}}
 
->>
 
-Our service {{{user_service}}} responds to any request parameter, even
+Sending 404{%html:<br/>%}
+[Eliom_registration.Any]
+
+{%wodoc:end%}
+
+Our service [user_service] responds to any request parameter, even
 if the user does not exist in the database.  We want to check that the
 user is in the database before displaying the page, and send a 404
 error if the user is not.  To do that, we will replace module
-{{{ Eliom_registration.Html }}}
-by <<a_api project="eliom" subproject="server" | module
-Eliom_registration.Any >> to register the service {{{user_service}}}:
+[Eliom_registration.Html]
+by {!module
+Eliom_registration.Any} to register the service [user_service]:
 
-<<code language="ocaml"|
+{@ocaml[
   Eliom_registration.Any.register
     ~service:user_service
     (fun name () ->
@@ -1144,45 +1178,46 @@ Eliom_registration.Any >> to register the service {{{user_service}}}:
              (body [h1 [txt "404"];
                     p [txt "That page does not exist"]]))
     );
->>
+]}
+
+
 
-<<| BB
-  Why not {{{raise_lwt Eliom_common.Eliom_404}}}?
-  >>
+{%wodoc:aside class="concept"%}{b Concept: Eliom_registration.Any}
 
-<<concept title="Eliom_registration.Any" |
 
-The module <<a_api project="eliom" subproject="server" | module
-Eliom_registration.Any >> can be used to create services that are
+
+The module {!module
+Eliom_registration.Any} can be used to create services that are
 flexible to choose the kind of output they want to send.
 
-Use the {{{send}}} function from the module you want to send the
+Use the [send] function from the module you want to send the
 output.  That function also allows, for example, to specify the HTTP
 response code (here, we choose to use 404) or to set HTTP headers.
 
->>
+{%wodoc:end%}
+
+{%wodoc:aside class="wip"%}{b Work in progress}
+
 
-<<wip|
 
-In the future, we may add functions like {{{set_http_code}}} or
-{{{set_http_header}}} to personalize the answer without using
-{{{Eliom_registration.Any}}}.
+In the future, we may add functions like [set_http_code] or
+[set_http_header] to personalize the answer without using
+[Eliom_registration.Any].
 
->>
+{%wodoc:end%}
 
-=== Wrapping the server handler to easily get the user data
+{2 Wrapping the server handler to easily get the user data}
 
 When you want to assume that you have information available in
 sessions, for instance when a site is mainly available to connected
 users, it becomes tedious to check everywhere that a reference is not
-{{{None}}}.  A simple way to distinguish authenticated and anonymous
-requests lies in the usage of <<a_api project="eliom"
-subproject="server"|val Eliom_tools.wrap_handler>>. It allows you to
+[None].  A simple way to distinguish authenticated and anonymous
+requests lies in the usage of {!Eliom_tools.wrap_handler}. It allows you to
 provide two handler functions, one is called if a certain
 information is not made available by the first argument, the other is
 called when that information is available.
 
-<<code language="ocaml"|
+{@ocaml[
 
 let authenticated_handler f = Eliom_content.Html.D.(
   let handle_anonymous _get _post =
@@ -1220,7 +1255,7 @@ let () = Eliom_content.Html.D.(
               (head (title (txt "")) [])
               (body [h1 [txt ("Hello " ^ username) ]]))))
 )
->>
+]}
 
-[[wiki:manual/application|prev]]
-[[wiki:manual/misc|next]]
+{{:wiki:manual/application}prev}
+{{:wiki:manual/misc}next}
diff --git a/tutos/8.0/manual/intro.mld b/tutos/8.0/manual/intro.mld
new file mode 100644
index 00000000..04a8f2a4
--- /dev/null
+++ b/tutos/8.0/manual/intro.mld
@@ -0,0 +1,139 @@
+
+{0 Introduction}
+
+Ocsigen is a complete framework for developing Web and mobile apps
+using cutting edge techniques. It can be used to write simple server side
+Web sites, client-side programs, or complex client-server Web
+and mobile apps.
+Its main characteristics are:
+
+- The use of a strongly typed language, {e OCaml}, and a very advanced use
+of its type system to check many properties of a program at compile time.
+This allows to drastically reduce the development time of complex apps,
+and makes it easier to refactor the code to follow evolutions of its features.
+As an example, the conformance of generated HTML is checked at compile time,
+which makes it almost impossible to generate invalid pages.
+- {e Multi-tier programming}: client and server sides of the application are
+written using the same language, and as a {e single code}. Annotations in
+the code are used indicate on which side the code is to be run.
+The client side parts are automatically extracted and compiled into JavaScript
+to be executed in the browser.
+This gives a lot of flexibility to the programmer, allowing for example to
+generate some parts of pages either on client or server code according
+to your needs. It also makes communication between server and client
+straightforward, as you can use server side variables in client code,
+or call a server side OCaml functions from client code.
+- {e Web and mobile multi-platform apps}: Android and iOS apps are
+generated from the exact same code as the Web app, and run in a webview.
+
+To see some examples of mobile or Web apps written with Ocsigen, have a look
+at the {{:https://www.besport.com/news}Be Sport social network} (available in
+{{:https://play.google.com/store/apps/details?id=com.besport.www.mobile}Google Play Store} and {{:https://apps.apple.com/fr/app/be-sport/id1104216922}Apple app store}), or
+{{:http://ocsigen-1.inria.fr/ocsigen-start/demo/}Ocsigen Start's demo app}
+(available on {{:https://play.google.com/store/apps/details?id=com.osdemo.mobile}Google Play store}).
+
+Ocsigen consists of several quite independent projects, all
+released as open source software on {{:https://github.com/ocsigen}Github}.
+The main projects are:
+- {{:../lwt/}Lwt}, a general purpose concurrent programming library for OCaml,
+- {{:../tyxml/}TyXML} for generating typed XML,
+- the {{:../js_of_ocaml/}Js_of_ocaml} compiler (from Ocaml bytecode to JavaScript),
+- {{:../eliom/}Eliom}, the multi-tier framework for client-server
+Web and mobile apps,
+- {{:../ocsigenserver/}Ocsigen Server}, a full-featured Web server,
+- {{:../ocsigen-toolkit/}Ocsigen Toolkit}, a client-server widget library written for Eliom and Js_of_ocaml,
+- {{:../ocsigen-start/}Ocsigen Start}, an application template with
+many code examples, to be used as a basis for your apps, or to learn.
+
+The {{:../install}installation is described here}.
+
+Ocsigen originates from a research project by the CNRS, Université de Paris
+and Inria. It innovates in many aspects, and you will have to learn several
+new programming techniques to become autonomous.
+Depending on your level and goals, we suggest to continue by reading
+some of the following chapters:
+
+- Chapter {{:wiki:manual/basics}Client-server application programming guide} can be used as your training plan.
+It provides a wide overview of each main concept, with links to more detailed
+documentation.
+- If you want to start with a server-side only Web site, read {{:wiki:manual/basics-server}Server-side website programming guide} instead.
+- Then, a good starting point is this
+{{:wiki:manual/start}Ocsigen Start tutorial},
+if you plan to build a client-server Web (and/or mobile) app.
+It will help you to build your first app very quickly,
+with many code samples to study.
+- If you are fluent in OCaml and want a quick introduction to
+client-server Web programming with Eliom,
+read tutorial
+{{:wiki:manual/tutowidgets}Eliom apps basics: writing client server widgets}.
+It illusrates the client-server syntax with an example,
+and is a good starting point for understanding Eliom's client-server features.
+- If you want a full step-by-step tutorial on how to write a client-server Web
+application, read tutorial
+{{:wiki:manual/application}Client-server application}.
+It describes step by step how to write a client/server
+{{:../graffiti/}collaborative drawing application}. You will learn,
+from the very beginning, how to:
+- Create new {e services}
+- Output {e valid HTML}
+- Send {e OCaml code} to be executed {e on the client}
+- Call {e JavaScript methods} from OCaml
+- Catch {e mouse events}
+- {e Communicate} with the server, in both directions
+- Create services with {e non-HTML output}
+- If you want to build mobile applications,
+read tutorial {{:wiki:manual/mobile}Mobile applications with Ocsigen}.
+It describes how to build a mobile app (e.g., for Android)
+with the same codebase as for your Web application.
+- If you want to write a more traditional Web site, with pages, forms, and sessions, read tutorial {{:wiki:manual/interaction}Service based Web programming}.
+It is devoted to server side programming.
+It shows how to
+create a new Web site with several pages and user connections.
+You will learn how to:
+- Create a {e link} towards another service
+- Create {e forms}
+- Register {e session data} or {e session services}
+- Create services performing {e actions} (with no output)
+- Dynamically register new services ({e continuation based} Web programming)
+- If you want to learn more details about Ocsigen
+read tutorial {{:wiki:manual/misc}Miscellaneous features}.
+It will mix the client-server drawing application
+with the session mechanism and user management
+to produce a multi-user collaborative drawing
+application.  In this chapter, you will learn how to:
+- Integrate a typical Web interaction (links, forms,~ …) with a client side program.
+- Add {e sounds or videos} to your application
+- Change pages {e without stopping the client side program}
+- Connect with external accounts ({e openID})
+- Add an Atom feed
+- If you want to have a full application with user management
+(registration, activation emails, authentication),
+have a look at {{:../ocsigen-start/}Ocsigen-start}.
+Ocsigen-start is a library and a template for Eliom distillery that
+contains a working Eliom application with user and right
+management.
+- For a more comprehensive understanding refer to the manual of each project,
+and/or the API documentation.
+- You will also find more tutorials in the menu on the left.
+
+
+
+
+
+
+
+
+
+
+We recommend to ask your questions on
+{{:https://discuss.ocaml.org}discuss.ocaml.org} with tag [ocsigen].
+You can also come and chat with us on
+IRC in channel [#ocsigen] on [freenode.net] (e.g. by using
+their {{:http://webchat.freenode.net/?channels=ocsigen}webchat})!
+
+
+Now, we recommend to read, chapter
+{{:wiki:manual/basics}All Ocsigen in one page}
+for a wide and complete overview.
+
+
diff --git a/tutos/8.0/manual/intro.wiki b/tutos/8.0/manual/intro.wiki
deleted file mode 100644
index 01fec817..00000000
--- a/tutos/8.0/manual/intro.wiki
+++ /dev/null
@@ -1,157 +0,0 @@
-
-=Introduction=
-
-Ocsigen is a complete framework for developing Web and mobile apps
-using cutting edge techniques. It can be used to write simple server side
-Web sites, client-side programs, or complex client-server Web
-and mobile apps.
-Its main characteristics are:
-
-* The use of a strongly typed language, //OCaml//, and a very advanced use
-of its type system to check many properties of a program at compile time.
-This allows to drastically reduce the development time of complex apps,
-and makes it easier to refactor the code to follow evolutions of its features.
-As an example, the conformance of generated HTML is checked at compile time,
-which makes it almost impossible to generate invalid pages.
-* //Multi-tier programming//: client and server sides of the application are
-written using the same language, and as a //single code//. Annotations in
-the code are used indicate on which side the code is to be run.
-The client side parts are automatically extracted and compiled into JavaScript
-to be executed in the browser.
-This gives a lot of flexibility to the programmer, allowing for example to
-generate some parts of pages either on client or server code according
-to your needs. It also makes communication between server and client
-straightforward, as you can use server side variables in client code,
-or call a server side OCaml functions from client code.
-* //Web and mobile multi-platform apps//: Android and iOS apps are
-generated from the exact same code as the Web app, and run in a webview.
-
-To see some examples of mobile or Web apps written with Ocsigen, have a look
-at the [[https://www.besport.com/news|Be Sport social network]] (available in
-[[https://play.google.com/store/apps/details?id=com.besport.www.mobile|Google Play Store]] and [[https://apps.apple.com/fr/app/be-sport/id1104216922|Apple app store]]), or
-[[http://ocsigen-1.inria.fr/ocsigen-start/demo/|Ocsigen Start's demo app]]
-(available on [[https://play.google.com/store/apps/details?id=com.osdemo.mobile|Google Play store]]).
-
-Ocsigen consists of several quite independent projects, all
-released as open source software on [[https://github.com/ocsigen|Github]].
-The main projects are:
-* [[wiki("lwt"):|Lwt]], a general purpose concurrent programming library for OCaml,
-* [[wiki("tyxml"):|TyXML]] for generating typed XML,
-* the [[wiki("js_of_ocaml"):|Js_of_ocaml]] compiler (from Ocaml bytecode to JavaScript),
-* [[wiki("eliom"):|Eliom]], the multi-tier framework for client-server
-Web and mobile apps,
-* [[wiki("ocsigenserver"):|Ocsigen Server]], a full-featured Web server,
-* [[wiki("ocsigen-toolkit"):|Ocsigen Toolkit]], a client-server widget library written for Eliom and Js_of_ocaml,
-* [[wiki("ocsigen-start"):|Ocsigen Start]], an application template with
-many code examples, to be used as a basis for your apps, or to learn.
-
-The [[site:install|installation is described here]].
-
-Ocsigen originates from a research project by the CNRS, Université de Paris
-and Inria. It innovates in many aspects, and you will have to learn several
-new programming techniques to become autonomous.
-Depending on your level and goals, we suggest to continue by reading
-some of the following chapters:
-
-* Chapter [[wiki:manual/basics|Client-server application programming guide]] can be used as your training plan.
-It provides a wide overview of each main concept, with links to more detailed
-documentation.
-* If you want to start with a server-side only Web site, read [[wiki:manual/basics-server|Server-side website programming guide]] instead.
-* Then, a good starting point is this
-[[wiki:manual/start|Ocsigen Start tutorial]],
-if you plan to build a client-server Web (and/or mobile) app.
-It will help you to build your first app very quickly,
-with many code samples to study.
-* If you are fluent in OCaml and want a quick introduction to
-client-server Web programming with Eliom,
-read tutorial
-[[wiki:manual/tutowidgets|Eliom apps basics: writing client server widgets]].
-It illusrates the client-server syntax with an example,
-and is a good starting point for understanding Eliom's client-server features.
-* If you want a full step-by-step tutorial on how to write a client-server Web
-application, read tutorial
-[[wiki:manual/application|Client-server application]].
-It describes step by step how to write a client/server
-[[site:graffiti/|collaborative drawing application]]. You will learn,
-from the very beginning, how to:
-** Create new //services//
-** Output //valid HTML//
-** Send //OCaml code// to be executed //on the client//
-** Call //JavaScript methods// from OCaml
-** Catch //mouse events//
-** //Communicate// with the server, in both directions
-** Create services with //non-HTML output//
-* If you want to build mobile applications,
-read tutorial [[wiki:manual/mobile|Mobile applications with Ocsigen]].
-It describes how to build a mobile app (e.g., for Android)
-with the same codebase as for your Web application.
-* If you want to write a more traditional Web site, with pages, forms, and sessions, read tutorial [[wiki:manual/interaction|Service based Web programming]].
-It is devoted to server side programming.
-It shows how to
-create a new Web site with several pages and user connections.
-You will learn how to:
-** Create a //link// towards another service
-** Create //forms//
-** Register //session data// or //session services//
-** Create services performing //actions// (with no output)
-** Dynamically register new services (//continuation based// Web programming)
-* If you want to learn more details about Ocsigen
-read tutorial [[wiki:manual/misc|Miscellaneous features]].
-It will mix the client-server drawing application
-with the session mechanism and user management
-to produce a multi-user collaborative drawing
-application.  In this chapter, you will learn how to:
-** Integrate a typical Web interaction (links, forms,~ …) with a client side program.
-** Add //sounds or videos// to your application
-** Change pages //without stopping the client side program//
-** Connect with external accounts (//openID//)
-** Add an Atom feed
-* If you want to have a full application with user management
-(registration, activation emails, authentication),
-have a look at [[wiki("ocsigen-start"):|Ocsigen-start]].
-Ocsigen-start is a library and a template for Eliom distillery that
-contains a working Eliom application with user and right
-management.
-* For a more comprehensive understanding refer to the manual of each project,
-and/or the API documentation.
-* You will also find more tutorials in the menu on the left.
-
-
-<<|[[http://www.dailymotion.com/video/k3m1rZBWQCWBCL693Y5|{{files/2014-epita-video.png|video}}]]
-If you want a wide overview about Ocsigen, for beginners, in french
-look at  [[href:http://www.dailymotion.com/video/k3m1rZBWQCWBCL693Y5|this video]]
->>
-
-<<|div class="tutocase"|
-[[https://www.irill.org/videos/OUPS-2014-07/Meetup_OCaml_Oscigen|OUPS meeting at Mozilla Paris]]
-;A short talk, in english, that highlights a few features of Js~_of~_ocaml
-and Eliom.
-:Look at [[https://www.irill.org/videos/OUPS-2014-07/Meetup_OCaml_Oscigen|this video]]
->>
-
-<<|div class="tutocase"|
-[[http://www.irill.org/videos/oups-december-2014/Ocsigen|OUPS meeting at IRILL]]
-;A short talk, in english, that shows how to write a small client-server reactive application with Js~_of~_ocaml and Eliom.
-:Look at [[http://www.irill.org/videos/oups-december-2014/Ocsigen|this video]]
-and read this [[wiki:manual/tutoreact|tutorial]].
-It describes the most recent features of Eliom.
->>
-
-
-
-We recommend to ask your questions on
-[[https://discuss.ocaml.org|discuss.ocaml.org]] with tag {{{ocsigen}}}.
-You can also come and chat with us on
-IRC in channel {{{#ocsigen}}} on {{{freenode.net}}} (e.g. by using
-their [[http://webchat.freenode.net/?channels=ocsigen|webchat]])!
-
-
-Now, we recommend to read, chapter
-[[wiki:manual/basics|All Ocsigen in one page]]
-for a wide and complete overview.
-
-<<|wip|
-Manuals are permanently under evolution.
-Please report any error, mistake, for example by doing pull requests
-on Github, and send us your comments and suggestions!
->>
diff --git a/tutos/8.0/manual/lwt.wiki b/tutos/8.0/manual/lwt.mld
similarity index 57%
rename from tutos/8.0/manual/lwt.wiki
rename to tutos/8.0/manual/lwt.mld
index fc48edeb..86dae89c 100644
--- a/tutos/8.0/manual/lwt.wiki
+++ b/tutos/8.0/manual/lwt.mld
@@ -1,10 +1,12 @@
-<<header| = Lwt in 5 minutes >>
+{%wodoc:header%}
+{0 Lwt in 5 minutes}
+{%wodoc:end%}
 
-== Principles
+{1 Principles}
 
 The Lwt library implements cooperative threads for OCaml.  Cooperative
 threads are an alternative to preemptive threads (used in many
-languages and in OCaml's {{{Thread}}} module) that solve most common
+languages and in OCaml's [Thread] module) that solve most common
 issues with preemptive threads: with Lwt, there is very limited risk
 of deadlocks and very limited need for locks.  Lwt threads are even
 usable in programs compiled to JavaScript using Js_of_ocaml.
@@ -13,137 +15,137 @@ Lwt is based on the fact that most programs spend most of their time
 waiting for inputs, e.g., keys, data coming from sockets, and mouse
 events. Instead of relying on a preemptive scheduler that switches
 between threads at arbitrary moments, Lwt uses these waiting times as
-//cooperation points//. This means that instead of blocking (for
-example on a {{{read}}}), Lwt resumes another waiting thread, if there
+{e cooperation points}. This means that instead of blocking (for
+example on a [read]), Lwt resumes another waiting thread, if there
 is one that is ready to continue. All you have to do is to use the
 cooperative version of each blocking function, for example
-{{{Lwt_unix.sleep}}} instead of {{{Unix.sleep}}}
-and {{{Lwt_unix.read}}} instead of {{{Unix.read}}}.
+[Lwt_unix.sleep] instead of [Unix.sleep]
+and [Lwt_unix.read] instead of [Unix.read].
 If one of your computations takes a lot of time, it is also possible
 to manually insert cooperation points using the function
-{{{Lwt_main.yield}}}.
+[Lwt_main.yield].
 
-== Promises
+{1 Promises}
 
-Lwt defines a type {{{'a Lwt.t}}}, which is the type of promises.
+Lwt defines a type ['a Lwt.t], which is the type of promises.
 For example, the function:
 
-<<code language="ocaml"|
+{@ocaml[
 val f : unit -> int Lwt.t
->>
+]}
 
-immediately returns a promise of {{{int}}}, that is, something that
+immediately returns a promise of [int], that is, something that
 will eventually become an integer once the computation is finished.
 
-The following code will launch the computation of {{{f ()}}}
+The following code will launch the computation of [f ()]
 (asynchronously). If the code reaches a cooperation point (for example
 when the integer is requested via the network), it will continue the
 program (print "hello") and resume at a subsequent cooperation point,
 when the data is available.
 
-<<code language="ocaml"|
+{@ocaml[
 let g1 () =
   let p = f () in
   print_endline "hello"
->>
+]}
 
-== Bind: Using the value of promises
+{1 Bind: Using the value of promises}
 
 It is possible to tell Lwt to execute a function once a promise is
 completed, by using the function:
 
-<<code language="ocaml"|
+{@ocaml[
 Lwt.bind : 'a Lwt.t -> ('a -> 'b Lwt.t) -> 'b Lwt.t
->>
+]}
 
-For instance {{{Lwt.bind p h}}} will call the function {{{h}}} with
-the return value of the promise {{{p}}} as soon as the value is known.
-The expression {{{(Lwt.bind p h)}}} is also a promise (it may take
-time to complete). Function {{{h}}} must return a promise.
+For instance [Lwt.bind p h] will call the function [h] with
+the return value of the promise [p] as soon as the value is known.
+The expression [(Lwt.bind p h)] is also a promise (it may take
+time to complete). Function [h] must return a promise.
 
-To create a (terminated) promise from a value, use {{{Lwt.return}}}.
+To create a (terminated) promise from a value, use [Lwt.return].
 
 Example:
-<<code language="ocaml"|
+{@ocaml[
 let g2 () =
   let p = f () in
   Lwt.bind p (fun i -> print_int i; Lwt.return ())
->>
-Function {{{g2}}} calls function {{{f}}} to create a promise.
+]}
+Function [g2] calls function [f] to create a promise.
 Then it waits (in a cooperative manner) for the result,
-and prints the result. The expression {{{g2 ()}}} has type {{{unit Lwt.t}}}.
+and prints the result. The expression [g2 ()] has type [unit Lwt.t].
 
 
-== Syntax extension
+{1 Syntax extension}
 
 A PPX (and also camlp4) syntax extension is available.
 
-<<code language="ocaml"|
+{@ocaml[
 let%lwt i = f () in
 ...
->>
+]}
 
 is equivalent to
 
-<<code language="ocaml"|
+{@ocaml[
 Lwt.bind (f ()) (fun i -> ...)
->>
+]}
 
-== Examples
+{1 Examples}
 
-=== A function that prints "tic" every second forever, without blocking the rest of the program
+{2 A function that prints "tic" every second forever, without blocking the rest of the program}
 
-<<code language="ocaml"|
+{@ocaml[
 let rec tic () =
     print_endline "tic";
     let%lwt () = Lwt_unix.sleep 1.0 in
     tic ()
->>
+]}
 
-Replace {{{Lwt_unix.sleep}}} by {{{Lwt_js.sleep}}} if your program is
+Replace [Lwt_unix.sleep] by [Lwt_js.sleep] if your program is
 running in a browser.
 
 
-=== Launching concurrent threads and waiting for their results
+{2 Launching concurrent threads and waiting for their results}
 
 Suppose you have two cooperative functions:
-<<code language="ocaml"|
+{@ocaml[
 val f : unit -> unit Lwt.t
 val g : unit -> unit Lwt.t
->>
+]}
 
-The following code runs {{{f ()}}} and {{{g ()}}} sequentially:
-<<code language="ocaml"|
+The following code runs [f ()] and [g ()] sequentially:
+{@ocaml[
 let%lwt () = f () in
 let%lwt () = g () in
 ...
->>
+]}
 
-The following code launches {{{f ()}}} and {{{g ()}}} concurrently,
+The following code launches [f ()] and [g ()] concurrently,
 then waits for both to terminate before continuing:
-<<code language="ocaml"|
+{@ocaml[
 let p1 = f () in
 let p2 = g () in
 let%lwt () = p1 in
 let%lwt () = p2 in
 ...
->>
+]}
 
 To detach a thread, it is recommended to use
-<<code language="ocaml"|
+{@ocaml[
 Lwt.async (fun () -> f ())
->>
+]}
 instead of
-<<code language="ocaml"|
+{@ocaml[
 ignore (f ())
->>
+]}
 to catch exceptions properly.
 
-=== Serial and concurrent map on lists
+{2 Serial and concurrent map on lists}
 
 The following map function runs all computation concurrently
 on all list elements:
-<<code language="ocaml"|
+{@ocaml[
 let rec map f l =
   match l with
   | [] -> Lwt.return []
@@ -153,11 +155,11 @@ let rec map f l =
       let%lwt v' = t in
       let%lwt l' = rt in
       Lwt.return (v' :: l')
->>
+]}
 
 whereas the following one waits for the one to complete before
 launching the next one:
-<<code language="ocaml"|
+{@ocaml[
 let rec map_serial f l =
   match l with
   | [] -> return []
@@ -165,14 +167,14 @@ let rec map_serial f l =
       let%lwt v' = f v in
       let%lwt l' = map_serial f r in
       Lwt.return (v' :: l')
->>
+]}
 
 
-== More documentation
+{1 More documentation}
 
-Have a look at <<a_manual project="lwt" chapter="manual"|Lwt's manual>>
+Have a look at {{:../lwt/manual.html}Lwt's manual}
 for more details about Lwt.
-You will learn how to handle exceptions (using {{{Lwt.fail}}}
-and {{{Lwt.catch}}} or {{{try%lwt}}}).
+You will learn how to handle exceptions (using [Lwt.fail]
+and [Lwt.catch] or [try%lwt]).
 You will also learn for example how to create a thread that waits until it is
-awaken (using {{{Lwt.wait}}} and {{{Lwt.wakeup}}}).
+awaken (using [Lwt.wait] and [Lwt.wakeup]).
diff --git a/tutos/8.0/manual/macaque.wiki b/tutos/8.0/manual/macaque.mld
similarity index 69%
rename from tutos/8.0/manual/macaque.wiki
rename to tutos/8.0/manual/macaque.mld
index e830ef6f..d4000765 100644
--- a/tutos/8.0/manual/macaque.wiki
+++ b/tutos/8.0/manual/macaque.mld
@@ -1,10 +1,12 @@
-=Type safe database requests using Macaque=
+{0 Type safe database requests using Macaque}
 
-<<concepts |Type safe database requests>>
+{%wodoc:aside class="concepts"%}{b Concepts}
+
+Type safe database requests{%wodoc:end%}
 
 The Macaque library allows easy manipulation of Postgresql
 database fully compatible with Lwt. (For more information see
-[[https://github.com/ocsigen/macaque| Macaque manual]]).
+{{:https://github.com/ocsigen/macaque} Macaque manual}).
 
 Macaque is fuly compatible with PGOcaml, and both can be used
 in the same application. PGOcaml requires database access at compile
@@ -12,32 +14,32 @@ time and makes difficult to generate queries at compile time.
 Macaque uses its own syntax, whereas PGOcaml uses SQL.
 Macaque supports only a small subset of Postgresql features.
 
-Warning: Macaque's syntax extension uses camlp4, which is not compatible with ppx. If you want to use macaque with Eliom's ppx, place your macaque code in an isolated file. Some details can be found in <<a_manual project="eliom" chapter="ppx-migration"|the ppx migration guide>>.
+Warning: Macaque's syntax extension uses camlp4, which is not compatible with ppx. If you want to use macaque with Eliom's ppx, place your macaque code in an isolated file. Some details can be found in {{:../eliom/ppx-migration.html}the ppx migration guide}.
 
 This tutorial shows how to store the login and the password
 f users in a Postgresql
 database. For more information on how to set up and run it, see
-[[http://www.postgresql.org/docs/9.0/static/index.html|Postgresql
-manual]].
+{{:http://www.postgresql.org/docs/9.0/static/index.html}Postgresql
+manual}.
 
 When the base is up and running, we create the base by running in a shell:
-<<code language="sh"|
+{@sh[
 $ createdb testbase
->>
+]}
 
-Then we create the {{{users}}} table, by executing this sql script:
+Then we create the [users] table, by executing this sql script:
 
-<<code language="sql"| CREATE TABLE users (
+{@sql[ CREATE TABLE users (
        login text NOT NULL,
        password text NOT NULL
 );
->>
+]}
 
-We save it under {{{create_table.sql}}} and run
+We save it under [create_table.sql] and run
 
-<<code language="sh"|
+{@sh[
 $ psql -d testbase -f create_table.sql
->>
+]}
 
 Macaque can use any thread library that provides a monadic
 interface. The default one provides simple blocking access to the
@@ -46,66 +48,66 @@ user will prevent the server from handling anything else until the
 request is finished. We need a version of Macaque specialised for
 Lwt. It is obtained by
 
-<<code language="ocaml"|
+{@ocaml[
 module Lwt_thread = struct
   include Lwt
   include Lwt_chan
 end
 module Lwt_PGOCaml = PGOCaml_generic.Make(Lwt_thread)
 module Lwt_Query = Query.Make_with_Db(Lwt_thread)(Lwt_PGOCaml)
->>
+]}
 
-We can now open the database with our newly created {{{Lwt_PGOCaml.connect}}}.
+We can now open the database with our newly created [Lwt_PGOCaml.connect].
 
-<<code language="ocaml"|
+{@ocaml[
 let get_db : unit -> unit Lwt_PGOCaml.t Lwt.t =
   let db_handler = ref None in
   fun () ->
     match !db_handler with
       | Some h -> Lwt.return h
       | None -> Lwt_PGOCaml.connect ~database:"testbase" ()
->>
+]}
 
 Then we declare the table on which we will work and the different
 requests we do on it.
 
-<<code language="ocaml"|
+{@ocaml[
 let table = <:table< users (
   login text NOT NULL,
   password text NOT NULL
-) ~>>
+) >>
 
 let find name =
-  (get_db () ~>>= fun dbh ->
+  (get_db () >>= fun dbh ->
    Lwt_Query.view dbh
    <:view< {password = user_.password} |
             user_ in $table$;
-            user_.login = $string:name$; ~>>)
+            user_.login = $string:name$; >>)
 
 let insert name pwd =
-  get_db () ~>>= fun dbh ->
+  get_db () >>= fun dbh ->
   Lwt_Query.query dbh
   <:insert< $table$ :=
-    { login = $string:name$; password = $string:pwd$; } ~>>
+    { login = $string:name$; password = $string:pwd$; } >>
 
->>
+]}
 
 Finally, we modify the handling code :
 
-<<code language="ocaml"|
+{@ocaml[
 let check_pwd name pwd =
-  (get_db () ~>>= fun dbh ->
+  (get_db () >>= fun dbh ->
    Lwt_Query.view dbh
    <:view< {password = user_.password} |
             user_ in $table$;
             user_.login = $string:name$;
-	    user_.password = $string:pwd$ ~>>)
+	    user_.password = $string:pwd$ >>)
   >|= (function [] -> false | _ -> true)
 
 let () = Eliom_registration.Action.register
   ~service:create_account_service
   (fun () (name, pwd) ->
-    find name ~>>=
+    find name >>=
       (function
 	| [] -> insert name pwd
 	| _ -> Lwt.return ()) )
@@ -113,17 +115,17 @@ let () = Eliom_registration.Action.register
 let () = Eliom_registration.Action.register
   ~service:connection_service
   (fun () (name, password) ->
-    check_pwd name password ~>>=
+    check_pwd name password >>=
       (function
 	| true -> Eliom_reference.set username (Some name)
 	| false -> Lwt.return ()))
->>
+]}
 
-We need to reference {{{macaque}}} in the {{{Makefile}}} (or in {{{Makefile.option}}} if you used {{{eliom-distillery}}}) :
-{{{
+We need to reference [macaque] in the [Makefile] (or in [Makefile.option] if you used [eliom-distillery]) :
+{v
 SERVER_PACKAGE := macaque.syntax
-}}}
-and in {{{ocsigenserver.conf}}} (only if you don't use {{{eliom-distillery}}}) :
-{{{
+v}
+and in [ocsigenserver.conf] (only if you don't use [eliom-distillery]) :
+{v
 <extension findlib-package="macaque"/>
-}}}
+v}
diff --git a/tutos/8.0/manual/misc.wiki b/tutos/8.0/manual/misc.mld
similarity index 83%
rename from tutos/8.0/manual/misc.wiki
rename to tutos/8.0/manual/misc.mld
index 65d606c9..7c0eb887 100644
--- a/tutos/8.0/manual/misc.wiki
+++ b/tutos/8.0/manual/misc.mld
@@ -1,20 +1,22 @@
-=Traditional web interaction in a client-server app=
+{0 Traditional web interaction in a client-server app}
 
-<<|outline target="documentation">>
 
-//The code of this tutorial has been tested with Eliom 6.0.// \\
 
-==Multi-user collaborative drawing application==
+{e The code of this tutorial has been tested with Eliom 6.0.} {%html:<br/>%}
+
+{1 Multi-user collaborative drawing application}
 
 We now want to turn our collaborative drawing application into a
 multi-user one. Each user will have their own drawing, where everyone
 can draw.
 
 See the
-[[https://github.com/ocsigen/graffiti/tree/master/extended/|full code of examples]].
+{{:https://github.com/ocsigen/graffiti/tree/master/extended/}full code of examples}.
+
+{2 Split application into multiple files and using several canvases}
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-===Split application into multiple files and using several canvases===
-<<concepts | Complex eliom project\\Unique elements>>
+ Complex eliom project{%html:<br/>%}Unique elements{%wodoc:end%}
 
 We first build a multi-canvas drawing application. Each drawing has
 its own URL. Everyone can create a new drawing by going to the
@@ -27,32 +29,32 @@ variables, like the bus, into local ones.
 When an application grows, it becomes useful to split it into multiple
 files. For example, we will split graffiti into 4 files.
 
-* {{{common.ml}}}, which will be part of both client and server,
+- [common.ml], which will be part of both client and server,
   containing shared types and declarations,
-* {{{client.ml}}}, client-only part of the application,
-* {{{server.ml}}}, server-only part of the application, and
-* {{{graffiti.eliom}}}, which is the only part where we need to
+- [client.ml], client-only part of the application,
+- [server.ml], server-only part of the application, and
+- [graffiti.eliom], which is the only part where we need to
   include both client-side and server-side code
 
-===={{{common.ml}}}====
+{3 [common.ml]}
 
-It contains what was previously in {{{ [%shared ... ] }}}
-<<code language="ocaml"|
+It contains what was previously in [[%shared ... ]]
+{@ocaml[
 type messages =
   ((int * int * int) * int * (int * int) * (int * int))
   [@@deriving json]
 
 let width = 700
 let height = 400
->>
+]}
 
-===={{{client.ml}}}====
+{3 [client.ml]}
 
-It is almost the same code as what was enclosed in {{{ {client{ ... }}
-}}}, with the difference that what was previously in the client value
-{{{init_client}}} is now in the function {{{launch_client_canvas}}}.
+It is almost the same code as what was enclosed in {v {client{ ... }}
+v}, with the difference that what was previously in the client value
+[init_client] is now in the function [launch_client_canvas].
 
-<<code language="ocaml"|
+{@ocaml[
 open Common
 open Js_of_ocaml
 open Eliom_content
@@ -79,15 +81,15 @@ let stop_drawing { message_thread; drawing_thread } =
   Lwt.cancel message_thread;
   (* cancelling this thread also close the bus *)
   Lwt.cancel drawing_thread
->>
+]}
+
 
-<<| WTF? Notice that the client does not keep data from pages it left.>>
-{{{Lwt.cancel t}}} stops thread t. In this case it also closes the
+[Lwt.cancel t] stops thread t. In this case it also closes the
   bus on which t is listening. For more informations see the
-  <<a_manual project="lwt"| Lwt programming guide >> and
-  <<a_api project="eliom" subproject="client" | module Eliom_bus >>.
+  {{:../lwt/.html}Lwt programming guide} and
+  {!Eliom_bus}.
 
-<<code language="ocaml"|
+{@ocaml[
 let launch_client_canvas bus image_elt canvas_elt slider =
   let canvas = Html.To_dom.of_canvas canvas_elt in
   let ctx = canvas##(getContext (Dom_html._2d_)) in
@@ -136,12 +138,12 @@ let launch_client_canvas bus image_elt canvas_elt slider =
   in
   { message_thread = t;
     drawing_thread = drawing_thread }
->>
+]}
 
-===={{{server.ml}}}====
+{3 [server.ml]}
 
 It contains almost all the server parts of the code.
-<<code language="ocaml"|
+{@ocaml[
 open Eliom_content
 open Common
 open Lwt
@@ -151,10 +153,10 @@ module My_app =
     let application_name = "graffiti"
     let global_data_path = None
   end)
->>
+]}
 
 The main difference is that the bus is now local.
-<<code language="ocaml"|
+{@ocaml[
 let launch_server_canvas () =
   let bus = Eliom_bus.create [%json: messages] in
 
@@ -220,14 +222,14 @@ let get_bus (name:string) =
       let bus,image_string = launch_server_canvas () in
       Hashtbl.add graffiti_info name (bus, image_string);
       bus
->>
+]}
 
 The main page now contains only a form to choose to which drawing you
 want to go.  The drawing will be sent by the
-{{{multigraffiti_service}}} service, registered in
-{{{graffiti.eliom}}}.
+[multigraffiti_service] service, registered in
+[graffiti.eliom].
 
-<<code language="ocaml"|
+{@ocaml[
 let main_service =
   Eliom_service.create
     ~path:(Eliom_service.Path [""])
@@ -279,29 +281,31 @@ let () = My_app.register ~service:main_service
   (fun () () ->
     make_page [h1 [txt "Welcome to Multigraffiti"];
 	       choose_drawing_form ()])
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Global node and scripts}
+
 
-<<concept title="Global node and scripts"|
   Sometimes we need to control when a script is loaded and reloaded on
   page change. Since clicking on links in an Eliom application do not
   reload the entire page, already loaded libraries stay loaded. But if
   we simply add a script to each page, it will be loaded each time.
   We usually don't want that.
 
-  Using <<a_api project="eliom" subproject="server"| val
-  Eliom_content.Html.Id.create_global_elt>> we can create an xml node
+  Using {!val
+  Eliom_content.Html.Id.create_global_elt} we can create an xml node
   manipulated 'by reference'. If a reference to a script node is
   included in a page, it will only be loaded the first time it appears
-  in the header. This is the case for {{{oclosure_script}}} above.
->>
-===={{{graffiti.eliom}}}====
+  in the header. This is the case for [oclosure_script] above.
+{%wodoc:end%}
+{3 [graffiti.eliom]}
 
 Here is the code that mixes client and server parts.
 
 We first open the corresponding modules for each parts of the
 application.
 
-<<code language="ocaml"|
+{@ocaml[
 [%%shared
     open Eliom_content.Html.D
     open Common
@@ -310,12 +314,12 @@ application.
     open Client
 ]
 open Server
->>
+]}
 
 And then we define a function initializing the client application by
 side effects in a client value.
 
-<<code language="ocaml"|
+{@ocaml[
 let start_drawing name image canvas slider =
   let bus = get_bus name in
   ignore [%client
@@ -325,15 +329,14 @@ let start_drawing name image canvas slider =
      Eliom_client.onunload (fun () -> stop_drawing canceller; None)
      : unit)
   ]
->>
+]}
 
-The function registered by <<a_api project="eliom"
-subproject="client"| val Eliom_service.onunload >> will be called when
+The function registered by {!Eliom_service.onunload} will be called when
 the page change inside the application.
 
 And we finally register the service sending a drawing:
 
-<<code language="ocaml"|
+{@ocaml[
 let counter = ref 0
 
 let () =
@@ -365,26 +368,26 @@ let () =
        choose_drawing_form ();
        canvas;
        div [slider]])
->>
+]}
 
 At this point, you can run your application on the server provided
 that you installed the css and images directories in the main
 directory of your application, build it using this
-[[https://github.com/ocsigen/graffiti/tree/master/extended/Makefile|Makefile]]
+{{:https://github.com/ocsigen/graffiti/tree/master/extended/Makefile}Makefile}
 along with the appropriate
-[[https://github.com/ocsigen/graffiti/tree/master/extended/Makefile.options|Makefile.options]],
+{{:https://github.com/ocsigen/graffiti/tree/master/extended/Makefile.options}Makefile.options},
 and configured it using
-[[https://github.com/ocsigen/graffiti/tree/master/extended/graffiti.conf.in|graffiti.conf.in]],
+{{:https://github.com/ocsigen/graffiti/tree/master/extended/graffiti.conf.in}graffiti.conf.in},
 as the basis for your configuration file.
 
-===Mixing client-server application with traditional web interaction===
+{2 Mixing client-server application with traditional web interaction}
 
 We now want to restrict the site to connected users.
 
 From the previous chapter, we copy the code handling users to
-{{{server.ml}}}:
+[server.ml]:
 
-<<code language="ocaml"|
+{@ocaml[
 let connection_service = Eliom_service.create
     ~path:Eliom_service.No_path
     ~meth:(Eliom_service.Post (
@@ -457,14 +460,14 @@ let login_name_form service button_text =
            Html.D.Form.input ~input_type:`Submit ~value:button_text
              Html.D.Form.string
          ]]) ()
->>
+]}
 
 We make a customized registration module such that disconnected users
 (those for which the username reference is not set), are automaticaly
 shown a connection box. This way the other pages can assume that the
 username is always available.
 
-<<code language="ocaml"|
+{@ocaml[
 let default_content () =
   make_page
     [Html.D.h1 [Html.D.txt "Welcome to Multigraffiti"];
@@ -485,20 +488,20 @@ end
 
 module Connected =
   Eliom_registration.Customize (My_app) (Connected_translate)
->>
+]}
 
-We replace the previous {{{main_service}}} registration :
+We replace the previous [main_service] registration :
 
-<<code language="ocaml"|
+{@ocaml[
 let () = My_app.register ~service:main_service
   (fun () () ->
     make_page [h1 [txt "Welcome to Multigraffiti"];
 	       choose_drawing_form ()])
->>
+]}
 
 by :
 
-<<code language="ocaml"|
+{@ocaml[
 let ( !% ) f = fun a b -> return (fun c -> f a b c)
 
 let () = Connected.register
@@ -507,15 +510,15 @@ let () = Connected.register
     make_page
       [Html.D.h1 [Html.D.txt ("Welcome to Multigraffiti " ^ username)];
        choose_drawing_form ()])
->>
+]}
 
-to use that, in {{{graffiti.eliom}}} we just replace add a call
-to {{{disconnect_box}}}
-<<code language="ocaml"|
+to use that, in [graffiti.eliom] we just replace add a call
+to [disconnect_box]
+{@ocaml[
       [h1 [txt name];
        disconnect_box ();
        choose_drawing_form ();
        canvas;])
->>
+]}
 
-[[wiki:manual/interaction|prev]]
+{{:wiki:manual/interaction}prev}
diff --git a/tutos/dev/manual/mobile.wiki b/tutos/8.0/manual/mobile.mld
similarity index 58%
rename from tutos/dev/manual/mobile.wiki
rename to tutos/8.0/manual/mobile.mld
index d6ab645f..73176e99 100644
--- a/tutos/dev/manual/mobile.wiki
+++ b/tutos/8.0/manual/mobile.mld
@@ -1,4 +1,4 @@
-= Mobile applications with Ocsigen
+{0 Mobile applications with Ocsigen}
 
 Since Eliom 6.0, the Ocsigen framework provides infrastructure for
 building mobile applications. This enables rapid development of
@@ -8,36 +8,36 @@ fact, one single codebase can be used to produce all these
 applications simultaneously.
 
 The easiest way to get started with Ocsigen-based mobile development
-is to use [[wiki("ocsigen-start"):|Ocsigen-start]].  Ocsigen-start is a
+is to use {{:../ocsigen-start/}Ocsigen-start}.  Ocsigen-start is a
 library and skeleton for building "minimum viable product" Web
 applications with standard functionality like users, notifications,
 etc. This skeleton is immediately usable as a mobile application. You
-can install {{{ocsigen-start}}} via OPAM
-( {{{opam install ocsigen-start}}} )
+can install [ocsigen-start] via OPAM
+( [opam install ocsigen-start] )
 and instantiate its template with the command
-{{{eliom-distillery -name ocsimobile -template os}}}.  For
+[eliom-distillery -name ocsimobile -template os.pgocaml].  For
 launching the mobile application, follow the instructions in the
-template's {{{README.md}}}.
+template's [README.md].
 
-== Programming style
+{1 Programming style}
 
 You need to follow a certain programming style for your Eliom code to
 work flawlessly inside an Ocsigen-start mobile app. This style is
-described in the <<a_manual project="eliom" chapter="clientserver-services"|chapter on
-client services>> from the Eliom manual. The idea is that you
+described in the {{:../eliom/clientserver-services.html}chapter on
+client services} from the Eliom manual. The idea is that you
 implement as much of your application as possible in shared sections
-({{{[%%shared ...]}}} or {{{let%shared ... = ...}}}), and that you
+([[%%shared ...]] or [let%shared ... = ...]), and that you
 register handlers for your Eliom services on both the client and the
 server. The Ocsigen-start template already uses the above programming
-style, so refer to the files generated by {{{eliom-distillery}}} for
+style, so refer to the files generated by [eliom-distillery] for
 inspiration.
 
-== Going further
+{1 Going further}
 
-* [[wiki("ocsigen-toolkit"):|Ocsigen-toolkit]] provides a set of user
+- {{:../ocsigen-toolkit/}Ocsigen-toolkit} provides a set of user
   interface widgets that are particularly useful for mobile applications.
 
-* Danny Willems provides a comprehensive set of
-  [[https://github.com/dannywillems/ocaml-cordova-plugin-list|OCaml
-  bindings to Cordova plugins]]. These can readily be used for your
+- Danny Willems provides a comprehensive set of
+  {{:https://github.com/dannywillems/ocaml-cordova-plugin-list}OCaml
+  bindings to Cordova plugins}. These can readily be used for your
   Eliom mobile application.
diff --git a/tutos/8.0/manual/music.wiki b/tutos/8.0/manual/music.mld
similarity index 69%
rename from tutos/8.0/manual/music.wiki
rename to tutos/8.0/manual/music.mld
index 4880b4f1..cf9294bd 100644
--- a/tutos/8.0/manual/music.wiki
+++ b/tutos/8.0/manual/music.mld
@@ -1,5 +1,7 @@
-=Listening music=
-<<concepts |Persistence of the client application>>
+{0 Listening music}
+{%wodoc:aside class="concepts"%}{b Concepts}
+
+Persistence of the client application{%wodoc:end%}
 
 We will add an audio player to the page that will stay when page
 changes. This emphasises the fact that browsing inside an application
@@ -7,7 +9,7 @@ does not stop the client side code: the music keeps playing when the
 content of the page and the url change.
 
 We first create the player node at toplevel.
-<<code language="ocaml"|
+{@ocaml[
 let player =
   Eliom_content.Html.Id.create_global_elt
     (audio
@@ -16,18 +18,20 @@ let player =
               [])
        ~a:[a_autoplay (`Autoplay);a_controls (`Controls)]
        [txt "Your browser does not support audio element" ])
->>
+]}
 
 And we insert the player in the page.
 
-And that's all! Since the {{{player}}} node is declared unique, no new
+And that's all! Since the [player] node is declared unique, no new
 player is created when the page changed: this is exact same node.
 
-<<wip | In fact browsers stop the player as soon as the dom
+{%wodoc:aside class="wip"%}{b Work in progress}
+
+ In fact browsers stop the player as soon as the dom
 element is manipulated. That happens when we change the page: to
 continue playing the player should not be present as an element of the
-page>>
+page{%wodoc:end%}
 
 To run this example, you will need to add an ogg file in the static directory.
 If you can't find one, there is one here:
-[[http://www.gnu.org/music/free-software-song.html]].
+{{:http://www.gnu.org/music/free-software-song.html}http://www.gnu.org/music/free-software-song.html}.
diff --git a/tutos/8.0/manual/ocsipersist.wiki b/tutos/8.0/manual/ocsipersist.mld
similarity index 79%
rename from tutos/8.0/manual/ocsipersist.wiki
rename to tutos/8.0/manual/ocsipersist.mld
index eaa65949..5f13cabc 100644
--- a/tutos/8.0/manual/ocsipersist.wiki
+++ b/tutos/8.0/manual/ocsipersist.mld
@@ -1,10 +1,12 @@
-=Lightweight database using Ocsipersist=
-<<concepts |Persistent tables with Ocsipersist>>
+{0 Lightweight database using Ocsipersist}
+{%wodoc:aside class="concepts"%}{b Concepts}
+
+Persistent tables with Ocsipersist{%wodoc:end%}
 
 Ocsipersist is a module for persistent references and tables.
 
 For persistent references, Eliom has a higher level interface,
-called //Eliom references//, and you probably want to use it instead
+called {e Eliom references}, and you probably want to use it instead
 of using Ocsipersist directly.
 For example persistent Eliom references of scope session group
 can be used to store information about a user (if the session group
@@ -16,13 +18,13 @@ if you do not need the full power of a SQL database.
 This tutorial shows how to implement a table for storing users and passwords.
 
 We first create a table:
-<<code language="ocaml"|
+{@ocaml[
 let user_table = Ocsipersist.Polymorphic.open_table "user_table"
->>
+]}
 
 Then we can easily handle the user management code:
 
-<<code language="ocaml"|
+{@ocaml[
 let check_pwd name pwd =
   try%lwt
     lwt saved_password = Ocsipersist.Polymorphic.find user_table name in
@@ -40,10 +42,12 @@ let () = Eliom_registration.Action.register
     match%lwt check_pwd name password with
       | true -> Eliom_reference.set username (Some name)
       | false -> Lwt.return ())
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Ocsipersist}
+
 
-<<concept title="Ocsipersist"|
  Ocsipersist implements simple typed key/value tables.
  It can use different backends (currently sqlite and dbm).
- For more information see <<a_api project="ocsigenserver"| type Ocsipersist.table >>.
->>
+ For more information see {!Ocsipersist.table}.
+{%wodoc:end%}
diff --git a/tutos/8.0/manual/pictures.wiki b/tutos/8.0/manual/pictures.mld
similarity index 84%
rename from tutos/8.0/manual/pictures.wiki
rename to tutos/8.0/manual/pictures.mld
index 6cbff690..b59af2de 100644
--- a/tutos/8.0/manual/pictures.wiki
+++ b/tutos/8.0/manual/pictures.mld
@@ -1,24 +1,26 @@
-=Saving favorite pictures=
-<<concepts |Atom feed>>
+{0 Saving favorite pictures}
+{%wodoc:aside class="concepts"%}{b Concepts}
+
+Atom feed{%wodoc:end%}
 
 We will now add a button to the Graffiti application to save the current
 image. The images will be saved to the filesystem using the module
-<<a_api project="lwt"| module Lwt_io>>. We will then make an Atom feed
-with the saved images using [[https://github.com/Cumulus/Syndic|Syndic]].
+{!Lwt_io}. We will then make an Atom feed
+with the saved images using {{:https://github.com/Cumulus/Syndic}Syndic}.
 
 To install it, do:
-{{{
+{v
 opam install syndic
-}}}
+v}
 
 We save the images in the directory containing the static contents
-under the directory {{{images_saved/username}}}. The {{{username}}}
-directory is created if needed. If it already exists {{{mkdir}}} fails
+under the directory [images_saved/username]. The [username]
+directory is created if needed. If it already exists [mkdir] fails
 and we do nothing.
 
 We will add this code in a new file:
-===={{{feed.ml}}}====
-<<code language="ocaml"|
+{3 [feed.ml]}
+{@ocaml[
 open Eliom_content
 open Lwt.Infix
 open Html.F
@@ -56,23 +58,23 @@ let save image name number =
   let%lwt file_name = make_filename name number in
   let%lwt out_chan = Lwt_io.open_file ~mode:Lwt_io.output file_name in
   Lwt_io.write out_chan image
->>
+]}
 
 We number images and associate to each image the time of creation. It
-is stocked in an <<a_api project="eliom" subproject="server"| module Ocsipersist >>
+is stocked in an {!Ocsipersist}
 table.
 
-<<code language="ocaml"|
+{@ocaml[
 let image_info_table = Ocsipersist.Polymorphic.open_table "image_info_table"
->>
+]}
 
-For each user, we stock a value of type\\
-{{{ int * CalendarLib.Calendar.t * ((int * CalendarLib.Calendar.t) list)}}}.
+For each user, we stock a value of type{%html:<br/>%}
+[int * CalendarLib.Calendar.t * ((int * CalendarLib.Calendar.t) list)].
 The first integer is the name under which will be saved the image, the first
 time is the last update for that user and the list contains the names and
 times of old images. We need those times to timestamp the entries of the feed.
 
-<<code language="ocaml"|
+{@ocaml[
 let save_image username =
   let now = CalendarLib.Calendar.now () in
   let%lwt image_info_table = image_info_table in
@@ -104,15 +106,14 @@ let save_image_box name =
               ~value:name Html.D.Form.string;
              Html.D.Form.button_no_value ~button_type:`Submit [txt "save"]]])
        ())
->>
+]}
 
-We find the url of the images with <<a_api project="eliom"
-subproject="server"| val Eliom_service.static_dir >>.  It is a service
+We find the url of the images with {!Eliom_service.static_dir}.  It is a service
 taking file path as parameter, serving the content of the static
-directory. We use <<a_api project="eliom" subproject="server"| val
-Eliom_uri.make_string_uri >> to get the url as a string.
+directory. We use {!val
+Eliom_uri.make_string_uri} to get the url as a string.
 
-<<code language="ocaml"|
+{@ocaml[
 let feed_service =
   Eliom_service.create
     ~path:(Eliom_service.Path ["feed"])
@@ -169,14 +170,14 @@ let feed name () =
              | e -> Lwt.fail e )
 
 let () = Eliom_registration.String.register ~service:feed_service feed
->>
+]}
 
 And then use the new module as follow:
 
-<<code language="ocaml"|
+{@ocaml[
   [ a Feed.feed_service [txt "atom feed"] name;
     div (if name = username
       then [Feed.save_image_box name]
       else [txt "no saving"]);
   ]
->>
+]}
diff --git a/tutos/8.0/manual/reactivemediaplayer.wiki b/tutos/8.0/manual/reactivemediaplayer.mld
similarity index 64%
rename from tutos/8.0/manual/reactivemediaplayer.wiki
rename to tutos/8.0/manual/reactivemediaplayer.mld
index a06e0906..8851e117 100644
--- a/tutos/8.0/manual/reactivemediaplayer.wiki
+++ b/tutos/8.0/manual/reactivemediaplayer.mld
@@ -1,33 +1,36 @@
-=Reactive Media Player=
+{0 Reactive Media Player}
 
-You should read the [[site:/tuto/manual/music|Playing Music]] tutorial before this one.
+You should read the {{:../tuto/manual/music}Playing Music} tutorial before this one.
 
 Since version 4, Eliom embeds the
-[[http://erratique.ch/logiciel/react|React]] library in order to
+{{:http://erratique.ch/logiciel/react}React} library in order to
 provide reactive HTML elements
-(<<a_api project="eliom" subproject="server"| module Eliom_content.Html.R >>).
+({!Eliom_content.Html.R}).
 
 
-<<webonly| The final Eliom code is available
-[[https://github.com/ocsigen/tutorial/tree/master/files/tutorial/chapter3/reactive_media_player/reactive_media_player.eliom|for download]]. >>
+ The final Eliom code is available
+{{:https://github.com/ocsigen/tutorial/tree/master/files/tutorial/chapter3/reactive_media_player/reactive_media_player.eliom}for download}. 
 
-==@@id="basics"@@ Basics==
+{1:basics Basics}
 
 A reactive element, or more generally a reactive value, depends on the
 current value of a signal. For instance :
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 [%%shared
 open Eliom_content
 open Html
 ]
->>
+]}
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client s, set_s = React.S.create 0 (* signal creation *)
->>
+]}
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%shared example_div () =
   C.node {{R.txt (React.S.map string_of_int s)}}
 
@@ -36,48 +39,52 @@ let%shared incr_button =
       ~button_type:`Button
       ~a:[a_onclick [%client fun _ -> set_s (succ (React.S.value s)) ]]
       [txt "Increment"])
->>
+]}
 
-The signal {{{s}}} carries an int value initialized at 0 and
-{{{set_s}}} is the update function generating an occurence of the
+The signal [s] carries an int value initialized at 0 and
+[set_s] is the update function generating an occurence of the
 signal.
 
-{{{example_div}}} is a {{{<div>}}} containing a string which depends
+[example_div] is a [<div>] containing a string which depends
 on the value of s.
 
 The magic part: we never have to explicitly update
-{{{example_div}}}. Its behavior is declaratively described in its own
+[example_div]. Its behavior is declaratively described in its own
 code, and not in the code of the button.
 
-<<concept title="Client node on the server"|
-{{{C.node}}} takes a client node and brings it to the server side.
->>
+{%wodoc:aside class="concept"%}{b Concept: Client node on the server}
 
-<<concept title="Step semantics"|
-**Warning** If you haven't read the React semantics, be aware of this:
-a step occurence of a signal {{{s}}} happens when the update function
-is called on the signal or on a other signal {{{s'}}} which {{{s}}}
-depends on. But moreover, this update call must at least **modify**
+
+[C.node] takes a client node and brings it to the server side.
+{%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: Step semantics}
+
+
+{b Warning} If you haven't read the React semantics, be aware of this:
+a step occurence of a signal [s] happens when the update function
+is called on the signal or on a other signal [s'] which [s]
+depends on. But moreover, this update call must at least {b modify}
 the signal current value, otherwise it's not a step.
 
 This can be seen when there are side effects (like print) in the code
 of functions mapped to the signal. If the update function does not
 modify the signal value, the printing does not happen.
 
-The test equality function of a signal can be set in the {{{eq}}}
+The test equality function of a signal can be set in the [eq]
 optional parameters of React.S functions producing a signal (like
-{{{create}}}). >>
+[create]). {%wodoc:end%}
 
 
 
-==@@id="frp_medial_player"@@ Functional Reactive Media Player==
+{1:frp_medial_player Functional Reactive Media Player}
 
 
 
 This part explains how to create a simple media player, similar to the
-[[site:/tuto/manual/music|Playing Music]] tutorial but with custom
+{{:../tuto/manual/music}Playing Music} tutorial but with custom
 controls.We will apply
-[[https://en.wikipedia.org/wiki/Functional_reactive_programming|FRP (Functional Reactive Programming)]].
+{{:https://en.wikipedia.org/wiki/Functional_reactive_programming}FRP (Functional Reactive Programming)}.
 
 
 
@@ -85,23 +92,26 @@ In order to provide a short tutorial, we only create three controls:
 play, pause and seek/progress bar.  So, let's write the corresponding
 type:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 [%%shared
     open Eliom_content
     open Html
 
     type action = Play | Pause | Seek of float
 ]
->>
+]}
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client media_s, set_media_s = React.S.create Pause
->>
+]}
 
 Each HTML element emits a signal value corresponding to its action.
 It is enough to create our "play" and "pause" inputs.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let pause_button () =
   D.(Form.button_no_value
        ~button_type:`Button
@@ -113,20 +123,23 @@ let play_button () =
        ~button_type:`Button
        ~a:[a_onclick  [%client  fun _ -> set_media_s Play ]]
        [txt "Play"])
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Abstract the Js events}
+
 
-<<concept title="Abstract the Js events"|
 A nice thing about FRP is that we can abstract JavaScript
 events and only use signals.
 The JS event handler is only a function raising a signal.
->>
+{%wodoc:end%}
 
 
 
 To use our buttons, we now create a media (audio or video) HTML
 element on the server side.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let media_uri =
   Html.D.make_uri
     ~service:(Eliom_service.static_dir ())
@@ -152,20 +165,23 @@ let media_tag () =
      : unit)
   ] in
   media
->>
+]}
+
+The function [media_tag] builds an [<audio>] element.  The
+code in [[%client ... ]] is on the client part. It's an Lwt
+thread that maps a function [media_action -> unit] to the signal
+[media_s].
+
+{%wodoc:aside class="concept"%}{b Concept: Playing video}
 
-The function {{{media_tag}}} builds an {{{<audio>}}} element.  The
-code in {{{ [%client ... ] }}} is on the client part. It's an Lwt
-thread that maps a function {{{media_action -> unit}}} to the signal
-{{{media_s}}}.
 
-<<concept title="Playing video"|
 The code for playing video is conceptually similar. You just replace
-the {{{audio}}} tag by a {{{video}}} tag. But be careful, not all
+the [audio] tag by a [video] tag. But be careful, not all
 browsers are compatible with all formats.
->>
+{%wodoc:end%}
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 module React_Player_app =
   Eliom_registration.App
     (struct
@@ -190,24 +206,26 @@ let () =
            ])
        in
        Lwt.return (Eliom_tools.D.html ~title:"Media" ~css:[] body))
->>
+]}
 
 Now you should have an ΗΤΜL node with an audio tag, and two buttons:
 play and pause. The progress bar is slightly harder to understand, but
-thanks to FRP, very easy to write.  It's basically an {{{input}}} with
-{{{range}}} type. In our program, the progress bar must emit the
-signal {{{media_s}}} with the value {{{Seek f}}} at input handling.
+thanks to FRP, very easy to write.  It's basically an [input] with
+[range] type. In our program, the progress bar must emit the
+signal [media_s] with the value [Seek f] at input handling.
 Then, it must evolve during media playback, for which we need another
 signal. To conclude, we must check that the display (the value) of the
 progress bar is not modified when the user is seeking.
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client progress_s, set_progress_s = React.S.create (0., 0.)
 
 let%client unblock_s, set_unblock_s = React.S.create true
->>
+]}
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let progress_bar () =
   let progress_value =
     [%client
@@ -242,25 +260,28 @@ let progress_bar () =
      : unit)
   ] in
   d_input
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Reactive attributes and React.S.on}
+
 
-<<concept title="Reactive attributes and React.S.on" |
 
-The function {{{R.a_value}}}
-(under <<a_api project="eliom" subproject="server"| module Eliom_content.Html >>)
-is a reactive attribute value. {{{React.S.on c d s}}} is equal to
-{{{s}}} when {{{c}}} is true, otherwise it is equal to {{{d}}} (in
-case {{{c}}} has never been true). Which means we update the attribute
+The function [R.a_value]
+(under {!Eliom_content.Html})
+is a reactive attribute value. [React.S.on c d s] is equal to
+[s] when [c] is true, otherwise it is equal to [d] (in
+case [c] has never been true). Which means we update the attribute
 value of our input only if unblock is true.
 
->>
+{%wodoc:end%}
 
-To end this tutorial, you can add a {{{progress_bar ()}}} call inside
+To end this tutorial, you can add a [progress_bar ()] call inside
 the div containing play and pause. We also need a mechanism which
-emits the {{{progress_s}}} signal. We modify the media tag with an
-eventhandler on {{{timeupdate}}}.
+emits the [progress_s] signal. We modify the media tag with an
+eventhandler on [timeupdate].
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let media_tag () =
   let media = D.(audio ~src:media_uri [txt "alt"]) in
   let _ = [%client
@@ -281,11 +302,11 @@ let media_tag () =
      : unit)
   ] in
   media
->>
+]}
 
 
 
-====Exercises====
+{3 Exercises}
 
-* Add a control to set the volume
-* Add an {{{Eliom_bus}}} to control several clients
+- Add a control to set the volume
+- Add an [Eliom_bus] to control several clients
diff --git a/tutos/8.0/manual/rest.wiki b/tutos/8.0/manual/rest.mld
similarity index 76%
rename from tutos/8.0/manual/rest.wiki
rename to tutos/8.0/manual/rest.mld
index 76ca4401..5d07b95d 100644
--- a/tutos/8.0/manual/rest.wiki
+++ b/tutos/8.0/manual/rest.mld
@@ -1,5 +1,7 @@
-=RESTful JSON API using Eliom=
-<<concepts|RESTful API\\PUT and DELETE services>>
+{0 RESTful JSON API using Eliom}
+{%wodoc:aside class="concepts"%}{b Concepts}
+
+RESTful API{%html:<br/>%}PUT and DELETE services{%wodoc:end%}
 
 This tutorial will show you how to create a simple, yet complete, REST API
 using JSON as the serialization format.
@@ -9,23 +11,23 @@ locations storing a description and coordinates (latitude and longitude).
 
 To be RESTful, our interface will comply with the following principles:
 
-* URLs and GET params identify resources
-* HTTP methods are used to define actions to perform (GET, POST, PUT, DELETE)
-* GET action is safe (no side-effect)
-* PUT and DELETE actions are idempotent
-* Requests are stateless
+- URLs and GET params identify resources
+- HTTP methods are used to define actions to perform (GET, POST, PUT, DELETE)
+- GET action is safe (no side-effect)
+- PUT and DELETE actions are idempotent
+- Requests are stateless
 
 With this in mind, our goal will be to implement CRUD (Create, Read, Update,
 Delete) functions to handle our resources. We want the following requests to be
 valid:
 
-{{{GET http://localhost/}}} will return all available locations.
+[GET http://localhost/] will return all available locations.
 
-{{{GET http://localhost/ID}}} will return location associated to {{{ID}}}.
+[GET http://localhost/ID] will return location associated to [ID].
 
-{{{POST http://localhost/ID}}} with content:
+[POST http://localhost/ID] with content:
 
-<<code language="json"|
+{@json[
 {
   "description": "Paris",
   "coordinates": {
@@ -33,35 +35,35 @@ valid:
     "longitude": 2.3508
   }
 }
->>
+]}
 
 will store this location in the database.
 
-{{{PUT http://localhost/ID}}}, with some content, will update the location
-associated to {{{ID}}}.
+[PUT http://localhost/ID], with some content, will update the location
+associated to [ID].
 
-{{{DELETE http://localhost/ID}}} will delete the location associated to
-{{{ID}}}.
+[DELETE http://localhost/ID] will delete the location associated to
+[ID].
 
-==@@id="requirements"@@ Requirements==
+{1:requirements Requirements}
 
-* eliom >= 4.0
-* yojson
-* ppx_deriving
-* ppx_deriving_yojson
+- eliom >= 4.0
+- yojson
+- ppx_deriving
+- ppx_deriving_yojson
 
 You need some knowledge about Eliom to be able to fully understand this
 tutorial. It's not meant to be an Eliom introduction.
 
 The following browser extensions are useful to manually test your REST APIs:
 
-* [[https://addons.mozilla.org/en-US/firefox/addon/restclient/|RESTClient]] for
+- {{:https://addons.mozilla.org/en-US/firefox/addon/restclient/}RESTClient} for
 Firefox
 *
-[[https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm|Postman]]
+{{:https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm}Postman}
 for Chrome
 
-==@@id="types"@@ Data types==
+{1:types Data types}
 
 We start by defining our database types, that is to say the way we will
 represent our locations and associated information. Each location will be
@@ -70,15 +72,15 @@ information: a description and coordinates (made of a latitude and a
 longitude).
 
 We represent coordinates with decimal degrees, and use the
-{{{ppx_deriving_yojson}}} library to parse and generate JSON serialization of our
+[ppx_deriving_yojson] library to parse and generate JSON serialization of our
 types.
 
-We use a dedicated {{{error}}} type returned when something is wrong with the
+We use a dedicated [error] type returned when something is wrong with the
 request itself or with the processing of the request.
 
-As for the database, we use a simple {{{Ocsipersist}}} table.
+As for the database, we use a simple [Ocsipersist] table.
 
-<<code language="ocaml"|
+{@ocaml[
 type coordinates = {
   latitude : float;
   longitude : float;
@@ -100,62 +102,64 @@ type error = {
 
 let db : location Ocsipersist.table Lwt.t =
   Ocsipersist.Polymorphic.open_table "locations"
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Syntax extensions}
+
 
-<<concept title="Syntax extensions"|
 
 In order to successfully build this tutorial's source code, your
-{{{Makefile.options}}} must contain the following settings:
-<<code language="makefile"|
+[Makefile.options] must contain the following settings:
+{@makefile[
 # OCamlfind packages for the server
 SERVER_PACKAGES := ppx_deriving_yojson lwt_ppx js_of_ocaml-ppx.deriving
 # OCamlfind packages for the client
 CLIENT_PACKAGES := lwt_ppx ppx_deriving_yojson js_of_ocaml-ppx js_of_ocaml-ppx.deriving
->>
+]}
 
 This is due to the fact, that in the code snippet above we use a syntax extension
-provided by the {{{ppx_deriving_yojson}}} package.//
->>
+provided by the [ppx_deriving_yojson] package.{e 
+{%wodoc:end%}
 
-==@@id="services"@@ Services definition==
+{1:services Services definition}
 
 First, let's define common service parameters:
 
-* The {{{path}}} of the API: it's the same for all services.
+- The [path] of the API: it's the same for all services.
 
-* The GET parameter, which is an optional identifier given as a URL suffix. We
+- The GET parameter, which is an optional identifier given as a URL suffix. We
 set it as optional so we can distinguish GET requests for all resources or a
 single one, and return a detailed error if the identifier is missing in POST,
 PUT and DELETE requests. An alternative would be to use two services at the same
 path (one with id and the other without).
 
-<<code language="ocaml"|
+{@ocaml[
 let path = Eliom_service.Path [""]
 
 let get_params =
   Eliom_parameter.(suffix (neopt (string "id")))
->>
+]}
 
 Next step is to define our API services. We define four of them with the same
 path, using the four HTTP methods at our disposal:
 
-* GET method will be used to access the database, either all of it if no
+- GET method will be used to access the database, either all of it if no
 identifier is provided, or a single resource otherwise. An error will be
 returned if no resource matches the identifier.
 
-* POST method will be used to create a new resource (or update it if it already
-exists). We set a single POST parameter: {{{Eliom_parameter.raw_post_data}}},
+- POST method will be used to create a new resource (or update it if it already
+exists). We set a single POST parameter: [Eliom_parameter.raw_post_data],
 in order to retrieve raw JSON and bypass POST parameters decoding.
 
-* PUT method will be used to update an existing resource. An error will be
+- PUT method will be used to update an existing resource. An error will be
 returned if no resource matches the identifier. We don't need to define POST
-parameter, PUT services takes {{{Eliom_parameter.raw_post_data}}} as default
+parameter, PUT services takes [Eliom_parameter.raw_post_data] as default
 content.
 
-* DELETE method will be used to delete an existing resource. An error will be
+- DELETE method will be used to delete an existing resource. An error will be
 returned if no resource matches the identifier.
 
-<<code language="ocaml"|
+{@ocaml[
 let read_service =
   Eliom_service.create
     ~path
@@ -179,26 +183,26 @@ let delete_service =
     ~path
     ~meth:(Eliom_service.Delete get_params)
     ()
->>
+]}
 
-==@@id="handlers"@@ Handlers==
+{1:handlers Handlers}
 
 Let's start the handlers definition with a few helper values and functions
 used by handlers.
 
-Since we use the low-level {{{Eliom_registration.String.send}}} function to
-send our response, we wrap it in three specialized functions: {{{send_json}}},
-{{{send_error}}} and {{{send_success}}} (this one only send the 200 OK status
+Since we use the low-level [Eliom_registration.String.send] function to
+send our response, we wrap it in three specialized functions: [send_json],
+[send_error] and [send_success] (this one only send the 200 OK status
 code, without any content).
 
-Another function helps us to check the received {{{Content-type}}} is the
+Another function helps us to check the received [Content-type] is the
 expected one, by matching it against a MIME type. In our example, we'll verify
 that we are receiving JSON.
 
-The {{{read_raw_content}}} function retrieve at most {{{length}}} characters
-from the {{{raw_content}}} Ocsigen stream.
+The [read_raw_content] function retrieve at most [length] characters
+from the [raw_content] Ocsigen stream.
 
-<<code language="ocaml"|
+{@ocaml[
 let json_mime_type = "application/json"
 
 let send_json ~code json =
@@ -220,38 +224,38 @@ let check_content_type ~mime_type content_type =
 let read_raw_content ?(length = 4096) raw_content =
   let content_stream = Ocsigen_stream.get raw_content in
   Ocsigen_stream.string_of_stream length content_stream
->>
+]}
 
 Then we define our handlers in order to perform the required actions and
 return a response.
 
-POST and PUT handlers will read raw body content as JSON and use {{{Yojson}}}
+POST and PUT handlers will read raw body content as JSON and use [Yojson]
 to convert it to our types.
 
 We use HTTP status codes in responses, with these meaning:
 
-* 200 (OK): the request succeeded.
-* 400 (Bad request): something is wrong with the request (missing parameter,
+- 200 (OK): the request succeeded.
+- 400 (Bad request): something is wrong with the request (missing parameter,
 parsing error...).
-* 404 (Not found): no resource matches the provided identifier.
+- 404 (Not found): no resource matches the provided identifier.
 
 The GET handler either returns a single location if an identifier is provided,
 or a list of all existing locations otherwise.
 
-<<code language="ocaml"|
+{@ocaml[
 let read_handler id_opt () =
   let%lwt db = db in
   match id_opt with
   | None ->
     Ocsipersist.Polymorphic.fold_step
       (fun id loc acc -> Lwt.return ((id, loc) :: acc)) db []
-    ~>>= fun locations ->
+    >>= fun locations ->
     let json = Yojson.Safe.to_string (locations_to_yojson locations) in
     send_json ~code:200 json
   | Some id ->
     catch
       (fun () ->
-         Ocsipersist.Polymorphic.find db  id ~>>= fun location ->
+         Ocsipersist.Polymorphic.find db  id >>= fun location ->
          let json =
            Yojson.Safe.to_string (location_to_yojson location) in
          send_json ~code:200 json)
@@ -260,7 +264,7 @@ let read_handler id_opt () =
           (* [id] hasn't been found, return a "Not found" message *)
           send_error ~code:404 ("Resource not found: " ^ id)
         | _ ->  send_error ~code:500 "Internal server error" )
->>
+]}
 
 Next, let's create a common function for POST and PUT handlers, which have a
 very similar behaviour. The only difference is that a PUT request with a
@@ -268,7 +272,7 @@ non-existing identifier will fail (thus only accepting update requests, and
 rejecting creations), whereas the same request with POST method will succeed (a
 new location associated to the identifier will be created).
 
-<<code language="ocaml"|
+{@ocaml[
 let edit_handler_aux ?(create = false) id_opt (content_type, raw_content_opt) =
   let%lwt db = db in
   if not (check_content_type ~mime_type:json_mime_type content_type) then
@@ -280,20 +284,20 @@ let edit_handler_aux ?(create = false) id_opt (content_type, raw_content_opt) =
     | _, None ->
       send_error ~code:400 "Body content is missing"
     | Some id, Some raw_content ->
-      read_raw_content raw_content ~>>= fun location_str ->
+      read_raw_content raw_content >>= fun location_str ->
       catch (fun () ->
           (if create then
             Lwt.return_unit
            else
-            Ocsipersist.Polymorphic.find db id ~>>= fun _ -> Lwt.return_unit)
-          ~>>= fun () ->
+            Ocsipersist.Polymorphic.find db id >>= fun _ -> Lwt.return_unit)
+          >>= fun () ->
           let location =
             (let open Result in
             let loc_result = location_of_yojson (Yojson.Safe.from_string location_str) in
             match loc_result with
               Ok loc-> loc
             | Error _ -> raise Deriving_Yojson.Failed )  in
-          Ocsipersist.Polymorphic.add db  id location ~>>= fun () ->
+          Ocsipersist.Polymorphic.add db  id location >>= fun () ->
           send_success ())
       (function
         | Not_found ->
@@ -307,40 +311,40 @@ let create_handler id_opt content =
 
 let update_handler id_opt content =
   edit_handler_aux ~create:false id_opt content
->>
+]}
 
 We need a fourth handler to delete locations:
 
-<<code language="ocaml"|
+{@ocaml[
 let%lwt db = db in
   match id_opt with
   | None ->
     send_error ~code:400 "An id must be provided to delete a location"
   | Some id ->
-    Ocsipersist.Polymorphic.remove db id ~>>= fun () ->
+    Ocsipersist.Polymorphic.remove db id >>= fun () ->
     send_success ()
->>
+]}
 
-==@@id="registration"@@ Services registration==
+{1:registration Services registration}
 
-Finally we register services with the {{{Eliom_registration.Any}}} module in
+Finally we register services with the [Eliom_registration.Any] module in
 order to have full control on the sent response. This way, we'll be able to
 send an appropriate HTTP status code depending on what happens during the
 request processing (parsing error, resource not found...), as seen above when
 defining handlers.
 
-<<code language="ocaml"|
+{@ocaml[
 let () =
   Eliom_registration.Any.register read_service read_handler;
   Eliom_registration.Any.register create_service create_handler;
   Eliom_registration.Any.register update_service update_handler;
   Eliom_registration.Any.register delete_service delete_handler;
   ()
->>
+]}
 
-==@@id="source"@@ Full source==
+{1:source Full source}
 
-<<code language="ocaml"|
+{@ocaml[
 open Lwt
 
 (**** Data types ****)
@@ -431,13 +435,13 @@ let read_handler id_opt () =
   | None ->
     Ocsipersist.Polymorphic.fold_step
       (fun id loc acc -> Lwt.return ((id, loc) :: acc)) db []
-    ~>>= fun locations ->
+    >>= fun locations ->
     let json = Yojson.Safe.to_string (locations_to_yojson locations) in
     send_json ~code:200 json
   | Some id ->
     catch
       (fun () ->
-         Ocsipersist.Polymorphic.find db  id ~>>= fun location ->
+         Ocsipersist.Polymorphic.find db  id >>= fun location ->
          let json =
            Yojson.Safe.to_string (location_to_yojson location) in
          send_json ~code:200 json)
@@ -458,20 +462,20 @@ let edit_handler_aux ?(create = false) id_opt (content_type, raw_content_opt) =
     | _, None ->
       send_error ~code:400 "Body content is missing"
     | Some id, Some raw_content ->
-      read_raw_content raw_content ~>>= fun location_str ->
+      read_raw_content raw_content >>= fun location_str ->
       catch (fun () ->
           (if create then
             Lwt.return_unit
            else
-            Ocsipersist.Polymorphic.find db id ~>>= fun _ -> Lwt.return_unit)
-          ~>>= fun () ->
+            Ocsipersist.Polymorphic.find db id >>= fun _ -> Lwt.return_unit)
+          >>= fun () ->
           let location =
             (let open Result in
             let loc_result = location_of_yojson (Yojson.Safe.from_string location_str) in
             (function
               Ok loc-> loc
             | Error _ -> raise Deriving_Yojson.Failed ) loc_result)  in
-          Ocsipersist.Polymorphic.add db  id location ~>>= fun () ->
+          Ocsipersist.Polymorphic.add db  id location >>= fun () ->
           send_success ())
       (function
         | Not_found ->
@@ -492,7 +496,7 @@ let delete_handler id_opt _ =
   | None ->
     send_error ~code:400 "An id must be provided to delete a location"
   | Some id ->
-    Ocsipersist.Polymorphic.remove db id ~>>= fun () ->
+    Ocsipersist.Polymorphic.remove db id >>= fun () ->
     send_success ()
 
 (* Register services *)
@@ -503,4 +507,4 @@ let () =
   Eliom_registration.Any.register update_service update_handler;
   Eliom_registration.Any.register delete_service delete_handler;
   ()
->>
+]}
diff --git a/tutos/8.0/manual/start.mld b/tutos/8.0/manual/start.mld
new file mode 100644
index 00000000..860b0d64
--- /dev/null
+++ b/tutos/8.0/manual/start.mld
@@ -0,0 +1,111 @@
+{%wodoc:header%}
+{0 Your first app in 5 minutes}
+{%wodoc:end%}
+
+{e The code of this tutorial has been tested against Eliom 6.0.} {%html:<br/>%}
+
+
+
+This tutorial describes how to get started with Ocsigen
+quickly. Thanks to an application template provided by the Ocsigen
+team, you will get to a working application with standard
+functionality like users and notifications in only a few minutes. This
+template can be used for learning purposes, or even as a starting
+point for your own product.
+
+The template you will use comes from {{:../ocsigen-start/}Ocsigen Start}.
+Ocsigen Start provides a complete mechanism for adding and managing
+users, including activation links and password reset. It additionally
+contains a module for displaying tips, a module for sending
+notifications to your users, and other utilities typically needed in
+modern Web applications.
+
+The template comes with a default style (developed with
+SASS) that follows modern Web practices, e.g., it is responsive and
+thus mobile-friendly. Of course, you are free to modify the style to
+match your own brand or personality.
+
+The template is multi-platform. This means that it can run on a Web
+browser or as a mobile app for Android, iOS, or Windows.
+
+{%wodoc:div class="screenshots"%}
+{{:files/screenshots/start1.png}
+{{files/screenshots/start1.png|Ocsigen Start}}}
+{{:files/screenshots/start2.png}
+{{files/screenshots/start2.png|Ocsigen Start}}}
+{%wodoc:end%}
+
+{%wodoc:div class="screenshots"%}
+{{:files/screenshots/start-mobile-1.png}
+{{files/screenshots/start-mobile-1.png|Ocsigen Start}}}
+{{:files/screenshots/start-mobile-2.png}
+{{files/screenshots/start-mobile-2.png|Ocsigen Start}}}
+{{:files/screenshots/start-mobile-4.png}
+{{files/screenshots/start-mobile-4.png|Ocsigen Start}}}
+{%wodoc:end%}
+
+{1 Installation}
+
+Install the dependencies ([postgresql] and one of [sass], [sassc]).
+On Debian-based systems:
+{v
+apt install postgresql ruby-sass
+v}
+
+Install Ocsigen Start and all its OCaml dependencies using OPAM:
+{v
+opam install ocsigen-start
+v}
+
+Create your application using Eliom distillery:
+{v
+eliom-distillery -name myapp -template os.pgocaml
+v}
+
+Have a look at the
+{{:https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/README.md}README}
+file to learn how to compile it
+and, possibly, to generate the mobile applications.
+
+{1 I installed it and compiled it, what next?}
+
+It is now time to learn Ocsigen! The template is a great way to get
+started, because it comes with multiple runnable examples that show
+you:
+
+- How to do remote procedure calls (RPCs);
+- How to save session data (in {e Eliom references});
+- How to use the notification system;
+- How to create reactive pages;
+- Many examples of widgets from {{:../ocsigen-toolkit/}Ocsigen Toolkit}:
+- Carousel
+- Pages with several tabs
+- Time and date pickers
+- ...
+
+The corresponding files are well-commented, so you can quickly find
+out how things work.
+
+{%wodoc:div class="screenshots"%}
+{{:files/screenshots/start3.png}
+{{files/screenshots/start3.png|Ocsigen Start}}}
+{{:files/screenshots/start4.png}
+{{files/screenshots/start4.png|Ocsigen Start}}}
+{{:files/screenshots/start5.png}
+{{files/screenshots/start5.png|Ocsigen Start}}}
+{{:files/screenshots/start6.png}
+{{files/screenshots/start6.png|Ocsigen Start}}}
+{%wodoc:end%}
+
+{%wodoc:div class="screenshots"%}
+{{:files/screenshots/start-mobile-3.png}
+{{files/screenshots/start-mobile-3.png|Ocsigen Start}}}
+{{:files/screenshots/start-mobile-6.png}
+{{files/screenshots/start-mobile-6.png|Ocsigen Start}}}
+{{:files/screenshots/start-mobile-7.png}
+{{files/screenshots/start-mobile-7.png|Ocsigen Start}}}
+{{:files/screenshots/start-mobile-8.png}
+{{files/screenshots/start-mobile-8.png|Ocsigen Start}}}
+{%wodoc:end%}
+
+Have fun!
diff --git a/tutos/8.0/manual/start.wiki b/tutos/8.0/manual/start.wiki
deleted file mode 100644
index b625c60e..00000000
--- a/tutos/8.0/manual/start.wiki
+++ /dev/null
@@ -1,109 +0,0 @@
-<<header| =Your first app in 5 minutes >>
-
-//The code of this tutorial has been tested against Eliom 6.0.// \\
-
-<<|wip|This tutorial is work in progress. Please send us any corrections or comments./>>
-
-This tutorial describes how to get started with Ocsigen
-quickly. Thanks to an application template provided by the Ocsigen
-team, you will get to a working application with standard
-functionality like users and notifications in only a few minutes. This
-template can be used for learning purposes, or even as a starting
-point for your own product.
-
-The template you will use comes from [[wiki("ocsigen-start"):|Ocsigen Start]].
-Ocsigen Start provides a complete mechanism for adding and managing
-users, including activation links and password reset. It additionally
-contains a module for displaying tips, a module for sending
-notifications to your users, and other utilities typically needed in
-modern Web applications.
-
-The template comes with a default style (developed with
-SASS) that follows modern Web practices, e.g., it is responsive and
-thus mobile-friendly. Of course, you are free to modify the style to
-match your own brand or personality.
-
-The template is multi-platform. This means that it can run on a Web
-browser or as a mobile app for Android, iOS, or Windows.
-
-<<div class="screenshots"|
-[[files/screenshots/start1.png|
-{{files/screenshots/start1.png|Ocsigen Start}}]]
-[[files/screenshots/start2.png|
-{{files/screenshots/start2.png|Ocsigen Start}}]]
->>
-
-<<div class="screenshots"|
-[[files/screenshots/start-mobile-1.png|
-{{files/screenshots/start-mobile-1.png|Ocsigen Start}}]]
-[[files/screenshots/start-mobile-2.png|
-{{files/screenshots/start-mobile-2.png|Ocsigen Start}}]]
-[[files/screenshots/start-mobile-4.png|
-{{files/screenshots/start-mobile-4.png|Ocsigen Start}}]]
->>
-
-== Installation
-
-Install the dependencies ({{{postgresql}}} and one of {{{sass}}}, {{{sassc}}}).
-On Debian-based systems:
-{{{
-apt install postgresql ruby-sass
-}}}
-
-Install Ocsigen Start and all its OCaml dependencies using OPAM:
-{{{
-opam install ocsigen-start
-}}}
-
-Create your application using Eliom distillery:
-{{{
-eliom-distillery -name myapp -template os.pgocaml
-}}}
-
-Have a look at the
-[[https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/README.md|README]]
-file to learn how to compile it
-and, possibly, to generate the mobile applications.
-
-== I installed it and compiled it, what next?
-
-It is now time to learn Ocsigen! The template is a great way to get
-started, because it comes with multiple runnable examples that show
-you:
-
-* How to do remote procedure calls (RPCs);
-* How to save session data (in //Eliom references//);
-* How to use the notification system;
-* How to create reactive pages;
-* Many examples of widgets from [[wiki("ocsigen-toolkit"):|Ocsigen Toolkit]]:
-** Carousel
-** Pages with several tabs
-** Time and date pickers
-* ...
-
-The corresponding files are well-commented, so you can quickly find
-out how things work.
-
-<<div class="screenshots"|
-[[files/screenshots/start3.png|
-{{files/screenshots/start3.png|Ocsigen Start}}]]
-[[files/screenshots/start4.png|
-{{files/screenshots/start4.png|Ocsigen Start}}]]
-[[files/screenshots/start5.png|
-{{files/screenshots/start5.png|Ocsigen Start}}]]
-[[files/screenshots/start6.png|
-{{files/screenshots/start6.png|Ocsigen Start}}]]
->>
-
-<<div class="screenshots"|
-[[files/screenshots/start-mobile-3.png|
-{{files/screenshots/start-mobile-3.png|Ocsigen Start}}]]
-[[files/screenshots/start-mobile-6.png|
-{{files/screenshots/start-mobile-6.png|Ocsigen Start}}]]
-[[files/screenshots/start-mobile-7.png|
-{{files/screenshots/start-mobile-7.png|Ocsigen Start}}]]
-[[files/screenshots/start-mobile-8.png|
-{{files/screenshots/start-mobile-8.png|Ocsigen Start}}]]
->>
-
-Have fun!
diff --git a/tutos/8.0/manual/tutoreact.wiki b/tutos/8.0/manual/tutoreact.mld
similarity index 68%
rename from tutos/8.0/manual/tutoreact.wiki
rename to tutos/8.0/manual/tutoreact.mld
index d6486edc..a633d3ed 100644
--- a/tutos/8.0/manual/tutoreact.wiki
+++ b/tutos/8.0/manual/tutoreact.mld
@@ -1,4 +1,4 @@
-= Client server reactive application with Ocsigen
+{0 Client server reactive application with Ocsigen}
 
 This is a short tutorial showing how to implement a simple reactive
 client-server application using Js_of_ocaml, Eliom and
@@ -9,82 +9,84 @@ that allows connected users to add new messages.
 
 You will learn:
 
-* How to use Ocsigen Start to quickly build an application with user
+- How to use Ocsigen Start to quickly build an application with user
   management.
-* How to create a client-server reactive interface: the HTML is
+- How to create a client-server reactive interface: the HTML is
   generated indifferently server-side or client-side, and
   contains reactive parts that are updated automatically when the data
   change.
-* How to implement a notification system for your application. Users
+- How to implement a notification system for your application. Users
   are notified when a new item (a message in our case) arrives.
 
 
 
-== First step: a basic application with user management
+{1 First step: a basic application with user management}
 
 Ocsigen Start contains a set of higher level libraries for Eliom
 (user management, tips, notifications). It also contains a template
-for {{{eliom-distillery}}} that creates an application with user
+for [eliom-distillery] that creates an application with user
 management. You can use this template as a starting point for your
 project.
 
-{{{
+{v
 eliom-distillery -name tutoreact -template os.pgocaml
-}}}
+v}
 
 This template is using PostgreSQL to store the data. You need a recent
 version of Postgresql installed on your system.  With that available,
 you can create the local database and start the database server:
 
-{{{
+{v
 make db-init
 make db-create
 make db-schema
-}}}
+v}
 
 Compile and run the program:
-{{{
+{v
 make test.byte
-}}}
+v}
 
-Go to {{{http://localhost:8080}}}, you should see the welcome page. You can now
+Go to [http://localhost:8080], you should see the welcome page. You can now
 register a user and log in. Because the send mail function is not configured,
 the activation links will be printed on the console you started the server with.
 
 At any point, if you want to get back to this tutorial later, you may need to
 start the database again:
-{{{
+{v
 make db-start
-}}}
+v}
 
 While doing this tutorial, if you plan to work on another Ocsigen project
 requiring a database, do not forget to stop the tutorial's database beforehand:
-{{{
+{v
 make db-stop
-}}}
+v}
 
 
 
-== Display messages from db
+{1 Display messages from db}
 
 To make this example more realistic, let's suppose that we do not want to
 display all the messages in the database, but only a few of them.
 
 In this tutorial, we will not focus on the implementation details of the
-database part. Create a new file named {{{tutoreact_messages.eliom}}}. From now
+database part. Create a new file named [tutoreact_messages.eliom]. From now
 on, if not explicitly specified, the code we are going to write will go there.
-We are going to create a module {{{Db}}} containing these functions:
+We are going to create a module [Db] containing these functions:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 val get_messages : unit -> int list Lwt.t
 val get_message : int -> string Lwt.t
 val add_message : string -> int Lwt.t
->>
+]}
 
 You can try to make your own implementation using for instance pgocaml.
 Here's our implementation using Ocsipersist:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 [%%server
 module Db = struct
   let db = Ocsipersist.Polymorphic.open_table "messages"
@@ -115,16 +117,18 @@ module Db = struct
     let%lwt () = Ocsipersist.Polymorphic.add db (string_of_int index) v in
     Lwt.return index
 end]
->>
+]}
 
 Add the following code:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 [%%shared
     open Eliom_content.Html
     open Eliom_content.Html.D]
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server display userid_o =
   let%lwt messages = Db.get_messages () in
   let%lwt l =
@@ -135,44 +139,46 @@ let%server display userid_o =
       messages
   in
   Lwt.return [ul l]
->>
+]}
 
 Depending on your database, it is probably more efficient to
 fetch all messages and their identifiers using only one request.
-Here we use {{{Lwt_list.map_s}}} to do the requests sequentially.
+Here we use [Lwt_list.map_s] to do the requests sequentially.
 
 The content of the main page is defined in
-the file {{{tutoreact_handlers.eliom}}}.
-Replace the code of {{{main_service_handler}}} by:
+the file [tutoreact_handlers.eliom].
+Replace the code of [main_service_handler] by:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server main_service_handler userid_o () () =
   let%lwt content = Tutoreact_messages.display userid_o in
   Tutoreact_container.page userid_o content
->>
+]}
 
-The {{{main_service_handler}}} you just replaced was in a shared section.
+The [main_service_handler] you just replaced was in a shared section.
 Therefore, we also need to change two other files to take into consideration
 this modification.
 
-In the file {{{tutoreact_handlers.eliomi}}}, move the definition of
-{{{main_service_handler}}} from the shared section to the server section.
+In the file [tutoreact_handlers.eliomi], move the definition of
+[main_service_handler] from the shared section to the server section.
 
-In the file {{{tutoreact.eliom}}}, move the registration of {{{main_service}}}
+In the file [tutoreact.eliom], move the registration of [main_service]
 from the shared section to the server section.
 
 Try to compile in order to see if everything is fine.
 
 
 
-== Adding new messages
+{1 Adding new messages}
 
-=== Add an input in the page, for connected users
+{2 Add an input in the page, for connected users}
 
 To add an input in the page for connected users,
-replace the function {{{display}}} by the following version:
+replace the function [display] by the following version:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server display_messages () =
   let%lwt messages = Db.get_messages () in
   let%lwt l =
@@ -193,34 +199,36 @@ let%server display userid_o =
                           a_style "border-style:solid"] ()]
   in
   Lwt.return (messages :: l)
->>
+]}
 
-=== Make function {{{Db.add_message}}} accessible from the client
+{2 Make function [Db.add_message] accessible from the client}
 
 To be able to call a function from the client-side program,
-use {{{let%rpc}}}:
-<<code language="ocaml" class="shared"|
+use [let%rpc]:
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc add_message (value : string) : unit Lwt.t =
   let%lwt _ = Os_current_user.get_current_userid () (* fails if not connected *) in
   Db.add_message value
->>
+]}
 
-The parameter {{{[%json: string]}}} describes the type of
+The parameter [[%json: string]] describes the type of
 the function parameter. This exhibits the syntax provided by
-[[https://github.com/whitequark/ppx_deriving|ppx_deriving]] extended
+{{:https://github.com/whitequark/ppx_deriving}ppx_deriving} extended
 with our JSON plugin. We use this for safe server-side unmarshalling of data
 sent by the client.
 
-=== Bind the input to call the function
+{2 Bind the input to call the function}
 
 To call the function from the client program, we will define a
-//client value//, a client-side expression that is accessible
+{e client value}, a client-side expression that is accessible
 server-side. The client value will be executed client-side
 after the page is loaded. The syntax for client values of type
-{{{t}}} is {{{[%client (... : t)]}}}.
+[t] is [[%client (... : t)]].
 
-Replace the second branch of the {{{match}}} in the function {{{display}}} by:
-<<code language="ocaml" class="server"|
+Replace the second branch of the [match] in the function [display] by:
+{%wodoc:@ class=server%}
+{@ocaml[
 let inp = Raw.input ~a:[a_input_type `Text; a_style "border-style:solid"] () in
 let _ = [%client
   (let open Js_of_ocaml_lwt.Lwt_js_events in
@@ -233,16 +241,16 @@ let _ = [%client
    : unit)
 ] in
 [inp]
->>
-
-* We use module {{{Lwt_js_events}}} to manage events.
-* The syntax {{{~%v}}} allows using a server-side value {{{v}}} client-side.
-* {{{To_dom.of_input}}} returns the JS element corresponding to the
-  OCaml value {{{~%inp}}}.
-* {{{Lwt_js_events.async}}} is similar to {{{Lwt.async}}}.
-* {{{obj##.a}}} allows the access to the field {{{a}}}
-  of the JavaScript object {{{obj}}} (see Js_of_ocaml PPX extension).
-* {{{changes}}} takes a JS element and a function that will be
+]}
+
+- We use module [Lwt_js_events] to manage events.
+- The syntax [~%v] allows using a server-side value [v] client-side.
+- [To_dom.of_input] returns the JS element corresponding to the
+  OCaml value [~%inp].
+- [Lwt_js_events.async] is similar to [Lwt.async].
+- [obj##.a] allows the access to the field [a]
+  of the JavaScript object [obj] (see Js_of_ocaml PPX extension).
+- [changes] takes a JS element and a function that will be
   executed every time a "change" event is received on this element.
 
 This function gets the value of the input, resets the content of the
@@ -255,7 +263,7 @@ display them.
 
 
 
-== Structure of a client-server application
+{1 Structure of a client-server application}
 
 We have seen how to send data to the server without stopping the
 client-side program. Now we want to automatically update the page
@@ -273,16 +281,16 @@ generate pages indifferently (and with the same code) from both sides.
 
 In this section, we will see how to implement this kind of applications
 very concisely thanks to three notions:
-* The client-server cache of data
-* Reactive pages
-* Notification system
+- The client-server cache of data
+- Reactive pages
+- Notification system
 
 You will be able to test once you finish the three following sections!
 
-=== Client-server cache
+{2 Client-server cache}
 
 The module
-<<a_api project="eliom" subproject="server"| module Eliom_cscache >>
+{!Eliom_cscache}
 implements a cache of data, an association table where you
 will put the data of your application client-side. For the sake of
 uniformity (as we want to use it in shared sections), the
@@ -291,23 +299,25 @@ cache is also implemented server-side, with scope
 twice for the same request.
 
 We create a client-server cache by calling the function
-<<a_api project="eliom" subproject="server"| val Eliom_cscache.create >>
-server-side. The server-side cache {{{cache}}} created by this
-function will be accessible client-side through an injection {{{~%cache}}}.
+{!Eliom_cscache.create}
+server-side. The server-side cache [cache] created by this
+function will be accessible client-side through an injection [~%cache].
 
-We implement a function {{{get_data}}} to fetch the
+We implement a function [get_data] to fetch the
 data from the database. This function must have an implementation both
 server-side and client-side:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc get_data (id : int) : string Lwt.t = Db.get_message id
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server cache : (int, string) Eliom_cscache.t =
   Eliom_cscache.create ()
->>
+]}
 
-=== Reactive interface
+{2 Reactive interface}
 
 Updating the interface when some data change is usually not
 straightforward. This is usually done by putting identifiers on
@@ -318,50 +328,52 @@ A very elegant solution to simplify this consists in using Functional
 Reactive Programming (FRP). In reactive programming, you define
 relations between different pieces of data once, and each update
 automatically produces the recomputation of all the dependent data. In
-Ocsigen we use the module [[http://erratique.ch/logiciel/react|React]]
-combined with [[https://github.com/ocsigen/reactiveData/|ReactiveData]],
-which extends {{{React}}} to deal with incremental updates in
+Ocsigen we use the module {{:http://erratique.ch/logiciel/react}React}
+combined with {{:https://github.com/ocsigen/reactiveData/}ReactiveData},
+which extends [React] to deal with incremental updates in
 lists. Have a look at the documentation of the above modules if you
 are not familiar with FRP.
 
 The client-side module
-<<a_api project="eliom" subproject="client"| module Eliom_content.Html.R >>
+{!Eliom_content.Html.R}
 enables defining reactive page elements.
 
-The module <<a_api project="eliom" subproject="server"| module Eliom_shared >>
+The module {!Eliom_shared}
 enables defining shared reactive signals server-side.
-In order to do that, we use //shared values//, values defined
+In order to do that, we use {e shared values}, values defined
 both server-side and client-side. The server-side module
-<<a_api project="eliom" subproject="server"| module Eliom_content.Html.R >>
+{!Eliom_content.Html.R}
  enables constructing HTML5 elements that get updated automatically
-based on the signals of {{{Eliom_shared}}}. The modules
-<<a_api project="eliom" subproject="server"| module Eliom_shared.React >>
+based on the signals of [Eliom_shared]. The modules
+{!Eliom_shared.React}
 and
-<<a_api project="eliom" subproject="server"| module Eliom_shared.ReactiveData >>
-implement interfaces very similar to {{{React}}} and
-{{{ReactiveData}}}, but operate on shared signals.
+{!Eliom_shared.ReactiveData}
+implement interfaces very similar to [React] and
+[ReactiveData], but operate on shared signals.
 
-=== Implementation of the reactive interface
+{2 Implementation of the reactive interface}
 
-{{{display_message}}} now needs to be implemented in a shared fashion and take
+[display_message] now needs to be implemented in a shared fashion and take
 its data from the cache. In order to do that,
-we call {{{Eliom_cscache.find cache get_data key}}} from either side to get the
-value associated to {{{key}}}. If the value is not present in the cache, it will
-be fetched using the function {{{get_data}}} and added to the cache.
+we call [Eliom_cscache.find cache get_data key] from either side to get the
+value associated to [key]. If the value is not present in the cache, it will
+be fetched using the function [get_data] and added to the cache.
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%shared display_message id =
   let%lwt msg = Eliom_cscache.find ~%cache get_data id in
   Lwt.return (li [txt msg])
->>
+]}
 
-The function {{{display_messages}}} now creates a reactive list of
+The function [display_messages] now creates a reactive list of
 message identifiers, and maps page content from this reactive value
-using module {{{Eliom_shared.ReactiveData}}}. Note that {{{rmessage}}} is
+using module [Eliom_shared.ReactiveData]. Note that [rmessage] is
 a tuple, the first element is the list, the second element is the update
 function.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server display_messages () =
   let%lwt messages = Db.get_messages () in
   let rmessages = Eliom_shared.ReactiveData.RList.create messages in
@@ -371,47 +383,50 @@ let%server display_messages () =
       (fst rmessages)
   in
   Lwt.return (R.ul content)
->>
+]}
 
-== Notifications
+{1 Notifications}
 
 We now want to be notified when a message has been added. To do that
-easily, we use the module {{{Os_notif}}} from Ocsigen Start.
+easily, we use the module [Os_notif] from Ocsigen Start.
 
 We first define a notification module for the type of data we want
 clients to be able to listen on (here the lists of message identifiers):
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 [%%server
 module Forum_notif = Os_notif.Make_Simple (struct
   type key = unit
   type notification = int
 end)
 ]
->>
+]}
 
-{{{key}}} is the type of the identifier of the data we want to listen
-on. In our case, there is a single message list (thus {{{unit}}}
+[key] is the type of the identifier of the data we want to listen
+on. In our case, there is a single message list (thus [unit]
 suffices as the identifier since we don't need to be specific).
 
-{{{notification}}} is the type of the notifications to send. Here: the
+[notification] is the type of the notifications to send. Here: the
 identifier of the new message to be added in the list.
 
 We define a function to handle notifications. It adds the new
 identifier in the reactive list of messages:
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client handle_notif_message_list rmessages (_, msgid) =
   Eliom_shared.ReactiveData.RList.cons msgid (snd rmessages)
->>
+]}
 
 We notify the server that we are listening on this piece of data by
-calling {{{Forum_notif.listen}}} (server-side). Notifications are
-received client-side through a {{{React}}} event
-{{{Forum_notif.client_ev ()}}}. We map this event to the function
-{{{handle_notif_message_list}}}, meaning that we will execute this function
+calling [Forum_notif.listen] (server-side). Notifications are
+received client-side through a [React] event
+[Forum_notif.client_ev ()]. We map this event to the function
+[handle_notif_message_list], meaning that we will execute this function
 when this event happens.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server display_messages () =
   Forum_notif.listen ();
   let%lwt messages = Db.get_messages () in
@@ -428,17 +443,18 @@ let%server display_messages () =
       (fst rmessages)
   in
   Lwt.return (R.ul content)
->>
+]}
 
 When we add a message, we notify all the clients listening on this
 piece of data:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc add_message (value : string) : unit Lwt.t =
    let%lwt id = Db.add_message value in
    Forum_notif.notify () id;
    Lwt.return ()
->>
+]}
 
 The program is now fully functional, you can now test it! You should see the
 messages being added without the need to reload the page, even if messages are
@@ -446,37 +462,39 @@ added by another user! Try with several browser windows.
 
 
 
-== More information on cache and client-server reactive data
+{1 More information on cache and client-server reactive data}
 
 In this section we will demonstrate additional Eliom functionality for
 client-server programming by implementing some new features in our
 forum:
-* Multi-page forum
-* Client-side spinner while loading data
+- Multi-page forum
+- Client-side spinner while loading data
 
-=== Multi-page forum
+{2 Multi-page forum}
 
 We now want a forum with several pages, located at URLs
-{{{http://localhost:8080/}}}//i//, where //i// represents the {{{forumid}}}
+[http://localhost:8080/]{e i}, where {e i} represents the [forumid]
 as an integer.
 
-==== Services
+{3 Services}
 
-In the file {{{tutoreact_services.eliom}}}, we define the new following service:
+In the file [tutoreact_services.eliom], we define the new following service:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server forum_service =
   Eliom_service.create
     ~path:(Eliom_service.Path [""])
     ~meth:(Eliom_service.Get
             (Eliom_parameter.(suffix (int "i"))))
     ()
->>
+]}
 
-In the file {{{tutoreact_services.eliomi}}}, we define its signature, do not
+In the file [tutoreact_services.eliomi], we define its signature, do not
 forget to put it in a server section:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 [%%server.start]
 
 val forum_service
@@ -492,92 +510,101 @@ val forum_service
     , unit
     , Eliom_service.non_ocaml )
     Eliom_service.t
->>
+]}
 
-In the file {{{tutoreact_handlers.eliom}}}, we define the handler we will
+In the file [tutoreact_handlers.eliom], we define the handler we will
 associate to our new service:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server forum_service_handler userid_o forumid () =
   let%lwt content = Tutoreact_messages.display userid_o forumid in
   Tutoreact_container.page userid_o content
->>
+]}
 
-In the file {{{tutoreact_handlers.eliomi}}}, we define its signature, in the
+In the file [tutoreact_handlers.eliomi], we define its signature, in the
 server section:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 val forum_service_handler
   :  Os_types.User.id option
   -> int
   -> unit
   -> Os_page.content Lwt.t
->>
+]}
 
-In the file {{{tutoreact.eliom}}}, we register our handler to our new service in
+In the file [tutoreact.eliom], we register our handler to our new service in
 the server section:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
   Tutoreact_base.App.register ~service:Tutoreact_services.forum_service
     (Tutoreact_page.Opt.connected_page Tutoreact_handlers.forum_service_handler)
->>
+]}
 
-Since we have a new parameter {{{forumid}}}, we need to take it into
+Since we have a new parameter [forumid], we need to take it into
 consideration in many places.
 
-In the file {{{tutoreact_messages.eliom}}}, the functions {{{display_messages}}}
-and {{{display}}} take it as a new parameter. Do not forget to also replace
-the latter in the call of {{{display_messages}}} in function {{{display}}}:
+In the file [tutoreact_messages.eliom], the functions [display_messages]
+and [display] take it as a new parameter. Do not forget to also replace
+the latter in the call of [display_messages] in function [display]:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server display_messages forumid =
   ...
->>
+]}
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server display userid_o forumid =
   let%lwt messages = display_messages forumid in
   ...
->>
+]}
 
-In the file {{{tutoreact_handlers.eliom}}}, update the code of
-{{{main_service_handler}}}:
+In the file [tutoreact_handlers.eliom], update the code of
+[main_service_handler]:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server main_service_handler forumid userid_o () () =
   let%lwt content = Tutoreact_messages.display userid_o forumid in
   Tutoreact_container.page userid_o content
->>
+]}
 
-In the file {{{tutoreact_handlers.eliomi}}}, update its signature:
+In the file [tutoreact_handlers.eliomi], update its signature:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 val main_service_handler
   :  int
   -> Os_types.User.id option
   -> unit
   -> unit
   -> Os_page.content Lwt.t
->>
+]}
 
-In the file {{{tutoreact.eliom}}}, in the {{{main_service}}}, we have to specify
+In the file [tutoreact.eliom], in the [main_service], we have to specify
 the forumid of the forum we want to reach when we arrive in our application.
 We will take 0 for instance and give it as the parameter of
-{{{main_service_handler}}}. We update the registration of {{{main_service}}}:
+[main_service_handler]. We update the registration of [main_service]:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
   Tutoreact_base.App.register
     ~service:Os_services.main_service
     (Tutoreact_page.Opt.connected_page
     (Tutoreact_handlers.main_service_handler 0));
->>
+]}
 
-==== Db
+{3 Db}
 
-The functions {{{Db.get_messages}}} and {{{Db.add_message}}} now take the forum
+The functions [Db.get_messages] and [Db.add_message] now take the forum
 identifier:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 [%%server
 module Db = struct
 
@@ -617,37 +644,40 @@ module Db = struct
 
 end
 ]
->>
+]}
 
-==== Message type
+{3 Message type}
 
-Since we are now adding besides the message, the {{{forumid}}} as well in our
+Since we are now adding besides the message, the [forumid] as well in our
 database, we need to specify a new type:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 [%%shared
     type add_message_type = int * string [@@deriving json]
 ]
->>
+]}
 
 We don't forget to take that into consideration in the function
-{{{add_message}}}.
+[add_message].
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%rpc add_message ((forumid, value) : add_message_type) : unit Lwt.t =
    let%lwt id = Db.add_message forumid value in
    Forum_notif.notify () id;
    Lwt.return ()
->>
+]}
 
-In the function {{{display}}}, in the client section:
-<<code language="ocaml" class="client"|
+In the function [display], in the client section:
+{%wodoc:@ class=client%}
+{@ocaml[
   ...
   add_message (~%forumid, value)
 ...
->>
+]}
 
-==== Cache of forum message identifiers
+{3 Cache of forum message identifiers}
 
 We must send the notifications only to the clients listening on the
 same forum.
@@ -655,29 +685,31 @@ same forum.
 We will create a new client-server cache to keep the reactive list of
 message identifiers for each forums:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server forumcache :
   (int,
    int Eliom_shared.ReactiveData.RList.t *
    int Eliom_shared.ReactiveData.RList.handle) Eliom_cscache.t =
   Eliom_cscache.create ()
->>
+]}
 
-We will now implement the equivalent of {{{get_data}}} for this new cache.
+We will now implement the equivalent of [get_data] for this new cache.
 
-**Be very careful:**
+{b Be very careful:}
 
-In {{{get_data_forum}}}, we must find the reactive list of messages in
+In [get_data_forum], we must find the reactive list of messages in
 the new cache —if it exists — instead of creating a new one!
 Otherwise you will have several reactive data for the same forum and
 the page updates will fail!
 
-To do that, we provide an optional argument {{{?default}}} to the function
-{{{Eliom_shared.ReactiveData.RList.create}}}, a client value
+To do that, we provide an optional argument [?default] to the function
+[Eliom_shared.ReactiveData.RList.create], a client value
 (optionally) containing the current reactive list. If it does not
 exist in the cache, a new one will be created like previously:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc get_data_forum (forumid : int) : _ Lwt.t =
   let%lwt messages = Db.get_messages forumid in
   let default = [%client
@@ -686,87 +718,94 @@ let%rpc get_data_forum (forumid : int) : _ Lwt.t =
      : 'a option)
   ] in
   Lwt.return (Eliom_shared.ReactiveData.RList.create ~default messages)
->>
+]}
 
-{{{display_messages}}} now takes the reactive list from the cache:
-<<code language="ocaml" class="server"|
+[display_messages] now takes the reactive list from the cache:
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server display_messages forumid =
   Forum_notif.listen ();
   let%lwt rmessages =
     Eliom_cscache.find forumcache get_data_forum forumid
   in
   ...
->>
+]}
 
-==== Notifications dependent on forum ID
+{3 Notifications dependent on forum ID}
 Since we now want to be specific about the data we want to listen to, the unit
 parameter we defined can't be used anymore. Indeed, notifications now depend on
 the identifier. We want to receive notifications only for the forums present in
-the client-side cache of forums. Therefore, we just change the type {{{key}}} of
-module {{{Forum_notif}}} to use an integer (instead of {{{unit}}}):
+the client-side cache of forums. Therefore, we just change the type [key] of
+module [Forum_notif] to use an integer (instead of [unit]):
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 [%%server
 module Forum_notif = Os_notif.Make_Simple (struct
   type key = int
   type notification = int
 end)
 ]
->>
+]}
 
-The function {{{Forum_notif.notify}}} used in the function {{{add_message}}}
-now takes the {{{forumid}}} parameter.
+The function [Forum_notif.notify] used in the function [add_message]
+now takes the [forumid] parameter.
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc add_message ... =
   ...
   Forum_notif.notify forumid id;
   ...
->>
+]}
 
-In the function {{{display_messages}}}, we need to take care of the
-{{{forumid}}} parameter and the type annotation of {{{client_ev}}}:
+In the function [display_messages], we need to take care of the
+[forumid] parameter and the type annotation of [client_ev]:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server display_messages forumid =
   Forum_notif.listen (forumid : int);
   ...
   ~%(Forum_notif.client_ev () : (int * int) Eliom_react.Down.t))
   ...
->>
+]}
 
-We annotate the type of {{{forumid}}} in the call of the function {{{listen}}}
+We annotate the type of [forumid] in the call of the function [listen]
 to help the typing system.
 
-The function {{{handle_notif_message}}} now takes the reactive
-list {{{rmessage}}} from the cache, therefore we no longer need it as a
+The function [handle_notif_message] now takes the reactive
+list [rmessage] from the cache, therefore we no longer need it as a
 parameter:
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client handle_notif_message_list (forumid, msgid) =
   try
     let rmessages = Eliom_cscache.find_if_ready ~%forumcache forumid in
     Eliom_shared.ReactiveData.RList.cons msgid (snd rmessages)
   with Not_found | Eliom_cscache.Not_ready -> ()
->>
+]}
 
-In the function {{{display_messages}}}, do not forget to remove the injection
-of {{{rmessage}}} in the call of {{{handle_notif_message_list}}} in the client
+In the function [display_messages], do not forget to remove the injection
+of [rmessage] in the call of [handle_notif_message_list] in the client
 section:
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 ...
 (React.E.map handle_notif_message_list
 ...
->>
+]}
 
-=== Display a spinner while loading the messages
+{2 Display a spinner while loading the messages}
 
 Retrieving messages from server can take time.
 To display a spinner while loading the messages when you send them, replace
-the function {{{display_message}}} by:
+the function [display_message] by:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%shared display_message id =
   let th =
     let%lwt msg = Eliom_cscache.find ~%cache get_data id in
@@ -774,29 +813,32 @@ let%shared display_message id =
   in
   let%lwt v = Ot_spinner.with_spinner th in
   Lwt.return (li [v])
->>
+]}
 
-To simulate network latency, you can add a {{{Lwt_unix.sleep}}} in the
-server-side {{{get_data}}} function.
+To simulate network latency, you can add a [Lwt_unix.sleep] in the
+server-side [get_data] function.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server get_data id =
   let%lwt () = Lwt_unix.sleep 2.0 in
   Db.get_message id
->>
+]}
 
 
 
-== The full code ({{{tutoreact_messages.eliom}}}):
+{1 The full code ([tutoreact_messages.eliom]):}
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 [%%shared
     open Eliom_content.Html
     open Eliom_content.Html.D
 ]
->>
+]}
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 [%%server
 module Db = struct
   let db = Ocsipersist.Polymorphic.open_table "messages"
@@ -835,22 +877,25 @@ module Forum_notif = Os_notif.Make_Simple (struct
   type notification = int
 end)
 ]
->>
+]}
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 [%%shared
     type add_message_type = int * string [@@deriving json]
 ]
->>
+]}
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc add_message ((forumid, value) : add_message_type) : unit Lwt.t =
    let%lwt id = Db.add_message forumid value in
    Forum_notif.notify forumid (id : int);
    Lwt.return ()
->>
+]}
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server cache : (int, string) Eliom_cscache.t = Eliom_cscache.create ()
 
 let%server forumcache :
@@ -858,15 +903,17 @@ let%server forumcache :
    int Eliom_shared.ReactiveData.RList.t *
    int Eliom_shared.ReactiveData.RList.handle) Eliom_cscache.t =
   Eliom_cscache.create ()
->>
+]}
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 ler%rpc get_data (id : int) : string Lwt.t =
   let%lwt () = Lwt_unix.sleep 2.0 in
   Db.get_message id
->>
+]}
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc get_data_forum (forumid : int) : _ Lwt.t =
   let%lwt messages = Db.get_messages forumid in
   let default = [%client
@@ -877,9 +924,10 @@ let%rpc get_data_forum (forumid : int) : _ Lwt.t =
        : 'a option)
   ] in
   Lwt.return (Eliom_shared.ReactiveData.RList.create ~default messages)
->>
+]}
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%shared display_message id =
   let th =
     let%lwt msg = Eliom_cscache.find ~%cache get_data id in
@@ -887,17 +935,19 @@ let%shared display_message id =
   in
   let%lwt v = Ot_spinner.with_spinner th in
   Lwt.return (li [v])
->>
+]}
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client handle_notif_message_list (forumid, msgid) =
   try
     let rmessages = Eliom_cscache.find_if_ready ~%forumcache forumid in
     Eliom_shared.ReactiveData.RList.cons msgid (snd rmessages)
   with Not_found | Eliom_cscache.Not_ready -> ()
->>
+]}
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server display_messages forumid =
   Forum_notif.listen (forumid : int);
   let%lwt rmessages =
@@ -940,4 +990,4 @@ let%server display userid_o forumid =
         [inp]
   in
   Lwt.return (messages :: l)
->>
+]}
diff --git a/tutos/8.0/manual/tutowidgets.wiki b/tutos/8.0/manual/tutowidgets.mld
similarity index 69%
rename from tutos/8.0/manual/tutowidgets.wiki
rename to tutos/8.0/manual/tutowidgets.mld
index 7c7efcb0..965405a3 100644
--- a/tutos/8.0/manual/tutowidgets.wiki
+++ b/tutos/8.0/manual/tutowidgets.mld
@@ -1,4 +1,4 @@
-= Mini-tutorial: client-server widgets =
+{0 Mini-tutorial: client-server widgets}
 
 This short tutorial is an example of client-server Eliom application.
 It gives an example of client-server widgets.
@@ -7,7 +7,7 @@ It is probably a good starting point if you know OCaml well, and want
 to quickly learn how to write a client-server Eliom application with a
 short example and concise explanations.  For more detailed explanations, see
 the
-<<a_manual project="tuto" chapter="application"|"graffiti" tutorial>>,
+{{:../tuto/application.html}"graffiti" tutorial},
 or read the manuals.
 
 The goal is to show that, unlike many JavaScript libraries that build
@@ -26,26 +26,27 @@ content. Furthermore, it is possible to group some of the boxes
 together to make them behave like radio buttons: when you open one of
 them, the previously opened one is closed.
 
-@@class="screenshot"@@{{files/tutorial/tutowidgets/ex-final.png|screenshot}}
+{%wodoc:@ class="screenshot"%}{%wodoc:img src="files/tutorial/tutowidgets/ex-final.png" alt="screenshot"%}
 
-<<outline| <<header| **Table of contents** >> >>
 
-== First step: define an application with a basic service ==
+
+{1 First step: define an application with a basic service}
 
 The following code defines a client-server Web application with only
-one service, registered at URL {{{/}}} (the root of the website).
+one service, registered at URL [/] (the root of the website).
 
-The code also defines a client-side application ({{{let%client}}} or section
-{{{ [%%client ... ] }}})
+The code also defines a client-side application ([let%client] or section
+[[%%client ... ]])
 that appends a client-side generated widget to the page.
-Section {{{ [%%shared ... ] }}} is compiled on both the server and the
+Section [[%%shared ... ]] is compiled on both the server and the
 client-side programs.
-Inside such a section, you can write {{{ let%server }}} or
-{{{ let%client }}} to override {{{ [%%shared ... ] }}}
+Inside such a section, you can write [let%server] or
+[let%client] to override [[%%shared ... ]]
 and define a server-only or client-only value (similarly for
-{{{ [%%server ... ] }}} and {{{ [%%client ... ] }}}).
+[[%%server ... ]] and [[%%client ... ]]).
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 
 module%server Ex_app =
   Eliom_registration.App (struct
@@ -62,8 +63,9 @@ let%server _ = Eliom_content.Html.D.(
          (Eliom_tools.D.html ~title:"tutowidgets" ~css:[["css"; "ex.css"]]
             (body [h2 [txt "Welcome to Ocsigen!"]])))
 )
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 
 let%client mywidget s1 s2 = Eliom_content.Html.D.(
   let button  = div ~a:[a_class ["button"]] [txt s1] in
@@ -77,61 +79,62 @@ let%client _ =
     (Js_of_ocaml.Dom_html.document##.body)
     (Eliom_content.Html.To_dom.of_element (mywidget "Click me" "Hello!"));
   Lwt.return ()
->>
+]}
 
 To compile it, first create a project by calling
 
-{{{
+{v
   eliom-distillery -name ex -template client-server.basic
-}}}
+v}
 
 The name of the project must match the name given to the functor
-{{{Eliom_registration.App}}}.
+[Eliom_registration.App].
 
-After you adapt the file {{{ex.eliom}}},
-you can compile by calling {{{make}}},
-and run the server by calling {{{make test.byte}}}.
+After you adapt the file [ex.eliom],
+you can compile by calling [make],
+and run the server by calling [make test.byte].
 Download the
-[[files/tutorial/tutowidgets/ex.css|CSS file]]
-and place it in directory {{{static/css}}}.
-Then open a browser window and go to URL {{{http://localhost:8080}}}.
+{{:files/tutorial/tutowidgets/ex.css}CSS file}
+and place it in directory [static/css].
+Then open a browser window and go to URL [http://localhost:8080].
 
-@@class="screenshot"@@{{files/tutorial/tutowidgets/ex1.png|screenshot}}
+{%wodoc:@ class="screenshot"%}{%wodoc:img src="files/tutorial/tutowidgets/ex1.png" alt="screenshot"%}
 
-=== More explanations
+{2 More explanations}
 
 This section gives very quick explanations on the rest of the program.
 For more detailed explanations, see the tutorial for the graffiti app
 or the manual of each of the projects.
 
-* The client side program is sent with the first page belonging to the
-  application (registered through module {{{Ex_app}}}).
-* The {{{##}}} is used to call a JS method from OCaml
-  and {{{##.}}} to access a JS object field
+- The client side program is sent with the first page belonging to the
+  application (registered through module [Ex_app]).
+- The [##] is used to call a JS method from OCaml
+  and [##.] to access a JS object field
   (See Js_of_ocaml's documentation:
-  <<a_api project="js_of_ocaml" subproject="js_of_ocaml-ppx" | module Ppx_js >>).
-* If there are several services in your application, the client-side
+  {!Ppx_js}).
+- If there are several services in your application, the client-side
   program will be sent only with the first page, and will not stop if
   you go to another page of the application.
-* {{{Lwt}}} is the concurrent library used to program threads on both
-  client and server sides. The syntax {{{let%lwt a = e1 in e2}}}
+- [Lwt] is the concurrent library used to program threads on both
+  client and server sides. The syntax [let%lwt a = e1 in e2]
   allows waiting (without blocking the rest of the program) for an Lwt
-  thread to terminate before continuing. {{{e2}}} must ben a Lwt
-  thread itself. {{{Lwt.return}}} enables creating an
+  thread to terminate before continuing. [e2] must ben a Lwt
+  thread itself. [Lwt.return] enables creating an
   already-terminated Lwt thread.
-* {{{Js_of_ocaml_lwt.Lwt_js_events}}} defines a convenient way to program
+- [Js_of_ocaml_lwt.Lwt_js_events] defines a convenient way to program
   interface events (mouse, keyboard, ...).
 
-{{{Js_of_ocaml_lwt.Lwt_js_events.onload}}} is a Lwt thread that waits until the page
+[Js_of_ocaml_lwt.Lwt_js_events.onload] is a Lwt thread that waits until the page
 is loaded. There are similar functions to wait for other events, e.g.,
 for a click on an element of the page, or for a key press.
 
-== Second step: bind the button ==
+{1 Second step: bind the button}
 
 To make the widget work, we must bind the click event.
-Replace function {{{mywidget}}} by the following lines:
+Replace function [mywidget] by the following lines:
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client switch_visibility elt =
   let elt = Eliom_content.Html.To_dom.of_element elt in
   if Js_of_ocaml.Js.to_bool (elt##.classList##contains (Js_of_ocaml.Js.string "hidden")) then
@@ -147,37 +150,38 @@ let%client mywidget s1 s2 = Eliom_content.Html.D.(
       (fun _ _ -> switch_visibility content; Lwt.return ()));
   div ~a:[a_class ["mywidget"]] [button; content]
 )
->>
+]}
 
-* Once again, we use {{{Js_of_ocaml_lwt.Lwt_js_events}}}. Function {{{clicks}}} is
+- Once again, we use [Js_of_ocaml_lwt.Lwt_js_events]. Function [clicks] is
   used to bind a handler to clicks on a specific element.
-* Function {{{async}}} runs an {{{Lwt}}} thread asynchronously
+- Function [async] runs an [Lwt] thread asynchronously
   (without waiting for its result).
-* {{{Js_of_ocaml_lwt.Lwt_js_events.clicks elt f}}} calls function {{{f}}} for each
-  mouseclick on element {{{elt}}}.
-* {{{Eliom_content.Html.To_dom.of_element}}}, {{{Js_of_ocaml.Js.string}}} and {{{Js_of_ocaml.Js.to_bool}}} are
+- [Js_of_ocaml_lwt.Lwt_js_events.clicks elt f] calls function [f] for each
+  mouseclick on element [elt].
+- [Eliom_content.Html.To_dom.of_element], [Js_of_ocaml.Js.string] and [Js_of_ocaml.Js.to_bool] are
   conversion functions between OCaml values and JS values.
 
-== Third step: Generating the widget on server side ==
+{1 Third step: Generating the widget on server side}
 
 The following version of the program shows how to generate the widget
 on server side, before sending it to the client.
 
 The code is exactly the same, with the following modifications:
-* We place function {{{mywidget}}} in server section.
-* The portion of code that must be run on client side (binding the
-  click event) is written as a //client value//, inside
-  {{{ [%client (... : unit) ] }}}.
+- We place function [mywidget] in server section.
+- The portion of code that must be run on client side (binding the
+  click event) is written as a {e client value}, inside
+  [[%client (... : unit) ]].
   This code will be executed by the client-side program when it
   receives the page. Note that you must give the type (here
-  {{{unit}}}), as the type inference for client values is currently
+  [unit]), as the type inference for client values is currently
   very limited. The client section may refer to server side values,
-  using the {{{~%x}}} syntax. These values will be serialized and sent
+  using the [~%x] syntax. These values will be serialized and sent
   to the client automatically with the page.
-* We include the widget on the server side generated page instead of
+- We include the widget on the server side generated page instead of
   adding it to the page from client side.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 
 module%server Ex_app =
   Eliom_registration.App (struct
@@ -185,8 +189,9 @@ module%server Ex_app =
     let global_data_path = None
   end)
 
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client switch_visibility elt =
   let elt = Eliom_content.Html.To_dom.of_element elt in
   if Js_of_ocaml.Js.to_bool (elt##.classList##(contains (Js_of_ocaml.Js.string "hidden"))) then
@@ -194,8 +199,9 @@ let%client switch_visibility elt =
   else
     elt##.classList##add (Js_of_ocaml.Js.string "hidden")
 
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server mywidget s1 s2 = Eliom_content.Html.D.(
   let button  = div ~a:[a_class ["button"]] [txt s1] in
   let content = div ~a:[a_class ["content"]] [txt s2] in
@@ -218,27 +224,29 @@ let%server _ = Eliom_content.Html.D.(
             (body [h2 [txt "Welcome to Ocsigen!"];
                    mywidget "Click me" "Hello!"])))
 )
->>
+]}
 
-== Fourth step: widget usable either on client or server sides ==
+{1 Fourth step: widget usable either on client or server sides}
 
-If you make function {{{mywidget}}} //shared//, it will be available
+If you make function [mywidget] {e shared}, it will be available
 both on server and client sides:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%shared mywidget s1 s2 =
   ...
->>
+]}
 
-@@class="screenshot"@@{{files/tutorial/tutowidgets/ex2.png|screenshot}}
+{%wodoc:@ class="screenshot"%}{%wodoc:img src="files/tutorial/tutowidgets/ex2.png" alt="screenshot"%}
 
 
-== Fifth step: close last window when opening a new one ==
+{1 Fifth step: close last window when opening a new one}
 
 To implement this, we record a client-side reference to a function for
 closing the currently opened window.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 
 module%server Ex_app =
   Eliom_registration.App (struct
@@ -246,8 +254,9 @@ module%server Ex_app =
     let global_data_path = None
   end)
 
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client close_last = ref (fun () -> ())
 
 let%client switch_visibility elt =
@@ -257,8 +266,9 @@ let%client switch_visibility elt =
   else
     elt##.classList##add (Js_of_ocaml.Js.string "hidden")
 
->>
-<<code language="ocaml" class="shared"|
+]}
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%shared mywidget s1 s2 = Eliom_content.Html.D.(
   let button  = div ~a:[a_class ["button"]] [txt s1] in
   let content = div ~a:[a_class ["content"]] [txt s2] in
@@ -274,8 +284,9 @@ let%shared mywidget s1 s2 = Eliom_content.Html.D.(
   ] in
   div ~a:[a_class ["mywidget"]] [button; content]
 )
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server _ = Eliom_content.Html.D.(
   Ex_app.create
     ~path:(Eliom_service.Path [""])
@@ -297,18 +308,19 @@ let%server _ = Eliom_content.Html.D.(
              mywidget "Click me" "server side"
            ])))
 )
->>
+]}
 
-== Last step: several sets of widgets ==
+{1 Last step: several sets of widgets}
 
 Now we want to enable several sets of widgets in the same page. A
 single reference no longer suffices. In the following version, the
 server-side program asks the client-side program to generate two
-different references, by calling function {{{new_set}}}. This function
-returns what we call a //client value//.  On server side, it is not
+different references, by calling function [new_set]. This function
+returns what we call a {e client value}.  On server side, it is not
 evaluated, and it has an abstract type.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 
 module%server Ex_app =
   Eliom_registration.App (struct
@@ -318,8 +330,9 @@ module%server Ex_app =
 
 let%server new_set () = [%client ( ref (fun () -> ()) : (unit -> unit) ref)]
 
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client switch_visibility elt =
   let elt = Eliom_content.Html.To_dom.of_element elt in
   if Js_of_ocaml.Js.to_bool (elt##.classList##(contains (Js_of_ocaml.Js.string "hidden"))) then
@@ -327,8 +340,9 @@ let%client switch_visibility elt =
   else
     elt##.classList##add (Js_of_ocaml.Js.string "hidden")
 
->>
-<<code language="ocaml" class="shared"|
+]}
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%shared mywidget set s1 s2 = Eliom_content.Html.D.(
   let button  = div ~a:[a_class ["button"]] [txt s1] in
   let content = div ~a:[a_class ["content"; "hidden"]] [txt s2] in
@@ -344,8 +358,9 @@ let%shared mywidget set s1 s2 = Eliom_content.Html.D.(
   div ~a:[a_class ["mywidget"]] [button; content]
 )
 
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server _ = Eliom_content.Html.D.(
   Ex_app.create
     ~path:(Eliom_service.Path [""])
@@ -368,22 +383,21 @@ let%server _ = Eliom_content.Html.D.(
              mywidget set2 "Click me" "server side"
            ])))
 )
->>
+]}
 
-@@class="screenshot"@@{{files/tutorial/tutowidgets/ex-final.png|screenshot}}
+{%wodoc:@ class="screenshot"%}{%wodoc:img src="files/tutorial/tutowidgets/ex-final.png" alt="screenshot"%}
 
 
-== And now? ==
+{1 And now?}
 
-===Calling server functions===
+{2 Calling server functions}
 An important feature missing from this tutorial is the ability
 to call server functions from the client-side program ("server functions").
 You can find a quick description of this
-in <<a_manual project="tuto" chapter="how-to-call-a-server-side-function-from-client-side"|this mini HOWTO>> or
-in <<a_manual project="eliom" chapter="clientserver-communication" fragment="rpc"|
-Eliom's manual>>.
+in {{:../tuto/how-to-call-a-server-side-function-from-client-side.html}this mini HOWTO} or
+in {{:../eliom/clientserver-communication.html#rpc}Eliom's manual}.
 
-===Services===
+{2 Services}
 
 For many applications, you will need several services. By default,
 client-side Eliom programs do not stop when you follow a link or send
@@ -392,11 +406,11 @@ music, animations, stateful applications~ ...)  with traditional Web
 interaction (links, forms, bookmarks, back button~ ...).  Eliom
 proposes several ways to identify services, either by the URL (and
 parameters), or by a session identifier (we call this kind of service
-a //coservice//). Eliom also allows creating new (co-)services
+a {e coservice}). Eliom also allows creating new (co-)services
 dynamically, for example coservices depending on previous interaction
 with a user. More information on the service identification mechanism
-in <<a_manual project="eliom" chapter="server-services"|Eliom's manual>>.
+in {{:../eliom/server-services.html}Eliom's manual}.
 
-===Sessions===
-Eliom also offers a rich session mechanism, with //scopes//
-(see <<a_manual project="eliom" chapter="server-state"|Eliom's manual>>).
+{2 Sessions}
+Eliom also offers a rich session mechanism, with {e scopes}
+(see {{:../eliom/server-state.html}Eliom's manual}).
diff --git a/tutos/dev/manual/application.wiki b/tutos/dev/manual/application.mld
similarity index 51%
rename from tutos/dev/manual/application.wiki
rename to tutos/dev/manual/application.mld
index 263eb1c1..89083b6e 100644
--- a/tutos/dev/manual/application.wiki
+++ b/tutos/dev/manual/application.mld
@@ -1,45 +1,49 @@
-<<header| =Writing a client/server Eliom application >>
+{%wodoc:header%}
+{0 Writing a client/server Eliom application}
+{%wodoc:end%}
 
-In this chapter, we will write a [[site:graffiti/|collaborative
-drawing application]]. It is a client/server web application
+In this chapter, we will write a {{:../graffiti/}collaborative
+drawing application}. It is a client/server web application
 displaying an area where users can draw using the mouse, and see what
 other users are drawing at the same time and in real-time.
 
 This tutorial is a good starting point if you want a step-by-step
 introduction to Eliom programming.
 
-<<webonly| The final eliom code is available
-[[https://github.com/ocsigen/graffiti/tree/master/simple|for download]].
->>
+ The final eliom code is available
+{{:https://github.com/ocsigen/graffiti/tree/master/simple}for download}.
 
-<<|outline target="documentation">>
 
-==@@id="basics"@@ Basics==
+
+
+{1:basics Basics}
 
 If not already done, install Eliom first:
-{{{
+{v
 opam install ocsipersist-sqlite eliom ocsigen-ppx-rpc
-}}}
+v}
 
-To get started, we recommend using <<a_manual project="eliom"
-chapter="workflow-distillery"|Eliom distillery>>, a program which
+To get started, we recommend using {{:../eliom/workflow-distillery.html}Eliom distillery}, a program which
 creates scaffolds for Eliom projects. The following command creates a
-very simple project called {{{graffiti}}} in the directory
-{{{graffiti}}}:
+very simple project called [graffiti] in the directory
+[graffiti]:
 
-<<code language="shell"|
+{@shell[
 $ eliom-distillery -name graffiti -template client-server.basic -target-directory graffiti
->>
+]}
 
-===My first page===
+{2 My first page}
 
-<<concepts|Services\\Configuration file\\Static validation of HTML>>
+{%wodoc:aside class="concepts"%}{b Concepts}
+
+Services{%html:<br/>%}Configuration file{%html:<br/>%}Static validation of HTML{%wodoc:end%}
 
 Our web application consists of a single page for now. Let's start by
 creating a very basic page. We define the service that will implement
 this page by the following declaration:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 open%server Eliom.Content.Html.D (* provides functions to create HTML nodes *)
 
 let%server main_service =
@@ -55,23 +59,25 @@ let%server () =
         (html
            (head (title (txt "Page title")) [])
            (body [h1 [txt "Graffiti"]])))
->>
+]}
 
-Annotations {{{%server}}} tells the compiler that the code is going to be executed
+Annotations [%server] tells the compiler that the code is going to be executed
 on the server (see later).
 
-Replace the content of file {{{graffiti.eliom}}} by the above lines and run:
+Replace the content of file [graffiti.eliom] by the above lines and run:
 
-<<code language="shell"|
+{@shell[
 $ make test.byte
->>
+]}
+
+This will compile your application and run [ocsigenserver].
 
-This will compile your application and run {{{ocsigenserver}}}.
+Your page is now available at URL {{:http://localhost:8080/graff}[http://localhost:8080/graff]}.
 
-Your page is now available at URL [[http://localhost:8080/graff|{{{http://localhost:8080/graff}}}]].
+
+{%wodoc:aside class="concept"%}{b Concept: Services}
 
 
-<<concept title="Services"|
 
 Unlike typical web programming techniques (CGI, PHP,~ ...), with Eliom
 you do not need to write one file per URL. The application can be
@@ -79,84 +85,88 @@ split into multiple files as per the developer's style. What matters
 is that you eventually produce a single module (*.cmo or *.cma) for
 the whole website.
 
-The module <<a_api project="eliom" subproject="server" | module Eliom.Service >> allows to
-create new entry points to your web site, called //services//. In
+The module {!Eliom.Service} allows to
+create new entry points to your web site, called {e services}. In
 general, services are attached to a URL and generate a web page.
 Services are represented by OCaml values, through which you must
 register a function that will generate a page.
 
-The {{{~path}}} parameter corresponds to the URL where you want to
+The [~path] parameter corresponds to the URL where you want to
 attach your service. It is a list of strings.  The value
-<<code-inline|["foo"; "bar"]>> corresponds to the URL
-<<code-inline|foo/bar>>.  <<code-inline|["dir"; ""]>> corresponds to
-the URL <<code-inline|dir/>> (that is: the default page of the
-directory <<code-inline|dir>>).
+{[["foo"; "bar"]]} corresponds to the URL
+{[foo/bar]}.  {[["dir"; ""]]} corresponds to
+the URL {[dir/]} (that is: the default page of the
+directory {[dir]}).
+
+{%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: Configuration file}
 
->>
 
-<<concept title="Configuration file"|
 
 In the directory of the project created by the Eliom-distillery, you
-can find the file {{{graffiti.conf.in}}}. This file is used in
-conjunction with the variables in {{{Makefile.options}}} to generate
-the {{{ocsigenserver}}} configuration file.
+can find the file [graffiti.conf.in]. This file is used in
+conjunction with the variables in [Makefile.options] to generate
+the [ocsigenserver] configuration file.
 
-Once you start up your application via {{{make test.byte}}}, the
+Once you start up your application via [make test.byte], the
 configuration file becomes available at
-{{{local/etc/graffiti/graffiti-test.conf}}}. It contains various
+[local/etc/graffiti/graffiti-test.conf]. It contains various
 directives for Ocsigen server (port, log files, extensions to be
-loaded, etc.), taken from {{{Makefile.options}}}, and something like:
+loaded, etc.), taken from [Makefile.options], and something like:
 
-{{{
+{v
 <host>
   <static dir="static" />
   <eliommodule module="/path_to/graffiti.cma" />
   <eliom />
 </host>
-}}}
+v}
 
-{{{<eliommodule ... />}}} asks the server to load Eliom module
-{{{graffiti.cma}}}, containing the Eliom application,
+[<eliommodule ... />] asks the server to load Eliom module
+[graffiti.cma], containing the Eliom application,
 at startup and attach it to this host (and site).
 
-Extensions {{{<static ... />}}} (staticmod) and {{{<eliom />}}}
+Extensions [<static ... />] (staticmod) and [<eliom />]
 are called successively:
-* If they exist, files from the directory <<code-inline|
-  /path_to/graffiti/static >> will be served,
-* Otherwise, Server will try to generate pages with Eliom
-  ({{{<eliom />}}}),
-* Otherwise it will generate a 404 (Not found) error (default).
+- If they exist, files from the directory {[
+  /path_to/graffiti/static ]} will be served,
+- Otherwise, Server will try to generate pages with Eliom
+  ([<eliom />]),
+- Otherwise it will generate a 404 (Not found) error (default).
+
+{%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: Static validation of HTML}
 
->>
 
-<<concept title="Static validation of HTML" id="tyxml"|
 
 There are several ways to create pages for Eliom.  You can generate
 pages as strings (as in other web frameworks). However, it is
 preferable to generate HTML in a way that provides compile-time HTML
 correctness guarantees. This tutorial achieves this by using the
-module <<a_api project="eliom" subproject="server" | module Eliom.Content.Html.D >>,
-which is implemented using the <<a_manual project="tyxml" |TyXML>>
+module {!Eliom.Content.Html.D},
+which is implemented using the {{:../tyxml/.html}TyXML}
 library.  The module defines a construction function for each HTML
 tag.
 
-//Note that it is also possible to use the usual HTML syntax directly
- in OCaml, cf.  <<a_api project="tyxml" | module Pa_tyxml >>.//
+{e Note that it is also possible to use the usual HTML syntax directly
+ in OCaml, cf.  {!Pa_tyxml}.}
 
-The TyXML library (and thus <<a_api project="eliom" subproject="server" | module
-Eliom.Content.Html.D >>) is very strict and compels you to respect
+The TyXML library (and thus {!module
+Eliom.Content.Html.D}) is very strict and compels you to respect
 HTML standard (with some limitations). For example if you write:
 
-<<code language="ocaml"|
+{@ocaml[
 (html
    (head (title (txt "")) [txt ""])
    (body [txt "Hallo"]))
->>
+]}
 
 You will get an error message similar to the following, referring to
 the end of line 2:
 
-{{{
+{v
 Error: This expression has type ([> `TXT ] as 'a) Html.elt
        but an expression was expected of type
          Html_types.head_content_fun Html.elt
@@ -169,89 +179,72 @@ Error: This expression has type ([> `TXT ] as 'a) Html.elt
            | `Script
            | `Style ]
        The second variant type does not allow tag(s) `TXT
-}}}
+v}
 
-where <<a_api project="tyxml" | type Html_types.head_content_fun >>
-is the type of content allowed inside {{{<head>}}} ({{{<base>}}},
-{{{<command>}}}, {{{<link>}}}, {{{<meta>}}}, etc.). Notice that
-{{{`TXT}}} (i.e. raw text) is not included in this polymorphic
-variant type, which means that {{{<head>}}} cannot contain raw text.
+where {!Html_types.head_content_fun}
+is the type of content allowed inside [<head>] ([<base>],
+[<command>], [<link>], [<meta>], etc.). Notice that
+[`TXT] (i.e. raw text) is not included in this polymorphic
+variant type, which means that [<head>] cannot contain raw text.
 
 Most functions take as parameter the list representing its contents.
-See other examples below. Each of them take an optional {{{?a}}}
+See other examples below. Each of them take an optional [?a]
 parameter for optional HTML attributes.
 Mandatory HTML attributes correspond to mandatory OCaml parameters.
 See below for examples.
 
-<<|
-**Another example:** In HTML, some tags cannot be empty. For example
-{{{<table>}}}must contain at least one row. To enforce this, function
-<<a_api project="tyxml" text="Html.table"| val Html.F.table ~>>
-takes two parameters: the first one is the first row, while
-the second one is a list containing all the other rows (same thing for
-{{{<tr>}}}, {{{<form>}}}, {{{<select>}}}, ...). This prevents tables
-of zero rows, and thus ensures that the W3C recommendation is met.
 
-//Strict typing of HTML may initially seem tedious, but in fact it is
-very easy to get used to.  It actually saves a significant amount of
-debugging time as you will never have to bother about the validity of
-pages afterwards.//
 
-A more detailed introduction to the construction of HTML5 tree is
-available in the <<a_api project="tyxml" text="TyXML reference API" |
-module Html.F ~>>.
+{%wodoc:end%}
 
->>
+{%wodoc:aside class="concept"%}{b Concept: Lwt}
 
->>
 
-<<concept title="Lwt"|
 
-**Important warning:** All the functions you write must be written in
+{b Important warning:} All the functions you write must be written in
 a cooperative manner using Lwt. Lwt is a convenient way to implement
 concurrent programs in OCaml, and is now also widely used for
 applications unrelated to Ocsigen.
 
-For now we will just use the {{{Lwt.return}}} function as above.  We
+For now we will just use the [Lwt.return] function as above.  We
 will come back to Lwt programming later. You can also have a look at
-the <<a_manual project="lwt"|Lwt programming guide>>.
+the {{:../lwt/.html}Lwt programming guide}.
+
+{%wodoc:end%}
 
->>
+{2 Execute parts of the program on the client}
 
-===Execute parts of the program on the client===
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-<<concepts|
-Service sending an application\\
-Client and server code\\
-Compiling a Web application with server and client parts\\
-Calling JavaScript methods with Js_of_ocaml\\
->>
 
-To create our first service, we used the function <<a_api
-project="eliom" subproject="server" | val Eliom.Registration.Html.create>>, as
+Service sending an application{%html:<br/>%}
+Client and server code{%html:<br/>%}
+Compiling a Web application with server and client parts{%html:<br/>%}
+Calling JavaScript methods with Js_of_ocaml{%html:<br/>%}
+{%wodoc:end%}
+
+To create our first service, we used the function {!Eliom.Registration.Html.create}, as
 all we wanted to do was return HTML. But we actually want a service
 that corresponds to a full application with client and server
 parts. To do so, we need to create our own registration module by
-using the functor {{{Eliom.Registration.App}}}:
+using the functor [Eliom.Registration.App]:
+
 
-<<|BB
-  This is a bit fast, especially if you just came to Ocsigen. The following
-  questions popped into my mind: What is an Eliom application? What's its
-  motivation, what comprises it and how does is work?
->>
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 module Graffiti_app =
   Eliom.Registration.App (struct
       let application_name = "graffiti"
       let global_data_path = None
     end)
->>
+]}
 
-It is now possible to use module {{{Graffiti_app}}} for registering our main
-service (now at URL {{{/}}}):
+It is now possible to use module [Graffiti_app] for registering our main
+service (now at URL [/]):
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server main_service =
   Eliom.Service.create
     ~path:(Eliom.Service.Path [""])
@@ -265,38 +258,41 @@ let%server () =
         (html
            (head (title (txt "Graffiti")) [])
            (body [h1 [txt "Graffiti"]]) ) )
->>
+]}
 
 We can now add some OCaml code to be executed by the browser. For this
 purpose, Eliom provides a syntax extension to distinguish between
 server and client code in the same file. We start by a very basic
 program, that will display a message to the user by calling the
-JavaScript function {{{alert}}}. Add the following lines to the
+JavaScript function [alert]. Add the following lines to the
 program:
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client _ = Eliom.Lib.alert "Hello!"
->>
+]}
+
+After running again [make test.byte], and visiting
+{{:http://localhost:8080/}http://localhost:8080/}, the browser will load the file
+[graffiti.js], and open an alert-box.
 
-After running again {{{make test.byte}}}, and visiting
-[[http://localhost:8080/]], the browser will load the file
-{{{graffiti.js}}}, and open an alert-box.
+{%wodoc:aside class="concept"%}{b Concept: Splitting the code into server and client parts}
 
-<<concept title="Splitting the code into server and client parts"|
 
-At the very toplevel of your source file (i.e. //not// inside modules
+
+At the very toplevel of your source file (i.e. {e not} inside modules
 or other server- /client-parts), you can use the following constructs
 to indicate which side the code should run on.
 
-* {{{ let%client }}}, {{{ let%server }}}, {{{ let%shared }}}: same as
+- [let%client], [let%server], [let%shared]: same as
   above for a single definition.
-* other syntaxes like {{{ module%server }}}, {{{ open%client }}},
-  {{{ type%shared }}} ...
-* {{{ [%%client ... ] }}}: the list of enclosed definitions is
-  client-only code (similarly for {{{ [%%server ... ] }}}). With
-  {{{ [%%shared ... ] }}}, the code is used both on the server and client.
-* {{{ [%%client.start] }}}, {{{ [%%server.start] }}},
-  {{{ [%%shared.start] }}}: these set the default location for all
+- other syntaxes like [module%server], [open%client],
+  [type%shared] ...
+- [[%%client ... ]]: the list of enclosed definitions is
+  client-only code (similarly for [[%%server ... ]]). With
+  [[%%shared ... ]], the code is used both on the server and client.
+- [[%%client.start]], [[%%server.start]],
+  [[%%shared.start]]: these set the default location for all
   definitions that follow, and which do not use the preceding
   constructs.
 
@@ -304,81 +300,89 @@ If no location is specified, the code is assumed to be for the server.
 
 The above constructs are implemented by means of PPX, OCaml's new
 mechanism for implementing syntax extensions. See
-<<a_api project="eliom" subproject="ppx"|module Ppx_eliom>> for details.
+{!Ppx_eliom} for details.
 
-**Client parts are executed once, when the client side process is
-launched.** The client process is not restarted after each page
+{b Client parts are executed once, when the client side process is
+launched.} The client process is not restarted after each page
 change.
 
-The Makefile created by {{{eliom-distillery}}} automatically splits the
+The Makefile created by [eliom-distillery] automatically splits the
 code into client and server parts, compiles the server part as usual,
 and compile the client part to a JavaScript program using
-{{{js_of_ocaml}}}.
+[js_of_ocaml].
+
+ {%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: Client values on the server}
 
- >>
 
-<<concept title="Client values on the server"|
 
 Additionally, it is possible to create client values within the server
 code by the following quotation:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
   [%client (expr : typ) ]
->>
+]}
 
-where {{{typ}}} is the type of an expression {{{expr}}} on the client.
+where [typ] is the type of an expression [expr] on the client.
 Note, that such a client value is abstract on the server, but becomes
 concrete, once it is received by the client.
 
-(The {{{typ}}} can be ommitted if it can be inferred from the usage of
+(The [typ] can be ommitted if it can be inferred from the usage of
 the client value in the server code.)
 
-**Client values are executed on the client after the service
-returns.** You can use client values when a service wants to ask the
+{b Client values are executed on the client after the service
+returns.} You can use client values when a service wants to ask the
 client to run something, for example binding some event handler on
 some element produced by the service.
 
->>
+{%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: Js_of_ocaml}
+
 
-<<concept title="Js_of_ocaml"|
 
 The client-side parts of the program are compiled to JavaScript by
-{{{js_of_ocaml}}}. (Technically, {{{js_of_ocaml}}} compiles OCaml
-bytecode to JavaScript.)  It is easy <<a_manual project="js_of_ocaml"
-chapter="bindings"|to bind JavaScript libraries>> so that OCaml
+[js_of_ocaml]. (Technically, [js_of_ocaml] compiles OCaml
+bytecode to JavaScript.)  It is easy {{:../js_of_ocaml/bindings.html}to bind JavaScript libraries} so that OCaml
 programs can call JavaScript functions. In the example, we are using
-the <<a_api project="js_of_ocaml" | module Js_of_ocaml.Dom_html >> module, which
+the {!Js_of_ocaml.Dom_html} module, which
 is a binding that allows the manipulation of an HTML page.
 
 Js_of_ocaml is using a syntax extension to call JavaScript methods:
-* {{{obj##m a b c}}} to call the method {{{m}}} of object {{{obj}}}
-  with parameters {{{a}}}, {{{b}}}, {{{c}}},
-* {{{obj##.m}}} to get a property,
-* {{{obj##.m := e}}} to set a property, and
-* {{{new%js constr a b c}}} to call a JavaScript constructor.
+- [obj##m a b c] to call the method [m] of object [obj]
+  with parameters [a], [b], [c],
+- [obj##.m] to get a property,
+- [obj##.m := e] to set a property, and
+- [new%js constr a b c] to call a JavaScript constructor.
 
 More information can be found in the Js_of_ocaml manual, in module
-<<a_api project="js_of_ocaml" subproject="js_of_ocaml-ppx"| module Ppx_js >>.
+{!Ppx_js}.
+
+{%wodoc:end%}
 
->>
+{2 Accessing server side variables on client side code}
 
-===Accessing server side variables on client side code===
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-<<concepts|
-Executing client side code after loading a page\\
-Sharing server side values\\
-Converting an HTML value to a portion of page (a.k.a. Dom node)\\
+
+Executing client side code after loading a page{%html:<br/>%}
+Sharing server side values{%html:<br/>%}
+Converting an HTML value to a portion of page (a.k.a. Dom node){%html:<br/>%}
 Manipulating HTML node 'by reference'
->>
+{%wodoc:end%}
 
 The client side process is not strictly separated from the server
 side.  We can access some server variables from the client code. For
 instance:
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 open%client Js_of_ocaml
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 
 let%server count = ref 0
 
@@ -402,110 +406,88 @@ let%server () =
          (html
             (head (title (txt "Graffiti")) [])
             (body [h1 [txt @@ text c]])))
->>
+]}
 
-Here, we are increasing the reference {{{count}}} each time the page
+Here, we are increasing the reference [count] each time the page
 is accessed. When the page is loaded and the document is in-place, the
-client program initializes the value inside {{{ [%client ... ] }}},
+client program initializes the value inside [[%client ... ]],
 and thus triggers an alert window. More specifically, the variable
-{{{c}}}, in the scope of the client value on the server is made
-available to the client value using the syntax extension {{{~%c}}}. In
-doing so, the server side value {{{c}}} is displayed in a message box
+[c], in the scope of the client value on the server is made
+available to the client value using the syntax extension [~%c]. In
+doing so, the server side value [c] is displayed in a message box
 on the client.
 
 
-<<concept
+{%wodoc:aside class="concept"%}{b Concept: Injections: Using server side values in client code}
+
 
-  title="Injections: Using server side values in client code" |
 
   Client side code can reference copies of server side values using
-  the {{{~%variable}}} syntax.  Values sent that way are weakly type
+  the [~%variable] syntax.  Values sent that way are weakly type
   checked: the name of the client side type must match the server side
   one. If you define a type and want it to be available on both sides,
-  declare it in {{{ [%%shared ... ]}}}. The Eliom manual provides more
-  information on the <<a_api project="eliom" subproject="ppx"
-  text="Eliom's syntax extension"|module Ppx_eliom>> and
-  its <<a_manual project="eliom" chapter="workflow-compilation"
-  fragment="compilation"|compilation process>>.
+  declare it in [[%%shared ... ]]. The Eliom manual provides more
+  information on the {{!Ppx_eliom}Eliom's syntax extension} and
+  its {{:../eliom/workflow-compilation.html#compilation}compilation process}.
 
-  The value of an injection into a {{{ let%client }}}
+  The value of an injection into a [let%client]
   section is sent only once when starting the application in the
   browser. In contrast, the
   values of injections into client values which are created during a
   request are sent alongside the next response.
 
->>
+{%wodoc:end%}
 
-<<|BB/BS This only applies to elements created by Html.F
-It is possible to send almost any type of values that way, but keep in
-mind that sent values are //copies// of server side ones. For HTML
-elements, this is not always the expected behaviour. Considering the
-following piece of code, the {{{onload}}} event handler won't do
-anything noticeable because we added the {{{<div>some text</div>}}} to
-a copy of the {{{<body>}}} element. Hence, the actual page's
-{{{<body>}}} is not modified.
 
-<<code language="ocaml" class="server"|
-let%server main_service =
-  Eliom.Service.create
-    ~path:(Eliom.Service.Path [""])
-    ~meth:(Eliom.Service.Get Eliom.Parameter.unit)
-    ()
 
-let%server () =
-  Graffiti_app.register ~service:main_service
-    (fun () () ->
-      let container = body [h1 [txt "Graffiti"]] in
-      Eliom.Service.onload {{
-        Html.Manip.appendChild %container (div [txt "some text"]);
-      }}
-      Lwt.return
-        (html
-           (head (title (txt "Graffiti")) [])
-           (container) ) )
->>
 
+{1:graffiti Collaborative drawing application}
+
+{2 Drawing on a canvas}
 
-==@@id="graffiti"@@ Collaborative drawing application==
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-===Drawing on a canvas===
 
-<<concepts|
 
 Canvas
 
->>
+{%wodoc:end%}
 
 We now want to draw something on the page using an HTML canvas. The
 drawing primitive is defined in the client-side function called
-{{{draw}}} that just draws a line between two given points in a canvas.
+[draw] that just draws a line between two given points in a canvas.
 
 To start our collaborative drawing application, we define another
-client-side function {{{ init_client }}}, which just draws a single
+client-side function [init_client], which just draws a single
 line for now.
 
 Here is the (full) new version of the program:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 open%server Eliom.Content
 open%server Eliom.Content.Html.D
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 open%client Js_of_ocaml
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 module%server Graffiti_app =
   Eliom.Registration.App (
     struct
       let application_name = "graffiti"
       let global_data_path = None
     end)
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server width  = 700
 let%server height = 400
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client draw ctx ((r, g, b), size, (x1, y1), (x2, y2)) =
   let color = CSS.Color.string_of_t (CSS.Color.rgb r g b) in
   ctx##.strokeStyle := (Js.string color);
@@ -514,8 +496,9 @@ let%client draw ctx ((r, g, b), size, (x1, y1), (x2, y2)) =
   ctx##(moveTo (float x1) (float y1));
   ctx##(lineTo (float x2) (float y2));
   ctx##stroke
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server canvas_elt =
   Html.D.canvas ~a:[Html.D.a_width width; Html.D.a_height height]
     [Html.D.txt "your browser doesn't support canvas"]
@@ -525,15 +508,17 @@ let%server page () =
      (head (title (txt "Graffiti")) [])
      (body [h1 [txt "Graffiti"];
             canvas_elt])
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client init_client () =
   let canvas = Eliom.Content.Html.To_dom.of_canvas ~%canvas_elt in
   let ctx = canvas##(getContext (Dom_html._2d_)) in
   ctx##.lineCap := Js.string "round";
   draw ctx ((0, 0, 0), 12, (10, 10), (200, 100))
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server main_service =
   Eliom.Service.create
     ~path:(Eliom.Service.Path ["graff"])
@@ -547,60 +532,66 @@ let%server () =
        (* Cf. section "Client side side-effects on the server" *)
        let _ = [%client (init_client () : unit) ] in
        Lwt.return (page ()))
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: JavaScript datatypes in OCaml}
 
-<<concept
 
-  title="JavaScript datatypes in OCaml"|
 
-  Here we use the function <<a_api project="js_of_ocaml" | val
-  Js_of_ocaml.Js.string>> from Js_of_ocaml's library to convert an OCaml string
+  Here we use the function {!val
+  Js_of_ocaml.Js.string} from Js_of_ocaml's library to convert an OCaml string
   into a JS string.
 
->>
+{%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: Client side side-effect on the server}
+
 
-<<concept title="Client side side-effect on the server" |
 
   If a client value
   is created while processing a request, it will be evaluated on the
   client once it receives the response and the document is created;
   the corresponding side effects are then executed.
   For example, the line
-  <<code language="ocaml"|
+  {@ocaml[
     let _ = [%client (init_client () : unit) ] in
     ...
-  >>
+  ]}
 
   creates a client value for the sole purpose of performing side
   effects on the client.  The client value can also be named (as
-  opposed to ignored via {{{_}}}), thus enabling server-side
-  manipulation of client-side values (see below). >>
+  opposed to ignored via [_]), thus enabling server-side
+  manipulation of client-side values (see below). {%wodoc:end%}
+
+{2 Single user drawing application}
 
-===Single user drawing application===
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-<<concepts|
-Lwt\\
+
+Lwt{%html:<br/>%}
 Mouse events with Lwt
->>
+{%wodoc:end%}
 
 We now want to catch mouse events to draw lines with the mouse like
-with the //brush// tools of any classical drawing application. One
+with the {e brush} tools of any classical drawing application. One
 solution would be to mimic typical JavaScript code in OCaml; for
-example by using the function <<a_api project="js_of_ocaml"| val
-Js_of_ocaml.Dom_events.listen >> that is the Js_of_ocaml's equivalent of
-{{{addEventListener}}}. However, this solution is at least as verbose
+example by using the function {!val
+Js_of_ocaml.Dom_events.listen} that is the Js_of_ocaml's equivalent of
+[addEventListener]. However, this solution is at least as verbose
 as the JavaScript equivalent, hence not satisfactory. Js_of_ocaml's
 library provides a much easier way to do that with the help of Lwt.
 
 To use this, add the following line on top of your file:
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 open%client Js_of_ocaml_lwt
->>
+]}
 
-Then, replace the {{{init_client}}} of the previous example by the
+Then, replace the [init_client] of the previous example by the
 following piece of code, then compile and draw!
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client init_client () =
 
   let canvas = Eliom.Content.Html.To_dom.of_canvas ~%canvas_elt in
@@ -631,253 +622,259 @@ let%client init_client () =
          Lwt.pick
            [mousemoves Dom_html.document (fun x _ -> line x);
             let%lwt ev = mouseup Dom_html.document in line ev]))
->>
+]}
 
-We use two references {{{x}}} and {{{y}}} to record the last mouse
-position.  The function {{{set_coord}}} updates those references from
-mouse event data.  The function {{{compute_line}}} computes the
+We use two references [x] and [y] to record the last mouse
+position.  The function [set_coord] updates those references from
+mouse event data.  The function [compute_line] computes the
 coordinates of a line from the initial (old) coordinates to the new
 coordinates--the event data sent as a parameter.
 
 The last four lines of code implement the event-handling loop.  They
-can be read as follows: for each {{{mousedown}}} event on the canvas,
-do {{{set_coord}}}, then {{{line}}} (this will draw a dot), then
-behave as the {{{first}}} of the two following lines that terminates:
+can be read as follows: for each [mousedown] event on the canvas,
+do [set_coord], then [line] (this will draw a dot), then
+behave as the [first] of the two following lines that terminates:
 
-* For each mousemove event on the document, call {{{line}}} (never
+- For each mousemove event on the document, call [line] (never
   terminates)
-* If there is a mouseup event on the document, call {{{line}}}.
+- If there is a mouseup event on the document, call [line].
+
+{%wodoc:aside class="concept"%}{b Concept: More on Lwt}
+
 
-<<concept title="More on Lwt" id="lwt"|
 
 Functions in Eliom and Js_of_ocaml which do not implement just a
 computation or direct side effect, but rather wait for user activity,
 or file system access, or need a unforseeable amount of time to return
-are defined //with Lwt//; instead of returning a value of type {{{a}}}
-they return an Lwt thread of type {{{a Lwt.t}}}.
+are defined {e with Lwt}; instead of returning a value of type [a]
+they return an Lwt thread of type [a Lwt.t].
 
 The only way to use the result of such functions (ones that return
-values in the //Lwt monad//), is to use {{{Lwt.bind}}}.
+values in the {e Lwt monad}), is to use [Lwt.bind].
 
-<<code language="ocaml"|
+{@ocaml[
 Lwt.bind : 'a Lwt.t -> ('a -> 'b Lwt.t) -> 'b Lwt.t
->>
+]}
 
 It is convenient to define an infix operator like this:
-<<code language="ocaml"| let (~>>=) = Lwt.bind>>
+{@ocaml[ let (>>=) = Lwt.bind]}
 
 Then the code
 
-<<code language="ocaml"| f () ~>>= fun x -> >>
+{@ocaml[ f () >>= fun x -> ]}
 
 is conceptually similar to
 
-<<code language="ocaml"| let x = f () in>>
+{@ocaml[ let x = f () in]}
 
 but only for functions returning a value in the Lwt monad.
 
 For more clarity, there is a syntax extension for Lwt, defining
-{{{let%lwt}}} to be used instead of {{{let}}} for Lwt functions:
-<<code language="ocaml"| let%lwt x = f () in>>
+[let%lwt] to be used instead of [let] for Lwt functions:
+{@ocaml[ let%lwt x = f () in]}
 
-{{{Lwt.return}}} creates a terminated thread from a value: <<code
-language="ocaml"| Lwt.return : 'a -> 'a Lwt.t>> Use it when you must
+[Lwt.return] creates a terminated thread from a value: {@ocaml[ Lwt.return : 'a -> 'a Lwt.t]} Use it when you must
 return something in the Lwt monad (for example in a service handler,
-or often after a {{{Lwt.bind}}}).
+or often after a [Lwt.bind]).
 
-=====Why Lwt?=====
+{4 Why Lwt?}
 
 An Eliom application is a cooperative program, as the server must be
 able to handle several requests at the same time.  Ocsigen is using
 cooperative threading instead of the more widely used preemptive
 threading paradigm. It means that no scheduler will interrupt your
 functions whenever it wants. Switching from one thread to another is
-done only when there is a //cooperation point//.
+done only when there is a {e cooperation point}.
 
-We will use the term //cooperative functions// to identify functions
+We will use the term {e cooperative functions} to identify functions
 implemented in cooperative way, that is: if something takes
 (potentially a long) time to complete (for example reading a value
 from a database), they insert a cooperation point to let other threads
 run.  Cooperative functions return a value in the Lwt monad
-(that is, a value of type {{{'a Lwt.t}}} for some type {{{'a}}}).
+(that is, a value of type ['a Lwt.t] for some type ['a]).
 
-{{{Lwt.bind}}} and {{{Lwt.return}}} do not introduce cooperation points.
+[Lwt.bind] and [Lwt.return] do not introduce cooperation points.
 
-In our example, the function {{{Lwt_js_events.mouseup}}} may introduce
+In our example, the function [Lwt_js_events.mouseup] may introduce
 a cooperation point, because it is unforseeable when this event
 happens. That's why it returns a value in the Lwt monad.
 
 Using cooperative threads has a huge advantage: given that you know
-precisely where the cooperation points are, //you need very few
-mutexes// and you have //very low risk of deadlocks//!
+precisely where the cooperation points are, {e you need very few
+mutexes} and you have {e very low risk of deadlocks}!
 
 Using Lwt is very easy and does not cause trouble, provided you never
-use //blocking functions// (non-cooperative functions).  //Blocking
-functions can cause the entre server to hang!// Remember:
+use {e blocking functions} (non-cooperative functions).  {e Blocking
+functions can cause the entre server to hang!} Remember:
 
-* Use the functions from module {{{Lwt_unix}}} instead of module
- {{{Unix}}},
-* Use cooperative database libraries (like PG'Ocaml for Lwt),
-* If you want to use a non-cooperative function, detach it in another
-  preemptive thread using <<a_api project="lwt" | val
-  Lwt_preemptive.detach >>,
-* If you want to launch a long-running computation, manually insert
-  cooperation points using {{{Lwt_unix.yield}}},
-* {{{Lwt.bind}}} does not introduce any cooperation point.
+- Use the functions from module [Lwt_unix] instead of module
+ [Unix],
+- Use cooperative database libraries (like PG'Ocaml for Lwt),
+- If you want to use a non-cooperative function, detach it in another
+  preemptive thread using {!val
+  Lwt_preemptive.detach},
+- If you want to launch a long-running computation, manually insert
+  cooperation points using [Lwt_unix.yield],
+- [Lwt.bind] does not introduce any cooperation point.
 
->> <<| END "encadre" >>
+{%wodoc:end%} 
 
-<<concept
+{%wodoc:aside class="concept"%}{b Concept: Handling events with Lwt}
 
-  title="Handling events with Lwt"|
 
-  Module <<a_api project="js_of_ocaml" subproject="js_of_ocaml-lwt"| module Js_of_ocaml_lwt.Lwt_js_events>>
+
+  Module {!Js_of_ocaml_lwt.Lwt_js_events}
   allows easily defining event listeners using Lwt.  For example,
-  <<a_api project="js_of_ocaml" subproject="js_of_ocaml-lwt"| val Js_of_ocaml_lwt.Lwt_js_events.click >> takes a
+  {!Js_of_ocaml_lwt.Lwt_js_events.click} takes a
   DOM element and returns an Lwt thread that will wait until a click
   occures on this element.
 
-  Functions with an ending "s" (<<a_api project="js_of_ocaml" subproject="js_of_ocaml-lwt"| val
-  Js_of_ocaml_lwt.Lwt_js_events.clicks >>, <<a_api project="js_of_ocaml" subproject="js_of_ocaml-lwt"| val
-  Js_of_ocaml_lwt.Lwt_js_events.mousedowns >>, ...) start again waiting after the
+  Functions with an ending "s" ({!val
+  Js_of_ocaml_lwt.Lwt_js_events.clicks}, {!val
+  Js_of_ocaml_lwt.Lwt_js_events.mousedowns}, ...) start again waiting after the
   handler terminates.
 
-  <<a_api project="lwt" | val Lwt.pick >> behaves as the first thread
+  {!Lwt.pick} behaves as the first thread
   in the list to terminate, and cancels the others.
 
->>
+{%wodoc:end%}
+
+{2 Collaborative drawing application}
 
-===Collaborative drawing application===
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-<<concepts|Client server communication >>
+Client server communication {%wodoc:end%}
 
 In order to see what other users are drawing, we now want to do the
 following:
 
-* Send the coordinates to the server when the user draw a line, then
-* Dispatch the coordinates to all connected users.
+- Send the coordinates to the server when the user draw a line, then
+- Dispatch the coordinates to all connected users.
 
 We first declare a type, shared by the server and the client,
 describing the color (as RGB values) and coordinates of drawn lines.
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 type%shared messages =
     ((int * int * int) * int * (int * int) * (int * int))
     [@@deriving json]
->>
+]}
 
-We annotate the type declaration with {{{[@@deriving json]}}} to allow
+We annotate the type declaration with [[@@deriving json]] to allow
 type-safe deserialization of this type. Eliom forces you to use this
 in order to avoid server crashes if a client sends corrupted data.
 This is defined using a JSON plugin for
-[[https://github.com/whitequark/ppx_deriving|ppx_deriving]], which you
+{{:https://github.com/whitequark/ppx_deriving}ppx_deriving}, which you
 need to install. You need to do that for each type of data sent by the
 client to the server.  This annotation can only be added on types
 containing exclusively basic types, or other types annotated with
-{{{[@@deriving json]}}}.
+[[@@deriving json]].
 
 Then we create an Eliom bus to broadcast drawing events to all client
-with the function <<a_api project="eliom" subproject="server"| val
-Eliom.Bus.create >>. This function take as parameter the type of
+with the function {!val
+Eliom.Bus.create}. This function take as parameter the type of
 values carried by the bus.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server bus = Eliom.Bus.create [%json: messages]
->>
+]}
 
 To write draw commands into the bus, we just replace the function
-{{{line}}} in {{{init_client}}} by:
+[line] in [init_client] by:
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let line ev =
   let v = compute_line ev in
   let _ = Eliom.Bus.write ~%bus v in
   draw ctx v;
   Lwt.return ()
 in
->>
+]}
 
 Finally, to interpret the draw orders read on the bus, we add the
-following line at the end of function {{{init_client}}}:
+following line at the end of function [init_client]:
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
   Lwt.async (fun () ->
     Lwt_stream.iter (draw ctx) (Eliom.Bus.stream ~%(bus : (messages, messages) Eliom.Bus.t)))
->>
+]}
 
 Now you can try the program using two browser windows to see that the
 lines are drawn on both windows.
 
-<<concept
+{%wodoc:aside class="concept"%}{b Concept: Communication channels}
+
 
-  title="Communication channels"|
 
   Eliom provides multiple ways for the server to send unsolicited data
   to the client:
 
-* Module <<a_api project="eliom" subproject="server" | module Eliom.Notif >>
-  (or <<a_api project="ocsigen-start" subproject="server" | module Os.Notif >>
+- Module {!Eliom.Notif}
+  (or {!Os.Notif}
   if you are using Ocsigen Start) provides a very simple way to send messages to
   clients. It's probably the solution you will use most of the times.
-* You can use <<a_api project="eliom" subproject="server"
-  | type Eliom.Bus.t >> instead, as in this example, in the particular case
+- You can use {!Eliom.Bus.t} instead, as in this example, in the particular case
   when you need to broadcast data to all connected clients. Buses are
   broadcasting channels where
-  client and server can participate (see also <<a_api project="eliom"
-  subproject="client" | type Eliom.Bus.t >> in the client
+  client and server can participate (see also {!Eliom.Bus.t} in the client
   API).
-* <<a_api project="eliom" subproject="server" | module
-  Eliom_react >> allows sending
-  [[http://erratique.ch/software/react/doc/React|React events]] from
+- {!module
+  Eliom_react} allows sending
+  {{:http://erratique.ch/software/react/doc/React}React events} from
   the server to the client, and conversely.
-* <<a_api project="eliom" subproject="server" | type
-  Eliom.Comet.Channel.t >> are one-way communication channels
-  allowing finer-grained control. It allows sending <<a_api
-  project="lwt" | module Lwt_stream >> to the client.
-  {{{Eliom_react}}} and {{{Eliom.Bus}}} are implemented over
-  {{{Eliom.Comet}}}.
+- {!type
+  Eliom.Comet.Channel.t} are one-way communication channels
+  allowing finer-grained control. It allows sending {!Lwt_stream} to the client.
+  [Eliom_react] and [Eliom.Bus] are implemented over
+  [Eliom.Comet].
 
-  It is possible to control the idle behaviour with module <<a_api
-  project="eliom" subproject="client" | module
-  Eliom.Comet.Configuration >>.
+  It is possible to control the idle behaviour with module {!module
+  Eliom.Comet.Configuration}.
 
->>
+{%wodoc:end%}
 
-===Color and size of the brush===
+{2 Color and size of the brush}
 
-<<concepts|
-Widgets with Ocsigen Toolkit\\
-Functional Reactive Programming\\
->>
+{%wodoc:aside class="concepts"%}{b Concepts}
+
+
+Widgets with Ocsigen Toolkit{%html:<br/>%}
+Functional Reactive Programming{%html:<br/>%}
+{%wodoc:end%}
 
 In this section, we add a color picker and slider to choose the size
 of the brush. For the colorpicker we used a widget available in
-<<a_manual project="ocsigen-toolkit" chapter="intro"|Ocsigen Toolkit>>.
+{{:../ocsigen-toolkit/intro.html}Ocsigen Toolkit}.
 
 To install Ocsigen Toolkit, do:
-{{{
+{v
 opam install ocsigen-toolkit
-}}}
+v}
 
-Add package {{{ocsigen-toolkit.server}}} to the {{{libraries}}} section of your {{{dune}}} file, and {{{ocsigen-toolkit.client}}} to the {{{libraries}}} section of your {{{client/dune}}} file.
+Add package [ocsigen-toolkit.server] to the [libraries] section of your [dune] file, and [ocsigen-toolkit.client] to the [libraries] section of your [client/dune] file.
 
-{{{
+{v
   (libraries ... ocsigen-toolkit.server)
-}}}
-{{{
+v}
+{v
   (libraries ... ocsigen-toolkit.client)
-}}}
+v}
 
-In {{{Makefile.options}}}, created by Eliom's distillery, add
-{{{ocsigen-toolkit.server}}} to the {{{SERVER_PACKAGES}}}.
+In [Makefile.options], created by Eliom's distillery, add
+[ocsigen-toolkit.server] to the [SERVER_PACKAGES].
 This will be used to regenerate Ocsigen Server's configuration file.
-<<code language="makefile"|
+{@makefile[
 SERVER_PACKAGES := ... ocsigen-toolkit.server
->>
+]}
 
-To create the widget, we replace {{{page}}} by :
+To create the widget, we replace [page] by :
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server page () =
   let colorpicker, cp_sig =
     Ot.Color_picker.make ~a:[Html.D.a_class ["colorpicker"]] ()
@@ -889,11 +886,12 @@ let%server page () =
                    ; canvas_elt
                    ; colorpicker])
   , cp_sig )
->>
+]}
 
-Replace the registration of {{{main_service}}} by:
+Replace the registration of [main_service] by:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server () =
   Graffiti_app.register ~service:main_service
     (fun () () ->
@@ -901,13 +899,14 @@ let%server () =
       let page, cp_sig = page () in
        let _ = [%client (init_client ~cp_sig:~%cp_sig () : unit) ] in
        Lwt.return page)
->>
+]}
 
 We subsequently add a simple HTML slider to change the size of the
-brush. Near the {{{canvas_elt}}} definition, simply add the following
+brush. Near the [canvas_elt] definition, simply add the following
 code:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server slider =
   Eliom.Content.Html.D.Form.input
     ~a:
@@ -917,9 +916,9 @@ let%server slider =
       ; Html.D.a_input_max (`Number 80)
       ; Html.D.a_value "22" ]
     ~input_type:`Range Html.D.Form.int
->>
+]}
 
-{{{Form.int}}} is a typing information telling that this input takes
+[Form.int] is a typing information telling that this input takes
 an integer value. This kind of input can only be associated to
 services taking an integer as parameter.
 
@@ -927,10 +926,11 @@ We then add the slider to the page body, between the canvas and
 the colorpicker.
 
 To change the size and the color of the brush, we add parameter
-{{{~cp_sig}}} to {{{init_client}}} and modify
-function {{{compute_line}}}:
+[~cp_sig] to [init_client] and modify
+function [compute_line]:
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client init_client ~cp_sig () =
 ...
   let compute_line ev =
@@ -944,13 +944,13 @@ let%client init_client ~cp_sig () =
     (rgb, size, (oldx, oldy), (!x, !y))
   in
 ...
->>
+]}
 
 Finally, we need to add a stylesheet in the headers of our page
-with function <<a_api project="eliom" subproject="server"|
-val Eliom.Tools.D.css_link>>:
+with function {!Eliom.Tools.D.css_link}:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server page () =
   let colorpicker, cp_sig =
     Ot.Color_picker.make ~a:[Html.D.a_class ["colorpicker"]] ()
@@ -972,41 +972,40 @@ let%server page () =
              () ])
       (body [canvas_elt; slider; colorpicker])
   , cp_sig )
->>
+]}
 
 
 You need to install the corresponding stylesheets and images into your
 project. The stylesheet files should go to the directory
-{{{static/css}}}.
-Download file {{{graffiti.css}}} from <<a_file
-  src="tutorial/static/css/graffiti.css"|here>>.
-Copy file {{{ot_color_picker.css}}} from directory
-{{{~/.opam/<version>/share/ocsigen-toolkit/css}}} into {{{static/css}}}.
+[static/css].
+Download file [graffiti.css] from {{:files/tutorial/static/css/graffiti.css}here}.
+Copy file [ot_color_picker.css] from directory
+[~/.opam/<version>/share/ocsigen-toolkit/css] into [static/css].
+
+You can then test your application ([make test.byte]).
 
-You can then test your application ({{{make test.byte}}}).
+{%wodoc:aside class="concept"%}{b Concept: Ocsigen Toolkit}
 
-<<concept
 
-  title="Ocsigen Toolkit" |
 
   Ocsigen Toolkit is a Js_of_ocaml library providing useful
   client-server widgets
   for your Eliom applications. You can use it for building complex
   user interfaces. The full documentation is available
-  (<<a_manual project="ocsigen-toolkit" |Ocsigen Toolkit>>).
+  ({{:../ocsigen-toolkit/.html}Ocsigen Toolkit}).
 
->>
+{%wodoc:end%}
 
-<<concept
+{%wodoc:aside class="concept"%}{b Concept: Functional Reactive Programming}
 
-  title="Functional Reactive Programming" |
 
-  Ocsigen Toolkit is using //Functional Reactive Programming// to
+
+  Ocsigen Toolkit is using {e Functional Reactive Programming} to
   simplify and automatize page changes, through Daniel Bünzli's
   React library.
 
-  For example, {{{Ot.Color_picker.make}}} returns both the element
-  and a //reactive signal// on which you can bind other computations
+  For example, [Ot.Color_picker.make] returns both the element
+  and a {e reactive signal} on which you can bind other computations
   or other page elements, that would be updated automatically when
   the signal value changes.
 
@@ -1014,34 +1013,37 @@ You can then test your application ({{{make test.byte}}}).
   from server side, through module Eliom.Shared.
 
   This basic program does not show the full power of reactive
-  programming, however. See [[wiki:manual/tutoreact|this tutorial]]
+  programming, however. See {{:wiki:manual/tutoreact}this tutorial}
   for a better introduction to reactive programming with Eliom.
 
->>
+{%wodoc:end%}
+
+{2:initial-image Sending the initial image}
 
-===@@Id="initial-image"@@ Sending the initial image===
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-<<concepts|Services sending other data types>>
+Services sending other data types{%wodoc:end%}
 
 To finish the first part of the tutorial, we want to save the current
 drawing on server side and send the current image when a new user
 arrives. To do that, we will use the
-[[https://github.com/Chris00/ocaml-cairo|Cairo binding]] for OCaml.
+{{:https://github.com/Chris00/ocaml-cairo}Cairo binding} for OCaml.
 
 For using Cairo, first, make sure that it is installed (it is
-available as {{{cairo2}}} via OPAM). Second, add it to the
-{{{libraries}}} section in your {{{dune}}} file.
+available as [cairo2] via OPAM). Second, add it to the
+[libraries] section in your [dune] file.
 
 Second, add it to the SERVER_PACKAGES in your Makefile.options:
-<<code language="makefile"|
+{@makefile[
 SERVER_PACKAGES := ... cairo2
->>
+]}
 
-The {{{draw_server}}} function below is the equivalent of the
-{{{draw}}} function on the server side and the {{{image_string}}}
+The [draw_server] function below is the equivalent of the
+[draw] function on the server side and the [image_string]
 function outputs the PNG image in a string.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server draw_server, image_string =
   let rgb_ints_to_floats (r, g, b) =
     float r /. 255., float g /. 255., float b /. 255.
@@ -1068,11 +1070,12 @@ let%server draw_server, image_string =
       Buffer.contents b )
 
 let%server _ = Lwt_stream.iter draw_server (Eliom.Bus.stream bus)
->>
+]}
 
 We also define a service that sends the picture:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server imageservice =
   Eliom.Service.create
     ~path:(Eliom.Service.Path ["image"])
@@ -1082,39 +1085,40 @@ let%server imageservice =
 let%server () =
   Eliom.Registration.String.register ~service:imageservice
     (fun () () -> Lwt.return (image_string (), "image/png"))
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Eliom.Registration}
 
-<<concept
 
-  title="Eliom.Registration"|
 
-  The module {{{Eliom.Registration}}} defines several modules with
+  The module [Eliom.Registration] defines several modules with
   registration and creation functions for a variety of data types.
-  We have already seen {{{Eliom.Registration.Html}}} and {{{Eliom.Registration.App}}}.
-  The module {{{Eliom.Registration.String}}} sends arbitrary byte output
+  We have already seen [Eliom.Registration.Html] and [Eliom.Registration.App].
+  The module [Eliom.Registration.String] sends arbitrary byte output
   (represented by an OCaml string). The handler function must return
   a pair consisting of the content and the content-type.
 
   There are also several other output modules, for example:
 
-* {{{Eliom.Registration.File}}} to send static files
-* {{{Eliom.Registration.Redirection}}} to create a redirection towards another page
-* {{{Eliom.Registration.Any}}} to create services that decide late what
+- [Eliom.Registration.File] to send static files
+- [Eliom.Registration.Redirection] to create a redirection towards another page
+- [Eliom.Registration.Any] to create services that decide late what
 they want to send
-* {{{Eliom.Registration.Ocaml}}} to send any OCaml data to be used in a
+- [Eliom.Registration.Ocaml] to send any OCaml data to be used in a
 client side program
-* {{{Eliom.Registration.Action}}} to create service with no output
+- [Eliom.Registration.Action] to create service with no output
 (the handler function just performs a side effect on the server)
 and reload the current page (or not). We will see an example of actions
 in the next chapter.
 
->>
+{%wodoc:end%}
 
 We now want to load the initial image once the canvas is created.  Add
 the following lines just after the creation of the canvas context
-in {{{init_client}}}:
+in [init_client]:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 (* The initial image: *)
 let img = Eliom.Content.Html.To_dom.of_img
     (img ~alt:"canvas"
@@ -1123,48 +1127,46 @@ let img = Eliom.Content.Html.To_dom.of_img
 in
 img##.onload := Dom_html.handler (fun _ev ->
   ctx##drawImage img 0. 0.; Js._false);
->>
+]}
 
-As we are now using {{{Eliom.Content.Html.D}}} in both client and server sections,
+As we are now using [Eliom.Content.Html.D] in both client and server sections,
 we need to open it in a shared section:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 open%shared Eliom.Content.Html.D
->>
+]}
 
 Finally, we can add a new canvas where we would draw a visualisation of the
 current size  of the brush. The complete code of this application
-can be found [[https://github.com/ocsigen/graffiti/tree/master/simple|here]].
+can be found {{:https://github.com/ocsigen/graffiti/tree/master/simple}here}.
 
-The {{{Makefile}}} from the distillery automatically adds
-the packages defined in {{{SERVER_PACKAGES}}} as an extension in your
-configuration file {{{local/etc/graffiti/graffiti-test.conf}}}:
+The [Makefile] from the distillery automatically adds
+the packages defined in [SERVER_PACKAGES] as an extension in your
+configuration file [local/etc/graffiti/graffiti-test.conf]:
 
-<<code language="xml"|
+{@xml[
 <extension findlib-package="cairo2" />
->>
+]}
 
 The first version of the program is now complete.
 
-<<div class="exercices"|
+{%wodoc:div class="exercices"%}
 
-====Exercises====
+{3 Exercises}
 
-* Add a button that allows download the current
+- Add a button that allows download the current
   image, and saving it to the hard disk (reuse the service
-  {{{imageservice}}}).
-  <<|BB
-    Wrapping my head around the huge oclosure-API offhanded is very hard. A
-    hint on how to register a click-listener with the button would help.
-  >>
-* Add a button with a color picker to select a color from the
+  [imageservice]).
+  
+- Add a button with a color picker to select a color from the
   drawing. Pressing the button changes the mouse cursor, and disables
   current mouse events until the next mouse click event on the
   document.  Then the color palette changes to the color of the pixel
-  clicked.  (Use the function {{{Dom_html.pixel_get}}}).
+  clicked.  (Use the function [Dom_html.pixel_get]).
 
->>
+{%wodoc:end%}
 
 If you want to continue learning client-server programming with Eliom
 and build your first application, we suggest to read
-[[wiki:manual/start|the tutorial about Ocsigen Start]].
+{{:wiki:manual/start}the tutorial about Ocsigen Start}.
diff --git a/tutos/dev/manual/basics-server.wiki b/tutos/dev/manual/basics-server.mld
similarity index 52%
rename from tutos/dev/manual/basics-server.wiki
rename to tutos/dev/manual/basics-server.mld
index 2961aa5c..2526a771 100644
--- a/tutos/dev/manual/basics-server.wiki
+++ b/tutos/dev/manual/basics-server.mld
@@ -1,4 +1,4 @@
-=Server-side website programming guide=
+{0 Server-side website programming guide}
 
 While Eliom is well known for its unique client-server programming
 model, it is also perfectly suited to programming more traditional
@@ -14,26 +14,30 @@ sessions or continuation-based Web programming.
 Programming with Eliom will make your website ready for future
 evolutions by allowing you to introduce progressively client-side
 features like event handlers, fully in OCaml. You will even be able to
-turn your website into a [[basics|distributed client-server Web app]],
+turn your website into a {{:basics.html}distributed client-server Web app},
 and even a mobile app if needed in the future, without having to rewrite
 anything.
 
-<<outline| <<header| **Table of contents** >> >>
 
-<<section class="docblock" |
-<<header |==OCaml==>>
 
-This programming guide assumes you know the //OCaml// language.
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 OCaml}
+{%wodoc:end%}
+
+This programming guide assumes you know the {e OCaml} language.
 Many resources and books are available online.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Lwt==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Lwt}
+{%wodoc:end%}
 
-//Lwt// is a concurrent programming library for OCaml, initially written
+{e Lwt} is a concurrent programming library for OCaml, initially written
 by Jérôme Vouillon in 2001 for the
-[[https://github.com/bcpierce00/unison|Unison]] file synchronizer.
+{{:https://github.com/bcpierce00/unison}Unison} file synchronizer.
 It provides an alternative to the more usual preemptive threads approach
 for programming concurrent applications, that avoids most problems of concurrent
 data access and deadlocks.
@@ -41,29 +45,31 @@ It is used by Ocsigen Server and Eliom and has now become one of the
 standard ways to implement concurrent applications in OCaml.
 All your Web sites must be written in Lwt-compatible way!
 
-<<div class="focused"|
-===How it works===
-Instead of calling blocking functions, like {{{Unix.sleep}}}
-or {{{Unix.read}}}, that could block the entire program, replace them
-by their cooperative counterparts ({{{Lwt_unix.sleep}}},
-{{{Lwt_unix.read}}}, etc.). Instead of taking time to execute,
-they always return immediately a //promise// of the result,
-of type {{{'a Lwt.t}}}. This type is abstract, and the only way
-to use the result is to //bind// a function to the promise.
-{{{Lwt.bind p f}}} means: "when promise {{{p}}} is completed, give its result
-to function {{{f}}}".
-
-Syntax {{{let%lwt x = p in e}}} is equivalent to {{{Lwt.bind p (fun x -> e)}}}
+{%wodoc:div class="focused"%}
+{2 How it works}
+Instead of calling blocking functions, like [Unix.sleep]
+or [Unix.read], that could block the entire program, replace them
+by their cooperative counterparts ([Lwt_unix.sleep],
+[Lwt_unix.read], etc.). Instead of taking time to execute,
+they always return immediately a {e promise} of the result,
+of type ['a Lwt.t]. This type is abstract, and the only way
+to use the result is to {e bind} a function to the promise.
+[Lwt.bind p f] means: "when promise [p] is completed, give its result
+to function [f]".
+
+Syntax [let%lwt x = p in e] is equivalent to [Lwt.bind p (fun x -> e)]
 and makes it very natural to sequentialize computations without blocking the rest
 of the program.
->>
+{%wodoc:end%}
 
-To learn Lwt, read this [[lwt|short tutorial]], or its [[wiki("lwt"):|user manual]].
+To learn Lwt, read this {{:lwt.html}short tutorial}, or its {{:../lwt/}user manual}.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Ocsigen Server: A full featured extensible Web server in OCaml==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Ocsigen Server: A full featured extensible Web server in OCaml}
+{%wodoc:end%}
 Ocsigen Server can be used either as a library for you OCaml programs, or as
 an executable, taking its configuration from a file (and with dynamic linking).
 
@@ -72,50 +78,50 @@ to serve static files, Deflatemod to compress the output, Redirectmod to
 configure redirections etc.
 
 Install Ocsigen Server with:
-{{{
+{v
 opam install ocsigenserver
-}}}
+v}
 
-===Use as a library===
+{2 Use as a library}
 
 Let's create a new OCaml project with Dune:
-{{{
+{v
 dune init project mysite
-}}}
+v}
 
 To include a Web server in your OCaml program, just add
-package {{{ocsigenserver}}} to your Dune file, together with all the extensions
-you need. For example, modify file {{{bin/dune}}} like this:
+package [ocsigenserver] to your Dune file, together with all the extensions
+you need. For example, modify file [bin/dune] like this:
 
-{{{
+{v
 (executable
  (public_name mysite)
  (name main)
  (libraries
   ocsigenserver
   ocsigenserver.ext.staticmod))
-}}}
+v}
 
 The following command will launch a server, serving static files from 
-directory {{{static}}}:
-<<code language="ocaml"|
+directory [static]:
+{@ocaml[
 let () = 
   Ocsigen.Server.start [ Ocsigen.Server.host [Staticmod.run ~dir:"static" ()]]
->>
-Put this in file {{{bin/main.ml}}}, and run {{{dune exec mysite}}}.
+]}
+Put this in file [bin/main.ml], and run [dune exec mysite].
 
-By default, the server runs on port 8080. Create a {{{static}}} directory
+By default, the server runs on port 8080. Create a [static] directory
 with some files and try to fetch them using your Web browser.
 
-===Use as an executable===
-Alternatively, you can run command {{{ocsigenserver}}} with a configuration
+{2 Use as an executable}
+Alternatively, you can run command [ocsigenserver] with a configuration
 file:
-{{{
+{v
 ocsigenserver -c mysite.conf
-}}}
+v}
 
 The following configuration file corresponds to the program above:
-{{{
+{v
 <ocsigen>
   <server>
     <port>8080</port>
@@ -125,27 +131,29 @@ The following configuration file corresponds to the program above:
     </host>
   </server>
 </ocsigen>
-}}}
+v}
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Eliom: Services==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Eliom: Services}
+{%wodoc:end%}
 The following code shows how to create a service that answers
-for requests at URL {{{http://.../aaa/bbb}}}, by invoking an
-Ocaml function {{{f}}} of type:
+for requests at URL [http://.../aaa/bbb], by invoking an
+Ocaml function [f] of type:
 
-<<code language="ocaml" |
+{@ocaml[
 
  f : (string * string) list -> unit -> string Lwt.t
 
->>
+]}
 
-Function {{{f}}} generates HTML as a string, taking as first argument the list
+Function [f] generates HTML as a string, taking as first argument the list
 of URL parameters (GET parameters), and as second argument the list of POST
 parameters (here none).
 
-<<code language="ocaml" |
+{@ocaml[
 
 let f _ () =
   Lwt.return "<html><head><title>Hello world</title></head><body>Welcome</body></html>"
@@ -160,47 +168,49 @@ let () =
   Eliom.Registration.Html_text.register
     ~service:myservice
     f
->>
+]}
 
-{{{Eliom.Service.Get Eliom.Parameter.any}}} means that the service uses the GET HTTP method
-and takes any GET parameter. The first parameter of function {{{f}}} is an association list of GET parameters.
+[Eliom.Service.Get Eliom.Parameter.any] means that the service uses the GET HTTP method
+and takes any GET parameter. The first parameter of function [f] is an association list of GET parameters.
 
-Module {{{Eliom.Registration.Html_text}}} is used to register a service sending
+Module [Eliom.Registration.Html_text] is used to register a service sending
 HTML as strings. But we recommend to used typed-HTML instead (see below).
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Compiling==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Compiling}
+{%wodoc:end%}
 
-In this section, we will show how to compile and run a //server-side only// Web site by creating your project manually.
+In this section, we will show how to compile and run a {e server-side only} Web site by creating your project manually.
 
-===Build an executable===
+{2 Build an executable}
 This section shows how to create a static executable for you program
 (without configuration file).
 
 Run the following command:
-{{{
+{v
 opam install ocsipersist-sqlite-config eliom
 dune init project --kind=executable mysite
 cd mysite
-}}}
+v}
 
 Create the directories will we use for data (logs, etc.):
-{{{
+{v
 mkdir -p local/var/log/mysite
 mkdir -p local/var/data/mysite
 mkdir -p local/var/run
-}}}
+v}
 
-Add packages {{{ocsipersist-sqlite}}} and {{{eliom.server}}} to file
-{{{bin/dune}}}, in the "libraries" section.
+Add packages [ocsipersist-sqlite] and [eliom.server] to file
+[bin/dune], in the "libraries" section.
 
-Copy the definition and registration of service {{{myservice}}} at the beginning 
-of file {{{bin/main.ml}}},
-and replace the call to {{{Ocsigen.Server.start}}} by the following lines:
+Copy the definition and registration of service [myservice] at the beginning 
+of file [bin/main.ml],
+and replace the call to [Ocsigen.Server.start] by the following lines:
 
-<<code language="ocaml"|
+{@ocaml[
 let () = 
   Ocsigen.Server.start
     ~command_pipe:"local/var/run/mysite-cmd"
@@ -211,45 +221,45 @@ let () =
        [ Staticmod.run ~dir:"local/var/www/mysite" ()
        ; Eliom.App.run () ]
     ]
->>
+]}
 
 Build and execute the program with:
-{{{
+{v
 dune exec mysite
-}}}
+v}
 
-Open URL {{{http://localhost:8080/aaa/bbb}}} with your browser.
+Open URL [http://localhost:8080/aaa/bbb] with your browser.
 
-===Use with ocsigenserver===
+{2 Use with ocsigenserver}
 Alternatively, you can decide to build your Eliom app as a library and 
 load it dynamically into ocsigenserver using a configuration file.
 
-{{{
+{v
 opam install ocsipersist-sqlite-config eliom
 dune init proj --kind=lib mysite
 cd mysite
-}}}
+v}
 
-Add {{{(libraries eliom.server)}}} into file {{{lib/dune}}}.
+Add [(libraries eliom.server)] into file [lib/dune].
 
 Create the directories will we use for data (logs, etc.):
-{{{
+{v
 mkdir -p local/var/log/mysite
 mkdir -p local/var/data/mysite
 mkdir -p local/var/run
-}}}
+v}
 
-Create your {{{.ml}}} files in directory {{{lib}}}.
-For example, copy the definition and registration of service {{{myservice}}} above.
+Create your [.ml] files in directory [lib].
+For example, copy the definition and registration of service [myservice] above.
 
 Compile:
-{{{
+{v
 dune build
-}}}
+v}
 
-Create a configuration file {{{mysite.conf}}}
+Create a configuration file [mysite.conf]
 with this content on your project root directory:
-{{{
+{v
 <ocsigen>
   <server>
     <port>8080</port>
@@ -269,55 +279,48 @@ with this content on your project root directory:
     </host>
   </server>
 </ocsigen>
-}}}
+v}
 Launch the application:
-{{{
+{v
 ocsigenserver -c mysite.conf
-}}}
-Open URL {{{http://localhost:8080/aaa/bbb}}} with your browser.
->>
+v}
+Open URL [http://localhost:8080/aaa/bbb] with your browser.
+{%wodoc:end%}
 
 
-<<section class="docblock" |
-<<header |==TyXML: typing HTML==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 TyXML: typing HTML}
+{%wodoc:end%}
 
 TyXML statically checks that your OCaml functions will never
 generate wrong HTML. For example a program that could generate a paragraph
 containing another paragraph will be rejected at compile time.
 
 Example of use:
-<<code language="ocaml"|
+{@ocaml[
 let open Eliom.Content.Html.F in
 html
   (head (title (txt "Ex")) [])
   (body [h1 ~a:[a_id "toto"; a_class ["blah"; "blih"]]
            [txt "Hallo!"]])
->>
+]}
 
-<<|From Eliom > 2.2
-(you can also use <<a_api project="eliom" subproject="server"|val Eliom.Tools.F.html> > to ease the creation of the {{{head}}} tag.)
 
-(Eliom.Tools.F.head
-    ~title:"Hello"
-    ~css:[["css";"style.css"]]
-    ~js:[["libjs";"mylib.js"];
-         ["libjs";"otherlib.js"]]
-    ())
->>
 
 
-<<div class="focused"|
-===How it works===
+{%wodoc:div class="focused"%}
+{2 How it works}
 
 TyXML builds the page as an OCaml data-structure using a construction function
 for each HTML tag. These functions take as parameters and return nodes
-of type {{{'a elt}}} where {{{'a}}} is a polymorphic variant type added in the
+of type ['a elt] where ['a] is a polymorphic variant type added in the
 module signature to constrain usage (phantom type).
->>
+{%wodoc:end%}
 
-===Example of typing error===
+{2 Example of typing error}
 
-<<code language="ocaml"|
+{@ocaml[
 p [p [txt "Aïe"]]
    ^^^^^^^^^^^^^
 Error: This expression has type
@@ -339,17 +342,19 @@ Error: This expression has type
             ...
             | `Wbr ]
        The second variant type does not allow tag(s) `P
->>
-Read more about TyXML in this [[html|short tutorial]] or in its [[wiki("tyxml"):|user manual]].
+]}
+Read more about TyXML in this {{:html.html}short tutorial} or in its {{:../tyxml/}user manual}.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Eliom: Service returning typed HTML==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Eliom: Service returning typed HTML}
+{%wodoc:end%}
 
-To use typed HTML, just replace module {{{Eliom.Registration.Html_text}}}
-by  {{{Eliom.Registration.Html}}}:
-<<code language="ocaml" |
+To use typed HTML, just replace module [Eliom.Registration.Html_text]
+by  [Eliom.Registration.Html]:
+{@ocaml[
 
 let f _ () =
   Lwt.return
@@ -366,73 +371,79 @@ let () =
   Eliom.Registration.Html.register
     ~service:myservice
     f
->>
+]}
 
-===Outputs===
+{2 Outputs}
 
 Services can return a typed HTML page as in the example above, but also
 any other kind of result. To choose the return type, use the register function
 from the corresponding submodule of
-<<a_api project="eliom" | module Eliom.Registration >>:
-
-<<div id="servicetable"|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Html"| module Eliom.Registration.Html >>|@@colspan="3"@@Services returning typed HTML pages|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Html_text"| module Eliom.Registration.Html >>|@@colspan="3"@@Services returning untyped HTML pages as strings|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="App"| module Eliom.Registration.ELIOM_APPL >>|@@colspan="3"@@Apply this functor to generate registration functions for services belonging to an Eliom client/server application. These services also return typed HTML pages, but Eliom will automatically add the client-side program as a JS file, and all the data needed (values of all injections, etc.)|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Flow"| module Eliom.Registration.Flow5 >>|@@colspan="3"@@Services returning portions of HTML pages.|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Action"| module Eliom.Registration.Action >>|@@colspan="3"@@Services performing actions (server side effects) with or without reloading the page (e.g. login, logout, payment, modification of user information...)|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Files"| module Eliom.Registration.File >>|@@colspan="3"@@Serve files from the server hard drive|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Ocaml"| module Eliom.Registration.Ocaml >>|@@colspan="3"@@Services returning OCaml values to be sent to a client side OCaml program (this kind of services is used as low level interface for server functions -- see below)|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="String"| module Eliom.Registration.String >>|@@colspan="3"@@Services returning any OCaml string (array of byte)|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Redirection"| module Eliom.Registration.Redirection >>|@@colspan="3"@@Services returning an HTTP redirection to another service|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Any"| module Eliom.Registration.Any >>|@@colspan="3"@@To be used to make the service chose what it sends. Call function {{{send}}} from the corresponding module to choose the output.|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Customize"| module Eliom.Registration.Customize >>|@@colspan="3"@@Apply this functor to define your own registration module|
->>
->>
-
-<<section class="docblock" |
-<<header |==Eliom: Typing page parameters==>>
-
-Instead of taking GET parameters as an untyped {{{string * string}}}
+{!Eliom.Registration}:
+
+{%wodoc:div%}
+{t
+ | {{!Eliom.Registration.Html}Html} | Services returning typed HTML pages |
+ | {{!Eliom.Registration.Html}Html_text} | Services returning untyped HTML pages as strings |
+ | {{!Eliom.Registration.ELIOM_APPL}App} | Apply this functor to generate registration functions for services belonging to an Eliom client/server application. These services also return typed HTML pages, but Eliom will automatically add the client-side program as a JS file, and all the data needed (values of all injections, etc.) |
+ | {{!Eliom.Registration.Flow5}Flow} | Services returning portions of HTML pages. |
+ | {{!Eliom.Registration.Action}Action} | Services performing actions (server side effects) with or without reloading the page (e.g. login, logout, payment, modification of user information...) |
+ | {{!Eliom.Registration.File}Files} | Serve files from the server hard drive |
+ | {{!Eliom.Registration.Ocaml}Ocaml} | Services returning OCaml values to be sent to a client side OCaml program (this kind of services is used as low level interface for server functions -- see below) |
+ | {{!Eliom.Registration.String}String} | Services returning any OCaml string (array of byte) |
+ | {{!Eliom.Registration.Redirection}Redirection} | Services returning an HTTP redirection to another service |
+ | {{!Eliom.Registration.Any}Any} | To be used to make the service chose what it sends. Call function [send] from the corresponding module to choose the output. |
+ | {{!Eliom.Registration.Customize}Customize} | Apply this functor to define your own registration module |
+}
+{%wodoc:end%}
+{%wodoc:end%}
+
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Eliom: Typing page parameters}
+{%wodoc:end%}
+
+Instead of taking GET parameters as an untyped [string * string]
 association list, you can ask Eliom to decode and check parameter types
 automatically.
 
-For example, the following code defines a service at URL {{{/foo}}},
-that will use GET HTTP method, and take one parameter of type {{{string}}},
-named {{{s}}}, and one of type {{{int}}}, named {{{i}}}.
-<<code language="ocaml" class="server"|
+For example, the following code defines a service at URL [/foo],
+that will use GET HTTP method, and take one parameter of type [string],
+named [s], and one of type [int], named [i].
+{%wodoc:@ class=server%}
+{@ocaml[
 let myservice =
   Eliom.Service.create
     ~path:(Eliom.Service.Path ["foo"])
     ~meth:(Eliom.Service.Get (Eliom.Parameter.(string "s" ** int "i")))
     ()
->>
+]}
 
 Then register an OCaml function as handler on this service:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let () =
   Eliom.Registration.Html.register ~service:myservice
     (fun (s, i) () ->
       Lwt.return
          Eliom.Content.Html.F.(html (head (title (txt "")) [])
                                     (body [h1 [txt (s^string_of_int i)]])))
->>
+]}
 
 The handler takes as first parameter the GET page parameters, typed according to
 the parameter specification given while creating the service.
 The second parameter is for POST parameters (see below).
 
-Recompile you program, and to to URL {{{http://localhost:8080/foo?s=hello&i=22}}}
+Recompile you program, and to to URL [http://localhost:8080/foo?s=hello&i=22]
 to see the result.
 
-===Parameters===
+{2 Parameters}
 
-Module <<a_api project="eliom" subproject="server"| module Eliom.Parameter>>
+Module {!Eliom.Parameter}
 is used to describe the type of service parameters.
 
 Examples:
-<<code language="ocaml"|
+{@ocaml[
 Eliom.Parameter.(int "i" ** (string "s" ** bool "b"))
    (* /path?i=42&s=toto&b=on *)
 
@@ -455,114 +466,122 @@ Eliom.Parameter.(suffix (int "year" ** int "month"))
 Eliom.Parameter.(suffix_prod (int "year" ** int "month") (int "a"))
    (* /path/2012/09?a=4 *)
 
->>
+]}
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Eliom: POST services==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Eliom: POST services}
+{%wodoc:end%}
 
-To define a service with POST parameters, just change the {{{~meth}}} parameter.
+To define a service with POST parameters, just change the [~meth] parameter.
 For example the following example takes the same GET parameters as the service
 above, plus one POST parameter of type string, named "mypostparam".
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 ~meth:(Eliom.Service.Post (Eliom.Parameter.((string "s" ** int "i"),
                                             (string "mypostparam"))))
->>
+]}
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Eliom: Other kinds of services==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Eliom: Other kinds of services}
+{%wodoc:end%}
 
-The detailed explanation of services can be found in <<a_manual project="eliom" chapter="server-services" |Eliom's manual>>. Here is a summary:
+The detailed explanation of services can be found in {{:../eliom/server-services.html}Eliom's manual}. Here is a summary:
 
-===Pathless services===
+{2 Pathless services}
 
 Pathless services are not identified by the path in the URL,
 but by a name given as parameter, regardless of the path.
 Use this to make a functionality available from all pages
 (for example: log-in or log-out actions, add something in a shopping basket ...).
 The name can be specified manually
-using the {{{~name}}} optional parameter, otherwise, a random name is
+using the [~name] optional parameter, otherwise, a random name is
 generated automatically.
 This is also used to implement server functions (see below).
 If you are programming a client-server Eliom app, you will often prefer
 remote procedure calls (`let%rpc`).
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let pathless_service =
   Eliom.Service.create
     ~name:"pathless_example"
     ~path:Eliom.Service.No_path
     ~meth:(Eliom.Service.Get (Eliom.Parameter.(int "i")))
     ()
->>
+]}
 
 More information
-<<a_manual project="eliom" chapter="server-services" fragment="pathless"|in the manual>>.
+{{:../eliom/server-services.html#pathless}in the manual}.
 
-===Attached services===
+{2 Attached services}
 It is also possible to create services identified by both a path and a
 special parameter, using functions
-<<a_api project="eliom" subproject="server"| val Eliom.Service.create_attached_get >> or
-<<a_api project="eliom" subproject="server"| val Eliom.Service.create_attached_post >>.
-They take a regular service (with a path) as parameter ({{{~fallback}}}).
+{!Eliom.Service.create_attached_get} or
+{!Eliom.Service.create_attached_post}.
+They take a regular service (with a path) as parameter ([~fallback]).
 
 It is also possible to attach an existing pathless service to the URL of
 another service, with function
-<<a_api project="eliom" subproject="server"| val Eliom.Service.attach >>.
+{!Eliom.Service.attach}.
 This allows for example to create a link towards a pathless service,
 but on another path.
 
-===External services===
-Use <<a_api project="eliom" subproject="server"| val Eliom.Service.extern >> to create
+{2 External services}
+Use {!Eliom.Service.extern} to create
 links or forms towards external Web sites as if they were Eliom services.
 
-===Predefined services===
-Use service <<a_api project="eliom" subproject="server" text="(Eliom.Service.static_dir ())"| val Eliom.Service.static_dir >>
+{2 Predefined services}
+Use service {{!Eliom.Service.static_dir}(Eliom.Service.static_dir ())}
 to create links towards static files (see example below for images).
 
-Use service <<a_api project="eliom" subproject="server"| val Eliom.Service.reload_action >> and its variants to create links or forms towards the current URL (reload the page). From a client section, you can also call <<a_api project="ocsigen-start" subproject="server"| val Os.Lib.reload>> to reload the page and restart the client-side program.
+Use service {!Eliom.Service.reload_action} and its variants to create links or forms towards the current URL (reload the page). From a client section, you can also call {!Os.Lib.reload} to reload the page and restart the client-side program.
 
-<<a_manual project="eliom" chapter="server-services" |Full documentation about services>>, [[interaction|a tutorial about traditional service based Web programming]], API documentation of modules <<a_api project="eliom" subproject="server" | module Eliom.Service>> and <<a_api project="eliom" subproject="server" | module Eliom.Registration>>.
+{{:../eliom/server-services.html}Full documentation about services}, {{:interaction.html}a tutorial about traditional service based Web programming}, API documentation of modules {!Eliom.Service} and {!Eliom.Registration}.
 
-This example shows how to insert an image using {{{static_dir}}}:
-<<code language="ocaml"|img
+This example shows how to insert an image using [static_dir]:
+{@ocaml[img
   ~alt:"blip"
   ~src:(Eliom.Content.Html.F.make_uri
          (Eliom.Service.static_dir ())
          ["dir" ; "image.jpg"])
   ()
->>
+]}
 
->>
+{%wodoc:end%}
 
 
-<<section class="docblock" |
-<<header |==Forms and links==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Forms and links}
+{%wodoc:end%}
 
-Function <<a_api project="eliom" subproject="server" text="Eliom.Content.Html.F.a"|val Eliom_form_sigs.LINKS.a>> creates typed links to services with their parameters.
-For example, if {{{home_service}}} expects no parameter
-and {{{other_service}}} expects a string and an optional int:
-<<code language="ocaml"|
+Function {{!Eliom_form_sigs.LINKS.a}Eliom.Content.Html.F.a} creates typed links to services with their parameters.
+For example, if [home_service] expects no parameter
+and [other_service] expects a string and an optional int:
+{@ocaml[
 Eliom.Content.Html.F.a ~service:home_service [txt "Home"] ()
 Eliom.Content.Html.F.a ~service:other_service [txt "Other"] ("hello", Some 4)
->>
+]}
 
-Module <<a_api project="eliom" subproject="server" |module Eliom.Content.Html.F>>
+Module {!Eliom.Content.Html.F}
 defines the form's elements with the usual typed interface from TyXML.
 Use this for example if you have a client side program and
 want to manipulate the form's content from client side functions
 (for example do a server function call with the form's elements' content).
 
 In contrast,
-module <<a_api project="eliom" subproject="server" text="Eliom.Content.Html.F.Form"|module Eliom.Content_sigs.LINKS_AND_FORMS.Form>> defines a typed interface
+module {{!Eliom.Content_sigs.LINKS_AND_FORMS.Form}Eliom.Content.Html.F.Form} defines a typed interface
 for form elements. Use this for links (see above), or if you program traditional
 server-side Web interaction (with or without client-side program). This will statically check that your forms
 match the services. Example:
 
-<<code language="ocaml"|
+{@ocaml[
 let open Eliom.Content.Html.F in
 Form.post_form
  ~service:connection_service
@@ -580,111 +599,125 @@ Form.post_form
         Form.input ~input_type:`Submit ~value:"Connect" Form.string
       ]]) ()
 
->>
+]}
 
 As you can see, function
-<<a_api project="eliom" subproject="server" text="Eliom.Content.Html.F.Form.post_form"|val Eliom.Content_sigs.LINKS_AND_FORMS.Form.post_form>>
+{{!Eliom.Content_sigs.LINKS_AND_FORMS.Form.post_form}Eliom.Content.Html.F.Form.post_form}
 is used to create a form sending parameters using the POST HTTP method
-(and similarly, <<a_api project="eliom" subproject="server" text="get_form"|val Eliom.Content_sigs.LINKS_AND_FORMS.Form.get_form>> for GET method).
+(and similarly, {{!Eliom.Content_sigs.LINKS_AND_FORMS.Form.get_form}get_form} for GET method).
 It takes the service as first parameter, and a function that will generate the form.
 This function takes the names of the GET or POST parameters as arguments.
 
 Form elements (like inputs) are also built from using the
-<<a_api project="eliom" subproject="server" text="Eliom.Content.Html.F.Form"|module Eliom.Content_sigs.LINKS_AND_FORMS.Form>> module.
-They take the names as parameters, and a last parameter (like {{{Form.int}}} or {{{Form.string}}}) to match the expected type.
+{{!Eliom.Content_sigs.LINKS_AND_FORMS.Form}Eliom.Content.Html.F.Form} module.
+They take the names as parameters, and a last parameter (like [Form.int] or [Form.string]) to match the expected type.
 
->>
+{%wodoc:end%}
 
 
-<<section class="docblock" |
-<<header |==Sessions==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Sessions}
+{%wodoc:end%}
 
-Session data is saved on server side in //Eliom references//.
+Session data is saved on server side in {e Eliom references}.
 
 The following Eliom reference will count the number of visits of a user on a page:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server count_ref =
   Eliom.Reference.eref
     ~scope:Eliom.Common.default_session_scope
     0 (* default value for everyone *)
->>
+]}
 
 And somewhere in your service handler, increment the counter:
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%lwt count = Eliom.Reference.get count_ref in
 Eliom.Reference.set count_ref (count + 1);
 Lwt.return ()
->>
+]}
 
-With function <<a_api project="eliom" subproject="server"|val Eliom.Reference.eref_from_fun>>,
+With function {!Eliom.Reference.eref_from_fun},
 you can create Eliom references without initial value. The initial value is computed for the session
 the first time you use it.
 
 An Eliom reference can be persistant (value saved on hard drive) or volatile (in memory).
 
-===Scopes===
+{2 Scopes}
 Sessions are relative to a browser, and implemented using browser cookies.
-But Eliom allows to create Eliom references with other //scopes// than session:
+But Eliom allows to create Eliom references with other {e scopes} than session:
 
-|<<a_api project="eliom" subproject="server" text="global_scope"| val Eliom.Common.global_scope>>|Global value for all the Web server|
-|<<a_api project="eliom" subproject="server" text="site_scope"| val Eliom.Common.site_scope>>|Global value for the Eliom app in that subsite of the Web site|
-|<<a_api project="eliom" subproject="server" text="default_group_scope"| val Eliom.Common.default_group_scope>>|Value for a group of sessions. For example Ocsigen Start defines a group of session for each user, making it possible to save server side data for all sessions of a user.|
-|<<a_api project="eliom" subproject="server" text="default_session_scope"| val Eliom.Common.default_session_scope>>|The usual session data, based on browser cookies|
-|<<a_api project="eliom" subproject="server" text="default_process_scope"| val Eliom.Common.default_process_scope>>|Server side data for a given client-side process (a tab of the browser or a mobile app). This is available only with a client-server Eliom app.|
+{t
+ | {{!Eliom.Common.global_scope}global_scope} | Global value for all the Web server |
+ | {{!Eliom.Common.site_scope}site_scope} | Global value for the Eliom app in that subsite of the Web site |
+ | {{!Eliom.Common.default_group_scope}default_group_scope} | Value for a group of sessions. For example Ocsigen Start defines a group of session for each user, making it possible to save server side data for all sessions of a user. |
+ | {{!Eliom.Common.default_session_scope}default_session_scope} | The usual session data, based on browser cookies |
+ | {{!Eliom.Common.default_process_scope}default_process_scope} | Server side data for a given client-side process (a tab of the browser or a mobile app). This is available only with a client-server Eliom app. |
+}
 
 Applications based on Ocsigen Start use these scopes for user management.
 Session or client process data are discarded when a user logs in or out.
 But Ocsigen Start also defines scopes
-<<a_api project="ocsigen-start" subproject="server"| val Os.Session.user_indep_session_scope>>
+{!Os.Session.user_indep_session_scope}
 and
-<<a_api project="ocsigen-start" subproject="server"| val Os.Session.user_indep_process_scope>>
+{!Os.Session.user_indep_process_scope}
 which remain even if a user logs in or out.
 
 When session group is not set (for example the user is not connected),
 you can still use the group session scope: in that case, the group contains only
 one session.
 
->>
+{%wodoc:end%}
 
 
-<<section class="docblock" |
-<<header |==Browser events==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Browser events}
+{%wodoc:end%}
 By default, event handlers on HTML elements are given as OCaml functions,
 but it works only if you have a client-server Eliom program.
 If not, you want to give a javascript expression (as a string) instead.
-To so that, use attributes functions from module {{{Raw}}}. For example
-<<a_api project="eliom" subproject="server"| val Eliom.Content.Html.F.Raw.a_onclick>>
+To so that, use attributes functions from module [Raw]. For example
+{!Eliom.Content.Html.F.Raw.a_onclick}
 instead of
-<<a_api project="eliom" subproject="server"| val Eliom.Content.Html.F.a_onclick>>.
+{!Eliom.Content.Html.F.a_onclick}.
 
 Example:
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 Eliom.Content.Html.F.(button ~a:[Raw.onclick "alert(\"beep\");"] [txt "click"])
->>
+]}
 
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Database access==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Database access}
+{%wodoc:end%}
 
 You can use your favourite database library with Ocsigen.
 Ocsigen Start's template uses
-[[https://github.com/darioteixeira/pgocaml|PG'OCaml]]
+{{:https://github.com/darioteixeira/pgocaml}PG'OCaml}
 (typed queries for Postgresql using a PPX syntax extension).
 
 Here is an example, taken from Ocsigen Start's demo:
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let get () =
   full_transaction_block (fun dbh ->
     [%pgsql dbh "SELECT lastname FROM ocsigen_start.users"])
->>
+]}
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Continuation-based Web programming==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Continuation-based Web programming}
+{%wodoc:end%}
 
 Eliom allows the dynamic creation of temporary services.
 This is equivalent to a programming pattern known as "continuation-based
@@ -718,91 +751,96 @@ page for this ticket.
 
 To implement temporary services, we usually use pathless or attached
 services (see above). To avoid a memory leak, you can make them temporary using
-optional parameters of the service creation function ({{{?max_use}}} or {{{?timeout}}}).
+optional parameters of the service creation function ([?max_use] or [?timeout]).
 
->>
+{%wodoc:end%}
 
 
-<<section class="docblock" |
-<<header |==Internationalisation==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Internationalisation}
+{%wodoc:end%}
 
-[[https://github.com/besport/ocsigen-i18n|Ocsigen i18n]]
+{{:https://github.com/besport/ocsigen-i18n}Ocsigen i18n}
 is an internationalisation library for your OCaml programs.
 
 Create a .tsv file with, on each line, a key and the text in several languages:
 
-{{{
+{v
 welcome_message Welcome everybody!        Bienvenue à tous !      Benvenuti a tutti !
-}}}
+v}
 
 and Ocsigen i18n will automatically generate functions like this one:
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%shared welcome_message ?(lang = get_language ()) () () =
   match lang with
   | En -> [txt "Welcome everybody!"]
   | Fr -> [txt "Bienvenue à tous !"]
   | It -> [txt "Benvenuti a tutti !"]
->>
+]}
 
 Ocsigen i18n also defines a syntax extension to use these functions:
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
   Eliom.Content.Html.F.h1 [%i18n welcome_message]
->>
+]}
 
 Ocsigen i18n offers many other features:
-* Text can be inserted as a TyXML node (as in the example above) or as a string (ex: {{{[%i18n S.welcome_message]}}}),
-* Text can be parametrizable, or contain holes (ex: {{{[%i18n welcome ~capitalize:true ~name:"William"]}}})
-* .tsv file can be split into several modules
+- Text can be inserted as a TyXML node (as in the example above) or as a string (ex: [[%i18n S.welcome_message]]),
+- Text can be parametrizable, or contain holes (ex: [[%i18n welcome ~capitalize:true ~name:"William"]])
+- .tsv file can be split into several modules
 
 Have a look at the
-[[https://github.com/besport/ocsigen-i18n|README file]]
+{{:https://github.com/besport/ocsigen-i18n}README file}
 to see the full documentation,
 and see examples in
-[[https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/demo_i18n.eliom|Ocsigen Start's template]].
+{{:https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/demo_i18n.eliom}Ocsigen Start's template}.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Ocsigen Server==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Ocsigen Server}
+{%wodoc:end%}
 
-//Ocsigen Server// is a full featured Web server.
+{e Ocsigen Server} is a full featured Web server.
 
-It is now based on [[https://github.com/mirage/ocaml-cohttp|Cohttp]].
+It is now based on {{:https://github.com/mirage/ocaml-cohttp}Cohttp}.
 
 It has a powerful
 extension mechanism that makes it easy to plug your own OCaml modules
 for generating pages. Many extensions are already written:
-;<<a_manual project="ocsigenserver" chapter="staticmod"|Staticmod>>
+;{{:../ocsigenserver/staticmod.html}Staticmod}
 :    to serve static files.
-;[[wiki("eliom"):|Eliom]]
+;{{:../eliom/}Eliom}
 :    to create reliable client/server Web applications
      or Web sites in OCaml using advanced high level concepts.
-;<<a_manual project="ocsigenserver" chapter="extendconfiguration"|Extendconfiguration>>
+;{{:../ocsigenserver/extendconfiguration.html}Extendconfiguration}
 :    allows for more options in the configuration file.
-;<<a_manual project="ocsigenserver" chapter="accesscontrol"|Accesscontrol>>
+;{{:../ocsigenserver/accesscontrol.html}Accesscontrol}
 :    restricts access to the sites from the config file (to requests coming from a subnet, containing some headers, etc.).
-;<<a_manual project="ocsigenserver" chapter="authbasic"|Authbasic>>
+;{{:../ocsigenserver/authbasic.html}Authbasic}
 :    restricts access to the sites from the config file using Basic HTTP Authentication.
-;<<a_manual project="ocsigenserver" chapter="cgimod"|CGImod>>
+;{{:../ocsigenserver/cgimod.html}CGImod}
 :    serves CGI scripts. It may also be used to serve PHP through CGI.
-;<<a_manual project="ocsigenserver" chapter="deflatemod"|Deflatemod>>
+;{{:../ocsigenserver/deflatemod.html}Deflatemod}
 :    used to compress data before sending it to the client.
-;<<a_manual project="ocsigenserver" chapter="redirectmod"|Redirectmod>>
+;{{:../ocsigenserver/redirectmod.html}Redirectmod}
 :    sets redirections towards other Web sites from the configuration file.
-;<<a_manual project="ocsigenserver" chapter="revproxy"|Revproxy>>
+;{{:../ocsigenserver/revproxy.html}Revproxy}
 :    a reverse proxy for Ocsigen Server.
       It allows to ask another server to handle the request.
-;<<a_manual project="ocsigenserver" chapter="rewritemod"|Rewritemod>>
+;{{:../ocsigenserver/rewritemod.html}Rewritemod}
 :    changes incoming requests before sending them to other extensions.
-;<<a_manual project="ocsigenserver" chapter="outputfilter"|Outputfilter>>
+;{{:../ocsigenserver/outputfilter.html}Outputfilter}
 :    rewrites some parts of the output before sending it to the client.
-;<<a_manual project="ocsigenserver" chapter="userconf"|Userconf>>
+;{{:../ocsigenserver/userconf.html}Userconf}
 :    allows users to have their own configuration files.
-;<<a_manual project="ocsigenserver" chapter="comet"|Comet>>
+;{{:../ocsigenserver/comet.html}Comet}
 :    facilitates server to client communications.
 
-Ocsigen Server has a <<a_manual project="ocsigenserver"
-chapter="config"|sophisticated configuration>> file mechanism allowing
+Ocsigen Server has a {{:../ocsigenserver/config.html}sophisticated configuration} file mechanism allowing
 complex configurations of sites.
 
->>
+{%wodoc:end%}
diff --git a/tutos/dev/manual/basics.wiki b/tutos/dev/manual/basics.mld
similarity index 52%
rename from tutos/dev/manual/basics.wiki
rename to tutos/dev/manual/basics.mld
index 44427d1c..fd7b6cd0 100644
--- a/tutos/dev/manual/basics.wiki
+++ b/tutos/dev/manual/basics.mld
@@ -1,4 +1,4 @@
-=Client-server application programming guide=
+{0 Client-server application programming guide}
 
 This tutorial has been tested with Eliom 11.0.0.
 
@@ -7,43 +7,47 @@ with Ocsigen. Use it as your training plan or as a cheat sheet while programming
 
 Depending on your needs, you may not need to learn all this. Ocsigen is
 very flexible and can be used both for Web site programming (see
-[[basics-server|this page]]) or more complex client-server Web apps and
+{{:basics-server.html}this page}) or more complex client-server Web apps and
 their mobile counterparts.
 
 In parallel to the reading of that page,
-we recommend to generate your first [[wiki("ocsigen-start"):|Ocsigen Start]] app to see
-running examples of all these concepts (see [[start|that page]]).
+we recommend to generate your first {{:../ocsigen-start/}Ocsigen Start} app to see
+running examples of all these concepts (see {{:start.html}that page}).
 
-<<div class="quickstart-block"|
-**Too long; didn't read? Get your first app running in 3 minutes:**
-{{{
+{%wodoc:div class="quickstart-block"%}
+{b Too long; didn't read? Get your first app running in 3 minutes:}
+{v
 opam install ocsigen-start
 eliom-distillery -name myapp -template os
 cd myapp
 make db-init && make db-create && make db-schema
 make test.byte
-}}}
-Then open {{{http://localhost:8080}}}. \\
-Requires {{{postgresql}}} and {{{sass}}} (or {{{sassc}}}).
-Read the [[start|detailed instructions]] if needed.
->>
+v}
+Then open [http://localhost:8080]. {%html:<br/>%}
+Requires [postgresql] and [sass] (or [sassc]).
+Read the {{:start.html}detailed instructions} if needed.
+{%wodoc:end%}
 
-<<outline| <<header| **Table of contents** >> >>
 
-<<section class="docblock" |
-<<header |==OCaml==>>
 
-This programming guide assumes you know the //OCaml// language.
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 OCaml}
+{%wodoc:end%}
+
+This programming guide assumes you know the {e OCaml} language.
 Many resources and books are available online.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Lwt==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Lwt}
+{%wodoc:end%}
 
-//Lwt// is a concurrent programming library for OCaml, initially written
+{e Lwt} is a concurrent programming library for OCaml, initially written
 by Jérôme Vouillon in 2001 for the
-[[https://github.com/bcpierce00/unison|Unison]] file synchronizer.
+{{:https://github.com/bcpierce00/unison}Unison} file synchronizer.
 It provides an alternative to the more usual preemptive threads approach
 for programming concurrent applications, that avoids most problems of concurrent
 data access and deadlocks.
@@ -51,29 +55,31 @@ It is used by Ocsigen Server and Eliom and has now become one of the
 standard ways to implement concurrent applications in OCaml.
 All your Web sites must be written in Lwt-compatible way!
 
-<<div class="focused"|
-===How it works===
-Instead of calling blocking functions, like {{{Unix.sleep}}}
-or {{{Unix.read}}}, that could block the entire program, replace them
-by their cooperative counterparts ({{{Lwt_unix.sleep}}},
-{{{Lwt_unix.read}}}, etc.). Instead of taking time to execute,
-they always return immediately a //promise// of the result,
-of type {{{'a Lwt.t}}}. This type is abstract, and the only way
-to use the result is to //bind// a function to the promise.
-{{{Lwt.bind p f}}} means: "when promise {{{p}}} is completed, give its result
-to function {{{f}}}".
-
-Syntax {{{let%lwt x = p in e}}} is equivalent to {{{Lwt.bind p (fun x -> e)}}}
+{%wodoc:div class="focused"%}
+{2 How it works}
+Instead of calling blocking functions, like [Unix.sleep]
+or [Unix.read], that could block the entire program, replace them
+by their cooperative counterparts ([Lwt_unix.sleep],
+[Lwt_unix.read], etc.). Instead of taking time to execute,
+they always return immediately a {e promise} of the result,
+of type ['a Lwt.t]. This type is abstract, and the only way
+to use the result is to {e bind} a function to the promise.
+[Lwt.bind p f] means: "when promise [p] is completed, give its result
+to function [f]".
+
+Syntax [let%lwt x = p in e] is equivalent to [Lwt.bind p (fun x -> e)]
 and makes it very natural to sequentialize computations without blocking the rest
 of the program.
->>
+{%wodoc:end%}
 
-To learn Lwt, read this [[lwt|short tutorial]], or its [[wiki("lwt"):|user manual]].
+To learn Lwt, read this {{:lwt.html}short tutorial}, or its {{:../lwt/}user manual}.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Ocsigen Server: A full featured extensible Web server in OCaml==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Ocsigen Server: A full featured extensible Web server in OCaml}
+{%wodoc:end%}
 Ocsigen Server can be used either as a library for you OCaml programs, or as
 an executable, taking its configuration from a file (and with dynamic linking).
 
@@ -82,50 +88,50 @@ to serve static files, Deflatemod to compress the output, Redirectmod to
 configure redirections etc.
 
 Install Ocsigen Server with:
-{{{
+{v
 opam install ocsigenserver
-}}}
+v}
 
-===Use as a library===
+{2 Use as a library}
 
 Let's create a new OCaml project with Dune:
-{{{
+{v
 dune init project mysite
-}}}
+v}
 
 To include a Web server in your OCaml program, just add
-package {{{ocsigenserver}}} to your Dune file, together with all the extensions
-you need. For example, modify file {{{bin/dune}}} like this:
+package [ocsigenserver] to your Dune file, together with all the extensions
+you need. For example, modify file [bin/dune] like this:
 
-{{{
+{v
 (executable
  (public_name mysite)
  (name main)
  (libraries
   ocsigenserver
   ocsigenserver.ext.staticmod))
-}}}
+v}
 
 The following command will launch a server, serving static files from 
-directory {{{static}}}:
-<<code language="ocaml"|
+directory [static]:
+{@ocaml[
 let () = 
   Ocsigen.Server.start [ Ocsigen.Server.host [Staticmod.run ~dir:"static" ()]]
->>
-Put this in file {{{bin/main.ml}}}, and run {{{dune exec mysite}}}.
+]}
+Put this in file [bin/main.ml], and run [dune exec mysite].
 
-By default, the server runs on port 8080. Create a {{{static}}} directory
+By default, the server runs on port 8080. Create a [static] directory
 with some files and try to fetch them using your Web browser.
 
-===Use as an executable===
-Alternatively, you can run command {{{ocsigenserver}}} with a configuration
+{2 Use as an executable}
+Alternatively, you can run command [ocsigenserver] with a configuration
 file:
-{{{
+{v
 ocsigenserver -c mysite.conf
-}}}
+v}
 
 The following configuration file corresponds to the program above:
-{{{
+{v
 <ocsigen>
   <server>
     <port>8080</port>
@@ -135,50 +141,43 @@ The following configuration file corresponds to the program above:
     </host>
   </server>
 </ocsigen>
-}}}
+v}
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==TyXML: typing HTML==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 TyXML: typing HTML}
+{%wodoc:end%}
 
 TyXML statically checks that your OCaml functions will never
 generate wrong HTML. For example a program that could generate a paragraph
 containing another paragraph will be rejected at compile time.
 
 Example of use:
-<<code language="ocaml"|
+{@ocaml[
 let open Eliom.Content.Html.D in
 html
   (head (title (txt "Ex")) [])
   (body [h1 ~a:[a_id "toto"; a_class ["blah"; "blih"]]
            [txt "Hallo!"]])
->>
+]}
 
-<<|From Eliom > 2.2
-(you can also use <<a_api project="eliom" subproject="server"|val Eliom.Tools.D.html> > to ease the creation of the {{{head}}} tag.)
 
-(Eliom.Tools.F.head
-    ~title:"Hello"
-    ~css:[["css";"style.css"]]
-    ~js:[["libjs";"mylib.js"];
-         ["libjs";"otherlib.js"]]
-    ())
->>
 
 
-<<div class="focused"|
-===How it works===
+{%wodoc:div class="focused"%}
+{2 How it works}
 
 TyXML builds the page as an OCaml data-structure using a construction function
 for each HTML tag. These functions take as parameters and return nodes
-of type {{{'a elt}}} where {{{'a}}} is a polymorphic variant type added in the
+of type ['a elt] where ['a] is a polymorphic variant type added in the
 module signature to constrain usage (phantom type).
->>
+{%wodoc:end%}
 
-===Example of typing error===
+{2 Example of typing error}
 
-<<code language="ocaml"|
+{@ocaml[
 p [p [txt "Aïe"]]
    ^^^^^^^^^^^^^
 Error: This expression has type
@@ -200,72 +199,78 @@ Error: This expression has type
             ...
             | `Wbr ]
        The second variant type does not allow tag(s) `P
->>
-Read more about TyXML in this [[html|short tutorial]] or in its [[wiki("tyxml"):|user manual]].
+]}
+Read more about TyXML in this {{:html.html}short tutorial} or in its {{:../tyxml/}user manual}.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Eliom: Services==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Eliom: Services}
+{%wodoc:end%}
 
-Pages are generated by //services//.
+Pages are generated by {e services}.
 Eliom provides a very simple (yet extremely powerful) service creation and identification mechanism.
 
-To create a service, call <<a_api project="eliom" subproject="server"| val Eliom.Service.create>>.
-For example, the following code defines a service at URL {{{/foo}}},
-that will use GET HTTP method, and take one parameter of type {{{string}}},
-named {{{myparam}}}, and one of type {{{int}}}, named {{{i}}}.
-<<code language="ocaml" class="server"|
+To create a service, call {!Eliom.Service.create}.
+For example, the following code defines a service at URL [/foo],
+that will use GET HTTP method, and take one parameter of type [string],
+named [myparam], and one of type [int], named [i].
+{%wodoc:@ class=server%}
+{@ocaml[
 let myservice =
   Eliom.Service.create
     ~path:(Eliom.Service.Path ["foo"])
     ~meth:(Eliom.Service.Get (Eliom.Parameter.(string "myparam" ** int "i")))
     ()
->>
+]}
 
 Then register an OCaml function as handler on this service:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let () =
   Eliom.Registration.Html.register ~service:myservice
     (fun (myparam, _i) () ->
       Lwt.return
          Eliom.Content.Html.F.(html (head (title (txt "")) [])
                                     (body [h1 [txt myparam]])))
->>
+]}
 
 The handler takes as first parameter the GET page parameters, typed according to
 the parameter specification given while creating the service.
 The second parameter is for POST parameters (see below).
 
-===Outputs===
+{2 Outputs}
 
 Services can return a typed HTML page as in the example above, but also
 any other kind of result. To choose the return type, use the register function
 from the corresponding submodule of
-<<a_api project="eliom" | module Eliom.Registration >>:
-
-<<div id="servicetable"|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Html"| module Eliom.Registration.Html >>|@@colspan="3"@@Services returning typed HTML pages|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Html_text"| module Eliom.Registration.Html >>|@@colspan="3"@@Services returning untyped HTML pages as strings|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="App"| module Eliom.Registration.ELIOM_APPL >>|@@colspan="3"@@Apply this functor to generate registration functions for services belonging to an Eliom client/server application. These services also return typed HTML pages, but Eliom will automatically add the client-side program as a JS file, and all the data needed (values of all injections, etc.)|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Flow"| module Eliom.Registration.Flow5 >>|@@colspan="3"@@Services returning portions of HTML pages.|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Action"| module Eliom.Registration.Action >>|@@colspan="3"@@Services performing actions (server side effects) with or without reloading the page (e.g. login, logout, payment, modification of user information...)|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Files"| module Eliom.Registration.File >>|@@colspan="3"@@Serve files from the server hard drive|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Ocaml"| module Eliom.Registration.Ocaml >>|@@colspan="3"@@Services returning OCaml values to be sent to a client side OCaml program (this kind of services is used as low level interface for server functions -- see below)|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="String"| module Eliom.Registration.String >>|@@colspan="3"@@Services returning any OCaml string (array of byte)|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Redirection"| module Eliom.Registration.Redirection >>|@@colspan="3"@@Services returning an HTTP redirection to another service|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Any"| module Eliom.Registration.Any >>|@@colspan="3"@@To be used to make the service chose what it sends. Call function {{{send}}} from the corresponding module to choose the output.|
-|=@@class="row"@@<<a_api project="eliom" subproject="server" text="Customize"| module Eliom.Registration.Customize >>|@@colspan="3"@@Apply this functor to define your own registration module|
->>
-
-===Parameters===
-
-Module <<a_api project="eliom" subproject="server"| module Eliom.Parameter>>
+{!Eliom.Registration}:
+
+{%wodoc:div%}
+{t
+ | {{!Eliom.Registration.Html}Html} | Services returning typed HTML pages |
+ | {{!Eliom.Registration.Html}Html_text} | Services returning untyped HTML pages as strings |
+ | {{!Eliom.Registration.ELIOM_APPL}App} | Apply this functor to generate registration functions for services belonging to an Eliom client/server application. These services also return typed HTML pages, but Eliom will automatically add the client-side program as a JS file, and all the data needed (values of all injections, etc.) |
+ | {{!Eliom.Registration.Flow5}Flow} | Services returning portions of HTML pages. |
+ | {{!Eliom.Registration.Action}Action} | Services performing actions (server side effects) with or without reloading the page (e.g. login, logout, payment, modification of user information...) |
+ | {{!Eliom.Registration.File}Files} | Serve files from the server hard drive |
+ | {{!Eliom.Registration.Ocaml}Ocaml} | Services returning OCaml values to be sent to a client side OCaml program (this kind of services is used as low level interface for server functions -- see below) |
+ | {{!Eliom.Registration.String}String} | Services returning any OCaml string (array of byte) |
+ | {{!Eliom.Registration.Redirection}Redirection} | Services returning an HTTP redirection to another service |
+ | {{!Eliom.Registration.Any}Any} | To be used to make the service chose what it sends. Call function [send] from the corresponding module to choose the output. |
+ | {{!Eliom.Registration.Customize}Customize} | Apply this functor to define your own registration module |
+}
+{%wodoc:end%}
+
+{2 Parameters}
+
+Module {!Eliom.Parameter}
 is used to describe the type of service parameters.
 
 Examples:
-<<code language="ocaml"|
+{@ocaml[
 Eliom.Parameter.(int "i" ** (string "s" ** bool "b"))
    (* /path?i=42&s=toto&b=on *)
 
@@ -288,23 +293,24 @@ Eliom.Parameter.(suffix (int "year" ** int "month"))
 Eliom.Parameter.(suffix_prod (int "year" ** int "month") (int "a"))
    (* /path/2012/09?a=4 *)
 
->>
+]}
 
-===POST services===
+{2 POST services}
 
-To define a service with POST parameters, just change the {{{~meth}}} parameter.
+To define a service with POST parameters, just change the [~meth] parameter.
 For example the following example takes the same GET parameters as the service
 above, plus one POST parameter of type string, named "mypostparam".
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 ~meth:(Eliom.Service.Post (Eliom.Parameter.((string "myparam" ** int "i"),
                                             (string "mypostparam"))))
->>
+]}
 
-===Pathless services===
+{2 Pathless services}
 
 Pathless services are not identified by the path in the URL,
 but by a name given as parameter. This name can be specified manually
-using the {{{~name}}} optional parameter, otherwise, a random name is
+using the [~name] optional parameter, otherwise, a random name is
 generated automatically.
 This is used to implement server functions (see below).
 If you are programming a client-server Eliom app, you will probably prefer server functions.
@@ -312,72 +318,75 @@ If you are using traditional service based Web programming,
 use this to make a functionality available from all pages
 (for example: log-in or log-out actions, add something in a shopping basket ...).
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let pathless_service =
   Eliom.Service.create
     ~name:"pathless_example"
     ~path:Eliom.Service.No_path
     ~meth:(Eliom.Service.Get (Eliom.Parameter.(int "i")))
     ()
->>
+]}
 
 More information
-<<a_manual project="eliom" chapter="server-services" fragment="pathless"|in the manual>>.
+{{:../eliom/server-services.html#pathless}in the manual}.
 
-===External services===
-Use <<a_api project="eliom" subproject="server"| val Eliom.Service.extern >> to create
+{2 External services}
+Use {!Eliom.Service.extern} to create
 links or forms towards external Web sites as if they were Eliom services.
 
-===Predefined services===
-Use service <<a_api project="eliom" subproject="server" text="(Eliom.Service.static_dir ())"| val Eliom.Service.static_dir >>
+{2 Predefined services}
+Use service {{!Eliom.Service.static_dir}(Eliom.Service.static_dir ())}
 to create links towards static files (see example below for images).
 
-Use service <<a_api project="eliom" subproject="server"| val Eliom.Service.reload_action >> and its variants to create links or forms towards the current URL (reload the page). From a client section, you can also call <<a_api project="ocsigen-start" subproject="server"| val Os.Lib.reload>> to reload the page and restart the client-side program.
+Use service {!Eliom.Service.reload_action} and its variants to create links or forms towards the current URL (reload the page). From a client section, you can also call {!Os.Lib.reload} to reload the page and restart the client-side program.
 
-<<a_manual project="eliom" chapter="server-services" |Full documentation about services>>, [[interaction|a tutorial about traditional service based Web programming]], API documentation of modules <<a_api project="eliom" subproject="server" | module Eliom.Service>> and <<a_api project="eliom" subproject="server" | module Eliom.Registration>>.
+{{:../eliom/server-services.html}Full documentation about services}, {{:interaction.html}a tutorial about traditional service based Web programming}, API documentation of modules {!Eliom.Service} and {!Eliom.Registration}.
 
-This example shows how to insert an image using {{{static_dir}}}:
-<<code language="ocaml"|img
+This example shows how to insert an image using [static_dir]:
+{@ocaml[img
   ~alt:"blip"
   ~src:(Eliom.Content.Html.F.make_uri
          (Eliom.Service.static_dir ())
          ["dir" ; "image.jpg"])
   ()
->>
+]}
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Compiling==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Compiling}
+{%wodoc:end%}
 
-In this section, we will show how to compile and run a //server-side only// Web site by creating your project manually.
+In this section, we will show how to compile and run a {e server-side only} Web site by creating your project manually.
 
-===Build an executable===
+{2 Build an executable}
 This section shows how to create a static executable for you program
 (without configuration file).
 
 Run the following commands:
-{{{
+{v
 opam install ocsipersist-sqlite-config eliom
 dune init project --kind=executable mysite
 cd mysite
-}}}
+v}
 
 Create the directories will we use for data (logs, etc.):
-{{{
+{v
 mkdir -p local/var/log/mysite
 mkdir -p local/var/data/mysite
 mkdir -p local/var/run
-}}}
+v}
 
-Add packages {{{ocsipersist-sqlite}}} and {{{eliom.server}}} to file
-{{{bin/dune}}}, in the "libraries" section.
+Add packages [ocsipersist-sqlite] and [eliom.server] to file
+[bin/dune], in the "libraries" section.
 
-Copy the definition and registration of service {{{myservice}}} at the beginning 
-of file {{{bin/main.ml}}},
-and replace the call to {{{Ocsigen.Server.start}}} by the following lines:
+Copy the definition and registration of service [myservice] at the beginning 
+of file [bin/main.ml],
+and replace the call to [Ocsigen.Server.start] by the following lines:
 
-<<code language="ocaml"|
+{@ocaml[
 let () = 
   Ocsigen.Server.start 
     ~command_pipe:"local/var/run/mysite-cmd"
@@ -389,45 +398,45 @@ let () =
        [ Staticmod.run ~dir:"local/var/www/mysite" ()
        ; Eliom.App.run () ]
     ]
->>
+]}
 
 Build and execute the program with:
-{{{
+{v
 dune exec mysite
-}}}
+v}
 
-Open URL {{{http://localhost:8080/foo?myparam=Hello&i=27}}} with your browser.
+Open URL [http://localhost:8080/foo?myparam=Hello&i=27] with your browser.
 
-===Use with ocsigenserver===
+{2 Use with ocsigenserver}
 Alternatively, you can decide to build your Eliom app as a library and 
 load it dynamically into ocsigenserver using a configuration file.
 
-{{{
+{v
 opam install ocsipersist-sqlite-config eliom
 dune init project --kind=lib mysite
 cd mysite
-}}}
+v}
 
-Add {{{(libraries eliom.server)}}} into file {{{lib/dune}}}.
+Add [(libraries eliom.server)] into file [lib/dune].
 
-Create your {{{.ml}}} files in directory {{{lib}}}.
-For example, copy the definition and registration of service {{{myservice}}} above.
+Create your [.ml] files in directory [lib].
+For example, copy the definition and registration of service [myservice] above.
 
 Create the directories will we use for data (logs, etc.):
-{{{
+{v
 mkdir -p local/var/log/mysite
 mkdir -p local/var/data/mysite
 mkdir -p local/var/run
-}}}
+v}
 
 Compile:
-{{{
+{v
 dune build
-}}}
+v}
 
-Create a configuration file {{{mysite.conf}}}
+Create a configuration file [mysite.conf]
 with this content on your project root directory:
-{{{
+{v
 <ocsigen>
   <server>
     <port>8080</port>
@@ -447,88 +456,94 @@ with this content on your project root directory:
     </host>
   </server>
 </ocsigen>
-}}}
+v}
 Launch the application:
-{{{
+{v
 ocsigenserver -c mysite.conf
-}}}
-Open URL {{{http://localhost:8080/foo?myparam=Hello&i=27}}} with your browser.
->>
+v}
+Open URL [http://localhost:8080/foo?myparam=Hello&i=27] with your browser.
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Forms and links==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Forms and links}
+{%wodoc:end%}
 
-Functions <<a_api project="eliom" subproject="server" text="Eliom.Content.Html.F.a"|val Eliom_form_sigs.LINKS.a>> and
-<<a_api project="eliom" subproject="server" text="D.a"|val Eliom_form_sigs.LINKS.a>>
+Functions {{!Eliom_form_sigs.LINKS.a}Eliom.Content.Html.F.a} and
+{{!Eliom_form_sigs.LINKS.a}D.a}
 create typed links to services with their parameters.
-For example, if {{{home_service}}} expects no parameter
-and {{{other_service}}} expects a string and an optional int:
-<<code language="ocaml"|
+For example, if [home_service] expects no parameter
+and [other_service] expects a string and an optional int:
+{@ocaml[
 Eliom.Content.Html.D.a ~service:home_service [txt "Home"] ()
 Eliom.Content.Html.D.a ~service:other_service [txt "Other"] ("hello", Some 4)
->>
+]}
 
-Modules <<a_api project="eliom" subproject="server" |module Eliom.Content.Html.F>> and
-<<a_api project="eliom" subproject="server" text="D"|module Eliom.Content.Html.D>>
+Modules {!Eliom.Content.Html.F} and
+{{!Eliom.Content.Html.D}D}
 define the form's elements with the usual typed interface from TyXML.
 Use this for example if you have a client side program and
 want to manipulate the form's content from client side functions
 (for example do a server function call with the form's elements' content).
 
 In contrast,
-modules <<a_api project="eliom" subproject="server" text="Eliom.Content.Html.F.Form"|module Eliom.Content_sigs.LINKS_AND_FORMS.Form>> and
-<<a_api project="eliom" subproject="server" text="D.Form"|module Eliom.Content_sigs.LINKS_AND_FORMS.Form>>
+modules {{!Eliom.Content_sigs.LINKS_AND_FORMS.Form}Eliom.Content.Html.F.Form} and
+{{!Eliom.Content_sigs.LINKS_AND_FORMS.Form}D.Form}
 define a typed interface
 for form elements. Use this for links (see above), or if you program traditional
 server-side Web interaction (with or without client-side program). This will statically check that your forms
 match the services. See more information in the
-<<a_manual project="tuto" chapter="basics-server"|server-side programming manual>>.
+{{:../tuto/basics-server.html}server-side programming manual}.
 
->>
-<<section class="docblock" |
-<<header |==Js_of_ocaml==>>
+{%wodoc:end%}
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Js_of_ocaml}
+{%wodoc:end%}
 
-//Js_of_ocaml// is a compiler of OCaml bytecode to JavaScript,
+{e Js_of_ocaml} is a compiler of OCaml bytecode to JavaScript,
 allowing to run Ocaml programs in a Web browser.
 Its key features are the following:
-* The whole language, and most of the standard library are supported.
-* You can use a standard installation of OCaml to compile your programs. In particular, you do not have to recompile a library to use it with Js_of_ocaml.
-* It comes with a library to interface with the browser API.
+- The whole language, and most of the standard library are supported.
+- You can use a standard installation of OCaml to compile your programs. In particular, you do not have to recompile a library to use it with Js_of_ocaml.
+- It comes with a library to interface with the browser API.
 
-**WebAssembly:** OCaml programs can also be compiled to WebAssembly using
-//wasm_of_ocaml//. Eliom provides automatic browser detection: if WebAssembly
+{b WebAssembly:} OCaml programs can also be compiled to WebAssembly using
+{e wasm_of_ocaml}. Eliom provides automatic browser detection: if WebAssembly
 is supported, the WASM version is loaded, otherwise it falls back to JavaScript.
 
 Interaction with Javascript can be done:
-* either with untyped function calls (module {{{Js.Unsafe}}}),
-* or you can generate an interface just by writing an annotated {{{.mli}}}
-using [[https://github.com/LexiFi/gen_js_api|Gen_js_api]],
-* or you use a syntax extension to generate typed calls, using a
-{{{.mli}}} file describing Javascript objects
+- either with untyped function calls (module [Js.Unsafe]),
+- or you can generate an interface just by writing an annotated [.mli]
+using {{:https://github.com/LexiFi/gen_js_api}Gen_js_api},
+- or you use a syntax extension to generate typed calls, using a
+[.mli] file describing Javascript objects
 with OCaml class types as phantom types.
 
 The latter is used for the default Javascript library. Here is how it works:
 
-|{{{obj##.m}}}|access a JS property (has type {{{u}}} when {{{obj : <m : u prop> Js.t}}})|
-|{{{obj##.m := e}}}|change a JS property (when {{{obj : <m : u prop> Js.t}}} and {{{e:u}}})|
-|{{{obj##m e_1 ... e_n}}}|call a JS method (has type {{{u}}} when {{{obj : <m : t_1 -> ... -> t_n -> u meth; ..> Js.t}}} and {{{e_i : t_i}}})|
-|{{{new%js constr e1 ... en}}}|create a JS object (has type {{{u Js.t}}} when {{{constr : (t_1 -> ... -> t_n -> u Js.t) Js.constr}}} and {{{e_i : t_i}}})|
+{t
+ | [obj##.m] | access a JS property (has type [u] when [obj : <m : u prop> Js.t]) |
+ | [obj##.m := e] | change a JS property (when [obj : <m : u prop> Js.t] and [e:u]) |
+ | [obj##m e_1 ... e_n] | call a JS method (has type [u] when [obj : <m : t_1 -> ... -> t_n -> u meth; ..> Js.t] and [e_i : t_i]) |
+ | [new%js constr e1 ... en] | create a JS object (has type [u Js.t] when [constr : (t_1 -> ... -> t_n -> u Js.t) Js.constr] and [e_i : t_i]) |
+}
 
-Module <<a_api project="js_of_ocaml" |module Js_of_ocaml.Js>>
+Module {!Js_of_ocaml.Js}
 defines the base JS types and conversion functions from/to OCaml types.
-Example: {{{Js.Opt}}} to take into account nullable values, {{{Js.Optdef}}} for undefined values,
-or functions like {{{Js.to_string}}} and {{{Js.string}}} for consersions to and from
+Example: [Js.Opt] to take into account nullable values, [Js.Optdef] for undefined values,
+or functions like [Js.to_string] and [Js.string] for consersions to and from
 OCaml strings.
 
-Use modules <<a_api project="js_of_ocaml" |module Js_of_ocaml.Dom>>
-and <<a_api project="js_of_ocaml" |module Js_of_ocaml.Dom_html>>
+Use modules {!Js_of_ocaml.Dom}
+and {!Js_of_ocaml.Dom_html}
 to interact with the DOM, or more specifically with HTML.
 
 You can test Js_of_ocaml online in this
-[[https://ocsigen.org/js_of_ocaml/latest/manual/files/toplevel/index.html|Toplevel running in the browser]]
+{{:https://ocsigen.org/js_of_ocaml/latest/manual/files/toplevel/index.html}Toplevel running in the browser}
 
-===Examples===
-<<code language="ocaml"|
+{2 Examples}
+{@ocaml[
 # Dom_html.document;;
 - : Js_of_ocaml.Dom_html.document Js_of_ocaml__.Js.t = <abstr>
 # Dom_html.document##.body;;
@@ -568,55 +583,59 @@ val fsth3 :
 - : unit = ()
 # Firebug.console##log (Dom_html.document##.body);;
 - : unit = ()
->>
+]}
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==HTML: Functional and DOM semantics==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 HTML: Functional and DOM semantics}
+{%wodoc:end%}
 
-===DOM nodes and TyXML/Eliom.Content nodes===
+{2 DOM nodes and TyXML/Eliom.Content nodes}
 
-Functions [[https://ocsigen.org/js_of_ocaml/latest/api/js_of_ocaml-tyxml/Js_of_ocaml_tyxml/Tyxml_cast_sigs/module-type-OF/index.html|{{{Eliom.Content.Html.To_dom.of_element}}}, {{{Eliom.Content.Html.To_dom.of_div}}}, etc.]]
+Functions {{:https://ocsigen.org/js_of_ocaml/latest/api/js_of_ocaml-tyxml/Js_of_ocaml_tyxml/Tyxml_cast_sigs/module-type-OF/index.html}[Eliom.Content.Html.To_dom.of_element], [Eliom.Content.Html.To_dom.of_div], etc.}
 help to convert TyXML/Eliom.Content nodes into the DOM/js_of_ocaml counterparts.
 
-Module <<a_api project="eliom" subproject="client"|module Eliom.Content.Html.Manip>>
+Module {!Eliom.Content.Html.Manip}
 allows direct manipulation of TyXML nodes without conversion (only for D nodes)
 (see for example
-<<a_api project="eliom" subproject="client"|val Eliom.Content.Html.Manip.appendChild>>,
-<<a_api project="eliom" subproject="client"|val Eliom.Content.Html.Manip.removeSelf>>
-<<a_api project="eliom" subproject="client"|val Eliom.Content.Html.Manip.Class.add>>).
+{!Eliom.Content.Html.Manip.appendChild},
+{!Eliom.Content.Html.Manip.removeSelf}
+{!Eliom.Content.Html.Manip.Class.add}).
 
 
-===F or D===
+{2 F or D}
 
 Eliom uses TyXML to create several kinds of nodes:
 
-Module <<a_api project="eliom" subproject="server"| module Eliom.Content.Html.F>>
+Module {!Eliom.Content.Html.F}
 will create functional values representing
-your nodes. On client side, calling {{{Eliom.Content.Html.To_dom.of_element}}}
+your nodes. On client side, calling [Eliom.Content.Html.To_dom.of_element]
 on these nodes will create a new DOM node.
 
-Module <<a_api project="eliom" subproject="server"| module Eliom.Content.Html.D>>
+Module {!Eliom.Content.Html.D}
 will automatically insert an id in the
 attributes of the node, to label a precise instance of the node in the DOM.
-On client side, calling {{{Eliom.Content.Html.To_dom.of_element}}}
+On client side, calling [Eliom.Content.Html.To_dom.of_element]
 on these nodes will return the actual version of the nodes that are currently
 in the page.
 
 In a client server Eliom app,
-you probably always want to use {{{Eliom.Content.Html.D}}}
+you probably always want to use [Eliom.Content.Html.D]
 each time you want to bind events on
-an element (and more generally if you need to inject this element using {{{~%}}}).
+an element (and more generally if you need to inject this element using [~%]).
 
 
-Read more about {{{Eliom.Content.Html}}} (D or F?) in
-<<a_manual project="eliom" chapter="clientserver-html"|this manual page>>.
+Read more about [Eliom.Content.Html] (D or F?) in
+{{:../eliom/clientserver-html.html}this manual page}.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Eliom: client-server apps==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Eliom: client-server apps}
+{%wodoc:end%}
 
 Eliom can transform OCaml into a multi-tier language, allowing one to
 implement (both the server and client parts of) a distributed application
@@ -632,12 +651,12 @@ In a mobile app, all pages are usually generated on the client.
 One of the key features of Eliom is that it allows
 one to mix traditional Web interactions (URLs, forms, links,
 bookmarks, back button) with dynamic client side features. In
-particular, the client-side program **does not stop** when the user
+particular, the client-side program {b does not stop} when the user
 clicks on a link, sends a form, or presses the back button--yet the user
 can still save bookmarks on pages! This opens up a wide field of new
 possibilities.
 
-===Sections===
+{2 Sections}
 
 Eliom statically generates two programs from the same set of OCaml files:
 one compiled to native code (or bytecode) to be executed on the server,
@@ -646,30 +665,34 @@ in the browser.
 
 PPX annotations allow you to split the code into these two programs:
 
-|{{{ let%shared ... = ... }}}|Code to be included in both the client and server apps|
-|{{{ let%client ... = ... }}}|Code to be included in client app only|
-|{{{ let%server ... = ... }}}|Code to be included in server app only|
+{t
+ | [let%shared ... = ...] | Code to be included in both the client and server apps |
+ | [let%client ... = ...] | Code to be included in client app only |
+ | [let%server ... = ...] | Code to be included in server app only |
+}
 
-Same for {{{module%shared}}}, {{{open%shared}}}, {{{type%shared}}} etc.
+Same for [module%shared], [open%shared], [type%shared] etc.
 
-@@class="centered"@@{{@@class="img-col-width-400"@@files/tutorial/client-server.svg|Client-server build system}}
+{%wodoc:@ class="centered"%}{%wodoc:img class="img-col-width-400" src="files/tutorial/client-server.svg" alt="Client-server build system"%}
 
-===Client values===
+{2 Client values}
 Fragments of client code can be included in server (or shared) sections.
 
 Example:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
   button ~a:[a_onclick [%client fun ev -> ... ]] [ ... ]
->>
+]}
 
-The syntax is {{{[%client (<value> : <type>)]}}}.
+The syntax is [[%client (<value> : <type>)]].
 Type annotation is almost always required.
 
 These client fragments can be manipulated as server side OCaml values:
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server x : int Eliom.Client_value.t = [%client 1 + 3 ]
->>
+]}
 
 If such section is reached while generating a page on server side,
 the client-side code will be executed when the page is displayed.
@@ -681,71 +704,76 @@ If such section is reached during module initialization on the server
 (global client section), it will be executed on client side everytime
 a new client side program is launched.
 
-The tutorial [[tutowidgets|Client-Server Widgets]]
+The tutorial {{:tutowidgets.html}Client-Server Widgets}
 shows how client values can be manipulated
 on server side.
 
-===Injections===
+{2 Injections}
 
 Server side values can be injected in client code by prefixing
-them with {{{~%}}} as in this example:
-<<code language="ocaml" class="server"|
+them with [~%] as in this example:
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server ... =
   ...
   let x = ... in
   [%client[ ... ~%x ... ]]
   ...
->>
+]}
 The value will automatically be sent with the page by Eliom.
 
 It is possible to combine injections and client-values:
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server x : int Eliom.Client_value.t = [%client 1 + 3 ]
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client c : int = 3 + ~%x
->>
+]}
 
-===Calling server side functions from the client===
+{2 Calling server side functions from the client}
 
 Eliom makes it possible to call server side OCaml functions from your
 client-side program. You must export these functions explicitly,
 and declare the type of their parameters. Example:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc g (i : int) : string Lwt.t =
   Lwt.return (string_of_int (i + Random.int 1000))
->>
+]}
 
 Warning: type annotations are mandatory here
 so that the ppx can automatically inject the right conversion functions.
 These functions are generated automatically by
-[[https://github.com/ocsigen/deriving|Deriving]], as long as it knows
+{{:https://github.com/ocsigen/deriving}Deriving}, as long as it knows
 a deriver for each subtype. To create a deriver for your own types
-just append {{{[@@deriving json]}}} after your type declaration. Example:
+just append [[@@deriving json]] after your type declaration. Example:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 type%shared t = A | B
 [@@deriving json]
->>
+]}
 
-[[http://ocsigen.org/js_of_ocaml/latest/manual/ppx-deriving|More documentation about the JSON deriver]].
+{{:http://ocsigen.org/js_of_ocaml/latest/manual/ppx-deriving}More documentation about the JSON deriver}.
 
-<<div class="focused"|
-===How it works===
+{%wodoc:div class="focused"%}
+{2 How it works}
 
 The following picture shows two examples of requests:
-* First, the browser asks for a new page, and the server generates the page
-* then the user clicks on a link in the page, and the page is generated by the client-side program (because the service is registered on both sides). In this example, while generating the page, the client does a RPC to the server.
+- First, the browser asks for a new page, and the server generates the page
+- then the user clicks on a link in the page, and the page is generated by the client-side program (because the service is registered on both sides). In this example, while generating the page, the client does a RPC to the server.
 
 In both cases (first request or RPC), the server returns the expected value, but also the value of injections and an order for the client-side program to execute the client-values met during te server-side computation.
 
-@@class="centered"@@{{@@class="img-col-width-400"@@files/tutorial/client-server-req.svg|Example of requests}}
+{%wodoc:@ class="centered"%}{%wodoc:img class="img-col-width-400" src="files/tutorial/client-server-req.svg" alt="Example of requests"%}
 
-Tip 1: You can avoid waiting for the RPC to return by using a spinner from Ocsigen Toolkit (see module <<a_api project="ocsigen-toolkit" subproject="server"|module Ot.Spinner>>). Thus, the client-side generated page will be displayed without delay.
+Tip 1: You can avoid waiting for the RPC to return by using a spinner from Ocsigen Toolkit (see module {!Ot.Spinner}). Thus, the client-side generated page will be displayed without delay.
 
 Tip 2: To delay the execution of a client fragment after the page is actually displayed, you might want to use function
-<<a_api project="ocsigen-toolkit" subproject="client"|val Ot.Nodeready.nodeready>> from Ocsigen Toolkit.
+{!Ot.Nodeready.nodeready} from Ocsigen Toolkit.
 
 Regardless of the construction used and their combination, there is
 only one communication from server to client, when the Web page is
@@ -766,25 +794,30 @@ that will insert in the currently generated page some instruction to
 ask the client-side program to call the corresponding functions.
 Their arguments (injections) are serialized at the same time by the
 server-side program and also inserted in the generated page.
->>
+{%wodoc:end%}
 
-===Example===
+{2 Example}
 This section shows a typical example of client-server code: call a function
 when user clicks on a page element. Take time to analyse this example,
 as most of your code will probably be very similar.
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 open%client Js_of_ocaml
 open%client Js_of_ocaml_lwt
-open%client Eliom.Content.Html>>
-<<code language="ocaml" class="shared"|open%shared Eliom.Content.Html.F>>
-<<code language="ocaml" class="server"|let%server theservice =
+open%client Eliom.Content.Html]}
+{%wodoc:@ class=shared%}
+{@ocaml[open%shared Eliom.Content.Html.F]}
+{%wodoc:@ class=server%}
+{@ocaml[let%server theservice =
   Eliom.Service.create
     ~path:["ex"]
     ~meth:(Eliom.Service.Get Eliom.Parameter.unit)
-    ()>>
-<<code language="ocaml" class="client"|let%client theservice = ~%theservice>>
-<<code language="ocaml" class="shared"|
+    ()]}
+{%wodoc:@ class=client%}
+{@ocaml[let%client theservice = ~%theservice]}
+{%wodoc:@ class=shared%}
+{@ocaml[
 
 let%shared () =
   My_app.register ~service:theservice (fun () () ->
@@ -802,23 +835,25 @@ let%shared () =
       in
       Lwt.return (html (head (title (txt "Example")) [])
                        (body [h1 [txt aa]; b])))
->>
+]}
 
 Service handlers and service registration
 are usually written in shared sections to enable
 page generation on both sides.
 
-* Examples of client sections, injections or server functions can be found in
+- Examples of client sections, injections or server functions can be found in
 the demo included in
-[[https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/demo_rpc.eliom|Ocsigen-Start's app template]].
-* [[application|This page]] is a step by step introduction to client-server programming with Eliom for beginners.
-* [[tutowidgets|This one]] is a quick introduction for more experienced OCaml developers.
-* Comprehensive documentation on client-server programming can be found in
-<<a_manual project="eliom" page="intro"|Eliom's user manual>>.
->>
-
-<<section class="docblock" |
-<<header |==Compiling a client-server app==>>
+{{:https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/demo_rpc.eliom}Ocsigen-Start's app template}.
+- {{:application.html}This page} is a step by step introduction to client-server programming with Eliom for beginners.
+- {{:tutowidgets.html}This one} is a quick introduction for more experienced OCaml developers.
+- Comprehensive documentation on client-server programming can be found in
+{{:../eliom/.html}Eliom's user manual}.
+{%wodoc:end%}
+
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Compiling a client-server app}
+{%wodoc:end%}
 
 Compiling a client-server app requires a dedicated build system,
 which will separate server-side and client-side code, compile each side,
@@ -832,348 +867,382 @@ It also provides user management (create an account, recover lost password, etc.
 If you plan to build an app with these features, Ocsigen Start is a good basis.
 
 Install Ocsigen Start:
-{{{
+{v
 opam install ocsigen-start
-}}}
+v}
 Then:
-{{{
+{v
 eliom-distillery -template os -name myapp
-}}}
+v}
 It contains by default some code examples that you can remove or adapt to your own needs.
-Have a look at the {{{README}}} file.
+Have a look at the [README] file.
 
 If you don't want to use Ocsigen Start, you can use one of the basic templates:
-{{{
+{v
 eliom-distillery -template app.exe -name myapp
-}}}
+v}
 (to build a static executable without config file)
 or
-{{{
+{v
 eliom-distillery -template app.lib -name myapp
-}}}
+v}
 (to build your app as a library that will be loaded dynamically in Ocsigen Server using a config file).
 
-Have a look at the {{{README}}} file.
+Have a look at the [README] file.
 
 If these templates are not available, you are probably using an old version of Eliom.
-Try to upgrade, or use old template names (see {{{eliom-distillery -list-templates}}}).
+Try to upgrade, or use old template names (see [eliom-distillery -list-templates]).
 
->>
+{%wodoc:end%}
 
 
-<<section class="docblock" |
-<<header |==Sessions==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Sessions}
+{%wodoc:end%}
 
-Session data is saved on server side in //Eliom references//.
+Session data is saved on server side in {e Eliom references}.
 
 The following Eliom reference will count the number of visits of a user on a page:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server count_ref =
   Eliom.Reference.eref
     ~scope:Eliom.Common.default_session_scope
     0 (* default value for everyone *)
->>
+]}
 
 And somewhere in your service handler, increment the counter:
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%lwt count = Eliom.Reference.get count_ref in
 Eliom.Reference.set count_ref (count + 1);
 Lwt.return ()
->>
+]}
 
-With function <<a_api project="eliom" subproject="server"|val Eliom.Reference.eref_from_fun>>,
+With function {!Eliom.Reference.eref_from_fun},
 you can create Eliom references without initial value. The initial value is computed for the session
 the first time you use it.
 
 An Eliom reference can be persistant (value saved on hard drive) or volatile (in memory).
 
-===Scopes===
+{2 Scopes}
 Sessions are relative to a browser, and implemented using browser cookies.
-But Eliom allows to create Eliom references with other //scopes// than session:
+But Eliom allows to create Eliom references with other {e scopes} than session:
 
-|<<a_api project="eliom" subproject="server" text="global_scope"| val Eliom.Common.global_scope>>|Global value for all the Web server|
-|<<a_api project="eliom" subproject="server" text="site_scope"| val Eliom.Common.site_scope>>|Global value for the Eliom app in that subsite of the Web site|
-|<<a_api project="eliom" subproject="server" text="default_group_scope"| val Eliom.Common.default_group_scope>>|Value for a group of sessions. For example Ocsigen Start defines a group of session for each user, making it possible to save server side data for all sessions of a user.|
-|<<a_api project="eliom" subproject="server" text="default_session_scope"| val Eliom.Common.default_session_scope>>|The usual session data, based on browser cookies|
-|<<a_api project="eliom" subproject="server" text="default_process_scope"| val Eliom.Common.default_process_scope>>|Server side data for a given client-side process (a tab of the browser or a mobile app).|
+{t
+ | {{!Eliom.Common.global_scope}global_scope} | Global value for all the Web server |
+ | {{!Eliom.Common.site_scope}site_scope} | Global value for the Eliom app in that subsite of the Web site |
+ | {{!Eliom.Common.default_group_scope}default_group_scope} | Value for a group of sessions. For example Ocsigen Start defines a group of session for each user, making it possible to save server side data for all sessions of a user. |
+ | {{!Eliom.Common.default_session_scope}default_session_scope} | The usual session data, based on browser cookies |
+ | {{!Eliom.Common.default_process_scope}default_process_scope} | Server side data for a given client-side process (a tab of the browser or a mobile app). |
+}
 
 Applications based on Ocsigen Start use these scopes for user management.
 Session or client process data are discarded when a user logs in or out.
 But Ocsigen Start also defines scopes
-<<a_api project="ocsigen-start" subproject="server"| val Os.Session.user_indep_session_scope>>
+{!Os.Session.user_indep_session_scope}
 and
-<<a_api project="ocsigen-start" subproject="server"| val Os.Session.user_indep_process_scope>>
+{!Os.Session.user_indep_process_scope}
 which remain even if a user logs in or out.
 
 When session group is not set (for example the user is not connected),
 you can still use the group session scope: in that case, the group contains only
 one session.
 
->>
+{%wodoc:end%}
 
 
-<<section class="docblock" |
-<<header |==Browser events==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Browser events}
+{%wodoc:end%}
 
-Attributes like {{{a_onclick}}} in module {{{Eliom.Content.Html.D}}} or {{{F}}}
+Attributes like [a_onclick] in module [Eliom.Content.Html.D] or [F]
 take a client side function as parameter:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 button ~a:[a_onclick [%client fun ev -> ... ]] [ ... ]
->>
+]}
 
-Module {{{Lwt_js_events}}} of Js_of_ocaml defines a way to bind browser events
+Module [Lwt_js_events] of Js_of_ocaml defines a way to bind browser events
 using Lwt promises.
 
 For example,
-the following code will wait for a click on element {{{d}}} before continuing:
-<<code language="ocaml" class="client"|
+the following code will wait for a click on element [d] before continuing:
+{%wodoc:@ class=client%}
+{@ocaml[
 let%lwt ev = Lwt_js_events.click (Eliom.Content.Html.To_dom.of_element ~%d) in
 ...
->>
+]}
 
-Functions like {{{Lwt_js_events.clicks}}} or {{{Lwt_js_events.mousedowns}}}
+Functions like [Lwt_js_events.clicks] or [Lwt_js_events.mousedowns]
 (ending with "s")
 will call the function given as second parameter
-**for each** {{{click}}} or {{{mousedown}}} events
+{b for each} [click] or [mousedown] events
 on their first parameter.
 
-For example, the following code (inspired from [[https://ocsigen.org/tuto/latest/manual/application|this tutorial]])
-will wait for all {{{mousedown}}} events on the canvas,
-then for each {{{mousemove}}} event on the document,
-it will call function {{{f}}}, until {{{mouseup}}} is triggered.
-(See <<a_api project="lwt"| val Lwt.pick>>)
-<<code language="ocaml" class="client"|
+For example, the following code (inspired from {{:https://ocsigen.org/tuto/latest/manual/application}this tutorial})
+will wait for all [mousedown] events on the canvas,
+then for each [mousemove] event on the document,
+it will call function [f], until [mouseup] is triggered.
+(See {!Lwt.pick})
+{%wodoc:@ class=client%}
+{@ocaml[
 let open Lwt_js_events in
 Lwt.async (mousedowns
             (Eliom.Content.Html.To_dom.of_element ~%canvas)
             (fun ev _ ->
                Lwt.pick [mousemoves Dom_html.document f;
                          mouseup Dom_html.document]))
->>
->>
+]}
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Ocsigen Toolkit==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Ocsigen Toolkit}
+{%wodoc:end%}
 
 Ocsigen Toolkit defines several widgets that can be generated either
 on server or clide sides. Have look at
-[[wiki("ocsigen-start"):demo/|Ocsigen Start's demo app]]
-(or the [[https://play.google.com/store/apps/details?id=com.osdemo.mobile|corresponding Android app]])
+{{:../ocsigen-start/demo/}Ocsigen Start's demo app}
+(or the {{:https://play.google.com/store/apps/details?id=com.osdemo.mobile}corresponding Android app})
 to see them in action: carousel, drawer menu, date or time picker, color picker,
 pull to refresh feature for mobile apps, etc.
 
 For example module
-<<a_api project="ocsigen-toolkit" subproject="server"|module Ot.Spinner>>
+{!Ot.Spinner}
 implements a widgets that you can use to display a spinner (or fake elements)
 when some parts of your page take time to appear.
 It can be used in shared sections and gives you precise control
 of the delays and the feeling of responsiveness of your app.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Ocsigen Start==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Ocsigen Start}
+{%wodoc:end%}
 
-//Ocsigen-start// is a library and a template of Eliom application,
+{e Ocsigen-start} is a library and a template of Eliom application,
 with many common features like
 user registration, login box, notification system, etc.
 
 It also provides a demo of many features presented in this page.
-A [[wiki("ocsigen-start"):demo/|live version]] is accessible online.
-Read [[start|this page]] to create your first Ocsigen Start
+A {{:../ocsigen-start/demo/}live version} is accessible online.
+Read {{:start.html}this page} to create your first Ocsigen Start
 app and take time to study the code of each example.
 
 User management features are fully usable in production and
 will save you from implementing account creation, activation links
 or password recovery yourself.
-Module <<a_api project="ocsigen-start" subproject="server"|module Os.Current_user>>
+Module {!Os.Current_user}
 gives you information about current user
 from anywhere in your program.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Database access==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Database access}
+{%wodoc:end%}
 
 You can use your favourite database library with Ocsigen.
 Ocsigen Start's template uses
-[[https://github.com/darioteixeira/pgocaml|PG'OCaml]]
+{{:https://github.com/darioteixeira/pgocaml}PG'OCaml}
 (typed queries for Postgresql using a PPX syntax extension).
 
 Here is an example, taken from Ocsigen Start's demo:
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let get () =
   full_transaction_block (fun dbh ->
     [%pgsql dbh "SELECT lastname FROM ocsigen_start.users"])
->>
+]}
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Server to client communication==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Server to client communication}
+{%wodoc:end%}
 
 Modules
-<<a_api project="eliom" subproject="server"| module Eliom.Notif>>
+{!Eliom.Notif}
 and
-<<a_api project="ocsigen-start" subproject="server"| module Os.Notif>>
+{!Os.Notif}
 define the simplest interface to enable server to client communication
 (the second one being aware of Ocsigen Start users).
 
-<<div class="focused"|
-===How it works===
+{%wodoc:div class="focused"%}
+{2 How it works}
 Say you want to receive the messages for one or more chat rooms.
 First, define your notification module:
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 module%server Notif = Os.Notif.Make_Simple (struct
   type key = int64 (* the chat room ids *)
   type notification = string (* the type of messages *)
 end)
->>
+]}
 
 If you want to be notified when there is a new message in a chat room, call function
-{{{Notif.listen}}} (server side) on the chat room id.
+[Notif.listen] (server side) on the chat room id.
 
 If you want to send a message in a chat room, call function
-{{{Notif.notify}}} (server side) with the chat room id and the message as parameters.
+[Notif.notify] (server side) with the chat room id and the message as parameters.
 
-On client side, {{{~%(Notif.client_ev ())}}} is a React event of type
-{{{(key, notif) React.E.t}}}. Use it to receive the messages.
->>
+On client side, [~%(Notif.client_ev ())] is a React event of type
+[(key, notif) React.E.t]. Use it to receive the messages.
+{%wodoc:end%}
 
-Have a look at a [[https://ocsigen-1.inria.fr/ocsigen-start/demo/demo-notif|running example]] in Ocsigen Start's demo
-([[https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/demo_notif.eliom|source]]).
+Have a look at a {{:https://ocsigen-1.inria.fr/ocsigen-start/demo/demo-notif}running example} in Ocsigen Start's demo
+({{:https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/demo_notif.eliom}source}).
 
 Eliom has other communication modules:
-* <<a_api project="eliom" subproject="server"| module Eliom.Bus>> defines a communication bus,
+- {!Eliom.Bus} defines a communication bus,
 that you can use to share information with other client processes
-(see an example [[application|here]]).
-* <<a_api project="eliom" subproject="server"| module Eliom_react>> defines client-server React events.
-* <<a_api project="eliom" subproject="server"| module Eliom.Comet>> is lower level interface for
+(see an example {{:application.html}here}).
+- {!Eliom_react} defines client-server React events.
+- {!Eliom.Comet} is lower level interface for
 server to client communication.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Internationalisation==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Internationalisation}
+{%wodoc:end%}
 
-[[https://github.com/besport/ocsigen-i18n|Ocsigen i18n]]
+{{:https://github.com/besport/ocsigen-i18n}Ocsigen i18n}
 is an internationalisation library for your OCaml programs.
 
 Create a .tsv file with, on each line, a key and the text in several languages:
 
-{{{
+{v
 welcome_message Welcome everybody!        Bienvenue à tous !      Benvenuti a tutti !
-}}}
+v}
 
 and Ocsigen i18n will automatically generate functions like this one:
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%shared welcome_message ?(lang = get_language ()) () () =
   match lang with
   | En -> [txt "Welcome everybody!"]
   | Fr -> [txt "Bienvenue à tous !"]
   | It -> [txt "Benvenuti a tutti !"]
->>
+]}
 
 Ocsigen i18n also defines a syntax extension to use these functions:
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
   Eliom.Content.Html.F.h1 [%i18n welcome_message]
->>
+]}
 
 Ocsigen i18n offers many other features:
-* Text can be inserted as a TyXML node (as in the example above) or as a string (ex: {{{[%i18n S.welcome_message]}}}),
-* Text can be parametrizable, or contain holes (ex: {{{[%i18n welcome ~capitalize:true ~name:"William"]}}})
-* .tsv file can be split into several modules
+- Text can be inserted as a TyXML node (as in the example above) or as a string (ex: [[%i18n S.welcome_message]]),
+- Text can be parametrizable, or contain holes (ex: [[%i18n welcome ~capitalize:true ~name:"William"]])
+- .tsv file can be split into several modules
 
 Have a look at the
-[[https://github.com/besport/ocsigen-i18n|README file]]
+{{:https://github.com/besport/ocsigen-i18n}README file}
 to see the full documentation,
 and see examples in
-[[https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/demo_i18n.eliom|Ocsigen Start's template]].
+{{:https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/demo_i18n.eliom}Ocsigen Start's template}.
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Reactive programming==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Reactive programming}
+{%wodoc:end%}
 
-Eliom allows to insert //reactive nodes// in pages, that is, nodes which are automatically
+Eliom allows to insert {e reactive nodes} in pages, that is, nodes which are automatically
 updated when the values on which they depend change.
 
-This is based on the [[https://erratique.ch/software/react|React]] library by Daniel Bünzli,
-which implements //Functional Reactive Programming//.
+This is based on the {{:https://erratique.ch/software/react}React} library by Daniel Bünzli,
+which implements {e Functional Reactive Programming}.
 
-<<div class="focused"|
-===Functional Reactive Programming principle===
+{%wodoc:div class="focused"%}
+{2 Functional Reactive Programming principle}
 
-Function {{{React.S.create}}} creates a signal and a function to change its value:
-<<code language="ocaml" class="client"|
+Function [React.S.create] creates a signal and a function to change its value:
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client mysignal, set_mysignal = React.S.create 0
->>
+]}
 
-Functions like {{{React.S.map}}} or {{{React.S.l2}}} create new signals
+Functions like [React.S.map] or [React.S.l2] create new signals
 from one (resp. two) input signals.
 They are updated automatically when their input signals change.
 For example, we can can define the same value as a string signal and as TyXML node signal:
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client s_string = React.S.map string_of_int mysignal
 let%client s_p = React.S.map (fun v -> p [txt v]) s_string
->>
+]}
 
->>
+{%wodoc:end%}
 
-===Reactive nodes===
+{2 Reactive nodes}
 
 Insert a (client side) reactive node in a page using function
-<<a_api project="eliom" subproject="server"| val Eliom.Content.Html.R.node >>:
+{!Eliom.Content.Html.R.node}:
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client f () =
   let open Eliom.Content.Html in
   F.div [ R.node s_p ]
->>
+]}
 
-===Reactive node content===
+{2 Reactive node content}
 
 Module
-<<a_api project="eliom" subproject="server"|module Eliom.Content.Html.R >>
+{!Eliom.Content.Html.R}
 also defines all TyXML nodes,
 which take reactive content as parameter.
 
-For example {{{Eliom.Content.Html.R.txt}}} takes
-a value of type {{{string React.S.t}}} as parameter (string signal).
+For example [Eliom.Content.Html.R.txt] takes
+a value of type [string React.S.t] as parameter (string signal).
 
 Instead of taking a list signal as parameter, functions like
-{{{div}}} or {{{p}}} of module {{{Eliom.Content.Html.R}}}
+[div] or [p] of module [Eliom.Content.Html.R]
 take a parameter of type
-[[https://github.com/ocsigen/reactiveData|Eliom.Content.Html.F.elt ReactiveData.Rlist.t]].
+{{:https://github.com/ocsigen/reactiveData}Eliom.Content.Html.F.elt ReactiveData.Rlist.t}.
 This enables incremental update of the content
 (usually, appending an element at the end of the list,
 without having to redraw the whole list).
-See an example with {{{ReactiveData}}} in [[tutoreact|this tutorial]].
+See an example with [ReactiveData] in {{:tutoreact.html}this tutorial}.
 
-Node attributes can also be reactive. For example if {{{s}}} has type {{{string list React.S.t}}},
-you can write {{{Eliom.Content.Html.F.div ~a:[R.a_class s] []}}}.
+Node attributes can also be reactive. For example if [s] has type [string list React.S.t],
+you can write [Eliom.Content.Html.F.div ~a:[R.a_class s] []].
 
-===Client-server reactive programming===
+{2 Client-server reactive programming}
 
 Reactive nodes can be created in server or shared sections.
 To do that, use module
-<<a_api project="eliom" subproject="server"| module Eliom.Shared.React >>
-instead of the usual {{{React}}} module.
-On client side, this module behaves like {{{React}}}.
+{!Eliom.Shared.React}
+instead of the usual [React] module.
+On client side, this module behaves like [React].
 But when executed on server side, it will generate non reactive values,
 that will automatically become reactive on the client.
 
 Full example:
-<<code language="ocaml" class="server"|let%server theservice =
+{%wodoc:@ class=server%}
+{@ocaml[let%server theservice =
   Eliom.Service.create
     ~path:["ex"]
     ~meth:(Eliom.Service.Get Eliom.Parameter.unit)
-    ()>>
-<<code language="ocaml" class="client"|let%client theservice = ~%theservice>>
-<<code language="ocaml" class="client"|open%client Js_of_ocaml_lwt>>
-<<code language="ocaml" class="shared"|open%shared Eliom.Content.Html.F
+    ()]}
+{%wodoc:@ class=client%}
+{@ocaml[let%client theservice = ~%theservice]}
+{%wodoc:@ class=client%}
+{@ocaml[open%client Js_of_ocaml_lwt]}
+{%wodoc:@ class=shared%}
+{@ocaml[open%shared Eliom.Content.Html.F
 
 let%shared () =
   My_app.register ~service:theservice (fun () () ->
@@ -1197,18 +1266,20 @@ let%shared () =
            (head (title (txt s)) [])
            (body [h1 [txt s];
                   p [Eliom.Content.Html.R.txt s_string]])))
->>
+]}
 
-Function {{{Eliom.Shared.React.S.map}}} (and {{{Eliom.Shared.React.S.l2}}}, etc)
-takes a //shared function// as parameter (syntax {{{@@class="shared"@@[%shared f]}}}).
+Function [Eliom.Shared.React.S.map] (and [Eliom.Shared.React.S.l2], etc)
+takes a {e shared function} as parameter (syntax [@@class="shared"@@[%shared f]]).
 This can be seen as a couple containing both the server a client side implementation
 of the function.
 
 
->>
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Mobile apps==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Mobile apps}
+{%wodoc:end%}
 Applications can run on any Web browser or mobile device (iOS, Android, ...),
 thus eliminating the need for one custom version per platform.
 
@@ -1217,58 +1288,59 @@ Your CSS must be fully responsive to adapt to all screen sizes.
 Ocsigen Start's template comes with a Makefile which will automatically
 download the required NPM modules for Cordova and build your Android or iOS
 apps.
-Read the [[https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/README.md|README]] file
+Read the {{:https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/README.md}README} file
 to learn how to do that.
 
 Download
-[[https://play.google.com/store/apps/details?id=com.osdemo.mobile|Ocsigen Start's demo app]]
+{{:https://play.google.com/store/apps/details?id=com.osdemo.mobile}Ocsigen Start's demo app}
 from Google Play store to see an example.
-[[https://www.besport.com/news|Be Sport]] mobile apps are also generated like this (available in
-[[https://play.google.com/store/apps/details?id=com.besport.www.mobile|Google Play Store]]
-and [[https://apps.apple.com/fr/app/be-sport/id1104216922|Apple app store]]).
->>
+{{:https://www.besport.com/news}Be Sport} mobile apps are also generated like this (available in
+{{:https://play.google.com/store/apps/details?id=com.besport.www.mobile}Google Play Store}
+and {{:https://apps.apple.com/fr/app/be-sport/id1104216922}Apple app store}).
+{%wodoc:end%}
 
-<<section class="docblock" |
-<<header |==Ocsigen Server==>>
+{%wodoc:section class="docblock"%}
+{%wodoc:header%}
+{1 Ocsigen Server}
+{%wodoc:end%}
 
-//Ocsigen Server// is a full featured Web server.
+{e Ocsigen Server} is a full featured Web server.
 
-It is now based on [[https://github.com/mirage/ocaml-cohttp|Cohttp]].
+It is now based on {{:https://github.com/mirage/ocaml-cohttp}Cohttp}.
 
 It has a powerful
 extension mechanism that makes it easy to plug your own OCaml modules
 for generating pages. Many extensions are already written:
-;<<a_manual project="ocsigenserver" chapter="staticmod"|Staticmod>>
+;{{:../ocsigenserver/staticmod.html}Staticmod}
 :    to serve static files.
-;[[wiki("eliom"):|Eliom]]
+;{{:../eliom/}Eliom}
 :    to create reliable client/server Web applications
      or Web sites in OCaml using advanced high level concepts.
-;<<a_manual project="ocsigenserver" chapter="extendconfiguration"|Extendconfiguration>>
+;{{:../ocsigenserver/extendconfiguration.html}Extendconfiguration}
 :    allows for more options in the configuration file.
-;<<a_manual project="ocsigenserver" chapter="accesscontrol"|Accesscontrol>>
+;{{:../ocsigenserver/accesscontrol.html}Accesscontrol}
 :    restricts access to the sites from the config file (to requests coming from a subnet, containing some headers, etc.).
-;<<a_manual project="ocsigenserver" chapter="authbasic"|Authbasic>>
+;{{:../ocsigenserver/authbasic.html}Authbasic}
 :    restricts access to the sites from the config file using Basic HTTP Authentication.
-;<<a_manual project="ocsigenserver" chapter="cgimod"|CGImod>>
+;{{:../ocsigenserver/cgimod.html}CGImod}
 :    serves CGI scripts. It may also be used to serve PHP through CGI.
-;<<a_manual project="ocsigenserver" chapter="deflatemod"|Deflatemod>>
+;{{:../ocsigenserver/deflatemod.html}Deflatemod}
 :    used to compress data before sending it to the client.
-;<<a_manual project="ocsigenserver" chapter="redirectmod"|Redirectmod>>
+;{{:../ocsigenserver/redirectmod.html}Redirectmod}
 :    sets redirections towards other Web sites from the configuration file.
-;<<a_manual project="ocsigenserver" chapter="revproxy"|Revproxy>>
+;{{:../ocsigenserver/revproxy.html}Revproxy}
 :    a reverse proxy for Ocsigen Server.
       It allows to ask another server to handle the request.
-;<<a_manual project="ocsigenserver" chapter="rewritemod"|Rewritemod>>
+;{{:../ocsigenserver/rewritemod.html}Rewritemod}
 :    changes incoming requests before sending them to other extensions.
-;<<a_manual project="ocsigenserver" chapter="outputfilter"|Outputfilter>>
+;{{:../ocsigenserver/outputfilter.html}Outputfilter}
 :    rewrites some parts of the output before sending it to the client.
-;<<a_manual project="ocsigenserver" chapter="userconf"|Userconf>>
+;{{:../ocsigenserver/userconf.html}Userconf}
 :    allows users to have their own configuration files.
-;<<a_manual project="ocsigenserver" chapter="comet"|Comet>>
+;{{:../ocsigenserver/comet.html}Comet}
 :    facilitates server to client communications.
 
-Ocsigen Server has a <<a_manual project="ocsigenserver"
-chapter="config"|sophisticated configuration>> file mechanism allowing
+Ocsigen Server has a {{:../ocsigenserver/config.html}sophisticated configuration} file mechanism allowing
 complex configurations of sites.
 
->>
+{%wodoc:end%}
diff --git a/tutos/dev/manual/custom-conf.wiki b/tutos/dev/manual/custom-conf.mld
similarity index 86%
rename from tutos/dev/manual/custom-conf.wiki
rename to tutos/dev/manual/custom-conf.mld
index 9539feb1..636ad9d0 100644
--- a/tutos/dev/manual/custom-conf.wiki
+++ b/tutos/dev/manual/custom-conf.mld
@@ -1,16 +1,18 @@
-=Custom configuration options=
-<<concepts |Custom configuration options>>
+{0 Custom configuration options}
+{%wodoc:aside class="concepts"%}{b Concepts}
+
+Custom configuration options{%wodoc:end%}
 
 It is not convenient to have to edit the code to change some
 configurations, like the location where are saved the favorite
 images in the Graffiti tutorial
-(see: [[wiki:pictures|Saving favorite pictures]]).
+(see: {{:wiki:pictures}Saving favorite pictures}).
 Fortunately Ocsigen provides a mechanism to extend its
 configuration file.
 
-==Basic interface==
+{1 Basic interface}
 
-<<code language="ocaml"|
+{@ocaml[
 let static_dir =
   match Eliom.Config.get_config () with
     | [Simplexmlparser.Element
@@ -22,27 +24,27 @@ let static_dir =
     | _ ->
       raise (Ocsigen.Extensions.Error_in_config_file
                ("Unexpected content inside config"))
->>
+]}
 
 This will add a mandatory child to the eliom tag in the
 configuration file:
-{{{
+{v
 <eliom module="path/to/your/module.cma">
   <staticdir>/tmp/static</staticdir>
 </eliom>
-}}}
+v}
 
 
-==New interface==
+{1 New interface}
 
 From Eliom 4.0 it is much easier to define configuration file extension.
-Have a look at module <<a_api project="eliom" subproject="server"|module Eliom.Config>>.
+Have a look at module {!Eliom.Config}.
 For instance, here is how you can add an element "<ldap>"
 in the configuration file to store a list of LDAP servers your application
 interacts with.
 
 
-<<code language="ocaml"|
+{@ocaml[
 
 (** An LDAP server is characterized by an host and a port. *)
 type ldap_configuration = {
@@ -86,4 +88,4 @@ let ldap_configuration = Ocsigen.Extensions.Configuration.(
 
 let _ = Eliom.Config.parse_config [ldap_configuration]
 
->>
+]}
diff --git a/tutos/dev/manual/hash-password.wiki b/tutos/dev/manual/hash-password.mld
similarity index 73%
rename from tutos/dev/manual/hash-password.wiki
rename to tutos/dev/manual/hash-password.mld
index cf16a095..d662e2ed 100644
--- a/tutos/dev/manual/hash-password.wiki
+++ b/tutos/dev/manual/hash-password.mld
@@ -1,13 +1,13 @@
-=Protecting your passwords=
+{0 Protecting your passwords}
 
 For protecting the user passwords or other sensitive data,
 we can use
-[[http://ocaml-safepass.forge.ocamlcore.org/|ocaml-safepass]].
+{{:http://ocaml-safepass.forge.ocamlcore.org/}ocaml-safepass}.
 
 We can now write the encrypted password in our database
-(using <<a_api project="ocsigenserver"| type Ocsipersist.table >>
+(using {!Ocsipersist.table}
 in this example) as follow:
-<<code language="ocaml"|
+{@ocaml[
 let table =
   Ocsipersist.Polymorphic.open_table "users"
 
@@ -20,8 +20,8 @@ let add_user username password =
       | Not_found ->
         Ocsipersist.Polymorphic.add table username
           (Bcrypt.hash password, email)
-        ~>>= fun () ->
+        >>= fun () ->
         Lwt.return true
       | e -> Lwt.fail e
     )
->>
+]}
diff --git a/tutos/dev/manual/how-do-i-create-a-cryptographically-safe-identifier.mld b/tutos/dev/manual/how-do-i-create-a-cryptographically-safe-identifier.mld
new file mode 100644
index 00000000..5f62d904
--- /dev/null
+++ b/tutos/dev/manual/how-do-i-create-a-cryptographically-safe-identifier.mld
@@ -0,0 +1,3 @@
+{0 How do I create a cryptographically safe identifier?}
+
+{!Ocsigen_base.Lib.make_cryptographic_safe_string}
diff --git a/tutos/dev/manual/how-do-i-create-a-cryptographically-safe-identifier.wiki b/tutos/dev/manual/how-do-i-create-a-cryptographically-safe-identifier.wiki
deleted file mode 100644
index e49ead9f..00000000
--- a/tutos/dev/manual/how-do-i-create-a-cryptographically-safe-identifier.wiki
+++ /dev/null
@@ -1,3 +0,0 @@
-== How do I create a cryptographically safe identifier? ==
-
-<<a_api project="ocsigenserver"| val  Ocsigen_base.Lib.make_cryptographic_safe_string>>
diff --git a/tutos/dev/manual/how-does-a-page-s-source-code-look.mld b/tutos/dev/manual/how-does-a-page-s-source-code-look.mld
new file mode 100644
index 00000000..8674a2f7
--- /dev/null
+++ b/tutos/dev/manual/how-does-a-page-s-source-code-look.mld
@@ -0,0 +1,81 @@
+{0 How does a client-server app source code look like?}
+
+{2 Eliom client-server applications}
+
+Eliom client-server applications are running in your browser for a {{:../eliom/clientserver-applications.html}certain lifetime} and consist of one or several pages/URLs.
+An application has its associated js file, which must have the same name ({{:../manual/how-to-compile-my-ocsigen-pages}generated automatically by the default makefile} and added automatically by Eliom in the page).
+
+For example, we define an application called {e example}:
+{@ocaml[
+module Example =
+  Eliom.Registration.App
+    (struct
+      let application_name = "example"
+     end)
+]}
+
+{2 Eliom Services}
+
+Pages are generated by {e services}. Here is how to define a service:
+
+{@ocaml[
+let main =
+  Eliom.Service.create
+    ~path:(Eliom.Service.Path [])
+    ~meth:(Eliom.Service.Get unit)
+    ()
+]}
+
+The path is a list of string corresponding to the url. Here, the list is empty because it's the main page.
+
+If, for example, the list is ["hello";"world"], the page will be accessed using the address:
+{[http://website.com/hello/world/]}
+
+More information about parameters: {{:wiki:manual/how-to-use-get-parameters-or-parameters-in-the-url}How to use GET parameters (parameters in the URL)?}
+
+Now that our service has been declared, we associate to it an OCaml function that will generate the page. We call this {e service registration}. If the service belongs to the application, we use the registrations functions from module [Example] defined above.
+
+{@ocaml[
+let _ =
+  Example.register
+    ~service:main
+    (fun () () ->
+      Lwt.return ...)
+]}
+
+The third parameter is the function that will be called to generate the page.
+This function takes two parameters, corresponding respectively to GET and POST parameters. Here both are [()] because the service does not take any parameter. The function returns an element of type html (using Lwt).
+
+
+{2 Page Content}
+
+The content of Eliom application pages is made using functions.
+The {b html function} takes two parameters:
+head and body, which are also functions that takes parameters coresponding to their content.
+
+{@ocaml[
+(html
+           (head (title (txt "Page Title")) [])
+           (body [p [txt "Hello World!"]])))
+]}
+
+Most of the elements functions take a list of other elements as a parameter.
+
+{%wodoc:img src="http://public.db0.fr/dev/ocsigen/html.png" alt="ast"%}
+
+Validity of HTML is checked at compile time, which means that a program
+that may generate a page that does not respect the recommendations of the
+W3C will be rejected at compile time.
+
+{2 Download full code}
+
+{e Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.}
+
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/page/example.eliom}Read the full code}
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto}Download and try this example}
+
+
+{2 Links}
+
+- {{:../eliom/server-services.html}About services}
+- {{:../tyxml/.html}About html generation}
diff --git a/tutos/dev/manual/how-does-a-page-s-source-code-look.wiki b/tutos/dev/manual/how-does-a-page-s-source-code-look.wiki
deleted file mode 100644
index ae9ca35d..00000000
--- a/tutos/dev/manual/how-does-a-page-s-source-code-look.wiki
+++ /dev/null
@@ -1,81 +0,0 @@
-=How does a client-server app source code look like?=
-
-=== Eliom client-server applications
-
-Eliom client-server applications are running in your browser for a <<a_manual project="eliom" chapter="clientserver-applications"|certain lifetime>> and consist of one or several pages/URLs.
-An application has its associated js file, which must have the same name ([[site:manual/how-to-compile-my-ocsigen-pages|generated automatically by the default makefile]] and added automatically by Eliom in the page).
-
-For example, we define an application called //example//:
-<<code language="ocaml"|
-module Example =
-  Eliom.Registration.App
-    (struct
-      let application_name = "example"
-     end)
->>
-
-=== Eliom Services
-
-Pages are generated by //services//. Here is how to define a service:
-
-<<code language="ocaml"|
-let main =
-  Eliom.Service.create
-    ~path:(Eliom.Service.Path [])
-    ~meth:(Eliom.Service.Get unit)
-    ()
->>
-
-The path is a list of string corresponding to the url. Here, the list is empty because it's the main page.
-
-If, for example, the list is ["hello";"world"], the page will be accessed using the address:
-<<code|http://website.com/hello/world/>>
-
-More information about parameters: [[wiki:manual/how-to-use-get-parameters-or-parameters-in-the-url|How to use GET parameters (parameters in the URL)?]]
-
-Now that our service has been declared, we associate to it an OCaml function that will generate the page. We call this //service registration//. If the service belongs to the application, we use the registrations functions from module {{{Example}}} defined above.
-
-<<code language="ocaml"|
-let _ =
-  Example.register
-    ~service:main
-    (fun () () ->
-      Lwt.return ...)
->>
-
-The third parameter is the function that will be called to generate the page.
-This function takes two parameters, corresponding respectively to GET and POST parameters. Here both are {{{()}}} because the service does not take any parameter. The function returns an element of type html (using Lwt).
-
-
-=== Page Content
-
-The content of Eliom application pages is made using functions.
-The **html function** takes two parameters:
-head and body, which are also functions that takes parameters coresponding to their content.
-
-<<code language="ocaml"|
-(html
-           (head (title (txt "Page Title")) [])
-           (body [p [txt "Hello World!"]])))
->>
-
-Most of the elements functions take a list of other elements as a parameter.
-
-{{http://public.db0.fr/dev/ocsigen/html.png|ast}}
-
-Validity of HTML is checked at compile time, which means that a program
-that may generate a page that does not respect the recommendations of the
-W3C will be rejected at compile time.
-
-=== Download full code
-
-//Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.//
-
-* [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/page/example.eliom|Read the full code]]
-* [[https://github.com/db0company/Ocsigen-Quick-Howto|Download and try this example]]
-
-
-=== Links
-
-* <<a_manual project="eliom" chapter="server-services"|About services>>
-* <<a_manual project="tyxml"|About html generation>>
diff --git a/tutos/dev/manual/how-to-add-a-div.mld b/tutos/dev/manual/how-to-add-a-div.mld
new file mode 100644
index 00000000..bb28a08b
--- /dev/null
+++ b/tutos/dev/manual/how-to-add-a-div.mld
@@ -0,0 +1,25 @@
+{0 How to add a div?}
+
+{@ocaml[
+div ~a:[a_class ["firstclass"; "secondclass"]] [txt "Hello!"]
+]}
+
+{b Required parameter}: list containing other elements
+(Details of available elements in type
+{!Html_types.flow5}).
+
+{b Optional parameter} for attributes "a" ({{:wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements}How to set and id, classes or other attributes to HTML elements?}).
+
+{2 Download full code}
+
+{e Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.}
+
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/elements/example.eliom}Read the full code}
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto}Download and try this example}
+
+{2 Links}
+
+- Modules {!Eliom.Content.Html.D} and
+  {!Eliom.Content.Html.F}
+  (HTML5 Elements)
+- signature {!Html_sigs.T} (Element attributes)
diff --git a/tutos/dev/manual/how-to-add-a-div.wiki b/tutos/dev/manual/how-to-add-a-div.wiki
deleted file mode 100644
index e2b12c8f..00000000
--- a/tutos/dev/manual/how-to-add-a-div.wiki
+++ /dev/null
@@ -1,25 +0,0 @@
-=How to add a div?=
-
-<<code language='ocaml'|
-div ~a:[a_class ["firstclass"; "secondclass"]] [txt "Hello!"]
->>
-
-**Required parameter**: list containing other elements
-(Details of available elements in type
-<<a_api project="tyxml"|type Html_types.flow5>>).
-
-**Optional parameter** for attributes "a" ([[wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements|How to set and id, classes or other attributes to HTML elements?]]).
-
-=== Download full code
-
-//Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.//
-
-* [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/elements/example.eliom|Read the full code]]
-* [[https://github.com/db0company/Ocsigen-Quick-Howto|Download and try this example]]
-
-=== Links
-
-* Modules <<a_api project="eliom" subproject="server"|module Eliom.Content.Html.D>> and
-  <<a_api project="eliom" subproject="server"|module Eliom.Content.Html.F>>
-  (HTML5 Elements)
-* signature <<a_api project="tyxml"|module Html_sigs.T>> (Element attributes)
diff --git a/tutos/dev/manual/how-to-add-a-favicon.mld b/tutos/dev/manual/how-to-add-a-favicon.mld
new file mode 100644
index 00000000..13710144
--- /dev/null
+++ b/tutos/dev/manual/how-to-add-a-favicon.mld
@@ -0,0 +1,16 @@
+{0 How to add a Favicon?}
+
+A favicon is a file of type "ico" which contain a picture of size 16x16px. It is the picture that you can ususally see next to the title of the page on a browser.
+
+{%wodoc:img src="http://public.db0.fr/dev/ocsigen/favicon.png" alt="favicon for Ocsigen.org"%}
+
+By default, all browsers look for a file [favicon.ico]
+at the root of the website:
+{[ http://website.com/favicon.ico]}
+
+Just put the file at the root of the static directory set in the configuration file.
+
+{2 Links}
+
+- {{:../ocsigenserver/staticmod.html}Configuring Ocsigen Server for serving static files}
+- {{:http://www.favicon.cc/}An example of a favicon generator}
diff --git a/tutos/dev/manual/how-to-add-a-favicon.wiki b/tutos/dev/manual/how-to-add-a-favicon.wiki
deleted file mode 100644
index f8f76df9..00000000
--- a/tutos/dev/manual/how-to-add-a-favicon.wiki
+++ /dev/null
@@ -1,16 +0,0 @@
-=How to add a Favicon?=
-
-A favicon is a file of type "ico" which contain a picture of size 16x16px. It is the picture that you can ususally see next to the title of the page on a browser.
-
-{{http://public.db0.fr/dev/ocsigen/favicon.png|favicon for Ocsigen.org}}
-
-By default, all browsers look for a file {{{favicon.ico}}}
-at the root of the website:
-<<code| http://website.com/favicon.ico>>
-
-Just put the file at the root of the static directory set in the configuration file.
-
-=== Links
-
-* <<a_manual project="ocsigenserver" chapter="staticmod"|Configuring Ocsigen Server for serving static files>>
-* [[http://www.favicon.cc/|An example of a favicon generator]]
diff --git a/tutos/dev/manual/how-to-add-a-javascript-script.mld b/tutos/dev/manual/how-to-add-a-javascript-script.mld
new file mode 100644
index 00000000..9181e4d9
--- /dev/null
+++ b/tutos/dev/manual/how-to-add-a-javascript-script.mld
@@ -0,0 +1,30 @@
+{0 How to add a JavaScript script?}
+
+If you have client-side programs on your website, you can use Eliom's client-server features, that will compile client-side parts to JS using {b Ocsigen Js_of_ocaml}, and automatically include the script in the page. But in some cases you may also want to include external JS scripts yourself.
+
+{2 Include the script in the HTML header}
+
+Javascript scripts are included in the header using the {b js_script} function (defined in {!Eliom.Content.Html.D}).
+
+{@ocaml[
+open Eliom.Content.Html.D (* for make_uri an js_script *)
+
+js_script
+     ~uri:(make_uri (Eliom.Service.static_dir ())
+              ["hello.js"])
+     ()
+]}
+This function has 2 parameters: the file path and unit.
+
+The file path is generated using the {b make_uri} function (from {!Eliom.Content.Html.D} module). This function creates the relative URL string using the static directory (which is a service) configured in the configuration file and the given list.
+
+Insert this piece of code on the list given in parameter to the {b head} function.
+
+Or you can use:
+{!Eliom.Tools.F.head}
+
+{2 Call an external function}
+
+Have a look at
+{{:../js_of_ocaml/bindings.html}this page of Js_of_ocaml's manual}
+to understand how to call JS function from your OCaml program.
diff --git a/tutos/dev/manual/how-to-add-a-javascript-script.wiki b/tutos/dev/manual/how-to-add-a-javascript-script.wiki
deleted file mode 100644
index 1dd2ab42..00000000
--- a/tutos/dev/manual/how-to-add-a-javascript-script.wiki
+++ /dev/null
@@ -1,30 +0,0 @@
-=How to add a JavaScript script?=
-
-If you have client-side programs on your website, you can use Eliom's client-server features, that will compile client-side parts to JS using **Ocsigen Js_of_ocaml**, and automatically include the script in the page. But in some cases you may also want to include external JS scripts yourself.
-
-=== Include the script in the HTML header
-
-Javascript scripts are included in the header using the **js_script** function (defined in <<a_api project="eliom" subproject="server"| module Eliom.Content.Html.D>>).
-
-<<code language="ocaml"|
-open Eliom.Content.Html.D (* for make_uri an js_script *)
-
-js_script
-     ~uri:(make_uri (Eliom.Service.static_dir ())
-              ["hello.js"])
-     ()
->>
-This function has 2 parameters: the file path and unit.
-
-The file path is generated using the **make_uri** function (from <<a_api project="eliom" subproject="server"| module Eliom.Content.Html.D>> module). This function creates the relative URL string using the static directory (which is a service) configured in the configuration file and the given list.
-
-Insert this piece of code on the list given in parameter to the **head** function.
-
-Or you can use:
-<<a_api project="eliom" subproject="server"|val Eliom.Tools.F.head>>
-
-=== Call an external function
-
-Have a look at
-<<a_manual project="js_of_ocaml" chapter="bindings"|this page of Js_of_ocaml's manual>>
-to understand how to call JS function from your OCaml program.
diff --git a/tutos/dev/manual/how-to-add-a-list.mld b/tutos/dev/manual/how-to-add-a-list.mld
new file mode 100644
index 00000000..f20e65d7
--- /dev/null
+++ b/tutos/dev/manual/how-to-add-a-list.mld
@@ -0,0 +1,70 @@
+{0 How to add lists in a page?}
+
+{3 Simple list and ordered list}
+
+{4 Simple list}
+
+{@ocaml[
+  ul
+    [li [txt "first item"];
+     li [txt "second item"];
+     li [txt "third item"];
+     li [txt "fourth item"]]
+]}
+
+
+{4 Ordered list}
+
+{@ocaml[
+  ol
+    [li [txt "first item"];
+     li [txt "second item"]]
+]}
+
+{b Required parameter}: list containing {b li} elements ({{:../tyxml/api/Html_types#TYPEli_attrib}Details of li content}).
+
+{b Optional parameter} for attributes "a" ({{:wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements}How to set and id, classes or other attributes to HTML elements?}).
+
+{3 Definition list}
+
+{@ocaml[
+  dl
+    [((dt [txt "Banana"], []),
+      (dd [txt "An elongated curved fruit"], []));
+     ((dt [txt "Orange"], []),
+      (dd [txt "A globose, reddish-yellow, edible fruit"],
+       [dd [txt "A color between yellow and red"]]));
+     ((dt [txt "Kiwi"], []),
+      (dd [txt "Egg-sized green fruit from China"], []))]
+]}
+
+This kind of list contains definitions.
+
+{b Required parameter}:
+A list of pair of:
+- A pair containing:
+- The first element of type dt
+- A list of elements of type dt
+- Another pair containing:
+- The first element of type dd
+- A list of elements of type dd
+
+Details:
+- {{:../tyxml/api/Html_types#TYPEphrasing}dd content}
+- {{:../tyxml/api/Html_types#TYPEflow5}dt content}
+
+{b Optional parameter} for attributes "a" ({{:wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements}How to set and id, classes or other attributes to HTML elements?}).
+
+{2 Download full code}
+
+{e Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.}
+
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/elements/example.eliom}Read the full code}
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto}Download and try this example}
+
+{2 Links}
+
+- Modules {!Eliom.Content.Html.D} and
+  {!Eliom.Content.Html.F}
+  (HTML5 Elements)
+- signature {!Html_sigs.T} (Element attributes)
diff --git a/tutos/dev/manual/how-to-add-a-list.wiki b/tutos/dev/manual/how-to-add-a-list.wiki
deleted file mode 100644
index fc27a772..00000000
--- a/tutos/dev/manual/how-to-add-a-list.wiki
+++ /dev/null
@@ -1,70 +0,0 @@
-=How to add lists in a page?=
-
-==== Simple list and ordered list
-
-===== Simple list
-
-<<code language='ocaml'|
-  ul
-    [li [txt "first item"];
-     li [txt "second item"];
-     li [txt "third item"];
-     li [txt "fourth item"]]
->>
-
-
-===== Ordered list
-
-<<code language='ocaml'|
-  ol
-    [li [txt "first item"];
-     li [txt "second item"]]
->>
-
-**Required parameter**: list containing **li** elements ([[site:tyxml/api/Html_types#TYPEli_attrib|Details of li content]]).
-
-**Optional parameter** for attributes "a" ([[wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements|How to set and id, classes or other attributes to HTML elements?]]).
-
-==== Definition list
-
-<<code language='ocaml'|
-  dl
-    [((dt [txt "Banana"], []),
-      (dd [txt "An elongated curved fruit"], []));
-     ((dt [txt "Orange"], []),
-      (dd [txt "A globose, reddish-yellow, edible fruit"],
-       [dd [txt "A color between yellow and red"]]));
-     ((dt [txt "Kiwi"], []),
-      (dd [txt "Egg-sized green fruit from China"], []))]
->>
-
-This kind of list contains definitions.
-
-**Required parameter**:
-A list of pair of:
-* A pair containing:
-** The first element of type dt
-** A list of elements of type dt
-* Another pair containing:
-** The first element of type dd
-** A list of elements of type dd
-
-Details:
-* [[site:tyxml/api/Html_types#TYPEphrasing|dd content]]
-* [[site:tyxml/api/Html_types#TYPEflow5|dt content]]
-
-**Optional parameter** for attributes "a" ([[wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements|How to set and id, classes or other attributes to HTML elements?]]).
-
-=== Download full code
-
-//Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.//
-
-* [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/elements/example.eliom|Read the full code]]
-* [[https://github.com/db0company/Ocsigen-Quick-Howto|Download and try this example]]
-
-=== Links
-
-* Modules <<a_api project="eliom" subproject="server"|module Eliom.Content.Html.D>> and
-  <<a_api project="eliom" subproject="server"|module Eliom.Content.Html.F>>
-  (HTML5 Elements)
-* signature <<a_api project="tyxml"|module Html_sigs.T>> (Element attributes)
diff --git a/tutos/dev/manual/how-to-add-a-select-or-other-form-element.wiki b/tutos/dev/manual/how-to-add-a-select-or-other-form-element.mld
similarity index 61%
rename from tutos/dev/manual/how-to-add-a-select-or-other-form-element.wiki
rename to tutos/dev/manual/how-to-add-a-select-or-other-form-element.mld
index cc2cbc34..f05e7b8c 100644
--- a/tutos/dev/manual/how-to-add-a-select-or-other-form-element.wiki
+++ b/tutos/dev/manual/how-to-add-a-select-or-other-form-element.mld
@@ -1,8 +1,8 @@
-=How to add a select (or other form element)?=
+{0 How to add a select (or other form element)?}
 
-=== In forms towards Eliom services:
+{2 In forms towards Eliom services:}
 
-<<code language='ocaml'|
+{@ocaml[
 open Eliom.Content
 
 Html.D.Form.select ~name:select_name
@@ -20,23 +20,23 @@ Html.D.Form.select ~name:select_name
          [([a_disabled `Disabled], "Juliette", None, false);
           ([], "Alice", None, true);
           ([], "Germaine", Some (txt "Bob's mother"), false)]))]
->>
+]}
 
-=== Basic HTML5 elements without Eliom services
+{2 Basic HTML5 elements without Eliom services}
 For example if you want to use them with client side event handler.
 
-<<code language='ocaml'|
+{@ocaml[
 open Eliom.Content.Html.D
 
 Raw.select [option (txt "hello");
             option ~a:[a_value "a"; a_selected `Selected] (txt "cool")]
->>
+]}
 
 
-=== Links
+{2 Links}
 
-* [[wiki:manual/how-to-write-forms|How to write forms]]
-* <<a_manual project="eliom" chapter="server-links"|Eliom forms and links>>
-* API
-  <<a_api project="eliom" subproject="server"|module Eliom.Content.Html.D.Form>>
-* signature <<a_api project="tyxml"|module Html_sigs.T>> (Element attributes)
+- {{:wiki:manual/how-to-write-forms}How to write forms}
+- {{:../eliom/server-links.html}Eliom forms and links}
+- API
+  {!Eliom.Content.Html.D.Form}
+- signature {!Html_sigs.T} (Element attributes)
diff --git a/tutos/dev/manual/how-to-add-an-image.mld b/tutos/dev/manual/how-to-add-an-image.mld
new file mode 100644
index 00000000..f4641d90
--- /dev/null
+++ b/tutos/dev/manual/how-to-add-an-image.mld
@@ -0,0 +1,46 @@
+{0 How to add an image?}
+
++ Internal image
+
+{@ocaml[
+  img ~alt:("Ocsigen Logo")
+      ~src:(make_uri
+              ~service:(Eliom.Service.static_dir ())
+              ["ocsigen_logo.png"])
+    ()
+
+]}
+
++ External image
+
+{@ocaml[
+  img ~alt:("Ocsigen Logo")
+      ~src:(Xml.uri_of_string ("http://website.com/image.png"))
+    ()
+]}
+
+
+The function {b img} has 3 parameters:
+- {b alt}: A description of the image
+- {b src}: the URL of the image
+- unit
+
+For an internal image, the file path is generated using the {b make_uri} function. This function creates the relative URL string using the static directory configured in the configuration file and the given list.
+
+For an external image, you must convert the string url into uri using the {b uri_of_string} function. You can also create an {{:../eliom/server-services.html#unregistrable_services}external service}.
+
+{2 Download full code}
+
+{e Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.}
+
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/elements/example.eliom}Read the full code}
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto}Download and try this example}
+
+{2 Links}
+
+- Modules {!Eliom.Content.Html.D} and
+  {!Eliom.Content.Html.F}
+  (HTML5 Elements)
+- The {!Html_sigs.T.img} element
+- {{:http://en.wikipedia.org/wiki/Alt_attribute}Alt attribute}
+- signature {!Html_sigs.T} (Element attributes)
diff --git a/tutos/dev/manual/how-to-add-an-image.wiki b/tutos/dev/manual/how-to-add-an-image.wiki
deleted file mode 100644
index 14c20034..00000000
--- a/tutos/dev/manual/how-to-add-an-image.wiki
+++ /dev/null
@@ -1,46 +0,0 @@
-=How to add an image?=
-
-#### Internal image
-
-<<code language='ocaml'|
-  img ~alt:("Ocsigen Logo")
-      ~src:(make_uri
-              ~service:(Eliom.Service.static_dir ())
-              ["ocsigen_logo.png"])
-    ()
-
->>
-
-#### External image
-
-<<code language='ocaml'|
-  img ~alt:("Ocsigen Logo")
-      ~src:(Xml.uri_of_string ("http://website.com/image.png"))
-    ()
->>
-
-
-The function **img** has 3 parameters:
-* **alt**: A description of the image
-* **src**: the URL of the image
-* unit
-
-For an internal image, the file path is generated using the **make_uri** function. This function creates the relative URL string using the static directory configured in the configuration file and the given list.
-
-For an external image, you must convert the string url into uri using the **uri_of_string** function. You can also create an <<a_manual project="eliom" chapter="server-services" fragment="unregistrable_services"|external service>>.
-
-=== Download full code
-
-//Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.//
-
-* [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/elements/example.eliom|Read the full code]]
-* [[https://github.com/db0company/Ocsigen-Quick-Howto|Download and try this example]]
-
-=== Links
-
-* Modules <<a_api project="eliom" subproject="server"|module Eliom.Content.Html.D>> and
-  <<a_api project="eliom" subproject="server"|module Eliom.Content.Html.F>>
-  (HTML5 Elements)
-* The <<a_api project="tyxml"|val Html_sigs.T.img>> element
-* [[http://en.wikipedia.org/wiki/Alt_attribute|Alt attribute]]
-* signature <<a_api project="tyxml"|module Html_sigs.T>> (Element attributes)
diff --git a/tutos/dev/manual/how-to-add-css-stylesheet.mld b/tutos/dev/manual/how-to-add-css-stylesheet.mld
new file mode 100644
index 00000000..f7726712
--- /dev/null
+++ b/tutos/dev/manual/how-to-add-css-stylesheet.mld
@@ -0,0 +1,45 @@
+{0 How to add a CSS stylesheet?}
+
+{e Warning: css_link and make_uri come from Eliom.Content.Html.D module. This module is opened for each piece of code}
+
+CSS stylesheet are included in the header using the {b css_link} function.
+
+{@ocaml[
+css_link
+     ~uri:(make_uri (Eliom.Service.static_dir ())
+              ["css";"style.css"])
+     ()
+]}
+This function has 2 parameters: the file path and unit.
+
+The file path is generated using the {b make_uri} function. This function creates the relative URL string using the static directory configured in the configuration file and the given list.
+
+{2 Where?}
+
+Insert this piece of code on the list given in parameter to the {b head} function:
+
+{@ocaml[
+  (html
+     (head (title (txt "Page Title"))
+        [css_link ~uri:(make_uri (Eliom.Service.static_dir ())
+	        	  ["css";"style.css"]) ()])
+     (body [p [txt "Hello World!"]]))))
+]}
+
+Or you can use:
+{!Eliom.Tools.F.head}
+
+
+
+{2 Download full code}
+
+{e Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.}
+
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/css/example.eliom}Read the full code}
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto}Download and try this example}
+
+{2 Links}
+
+- {{:../eliom/misc.html}About images, css and javascript}
+- {!Eliom.Content.Html.D.make_uri}
+- {{:../ocsigenserver/staticmod.html}Configuring Ocsigen Server for serving static files}
diff --git a/tutos/dev/manual/how-to-add-css-stylesheet.wiki b/tutos/dev/manual/how-to-add-css-stylesheet.wiki
deleted file mode 100644
index 2207aeed..00000000
--- a/tutos/dev/manual/how-to-add-css-stylesheet.wiki
+++ /dev/null
@@ -1,45 +0,0 @@
-=How to add a CSS stylesheet?=
-
-//Warning: css_link and make_uri come from Eliom.Content.Html.D module. This module is opened for each piece of code//
-
-CSS stylesheet are included in the header using the **css_link** function.
-
-<<code language="ocaml"|
-css_link
-     ~uri:(make_uri (Eliom.Service.static_dir ())
-              ["css";"style.css"])
-     ()
->>
-This function has 2 parameters: the file path and unit.
-
-The file path is generated using the **make_uri** function. This function creates the relative URL string using the static directory configured in the configuration file and the given list.
-
-=== Where?
-
-Insert this piece of code on the list given in parameter to the **head** function:
-
-<<code language="ocaml"|
-  (html
-     (head (title (txt "Page Title"))
-        [css_link ~uri:(make_uri (Eliom.Service.static_dir ())
-	        	  ["css";"style.css"]) ()])
-     (body [p [txt "Hello World!"]]))))
->>
-
-Or you can use:
-<<a_api project="eliom" subproject="server"|val Eliom.Tools.F.head>>
-
-
-
-=== Download full code
-
-//Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.//
-
-* [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/css/example.eliom|Read the full code]]
-* [[https://github.com/db0company/Ocsigen-Quick-Howto|Download and try this example]]
-
-=== Links
-
-* <<a_manual project="eliom" chapter="misc"|About images, css and javascript>>
-* <<a_api project="eliom" subproject="server" |val Eliom.Content.Html.D.make_uri>>
-* <<a_manual project="ocsigenserver" chapter="staticmod"|Configuring Ocsigen Server for serving static files>>
diff --git a/tutos/8.0/manual/how-to-attach-ocaml-values-to-dom-elements.wiki b/tutos/dev/manual/how-to-attach-ocaml-values-to-dom-elements.mld
similarity index 52%
rename from tutos/8.0/manual/how-to-attach-ocaml-values-to-dom-elements.wiki
rename to tutos/dev/manual/how-to-attach-ocaml-values-to-dom-elements.mld
index 797c11d2..b0297293 100644
--- a/tutos/8.0/manual/how-to-attach-ocaml-values-to-dom-elements.wiki
+++ b/tutos/dev/manual/how-to-attach-ocaml-values-to-dom-elements.mld
@@ -1,14 +1,14 @@
-=How to attach OCaml values to DOM elements?=
+{0 How to attach OCaml values to DOM elements?}
 
 It is often convenient to attach OCaml values to certain elements of
 the page. There are several ways to achieve this.
 
-* The first possibility is to use DATA attributes (for example if the
+- The first possibility is to use DATA attributes (for example if the
   page is generated on server side).
-* Alternatively, you can add a new property to the element using the
-  {{{##.}}} syntax.
-  ** You can create a new class type with the new property
+- Alternatively, you can add a new property to the element using the
+  [##.] syntax.
+- You can create a new class type with the new property
      (that can be either an OCaml value or a JS value), possibly
      inheriting from the type of the DOM element, and create an
      (unsafe) coercion function for this type; or simply
-  ** Create getter and setter functions to add the new property.
+- Create getter and setter functions to add the new property.
diff --git a/tutos/dev/manual/how-to-attach-ocaml-values-to-the-html-nodes-sent-to-the-client.mld b/tutos/dev/manual/how-to-attach-ocaml-values-to-the-html-nodes-sent-to-the-client.mld
new file mode 100644
index 00000000..7ad8cb9d
--- /dev/null
+++ b/tutos/dev/manual/how-to-attach-ocaml-values-to-the-html-nodes-sent-to-the-client.mld
@@ -0,0 +1,3 @@
+{0 How to attach OCaml values to the HTML nodes sent to the client?}
+
+Use module {!Eliom.Content.Html.Custom_data}.
diff --git a/tutos/dev/manual/how-to-attach-ocaml-values-to-the-html-nodes-sent-to-the-client.wiki b/tutos/dev/manual/how-to-attach-ocaml-values-to-the-html-nodes-sent-to-the-client.wiki
deleted file mode 100644
index 9fb42e77..00000000
--- a/tutos/dev/manual/how-to-attach-ocaml-values-to-the-html-nodes-sent-to-the-client.wiki
+++ /dev/null
@@ -1,3 +0,0 @@
-== How to attach OCaml values to the HTML nodes sent to the client?
-
-Use module <<a_api project="eliom" subproject="server"|module Eliom.Content.Html.Custom_data>>.
diff --git a/tutos/dev/manual/how-to-build-js-object.mld b/tutos/dev/manual/how-to-build-js-object.mld
new file mode 100644
index 00000000..d6035f90
--- /dev/null
+++ b/tutos/dev/manual/how-to-build-js-object.mld
@@ -0,0 +1,13 @@
+{0 How to build js object?}
+
+Use syntax [new%js]:
+
+Example:
+
+{@ocaml[
+let get_timestamp () =
+  let date = new%js Js.date_now in
+  int_of_float (Js.to_float (date##getTime))
+]}
+
+More details in documentation: {{!Js_of_ocaml.Js.constr}Js object constructor}
diff --git a/tutos/dev/manual/how-to-build-js-object.wiki b/tutos/dev/manual/how-to-build-js-object.wiki
deleted file mode 100644
index 7d68c627..00000000
--- a/tutos/dev/manual/how-to-build-js-object.wiki
+++ /dev/null
@@ -1,13 +0,0 @@
-=How to build js object?=
-
-Use syntax {{{new%js}}}:
-
-Example:
-
-<<code language="ocaml"|
-let get_timestamp () =
-  let date = new%js Js.date_now in
-  int_of_float (Js.to_float (date##getTime))
->>
-
-More details in documentation: <<a_api project="js_of_ocaml" text="Js object constructor"|val Js_of_ocaml.Js.constr>>
diff --git a/tutos/8.0/manual/how-to-call-a-server-side-function-from-client-side.wiki b/tutos/dev/manual/how-to-call-a-server-side-function-from-client-side.mld
similarity index 52%
rename from tutos/8.0/manual/how-to-call-a-server-side-function-from-client-side.wiki
rename to tutos/dev/manual/how-to-call-a-server-side-function-from-client-side.mld
index ae2a580a..79598f08 100644
--- a/tutos/8.0/manual/how-to-call-a-server-side-function-from-client-side.wiki
+++ b/tutos/dev/manual/how-to-call-a-server-side-function-from-client-side.mld
@@ -1,36 +1,38 @@
-=How to call a server-side function from client-side?=
+{0 How to call a server-side function from client-side?}
 
 It is possible to call server-side functions from client-side.
 For security reasons, these functions must first
 be declared explicitly as RPCs (with the type of their
 argument).
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc f (x : int) : string Lwt.t = ...
 ...
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 [%client ... f 4 ... ]
->>
+]}
 
-The syntax is provided by opam package {{{ocsigen-ppx-rpc}}}.
+The syntax is provided by opam package [ocsigen-ppx-rpc].
 
-The server-side function ({{{f}}} in the example) needs to return a
+The server-side function ([f] in the example) needs to return a
 Lwt value.
 
 Server functions are just syntactic sugar for pathless services
 returning OCaml values.
 
-Note that you need to install {{{ppx_deriving}}}, and load our JSON
-{{{ppx_deriving}}} plugin in your project. The plugin is available as
-the Ocamlfind package {{{js_of_ocaml.deriving.ppx}}}.
+Note that you need to install [ppx_deriving], and load our JSON
+[ppx_deriving] plugin in your project. The plugin is available as
+the Ocamlfind package [js_of_ocaml.deriving.ppx].
 
 If the function takes a more complex type, this type must have been
-declared with {{{ppx_deriving}}}. For example,
+declared with [ppx_deriving]. For example,
 
-<<code language="ocaml"|
+{@ocaml[
 type t = int * string [@@deriving json]
->>
+]}
 
 Our infrastructure provides server-side data validation of the data
 sent, and prevents malformed data from crashing the server.
diff --git a/tutos/dev/manual/how-to-call-an-ocaml-function-from-js-code.mld b/tutos/dev/manual/how-to-call-an-ocaml-function-from-js-code.mld
new file mode 100644
index 00000000..5ef9e8a1
--- /dev/null
+++ b/tutos/dev/manual/how-to-call-an-ocaml-function-from-js-code.mld
@@ -0,0 +1,3 @@
+{0 How to call an OCaml function from JS code?}
+
+Have a look at function {!Js_of_ocaml.Js.wrap_callback}
diff --git a/tutos/dev/manual/how-to-call-an-ocaml-function-from-js-code.wiki b/tutos/dev/manual/how-to-call-an-ocaml-function-from-js-code.wiki
deleted file mode 100644
index 50adfdd1..00000000
--- a/tutos/dev/manual/how-to-call-an-ocaml-function-from-js-code.wiki
+++ /dev/null
@@ -1,3 +0,0 @@
-=How to call an OCaml function from JS code?=
-
-Have a look at function <<a_api project="js_of_ocaml" |val Js_of_ocaml.Js.wrap_callback>>
diff --git a/tutos/dev/manual/how-to-compile-my-ocsigen-pages.wiki b/tutos/dev/manual/how-to-compile-my-ocsigen-pages.mld
similarity index 50%
rename from tutos/dev/manual/how-to-compile-my-ocsigen-pages.wiki
rename to tutos/dev/manual/how-to-compile-my-ocsigen-pages.mld
index 1b47d6b4..c7def919 100644
--- a/tutos/dev/manual/how-to-compile-my-ocsigen-pages.wiki
+++ b/tutos/dev/manual/how-to-compile-my-ocsigen-pages.mld
@@ -1,45 +1,45 @@
-=How to compile my Ocsigen pages?=
+{0 How to compile my Ocsigen pages?}
 
-=== Eliom distillery
+{2 Eliom distillery}
 
 Eliom-distillery will help you to build your client-server application
 using Eliom.
 It comes with several templates ("client-server.basic", "os",
 and more to come  ...).
 
-{{{
+{v
 $ eliom-distillery -name <name> -template client-server.basic [-target-directory <dir>]
-}}}
+v}
 
 Eliom distillery will also create a default configuration file for Ocsigen
 Server.
 
 More information on Eliom distillery in
-<<a_manual project="eliom" subproject="server" chapter="workflow-distillery"|Eliom's manual>>.
+{{:../eliom/workflow-distillery.html}Eliom's manual}.
 
 More information on how client-server Eliom project are compiled on
-<<a_manual project="eliom" subproject="server" chapter="workflow-compilation"|this page>>.
+{{:../eliom/workflow-compilation.html}this page}.
 
 If you don't need client-server features, the compilation process is very
-simple and without surprise. Compile with {{{ocamlc}}} or {{{ocamlopt}}}
-using {{{ocamlfind}}}, with package {{{eliom.server}}}.
+simple and without surprise. Compile with [ocamlc] or [ocamlopt]
+using [ocamlfind], with package [eliom.server].
 You will have to create your configuration file manually.
 But you can still use Eliom distillery, which will make easier the inclusion
 of client side features, later.
 
 
-=== Compilation details
+{2 Compilation details}
 
-* **eliomdep** helps you handle dependencies of eliom files
-* **eliomc** compile server-side eliom files (and ml files too)
-* **js_of_eliom** compile client-side eliom files
+- {b eliomdep} helps you handle dependencies of eliom files
+- {b eliomc} compile server-side eliom files (and ml files too)
+- {b js_of_eliom} compile client-side eliom files
 
-Client code can also be compiled to **WebAssembly** using {{{wasm_of_ocaml}}}.
-Enable it by setting {{{ENABLE_WASM=yes}}} in {{{Makefile.options}}}.
+Client code can also be compiled to {b WebAssembly} using [wasm_of_ocaml].
+Enable it by setting [ENABLE_WASM=yes] in [Makefile.options].
 The server will automatically detect browser capabilities and serve the appropriate version.
 
 Read manuals for mor information about these compilers.
 
-=== Links
+{2 Links}
 
-* <<a_manual project="eliom" chapter="workflow-compilation" |Full documentation about Ocsigen compilation>>
+- {{:../eliom/workflow-compilation.html}Full documentation about Ocsigen compilation}
diff --git a/tutos/dev/manual/how-to-configure-and-launch-the-ocsigen-server.mld b/tutos/dev/manual/how-to-configure-and-launch-the-ocsigen-server.mld
new file mode 100644
index 00000000..6021acab
--- /dev/null
+++ b/tutos/dev/manual/how-to-configure-and-launch-the-ocsigen-server.mld
@@ -0,0 +1,23 @@
+{0 How to configure and launch the Ocsigen Server?}
+
+{2 Default configuration file}
+
+- Eliom distillery is generating a configuration file
+- If you want to create it yourself, you can have a look at the default configuration file provided with the installation of Ocsigen (usually [/etc/ocsigenserver/ocsigenserver.conf.sample]).
+- Change the port by the network port number you want your website to work on. The port {b 80} is the port used by http by default but you need to be the administrator of your server to use it.
+- Adapt paths.
+- Change other parameters that suit your needs using the {{:../ocsigenserver/config.html}configuration file documentation}.
+
+{2 Your own configuration file}
+
+Have a look at the {{:../ocsigenserver/config.html}configuration file full documentation}.
+
+{2 Launch the server}
+
+{[
+ocsigenserver -c your_config_file.conf
+]}
+
+{2 Links}
+
+- More information about this command or the configuration file in {{:../ocsigenserver/.html}Ocsigen Server's manual}.
diff --git a/tutos/dev/manual/how-to-configure-and-launch-the-ocsigen-server.wiki b/tutos/dev/manual/how-to-configure-and-launch-the-ocsigen-server.wiki
deleted file mode 100644
index 84ae6fca..00000000
--- a/tutos/dev/manual/how-to-configure-and-launch-the-ocsigen-server.wiki
+++ /dev/null
@@ -1,23 +0,0 @@
-=How to configure and launch the Ocsigen Server?=
-
-=== Default configuration file
-
-* Eliom distillery is generating a configuration file
-* If you want to create it yourself, you can have a look at the default configuration file provided with the installation of Ocsigen (usually {{{/etc/ocsigenserver/ocsigenserver.conf.sample}}}).
-* Change the port by the network port number you want your website to work on. The port **80** is the port used by http by default but you need to be the administrator of your server to use it.
-* Adapt paths.
-* Change other parameters that suit your needs using the <<a_manual project="ocsigenserver" chapter="config"|configuration file documentation>>.
-
-=== Your own configuration file
-
-Have a look at the <<a_manual project="ocsigenserver" chapter="config"|configuration file full documentation>>.
-
-=== Launch the server
-
-<<code |
-ocsigenserver -c your_config_file.conf
->>
-
-=== Links
-
-* More information about this command or the configuration file in <<a_manual project="ocsigenserver"|Ocsigen Server's manual>>.
diff --git a/tutos/dev/manual/how-to-create-form-wizard-sequence-of-pages-depending-on-data-entered-on-previous-ones.wiki b/tutos/dev/manual/how-to-create-form-wizard-sequence-of-pages-depending-on-data-entered-on-previous-ones.mld
similarity index 96%
rename from tutos/dev/manual/how-to-create-form-wizard-sequence-of-pages-depending-on-data-entered-on-previous-ones.wiki
rename to tutos/dev/manual/how-to-create-form-wizard-sequence-of-pages-depending-on-data-entered-on-previous-ones.mld
index eb7c2792..9a7d278d 100644
--- a/tutos/dev/manual/how-to-create-form-wizard-sequence-of-pages-depending-on-data-entered-on-previous-ones.wiki
+++ b/tutos/dev/manual/how-to-create-form-wizard-sequence-of-pages-depending-on-data-entered-on-previous-ones.mld
@@ -1,4 +1,4 @@
-=How to create a form wizard (sequence of pages depending on data entered on previous ones)?=
+{0 How to create a form wizard (sequence of pages depending on data entered on previous ones)?}
 
 The solution to implement wizard-like forms (that is a sequence of pages
 depending on data entered on previous ones) is to create dynamically new
@@ -15,7 +15,7 @@ To prevent memory leaks, use a timeout for these dynamic coservices.
 The scope of these service can be session or global for the site (as coservice
 identifiers are cryptographically safe).
 
-<<code language="ocaml"|
+{@ocaml[
 open Eliom.Content.Html.F
 
 (* -------------------------------------------------------- *)
@@ -85,4 +85,4 @@ let calc_i_handler i () =
 let () =
   Eliom.Registration.Html.register calc   calc_handler;
   Eliom.Registration.Html.register calc_i calc_i_handler
->>
+]}
diff --git a/tutos/dev/manual/how-to-create-link-to-a-current-page-without-knowing-its-url.mld b/tutos/dev/manual/how-to-create-link-to-a-current-page-without-knowing-its-url.mld
new file mode 100644
index 00000000..579290f7
--- /dev/null
+++ b/tutos/dev/manual/how-to-create-link-to-a-current-page-without-knowing-its-url.mld
@@ -0,0 +1,11 @@
+{0 How to create a link to the current page (without knowing its URL)?}
+
+Void coservices are here for that:
+{@ocaml[
+a ~service:Eliom.Service.reload_action
+  [txt "Click to reload"] ();
+]}
+
+More information in
+{{:../eliom/server-services.html#void}Eliom's manual}, and API documentation of
+{!Eliom.Service.reload_action}.
diff --git a/tutos/dev/manual/how-to-create-link-to-a-current-page-without-knowing-its-url.wiki b/tutos/dev/manual/how-to-create-link-to-a-current-page-without-knowing-its-url.wiki
deleted file mode 100644
index 3218d2bd..00000000
--- a/tutos/dev/manual/how-to-create-link-to-a-current-page-without-knowing-its-url.wiki
+++ /dev/null
@@ -1,11 +0,0 @@
-=How to create a link to the current page (without knowing its URL)?=
-
-Void coservices are here for that:
-<<code language="ocaml"|
-a ~service:Eliom.Service.reload_action
-  [txt "Click to reload"] ();
->>
-
-More information in
-<<a_manual project="eliom" chapter="server-services" fragment="void"|Eliom's manual>>, and API documentation of
-<<a_api project="eliom" subproject="server"|val Eliom.Service.reload_action>>.
diff --git a/tutos/dev/manual/how-to-detect-channel-disconnection.wiki b/tutos/dev/manual/how-to-detect-channel-disconnection.mld
similarity index 80%
rename from tutos/dev/manual/how-to-detect-channel-disconnection.wiki
rename to tutos/dev/manual/how-to-detect-channel-disconnection.mld
index df46a9de..688a1673 100644
--- a/tutos/dev/manual/how-to-detect-channel-disconnection.wiki
+++ b/tutos/dev/manual/how-to-detect-channel-disconnection.mld
@@ -1,24 +1,24 @@
-=How to detect channel disconnection
+{0 How to detect channel disconnection}
 
-==Question
+{1 Question}
 
  Is there a way to detect that some Eliom.Comet channel became
  disconnected? I would like to warn the user if the server becomes
  unreachable.
 
-==Answer
+{1 Answer}
 
 If you are using Ocsigen-start, you probably have nothing to do.
 Ocsigen-start will monitor the life of sessions and close the process
 when needed.
 
 If you are not using Ocsigen-start, you must catch exceptions
-{{{Eliom.Comet.Channel_full}}},
-{{{Eliom.Comet.Channel_closed}}} (and {{{Eliom.Comet.Process_closed}}}
+[Eliom.Comet.Channel_full],
+[Eliom.Comet.Channel_closed] (and [Eliom.Comet.Process_closed]
 on Eliom < 5). Have a look at module Os.Comet in
 Ocsigen-start.
 
-//explanation pasted from Ocsigen mailing list, 2014-08-06://
+{e explanation pasted from Ocsigen mailing list, 2014-08-06:}
 
 I assume that you want to know that from client side (it is also
 possible to know that on server side).
@@ -28,11 +28,11 @@ information through an exception when you try to read from the
 Lwt_stream. The different exceptions you have to handle depending on the
 case are:
 
-;{{{Eliom.Comet.Channel_full}}}
+;[Eliom.Comet.Channel_full]
 :For global channel. Those are never closed on server side and are not attached to a particular session. The server maintains a limited buffer of previous values to avoid memory leak. If a client reconnects to the network and too many messages have been sent to the channel since its last update, it will receive that exception.
-;{{{Eliom.Comet.Process_closed}}} (Eliom < 5)
+;[Eliom.Comet.Process_closed] (Eliom < 5)
 :For a channel associated to a client process. If the process is explicitly closed on the server, the server is rebooted, it timed out, ...
-;{{{Eliom.Comet.Channel_closed}}}
+;[Eliom.Comet.Channel_closed]
 :The channel was not maintained alive on the server (garbage collected).
 
 Usually it is just simpler to not distinguish and just catch all those
@@ -44,12 +44,12 @@ is to map your channel through Lwt_stream.map_exn and handle the
 exceptions at that point.
 
 Depending on your case the strategies I would recommend would be either:
-* If you maintain a global state between the client and the server, it
+- If you maintain a global state between the client and the server, it
 is usualy easier to rebuild it from scratch than to rebuild only the
 missing parts: i.e. the braindead/failure proof solution is to reload
 the complete contents
-{{{(Eliom.Client.exit_to ~service.Eliom.Service.reload_action () ())}}}.
-* If you only want to follow a stream of events and missing a few in the
+[(Eliom.Client.exit_to ~service.Eliom.Service.reload_action () ())].
+- If you only want to follow a stream of events and missing a few in the
 middle isn't a problem, you can just provides a Caml service that sends
 a channel, and when your channel disconnects, you just fetch a new one.
 (You may have to use Lwt_stream.concat to do the plumbing)
diff --git a/tutos/dev/manual/how-to-detect-on-client-side-that-the-server-side-state-for-the-process-is-closed.wiki b/tutos/dev/manual/how-to-detect-on-client-side-that-the-server-side-state-for-the-process-is-closed.mld
similarity index 67%
rename from tutos/dev/manual/how-to-detect-on-client-side-that-the-server-side-state-for-the-process-is-closed.wiki
rename to tutos/dev/manual/how-to-detect-on-client-side-that-the-server-side-state-for-the-process-is-closed.mld
index 9f0ba74c..a33ec8bb 100644
--- a/tutos/dev/manual/how-to-detect-on-client-side-that-the-server-side-state-for-the-process-is-closed.wiki
+++ b/tutos/dev/manual/how-to-detect-on-client-side-that-the-server-side-state-for-the-process-is-closed.mld
@@ -1,12 +1,12 @@
-= How to detect on client side that the server side state for the process is closed? =
+{0 How to detect on client side that the server side state for the process is closed?}
 
 If you are using Ocsigen-start, you probably have nothing to do.
 Ocsigen-start will monitor the life of sessions and close the process
 when needed.
 
 If you are not using Ocsigen-start, you must catch exceptions
-{{{Eliom.Comet.Channel_full}}},
-{{{Eliom.Comet.Channel_closed}}} (and {{{Eliom.Comet.Process_closed}}}
+[Eliom.Comet.Channel_full],
+[Eliom.Comet.Channel_closed] (and [Eliom.Comet.Process_closed]
 on Eliom < 5).
 For example, you can use a channel with a different client-process scope
 to warn client processes that the session is closed.
diff --git a/tutos/dev/manual/how-to-do-links-to-other-pages.wiki b/tutos/dev/manual/how-to-do-links-to-other-pages.mld
similarity index 91%
rename from tutos/dev/manual/how-to-do-links-to-other-pages.wiki
rename to tutos/dev/manual/how-to-do-links-to-other-pages.mld
index 8cefa958..8d8f06c6 100644
--- a/tutos/dev/manual/how-to-do-links-to-other-pages.wiki
+++ b/tutos/dev/manual/how-to-do-links-to-other-pages.mld
@@ -1,8 +1,8 @@
-=How to do links to other pages?=
+{0 How to do links to other pages?}
 
 Examples:
 
-<<code language="ocaml"|
+{@ocaml[
 (* Link to a service without parameter: *)
 Html.D.a ~service:coucou [txt "coucou"] ();
 
@@ -25,4 +25,4 @@ Html.F.Raw.a
   ~a:[a_href (Xml.uri_of_string "http://en.wikipedia.org/wiki/OCaml")]
   [txt "OCaml on wikipedia"]
 
->>
+]}
diff --git a/tutos/dev/manual/how-to-implement-a-notification-system.wiki b/tutos/dev/manual/how-to-implement-a-notification-system.mld
similarity index 61%
rename from tutos/dev/manual/how-to-implement-a-notification-system.wiki
rename to tutos/dev/manual/how-to-implement-a-notification-system.mld
index 636ff7b2..8a8447fa 100644
--- a/tutos/dev/manual/how-to-implement-a-notification-system.wiki
+++ b/tutos/dev/manual/how-to-implement-a-notification-system.mld
@@ -1,46 +1,47 @@
-=How to implement a notification system?=
+{0 How to implement a notification system?}
 
 The easiest way for the server to send notifications to the client is
-to use module <<a_api project="ocsigen-start"|module Os.Notif>> from
+to use module {!Os.Notif} from
 Ocsigen-start (OS), but it requires to use OS's user management
 system. If you are not using OS, we recommend to get inspiration from
 the code of this module, to implement your notification system
 conveniently and without memory leak.
 
-== With {{{Os.Notif}}}
+{1 With [Os.Notif]}
 
 For each type of data on which you want to receive updates,
-instanciate functor {{{Os.Notif.Make_Simple}}} on server side:
+instanciate functor [Os.Notif.Make_Simple] on server side:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 module My_notif = Os.Notif.Make_Simple (struct
   type key = ... (* The type of the identifier of the data we want listen on. *)
   type notification = ... (* The type of the notifications that will be sent *)
 end)
->>
+]}
 
-To declare that you are listening on one piece of data {{{i}}},
-call {{{My_notif.listen i}}}.
+To declare that you are listening on one piece of data [i],
+call [My_notif.listen i].
 
-To notify all the clients listening on data {{{i}}},
-call {{{My_notif.notify i (fun userid_o -> Lwt.return (Some notif))}}}.
-{{{userid_o}}} is the id of the user who will be notified,
-if he is connected ({{{None}}} otherwise).
+To notify all the clients listening on data [i],
+call [My_notif.notify i (fun userid_o -> Lwt.return (Some notif))].
+[userid_o] is the id of the user who will be notified,
+if he is connected ([None] otherwise).
 This make possible to customize the notifications.
-Return {{{None}}} if you don't want him to be notified.
+Return [None] if you don't want him to be notified.
 
 For more information, have a look at
-<<a_manual project="tutorial" chapter="tutoreact"|the tutorial
-about client-server reactive applications>>.
+{{:tutoreact.html}the tutorial
+about client-server reactive applications}.
 
 
 
-== Without {{{Os.Notif}}} (manual implementation)
+{1 Without [Os.Notif] (manual implementation)}
 
 If you want the user to receive notifications from the server
 (for example: "you have a new message"), first create a channel, and
-register it in an Eliom reference of scope {{{`Client_process}}}:
-<<code language="ocaml"|
+register it in an Eliom reference of scope [`Client_process]:
+{@ocaml[
 let channel_ref =
   Eliom.Reference.Volatile.eref_from_fun
     ~scope:Eliom.Common.default_process_scope
@@ -49,11 +50,11 @@ let channel_ref =
        let c = Eliom.Comet.Channel.create s in
        (c, notify)
     )
->>
+]}
 
 On client side, listen on this channel. To do that, execute this code
 (on server side) during the service that will start the client process:
-<<code language="ocaml"|
+{@ocaml[
 let (channel, _) = Eliom.Reference.Volatile.get channel_ref in
 let _ =
   [%client
@@ -65,22 +66,22 @@ let _ =
   ]
 in
 ...
->>
+]}
 
-And call function {{{notify}}} on the channel (from server side)
+And call function [notify] on the channel (from server side)
 when you want to notify the client.
 
-To get back the {{{notify}}} functions for one user, you may want to
-[[how-to-iterate-on-all-sessions-for-one-user-or-all-tabs|iterate on all client process states]].
+To get back the [notify] functions for one user, you may want to
+{{:how-to-iterate-on-all-sessions-for-one-user-or-all-tabs.html}iterate on all client process states}.
 To do that, create a session group for each user
-(see [[how-to-register-session-data|How to register session data]]).
+(see {{:how-to-register-session-data.html}How to register session data}).
 Here we suppose that the session group name is the user_id, as a string.
 Then iterate on all sessions from this group, and on all client processes
 for each session.
 
 For example:
 
-<<code language="ocaml"|
+{@ocaml[
 
 let notify user_id v =
   (* We get the session group state for this user: *)
@@ -99,12 +100,12 @@ let notify user_id v =
           let (_, notify) = Eliom.Reference.Volatile.Ext.get state channel_ref in
           notify (Some v)))
 
->>
+]}
 
-//Warning://      If you do not call the iterators during
+{e Warning:}      If you do not call the iterators during
       a request or during the initialisation phase of the Eliom module,
-      you must provide the extra parameter {{{?sitedata}}},
-      that you can get by calling {{{Eliom.Request_info.get_sitedata}}}
+      you must provide the extra parameter [?sitedata],
+      that you can get by calling [Eliom.Request_info.get_sitedata]
       during the initialisation phase of the Eliom module.
 
-Have a look at the implementation of {{{Os.Notif}}} for more details.
+Have a look at the implementation of [Os.Notif] for more details.
diff --git a/tutos/dev/manual/how-to-insert-raw-form-elements-not-belonging-to-a-form-towards-a-service.wiki b/tutos/dev/manual/how-to-insert-raw-form-elements-not-belonging-to-a-form-towards-a-service.mld
similarity index 57%
rename from tutos/dev/manual/how-to-insert-raw-form-elements-not-belonging-to-a-form-towards-a-service.wiki
rename to tutos/dev/manual/how-to-insert-raw-form-elements-not-belonging-to-a-form-towards-a-service.mld
index 38620a42..3c9c513c 100644
--- a/tutos/dev/manual/how-to-insert-raw-form-elements-not-belonging-to-a-form-towards-a-service.wiki
+++ b/tutos/dev/manual/how-to-insert-raw-form-elements-not-belonging-to-a-form-towards-a-service.mld
@@ -1,20 +1,20 @@
-=How to insert "raw" form elements (not belonging to a form towards a service)?=
+{0 How to insert "raw" form elements (not belonging to a form towards a service)?}
 
 Eliom redefines most forms elements (inputs, textareas, checkboxes, etc.)
 to make possible to check the type of the form w.r.t. the type of the service.
 
 If you don't want that (for example if you want to use it only from a client side program),
 you can use "raw form elements" (that is, basic tyxml elements), using
-module [[wiki("eliom"):api/server/Eliom.Content.Html.D.Raw|{{{Eliom.Content.Html.D.Raw}}}]]
-(or [[wiki("eliom"):api/server/Eliom.Content.Html.F.Raw|{{{Eliom.Content.Html.F.Raw}}}]]).
+module {{:../eliom/api/server/Eliom.Content.Html.D.Raw}[Eliom.Content.Html.D.Raw]}
+(or {{:../eliom/api/server/Eliom.Content.Html.F.Raw}[Eliom.Content.Html.F.Raw]}).
 
 Example:
 
-<<code language='ocaml'|
+{@ocaml[
 {{{
 open Eliom.Content.Html.D
 
 Raw.textarea (txt "blah")
 
 }}}
->>
+]}
diff --git a/tutos/dev/manual/how-to-iterate-on-all-sessions-for-one-user-or-all-tabs.wiki b/tutos/dev/manual/how-to-iterate-on-all-sessions-for-one-user-or-all-tabs.mld
similarity index 87%
rename from tutos/dev/manual/how-to-iterate-on-all-sessions-for-one-user-or-all-tabs.wiki
rename to tutos/dev/manual/how-to-iterate-on-all-sessions-for-one-user-or-all-tabs.mld
index dae03a18..41597d67 100644
--- a/tutos/dev/manual/how-to-iterate-on-all-sessions-for-one-user-or-all-tabs.wiki
+++ b/tutos/dev/manual/how-to-iterate-on-all-sessions-for-one-user-or-all-tabs.mld
@@ -1,10 +1,10 @@
-=How to iterate on all session belonging to the same user, or all tabs?=
+{0 How to iterate on all session belonging to the same user, or all tabs?}
 
 You must create a session group for each user, then iterate on all
 the sessions from this group, and possibly on all client processes
 for each session:
 
-<<code language="ocaml"|
+{@ocaml[
 
   (* We get the session group state for this user: *)
   let state =
@@ -22,4 +22,4 @@ for each session:
         (fun state ->
           let a = Eliom.Reference.Volatile.Ext.get state my_ref in
           ...)))
->>
+]}
diff --git a/tutos/8.0/manual/how-to-know-whether-the-browser-window-has-the-focus-or-not.wiki b/tutos/dev/manual/how-to-know-whether-the-browser-window-has-the-focus-or-not.mld
similarity index 77%
rename from tutos/8.0/manual/how-to-know-whether-the-browser-window-has-the-focus-or-not.wiki
rename to tutos/dev/manual/how-to-know-whether-the-browser-window-has-the-focus-or-not.mld
index f8383288..d0b15bcf 100644
--- a/tutos/8.0/manual/how-to-know-whether-the-browser-window-has-the-focus-or-not.wiki
+++ b/tutos/dev/manual/how-to-know-whether-the-browser-window-has-the-focus-or-not.mld
@@ -1,8 +1,8 @@
-=How to know whether the browser window has the focus or not?=
+{0 How to know whether the browser window has the focus or not?}
 
 Example:
 
-<<code language="ocaml"|
+{@ocaml[
 
 let has_focus = ref true
 
@@ -13,4 +13,4 @@ let _ =
   async (fun () -> blurs (Js.Unsafe.coerce (Dom_html.window))
     (fun _ _ -> has_focus := false; Lwt.return ()));
 
->>
+]}
diff --git a/tutos/dev/manual/how-to-make-hello-world-in-ocsigen.mld b/tutos/dev/manual/how-to-make-hello-world-in-ocsigen.mld
new file mode 100644
index 00000000..89b3d3f3
--- /dev/null
+++ b/tutos/dev/manual/how-to-make-hello-world-in-ocsigen.mld
@@ -0,0 +1,49 @@
+{0 How to make a "hello world" in Ocsigen?}
+
+Here it is! The famous "{b Hello World}" for a client/server Eliom application:
+
+{2 }
+
+{@ocaml[
+open Eliom.Content
+open Html.D
+open Eliom.Parameter
+
+module Example =
+  Eliom.Registration.App
+    (struct
+      let application_name = "example"
+     end)
+
+let main =
+  Eliom.Service.create
+    ~path:(Eliom.Service.Path [])
+    ~meth:(Eliom.Service.Get unit)
+    ()
+
+let _ =
+
+  Example.register
+    ~service:main
+    (fun () () ->
+      Lwt.return
+	(html
+	   (head (title (txt "Hello World of Ocsigen")) [])
+	   (body [h1 [txt "Hello World!"];
+		  p [txt "Welcome to my first Ocsigen website."]])))
+
+]}
+
+{2 }
+
+- To {e understand} this code, have a look at
+{{:wiki:manual/how-does-a-page-s-source-code-look}How does a page's source code look?}
+- Or directly continue by compiling this code:
+{{:wiki:manual/how-to-compile-my-ocsigen-pages}How to compile my Ocsigen pages?}
+
+
+
+{2 Links}
+
+- {{:wiki:manual/application}Tutorial to write a client/server application}
+- {{:wiki:manual/interaction}Tutorial to write a server side web site}
diff --git a/tutos/dev/manual/how-to-make-hello-world-in-ocsigen.wiki b/tutos/dev/manual/how-to-make-hello-world-in-ocsigen.wiki
deleted file mode 100644
index 0713fd44..00000000
--- a/tutos/dev/manual/how-to-make-hello-world-in-ocsigen.wiki
+++ /dev/null
@@ -1,56 +0,0 @@
-=How to make a "hello world" in Ocsigen?=
-
-Here it is! The famous "**Hello World**" for a client/server Eliom application:
-
-===
-
-<<code language="ocaml"|
-open Eliom.Content
-open Html.D
-open Eliom.Parameter
-
-module Example =
-  Eliom.Registration.App
-    (struct
-      let application_name = "example"
-     end)
-
-let main =
-  Eliom.Service.create
-    ~path:(Eliom.Service.Path [])
-    ~meth:(Eliom.Service.Get unit)
-    ()
-
-let _ =
-
-  Example.register
-    ~service:main
-    (fun () () ->
-      Lwt.return
-	(html
-	   (head (title (txt "Hello World of Ocsigen")) [])
-	   (body [h1 [txt "Hello World!"];
-		  p [txt "Welcome to my first Ocsigen website."]])))
-
->>
-
-===
-
-* To //understand// this code, have a look at
-[[wiki:manual/how-does-a-page-s-source-code-look|How does a page's source code look?]]
-* Or directly continue by compiling this code:
-[[wiki:manual/how-to-compile-my-ocsigen-pages|How to compile my Ocsigen pages?]]
-
-<<|
-=== Download full code
-
-//Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.//
-
-* [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/page/example.eliom|Read the full code]]
-* [[https://github.com/db0company/Ocsigen-Quick-Howto|Download and try this example]]
->>
-
-=== Links
-
-* [[wiki:manual/application|Tutorial to write a client/server application]]
-* [[wiki:manual/interaction|Tutorial to write a server side web site]]
diff --git a/tutos/dev/manual/how-to-make-page-a-skeleton.wiki b/tutos/dev/manual/how-to-make-page-a-skeleton.mld
similarity index 54%
rename from tutos/dev/manual/how-to-make-page-a-skeleton.wiki
rename to tutos/dev/manual/how-to-make-page-a-skeleton.mld
index 0fc5c861..703224c4 100644
--- a/tutos/dev/manual/how-to-make-page-a-skeleton.wiki
+++ b/tutos/dev/manual/how-to-make-page-a-skeleton.mld
@@ -1,46 +1,36 @@
-=How to make a page skeleton?=
+{0 How to make a page skeleton?}
 
-=== The same header for all your pages
+{2 The same header for all your pages}
 
 When your site will grow, you will have several different services for pages which will often contain the same header information.
 
 A great solution to avoid code copy-pasting of this recurrent information is to make a page skeleton function:
 
-<<code language="ocaml"|
+{@ocaml[
 let skeleton body_content =
   Lwt.return
     (html
        (head (title (txt "Page Title")) [])
        (body body_content)))
->>
+]}
 
 So when you define your pages, you just call this skeleton with the content of the page as an argument:
 
-<<code language="ocaml"|
+{@ocaml[
   Example.register ~service:main
     (fun () () -> skeleton [p [txt "Hello World!"]])
->>
+]}
 
 
 This method can also be adapted to add elements on all your pages, like a header, a footer and a menu.
 
-Module <<a_api project="eliom"  subproject="server"| module Eliom.Tools >> has a predefined function
+Module {!Eliom.Tools} has a predefined function
 for this:
 
-<<code language="ocaml"|
+{@ocaml[
 Eliom.Tools.D.html
   ~title:"ex"
   ~css:[["css"; "ex.css"]]
   (body [h2 [txt "Welcome to Ocsigen!"]]
->>
+]}
 
-<<|The following example is more complete.
-
-
-=== Download full code
-
-//Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.//
-
-* [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/skeleton/example.eliom|Read the full code]]
-* [[https://github.com/db0company/Ocsigen-Quick-Howto|Download and try this example]]
->>
\ No newline at end of file
diff --git a/tutos/8.0/manual/how-to-make-responsive-css.wiki b/tutos/dev/manual/how-to-make-responsive-css.mld
similarity index 73%
rename from tutos/8.0/manual/how-to-make-responsive-css.wiki
rename to tutos/dev/manual/how-to-make-responsive-css.mld
index 3f173245..54df225c 100644
--- a/tutos/8.0/manual/how-to-make-responsive-css.wiki
+++ b/tutos/dev/manual/how-to-make-responsive-css.mld
@@ -1,13 +1,13 @@
-=How to make reponsive CSS with ocsigen?=
+{0 How to make reponsive CSS with ocsigen?}
 
 The best way to do that is to make one general css sheet plus three css sheets, small, medium and large screen using media queries, a feature introduced in CSS3.
 
 Write theses lines in your css sheets:
 
-<<code language="css"|
+{@css[
 @media only screen and (max-device-width: 480px)
 @media only screen and (min-device-width: 481px) and (max-device-width: 768px)
 @media only screen and (min-device-width: 769px)
->>
+]}
 
-You can find more information about making responsive websites with media queries on [[http://www.w3schools.com/css/css_rwd_mediaqueries.asp|W3schools.com]]
+You can find more information about making responsive websites with media queries on {{:http://www.w3schools.com/css/css_rwd_mediaqueries.asp}W3schools.com}
diff --git a/tutos/dev/manual/how-to-make-the-client-side-program-get-an-html-element-from-the-server-and-insert-it-in-the-page.wiki b/tutos/dev/manual/how-to-make-the-client-side-program-get-an-html-element-from-the-server-and-insert-it-in-the-page.mld
similarity index 64%
rename from tutos/dev/manual/how-to-make-the-client-side-program-get-an-html-element-from-the-server-and-insert-it-in-the-page.wiki
rename to tutos/dev/manual/how-to-make-the-client-side-program-get-an-html-element-from-the-server-and-insert-it-in-the-page.mld
index 0a6bd41b..c4b1805b 100644
--- a/tutos/dev/manual/how-to-make-the-client-side-program-get-an-html-element-from-the-server-and-insert-it-in-the-page.wiki
+++ b/tutos/dev/manual/how-to-make-the-client-side-program-get-an-html-element-from-the-server-and-insert-it-in-the-page.mld
@@ -1,18 +1,20 @@
-=How to make the client side program get an HTML element from the server and insert it in the page?=
+{0 How to make the client side program get an HTML element from the server and insert it in the page?}
 
 A very convenient way to do that is to use RPCs :
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc get_mydiv (() : unit) : _ Lwt.t = div [ ... ]
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 [%client
   ...
   let%lwt mydiv = get_mydiv () in
   Dom.appendChild parent (To_dom.of_element mydiv)
   ...
 ]
->>
+]}
 
 Server functions take exactly one parameter.
 
@@ -20,11 +22,11 @@ RPCs are just syntactic sugar for pathless services
 returning OCaml values.
 
 The type of the function parameter must have been declared with the
-JSON module of {{{ppx_deriving}}} (which needs to be manually
+JSON module of [ppx_deriving] (which needs to be manually
 installed). This enables server-side data validation.
 
 example:
 
-<<code language="ocaml"|
+{@ocaml[
 type t = int * string [@@deriving json]
->>
+]}
diff --git a/tutos/dev/manual/how-to-register-a-service-that-decides-itself-what-to-send.wiki b/tutos/dev/manual/how-to-register-a-service-that-decides-itself-what-to-send.mld
similarity index 74%
rename from tutos/dev/manual/how-to-register-a-service-that-decides-itself-what-to-send.wiki
rename to tutos/dev/manual/how-to-register-a-service-that-decides-itself-what-to-send.mld
index 51f7a6e9..955ad442 100644
--- a/tutos/dev/manual/how-to-register-a-service-that-decides-itself-what-to-send.wiki
+++ b/tutos/dev/manual/how-to-register-a-service-that-decides-itself-what-to-send.mld
@@ -1,10 +1,10 @@
-=How to register a service that decides itself what to send?=
+{0 How to register a service that decides itself what to send?}
 
-Use <<a_api project="eliom"| module Eliom.Registration.Any >>.
+Use {!Eliom.Registration.Any}.
 
 In the following example, we send an Html page or a redirection:
 
-<<code language="ocaml"|
+{@ocaml[
 let send_any =
   Eliom.Registration.Any.create
     ~path:(Eliom.Service.Path ["any"])
@@ -18,4 +18,4 @@ let send_any =
             (body [p [txt "Hello."]]))
      else
        Eliom.Registration.Redirection.send other_service)
->>
+]}
diff --git a/tutos/dev/manual/how-to-register-session-data.wiki b/tutos/dev/manual/how-to-register-session-data.mld
similarity index 61%
rename from tutos/dev/manual/how-to-register-session-data.wiki
rename to tutos/dev/manual/how-to-register-session-data.mld
index c0e3319d..7ab59317 100644
--- a/tutos/dev/manual/how-to-register-session-data.wiki
+++ b/tutos/dev/manual/how-to-register-session-data.mld
@@ -1,7 +1,7 @@
-=How to register session data?=
+{0 How to register session data?}
 
-It is very easy to register session data using //Eliom references//.
-Just create an Eliom reference of //scope// session and its value
+It is very easy to register session data using {e Eliom references}.
+Just create an Eliom reference of {e scope} session and its value
 will be different for each session (one session = one browser process).
 
 But most of the time, what we want is to store data for one user,
@@ -10,7 +10,7 @@ for one user together, by creating a group of sessions.
 The name of the group may be for example the user id.
 
 To create a session group, open the session by doing something like:
-<<code language="ocaml"|
+{@ocaml[
 let open_session login password =
   let%lwt b = check_password login password in
   if b
@@ -19,56 +19,56 @@ let open_session login password =
       (Int64.to_string (get_userid login))
   else ...
 
->>
+]}
 
 If you want to store user data,
 just create a global Eliom reference of scope group:
-<<code language="ocaml"|
+{@ocaml[
 
 let myref =
   Eliom.Reference.Volatile.eref
     ~scope:Eliom.Common.default_group_scope
     None
 
->>
+]}
 
 And during a request, set this reference:
-<<code language="ocaml"|
+{@ocaml[
 
   ...
   Eliom.Reference.Volatile.set myref (Some "user data")
 
->>
+]}
 
 The value of this reference is different for each user:
-<<code language="ocaml"|
+{@ocaml[
 
   Eliom.Reference.Volatile.get myref
 
->>
+]}
 
-It is possible to create //persistent// Eliom references (see module
-<<a_api project="eliom" subproject="server"|module Eliom.Reference>>).
+It is possible to create {e persistent} Eliom references (see module
+{!Eliom.Reference}).
 
-==Other scopes==
+{1 Other scopes}
 If you want to store server side data for one browser (one session),
-use scope {{{Eliom.Common.default_session_scope}}}.
+use scope [Eliom.Common.default_session_scope].
 
 If you want to store server side data for one tab of your browser (one client process),
-use scope {{{Eliom.Common.default_process_scope}}} (available only if you
+use scope [Eliom.Common.default_process_scope] (available only if you
 have a client-server Eliom application).
 
 If you want to store server side data during one request,
-use scope {{{Eliom.Common.request_scope}}}.
+use scope [Eliom.Common.request_scope].
 
-==Persistent references==
+{1 Persistent references}
 
 Module
-<<a_api project="eliom" subproject="server"|module Eliom.Reference>>
+{!Eliom.Reference}
 also defines an interface for persistent references, that will survive
 if you restart the server.
 
-==Links
+{1 Links}
 
-* <<a_manual project="eliom" chapter="server-state"|More information on session data>>
-* module <<a_api project="eliom" subproject="server"|module Eliom.Reference>>
+- {{:../eliom/server-state.html}More information on session data}
+- module {!Eliom.Reference}
diff --git a/tutos/dev/manual/how-to-send-a-file-to-server-without-stopping-the-client-process.wiki b/tutos/dev/manual/how-to-send-a-file-to-server-without-stopping-the-client-process.mld
similarity index 82%
rename from tutos/dev/manual/how-to-send-a-file-to-server-without-stopping-the-client-process.wiki
rename to tutos/dev/manual/how-to-send-a-file-to-server-without-stopping-the-client-process.mld
index 41944ca2..19dd836f 100644
--- a/tutos/dev/manual/how-to-send-a-file-to-server-without-stopping-the-client-process.wiki
+++ b/tutos/dev/manual/how-to-send-a-file-to-server-without-stopping-the-client-process.mld
@@ -1,15 +1,15 @@
-=How to send a file to the server without stopping the client process?=
+{0 How to send a file to the server without stopping the client process?}
 
 This requires Eliom ≥ 3.1.
 
 Due to security reasons, browsers have limitations on sending files.
 But if the file is chosen by the user through an input file element,
-there is a way to send it to the server. You can't use the {{{server_function}}}
-or {{{let%rpc}}} syntax for this, but you can use
-{{{Eliom.Client.call_caml_service}}}.
+there is a way to send it to the server. You can't use the [server_function]
+or [let%rpc] syntax for this, but you can use
+[Eliom.Client.call_caml_service].
 
 Example:
-<<code language="ocaml"|
+{@ocaml[
 
 [%%client
 open Js_of_ocaml
@@ -45,4 +45,4 @@ let%client upload_pic_form () =
                     file)))));
   [txt "Upload a picture:"; file; submit_elt]
 
->>
+]}
diff --git a/tutos/8.0/manual/how-to-send-file-download.wiki b/tutos/dev/manual/how-to-send-file-download.mld
similarity index 68%
rename from tutos/8.0/manual/how-to-send-file-download.wiki
rename to tutos/dev/manual/how-to-send-file-download.mld
index d7df579d..1df1f2ab 100644
--- a/tutos/8.0/manual/how-to-send-file-download.wiki
+++ b/tutos/dev/manual/how-to-send-file-download.mld
@@ -1,7 +1,7 @@
-=How to send a file (download)?=
+{0 How to send a file (download)?}
 
 To serve file, you can use Ocsigen Server's module staticmod.
 But it is also possible to ask Eliom to send files using module
-<<a_api project="eliom" subproject="server"|module Eliom_registration.File>>,
+{!Eliom.Registration.File},
 for example if you want Eliom to perform some privacy checks before sending,
 or if the answer is not always a file.
\ No newline at end of file
diff --git a/tutos/dev/manual/how-to-send-file-upload.wiki b/tutos/dev/manual/how-to-send-file-upload.mld
similarity index 91%
rename from tutos/dev/manual/how-to-send-file-upload.wiki
rename to tutos/dev/manual/how-to-send-file-upload.mld
index 0db041cf..0f792ef8 100644
--- a/tutos/dev/manual/how-to-send-file-upload.wiki
+++ b/tutos/dev/manual/how-to-send-file-upload.mld
@@ -1,6 +1,6 @@
-=How to send a file (upload)?=
+{0 How to send a file (upload)?}
 
-To upload a file, use {{{Eliom.Parameter.file}}} as service parameter type.
+To upload a file, use [Eliom.Parameter.file] as service parameter type.
 
 Ocsigen server will save the file at a temporary location and keep it
 there during the request.  Then the file will be removed.  You must
@@ -8,7 +8,7 @@ link it somewhere else on the disk yourself if you want to keep it.
 
 Be careful also to set the right option in Ocsigen server's configuration file.
 For example:
-<<code|
+{[
 <ocsigen>
   <server>
     <uploaddir>/var/www/tmp</uploaddir>
@@ -16,10 +16,10 @@ For example:
     <maxrequestbodysize>100MB</maxrequestbodysize>
   </server>
 </ocsigen>
->>
+]}
 
 Example with Eliom.Content.Html.D module opened:
-<<code language="ocaml"|
+{@ocaml[
 
 let upload = Eliom.Service.create
     ~path:(Eliom.Service.Path ["upload"])
@@ -60,4 +60,4 @@ let uploadform =
         (html
            (head (title (txt "form")) [])
            (body [f])))
->>
+]}
diff --git a/tutos/8.0/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.wiki b/tutos/dev/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.mld
similarity index 57%
rename from tutos/8.0/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.wiki
rename to tutos/dev/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.mld
index 7bad37ac..a3fbe1de 100644
--- a/tutos/8.0/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.wiki
+++ b/tutos/dev/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.mld
@@ -1,67 +1,67 @@
-=How to set and id, classes or other attributes to HTML elements?=
+{0 How to set and id, classes or other attributes to HTML elements?}
 
 Mandatory element attributes are given as OCaml named parameters to
 constructions function.
 
-Optional element attributes are added using the optional OCaml parameter "**?a**" which is more or less available for every HTML5 elements. This parameter is taking a list of attributes compatible with the element.
+Optional element attributes are added using the optional OCaml parameter "{b ?a}" which is more or less available for every HTML5 elements. This parameter is taking a list of attributes compatible with the element.
 
-<<code language="ocaml" |
+{@ocaml[
   div ~a:[a_class ["red";"shadow"];
         a_id "the_div";
         a_onclick {{ fun ev -> Dom_html.window##alert(Js.string "hello") }}]
     [txt "I'm a div with two classes to describe me (red and shadow), ";
      txt "an id to make me unique and an action when you click me."]
->>
+]}
 
-=== Id
+{2 Id}
 The id attribute specifies a unique id for an HTML element (the value must be unique within the HTML document).
 
-The id attribute is mostly used to set a style in a style sheet for a particular element, and by JavaScript (via the HTML DOM) to manipulate the element with the specific id. With Eliom client-server apps, you do usually not need to set ids manually for that purpose: just use injections ({{{%v}}}) to refer to a node {{{v}}} created on server side.
+The id attribute is mostly used to set a style in a style sheet for a particular element, and by JavaScript (via the HTML DOM) to manipulate the element with the specific id. With Eliom client-server apps, you do usually not need to set ids manually for that purpose: just use injections ([%v]) to refer to a node [v] created on server side.
 
-Attribute "id" is created by function {{{a_id}}}, taking the value of the attribute as parameter:
-<<code language="ocaml" |~a:[a_id "identifier"]>>
+Attribute "id" is created by function [a_id], taking the value of the attribute as parameter:
+{@ocaml[~a:[a_id "identifier"]]}
 
-=== Classes
+{2 Classes}
 The class attribute specifies one or more classnames for an element.
 
 The class attribute is mostly used to point to a class in a style sheet. However, it can also be used by a JavaScript (via the HTML DOM) to make changes to HTML elements with a specified class.
 
 An element can have several classes. Class attribute is
-generated by function {{{a_class}}}, that takes a list of strings.
-<<code language="ocaml" |~a:[a_class ["blue_button"; "small"]]>>
+generated by function [a_class], that takes a list of strings.
+{@ocaml[~a:[a_class ["blue_button"; "small"]]]}
 
-=== Style
+{2 Style}
 
 The style attribute specifies an inline style for an element. The style attribute will override any style set globally, e.g. styles specified in the header of the page.
 
 Using this attribute to stylish elements is not a good practice.
 You should rather use
-[[wiki:manual/how-to-add-css-stylesheet|an external CSS file]].
+{{:wiki:manual/how-to-add-css-stylesheet}an external CSS file}.
 
 Its parameter is a string.
-<<code language="ocaml" |~a:[a_style "color: pink; padding: 10px;"]>>
+{@ocaml[~a:[a_style "color: pink; padding: 10px;"]]}
 
-=== Title
+{2 Title}
 
 The title attribute specifies extra information about an element. The information is most often shown as a tooltip text when the mouse moves over the element.
 
 Its parameter is a string.
-<<code language="ocaml" |~a:[a_title "Lorem ipsum dolor sit amet."]>>
+{@ocaml[~a:[a_title "Lorem ipsum dolor sit amet."]]}
 
-=== Events
+{2 Events}
 
 Some attributes allow you to do something when the user do an action. They are many available actions since HTML5.
 
 Its argument is an Eliom event handler, that is a client-side function
 taking the JS event as parameter:
-<<code language="ocaml" |~a:[a_onclick {{ fun ev -> Dom_html.window##alert(Js.string "hello") }}]>>
+{@ocaml[~a:[a_onclick {{ fun ev -> Dom_html.window##alert(Js.string "hello") }}]]}
 
-However, we recommend to use <<a_api project="js_of_ocaml" subproject="js_of_ocaml-lwt"|module Js_of_ocaml_lwt.Lwt_js_events>> rather than these elements to set event handlers.
+However, we recommend to use {!Js_of_ocaml_lwt.Lwt_js_events} rather than these elements to set event handlers.
 
 
-=== Links
+{2 Links}
 
-* Type <<a_api project="tyxml"|type Html_types.base_attrib>> (attributes available for every element)
-* signature <<a_api project="tyxml"|module Html_sigs.T>> (Element attributes)
-* [[http://www.w3schools.com/html/default.asp|W3Schools HTML5 reference]]
-* [[http://www.w3schools.com/html5/html5_ref_eventattributes.asp|Events attributes]]
+- Type {!Html_types.base_attrib} (attributes available for every element)
+- signature {!Html_sigs.T} (Element attributes)
+- {{:http://www.w3schools.com/html/default.asp}W3Schools HTML5 reference}
+- {{:http://www.w3schools.com/html5/html5_ref_eventattributes.asp}Events attributes}
diff --git a/tutos/8.0/manual/how-to-stop-default-behaviour-of-events.wiki b/tutos/dev/manual/how-to-stop-default-behaviour-of-events.mld
similarity index 61%
rename from tutos/8.0/manual/how-to-stop-default-behaviour-of-events.wiki
rename to tutos/dev/manual/how-to-stop-default-behaviour-of-events.mld
index f5215454..a1a54069 100644
--- a/tutos/8.0/manual/how-to-stop-default-behaviour-of-events.wiki
+++ b/tutos/dev/manual/how-to-stop-default-behaviour-of-events.mld
@@ -1,8 +1,8 @@
-=How to stop default behaviour of events?=
+{0 How to stop default behaviour of events?}
 
 Example:
 
-<<code language="ocaml"|
+{@ocaml[
 
 (** Disable Js event with stopping propagation during capture phase **)
 let disable_event event html_elt =
@@ -13,9 +13,9 @@ let disable_event event html_elt =
 
 
 disable_event Dom_html.Event.dragstart Dom_html.document
->>
+]}
 
-* event is a Dom_html.Event\\
-* html_elt is the target
+- event is a Dom_html.Event{%html:<br/>%}
+- html_elt is the target
 
-More details in documentation: <<a_api project="js_of_ocaml" |val Js_of_ocaml.Dom.preventDefault>>
+More details in documentation: {!Js_of_ocaml.Dom.preventDefault}
diff --git a/tutos/dev/manual/how-to-use-get-parameters-or-parameters-in-the-url.mld b/tutos/dev/manual/how-to-use-get-parameters-or-parameters-in-the-url.mld
new file mode 100644
index 00000000..a37437dd
--- /dev/null
+++ b/tutos/dev/manual/how-to-use-get-parameters-or-parameters-in-the-url.mld
@@ -0,0 +1,88 @@
+{0 How to use GET parameters (parameters in the URL)?}
+
+Pages are generated by services.
+
+Funcrions to create services using GET HTTP method take
+two mandatory parameters: [~path] and [~get_params].
+
+{2 path}
+
+This argument is a {b list of string}, corresponding to the URL where your page service can be found.
+
+For example, if you want your page to be accessed via this URL:
+{@ocaml[http://website.com/a/b/c]}
+You must provide this path:
+{@ocaml[    ~path:["a";"b";"c"]]}
+
+This parameter can also be an {b empty list}. It means that the service page will be accessed via this URL:
+{[http://website.com/]}
+
+{2 get_params}
+
+Eliom chooses the service automatically w.r.t. this path and parameter
+given (among other criteria).
+It decodes parameters automatically and checks their types.
+
+Description of parameters (names and types) is done using module
+{!Eliom.Parameter}.
+We recommend to open this module (at the beginning of your file, or locally).
+
+{3 Syntax for several parameters}
+
+- {b No parameter}
+{@ocaml[~get_params:unit]}
+
+- {b One parameter}
+{@ocaml[~get_params:(int "id")]}
+
+- {b More parameters}
+{@ocaml[~get_params:(string "name" ** int "age" ** bool "graduate")]}
+
+{3 Types of parameters}
+
+- {b Common types}: {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L121}string}, {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L122}int}, {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L123}int32}, {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L124}float}, {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L125}bool}
+- {b Some other types}: {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L126}optional values}, {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L158}any parameter}, {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L187}list}, {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L211}your own type}.
+
+- See more information on parameters in {{:../eliom/server-params.html}Eliom manual} and API documentation of module {!Eliom.Parameter}.
+
+{3 Get these parameters}
+
+On service registration, parameters can be retrieved as a parameter of the function:
+{@ocaml[
+Example.register ~service:the_service
+    (fun parameters () -> ...)
+]}
+
+- {b No parameter}
+{@ocaml[    (fun () () -> ...)]}
+
+- {b One parameter}
+{@ocaml[    (fun a () -> ...)]}
+
+- {b Several parameters}
+
+Operator [**] is left associative:
+{@ocaml[    (fun (a, (b, (c, d)))) () -> ...)]}
+
+{2 Parameters in the path}
+
+Sometimes you may want to take parameters from the path,
+for example to improve readability of URLs. E.g. [http://blah.com/archive/2014/2/] or [http://blah.com/user/toto/].
+
+To do that, add a parameter of type {b suffix} in {b get_params}:
+{[~get_params:(suffix (string "username"))]}
+
+
+{2 Download full code}
+
+{e Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.}
+
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom}Read the full code}
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto}Download and try this example (parameters)}
+
+{2 Links}
+
+- Manual: {{:../eliom/server-params.html}Parameters}
+- Manual: {{:../eliom/server-services.html}Services}
+- API: {!Eliom.Parameter}
+- API: {!Eliom.Service}
diff --git a/tutos/dev/manual/how-to-use-get-parameters-or-parameters-in-the-url.wiki b/tutos/dev/manual/how-to-use-get-parameters-or-parameters-in-the-url.wiki
deleted file mode 100644
index 80762439..00000000
--- a/tutos/dev/manual/how-to-use-get-parameters-or-parameters-in-the-url.wiki
+++ /dev/null
@@ -1,88 +0,0 @@
-=How to use GET parameters (parameters in the URL)?
-
-Pages are generated by services.
-
-Funcrions to create services using GET HTTP method take
-two mandatory parameters: {{{~path}}} and {{{~get_params}}}.
-
-=== path
-
-This argument is a **list of string**, corresponding to the URL where your page service can be found.
-
-For example, if you want your page to be accessed via this URL:
-<<code language='ocaml'|http://website.com/a/b/c>>
-You must provide this path:
-<<code language='ocaml'|    ~path:["a";"b";"c"]>>
-
-This parameter can also be an **empty list**. It means that the service page will be accessed via this URL:
-<<code|http://website.com/>>
-
-=== get_params
-
-Eliom chooses the service automatically w.r.t. this path and parameter
-given (among other criteria).
-It decodes parameters automatically and checks their types.
-
-Description of parameters (names and types) is done using module
-<<a_api project="eliom" subproject="server"|module Eliom.Parameter>>.
-We recommend to open this module (at the beginning of your file, or locally).
-
-==== Syntax for several parameters
-
-* **No parameter**
-<<code language='ocaml'|~get_params:unit>>
-
-* **One parameter**
-<<code language='ocaml'|~get_params:(int "id")>>
-
-* **More parameters**
-<<code language='ocaml'|~get_params:(string "name" ** int "age" ** bool "graduate")>>
-
-==== Types of parameters
-
-* **Common types**: [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L121|string]], [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L122|int]], [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L123|int32]], [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L124|float]], [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L125|bool]]
-* **Some other types**: [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L126|optional values]], [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L158|any parameter]], [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L187|list]], [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom#L211|your own type]].
-
-* See more information on parameters in <<a_manual project="eliom" chapter="server-params"|Eliom manual>> and API documentation of module <<a_api project="eliom" subproject="server"|module Eliom.Parameter>>.
-
-==== Get these parameters
-
-On service registration, parameters can be retrieved as a parameter of the function:
-<<code language='ocaml'|
-Example.register ~service:the_service
-    (fun parameters () -> ...)
->>
-
-* **No parameter**
-<<code language='ocaml'|    (fun () () -> ...)>>
-
-* **One parameter**
-<<code language='ocaml'|    (fun a () -> ...)>>
-
-* **Several parameters**
-
-Operator {{{**}}} is left associative:
-<<code language='ocaml'|    (fun (a, (b, (c, d)))) () -> ...)>>
-
-=== Parameters in the path
-
-Sometimes you may want to take parameters from the path,
-for example to improve readability of URLs. E.g. {{{http://blah.com/archive/2014/2/}}} or {{{http://blah.com/user/toto/}}}.
-
-To do that, add a parameter of type **suffix** in **get_params**:
-<<code|~get_params:(suffix (string "username"))>>
-
-
-=== Download full code
-
-//Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.//
-
-* [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/parameters/example.eliom|Read the full code]]
-* [[https://github.com/db0company/Ocsigen-Quick-Howto|Download and try this example (parameters)]]
-
-=== Links
-
-* Manual: <<a_manual project="eliom" chapter="server-params"|Parameters>>
-* Manual: <<a_manual project="eliom" chapter="server-services"|Services>>
-* API: <<a_api project="eliom" subproject="server"|module Eliom.Parameter>>
-* API: <<a_api project="eliom" subproject="server"|module Eliom.Service>>
diff --git a/tutos/dev/manual/how-to-write-a-json-service.wiki b/tutos/dev/manual/how-to-write-a-json-service.mld
similarity index 62%
rename from tutos/dev/manual/how-to-write-a-json-service.wiki
rename to tutos/dev/manual/how-to-write-a-json-service.mld
index de437186..322e24c6 100644
--- a/tutos/dev/manual/how-to-write-a-json-service.wiki
+++ b/tutos/dev/manual/how-to-write-a-json-service.mld
@@ -1,10 +1,10 @@
-=How to write a JSON service?=
+{0 How to write a JSON service?}
 
 *If you want to communicate with a client side Eliom program, you do not need to serialize yourself your data to JSON. Serialization/Deserialization of any OCaml type is done automatically by Eliom. Just use OCaml services (or, simpler: server functions and call the function from your OCaml client side program).
-*If you want to use your own JSON format, you need to have your own serialisation function to JSON (or for example to use some OCaml library like [[http://mjambon.com/yojson.html|yojson]] to generate JSON). In that case, you can register your service using {{{Eliom.Registration.String}}} instead of {{{Eliom.Registration.Html}}} (see example below). The handler function must return the JSON value as a string, and a the content-type.
-*It is even possible to define yourself your own registration module, to be used instead of {{{Eliom.Registration.String}}}. Thus, you can use an OCaml representation of the JSON value (and you don't call the serializer yourself). Have a look on how modules like {{{Eliom.Registration.String}}} are implemented to know how to do that.
+*If you want to use your own JSON format, you need to have your own serialisation function to JSON (or for example to use some OCaml library like {{:http://mjambon.com/yojson.html}yojson} to generate JSON). In that case, you can register your service using [Eliom.Registration.String] instead of [Eliom.Registration.Html] (see example below). The handler function must return the JSON value as a string, and a the content-type.
+*It is even possible to define yourself your own registration module, to be used instead of [Eliom.Registration.String]. Thus, you can use an OCaml representation of the JSON value (and you don't call the serializer yourself). Have a look on how modules like [Eliom.Registration.String] are implemented to know how to do that.
 
-<<code language="ocaml"|
+{@ocaml[
 
 let my_json_service =
   Eliom.Service.create
@@ -18,8 +18,8 @@ let _ =
     (fun () () ->
       Lwt.return ("{text:'something'}", "application/json"))
 
->>
+]}
 
-**Comments:** \\
-If you want to get result from a Database, it could already be in JSON format. \\
-Anyway, you probably do not need to pretty-print JSON yourself. \\
+{b Comments:} {%html:<br/>%}
+If you want to get result from a Database, it could already be in JSON format. {%html:<br/>%}
+Anyway, you probably do not need to pretty-print JSON yourself. {%html:<br/>%}
diff --git a/tutos/dev/manual/how-to-write-forms.wiki b/tutos/dev/manual/how-to-write-forms.mld
similarity index 72%
rename from tutos/dev/manual/how-to-write-forms.wiki
rename to tutos/dev/manual/how-to-write-forms.mld
index 7d75e3d0..7ac8eb2d 100644
--- a/tutos/dev/manual/how-to-write-forms.wiki
+++ b/tutos/dev/manual/how-to-write-forms.mld
@@ -1,22 +1,22 @@
-=How to write forms?=
+{0 How to write forms?}
 
-=== To write an HTML form towards an Eliom service
+{2 To write an HTML form towards an Eliom service}
 
 Just as we do for links, we provide form-building functions that call
 Eliom services in a safe manner. These functions are provided in the
 module
-<<a_api project="eliom" subproject="server" | module Eliom.Content.Html.D.Form >> (and
-<<a_api project="eliom" subproject="server" | module Eliom.Content.Html.F.Form >>).
+{!Eliom.Content.Html.D.Form} (and
+{!Eliom.Content.Html.F.Form}).
 The functions
-<<a_api project="eliom" subproject="server" | val Eliom.Content.Html.D.Form.get_form >> and
-<<a_api project="eliom" subproject="server" | val Eliom.Content.Html.D.Form.post_form >>
-accept a function (named {{{create_form}}} in our example below)
+{!Eliom.Content.Html.D.Form.get_form} and
+{!Eliom.Content.Html.D.Form.post_form}
+accept a function (named [create_form] in our example below)
 which is responsible for generating the content from
 appropriately-typed parameter names.
 
 Here a complete example.
 
-<<code language="ocaml"|
+{@ocaml[
 [%%shared
   open Eliom.Parameter
   open Eliom.Content.Html.D
@@ -77,34 +77,34 @@ let%server form_handler =
 let%server () =
   Eliom.Registration.Html.register ~service:form_result_service form_result_handler;
   Eliom.Registration.Html.register ~service:form_service form_handler
->>
+]}
 
 As shown in the example,
-<<a_api project="eliom" subproject="server" | module Eliom.Content.Html.D.Form >>
+{!Eliom.Content.Html.D.Form}
 provides functions for generating the various widgets, e.g.,
-<<a_api project="eliom" subproject="server" | val Eliom.Content.Html.D.Form.input >>.
+{!Eliom.Content.Html.D.Form.input}.
 These functions need to be called with a "type" argument (e.g.,
-<<a_api project="eliom" subproject="server" | val Eliom.Content.Html.D.Form.int >>)
+{!Eliom.Content.Html.D.Form.int})
 that matches the type of the corresponding parameter name.
 
 POST forms may also take get parameters, as last argument of function
-{{{post_form}}}:
+[post_form]:
 
-<<code language="ocaml"|
+{@ocaml[
 Eliom.Content.Html.D.Form.post_form
   my_service_with_get_and_post
   (fun my_string ->
     p [txt "Write a string: ";
        Form.input ~input_type:`Text ~name:my_string Form.string])
   222
->>
+]}
 
-=== Raw forms
+{2 Raw forms}
 
 There is also a raw interface to write basic forms without Eliom,
 using standard tyxml constructors.
 
-Use module [[wiki("eliom"):api/server/Eliom.Content.Html.D.Raw|Eliom.Content.Html.D.Raw]].
+Use module {{:../eliom/api/server/Eliom.Content.Html.D.Raw}Eliom.Content.Html.D.Raw}.
 
-===Links
-* [[wiki:manual/how-to-add-a-select-or-other-form-element|How to write a select (or other form element)?]]
+{2 Links}
+- {{:wiki:manual/how-to-add-a-select-or-other-form-element}How to write a select (or other form element)?}
diff --git a/tutos/dev/manual/how-to-write-titles-and-paragraphs.mld b/tutos/dev/manual/how-to-write-titles-and-paragraphs.mld
new file mode 100644
index 00000000..817e109e
--- /dev/null
+++ b/tutos/dev/manual/how-to-write-titles-and-paragraphs.mld
@@ -0,0 +1,34 @@
+{0 How to write titles and paragrahs?}
+
++ Titles
+
+{@ocaml[
+h3 [txt "Hello world"]
+]}
+
+There are 6 types of titles: h1, h2, h3, h4, h5 and h6. h1 is the largest and h6 is the smallest.
+
++ Pagragraph
+
+{@ocaml[
+p [txt "Some text, blah blah blah"]
+]}
+
+{b Required parameter}: list containing other elements (content: {!Html_types.flow5} elements).
+
+{b Optional parameter} for attributes "a" ({{:wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements}How to set and id, classes or other attributes to HTML elements?}).
+
+{2 Download full code}
+
+{e Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.}
+
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/elements/example.eliom}Read the full code}
+- {{:https://github.com/db0company/Ocsigen-Quick-Howto}Download and try this example}
+
+{2 Links}
+
+- Modules {!Eliom.Content.Html.D} and
+  {!Eliom.Content.Html.F}
+  (HTML5 Elements)
+- The {!Html_sigs.T.h1} element
+- signature {!Html_sigs.T} (Element attributes)
diff --git a/tutos/dev/manual/how-to-write-titles-and-paragraphs.wiki b/tutos/dev/manual/how-to-write-titles-and-paragraphs.wiki
deleted file mode 100644
index c446a75d..00000000
--- a/tutos/dev/manual/how-to-write-titles-and-paragraphs.wiki
+++ /dev/null
@@ -1,34 +0,0 @@
-=How to write titles and paragrahs?=
-
-#### Titles
-
-<<code language='ocaml'|
-h3 [txt "Hello world"]
->>
-
-There are 6 types of titles: h1, h2, h3, h4, h5 and h6. h1 is the largest and h6 is the smallest.
-
-#### Pagragraph
-
-<<code language='ocaml'|
-p [txt "Some text, blah blah blah"]
->>
-
-**Required parameter**: list containing other elements (content: <<a_api project="tyxml"|type Html_types.flow5>> elements).
-
-**Optional parameter** for attributes "a" ([[wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements|How to set and id, classes or other attributes to HTML elements?]]).
-
-=== Download full code
-
-//Warning: This third party code may be outdated. Please notify the author is something is broken, or do a pull request on github.//
-
-* [[https://github.com/db0company/Ocsigen-Quick-Howto/blob/master/elements/example.eliom|Read the full code]]
-* [[https://github.com/db0company/Ocsigen-Quick-Howto|Download and try this example]]
-
-=== Links
-
-* Modules <<a_api project="eliom" subproject="server"|module Eliom.Content.Html.D>> and
-  <<a_api project="eliom" subproject="server"|module Eliom.Content.Html.F>>
-  (HTML5 Elements)
-* The <<a_api project="tyxml"|val Html_sigs.T.h1>> element
-* signature <<a_api project="tyxml"|module Html_sigs.T>> (Element attributes)
diff --git a/tutos/dev/manual/html.wiki b/tutos/dev/manual/html.mld
similarity index 56%
rename from tutos/dev/manual/html.wiki
rename to tutos/dev/manual/html.mld
index 0cedda77..3a84c890 100644
--- a/tutos/dev/manual/html.wiki
+++ b/tutos/dev/manual/html.mld
@@ -1,4 +1,6 @@
-<<header| = HTML in 5 minutes >>
+{%wodoc:header%}
+{0 HTML in 5 minutes}
+{%wodoc:end%}
 
 The Tyxml library makes it possible to type-check HTML pages.
 This means that your Ocsigen program will never generate pages
@@ -6,55 +8,55 @@ which do not follow the recommendations from the W3C.
 For example a program that could generate a page with a paragraph
 inside another paragraph will be rejected at compile time.
 
-== Typed HTML
+{1 Typed HTML}
 
-=== Tags
+{2 Tags}
 
 Tyxml (or modules obtained by applying Tyxml functor,
-like {{{Eliom.Content.Html.D}}}) defines a contructor function
+like [Eliom.Content.Html.D]) defines a contructor function
 for each HTML tag, and for each attribute.
 
 Example:
 
-<<code language="ocaml"|
+{@ocaml[
    html
      (head (title (txt "Hello")) [])
      (body [ h1 [txt "Hello"] ;
              p [txt "Blah"] ])
->>
+]}
 
-As tag {{{<html>}}} contains a tag {{{<head>}}} and {{{<body>}}},
-function {{{html}}} takes two parameters:
+As tag [<html>] contains a tag [<head>] and [<body>],
+function [html] takes two parameters:
 
-<<code language="ocaml"|
+{@ocaml[
 val html : [`Head] elt -> [`Body] elt -> [`Html] elt
->>
+]}
 
-The only way to create a value of type {{{[`Head] elt}}} is to use
-function {{{head}}},
-and the only way to create a value of type {{{[`Body] elt}}} is to use
-function {{{body}}}.
+The only way to create a value of type [[`Head] elt] is to use
+function [head],
+and the only way to create a value of type [[`Body] elt] is to use
+function [body].
 
-As a {{{<title>}}} tag is mandatory inside {{{<head>}}},
-function {{{head}}} takes a {{{[`Title] elt}}} as first argument
-(that can be created using function {{{title}}}),
+As a [<title>] tag is mandatory inside [<head>],
+function [head] takes a [[`Title] elt] as first argument
+(that can be created using function [title]),
 then the list of other children.
 
-Function {{{txt}}} is used to include raw text.
+Function [txt] is used to include raw text.
 
-=== Error messages
+{2 Error messages}
 
 If you write an invalid page, for example:
-<<code language="ocaml"|
+{@ocaml[
 (html
    (head (title (txt "")) [txt ""])
    (body [txt "Hallo"]))
->>
+]}
 
 You will get an error message similar to the following, referring to
 the end of line 2:
 
-{{{
+{v
 Error: This expression has type ([> `TXT ] as 'a) Html.elt
        but an expression was expected of type
          Html_types.head_content_fun Html.elt
@@ -67,49 +69,49 @@ Error: This expression has type ([> `TXT ] as 'a) Html.elt
            | `Script
            | `Style ]
        The second variant type does not allow tag(s) `TXT
-}}}
+v}
 
-where <<a_api project="tyxml" | type Html_types.head_content_fun >>
-is the type of content allowed inside {{{<head>}}} ({{{<base>}}},
-{{{<command>}}}, {{{<link>}}}, {{{<meta>}}}, etc.). Notice that
-{{{`TXT}}} (i.e. raw text) is not included in this polymorphic
-variant type, which means that {{{<head>}}} cannot contain raw text.
+where {!Html_types.head_content_fun}
+is the type of content allowed inside [<head>] ([<base>],
+[<command>], [<link>], [<meta>], etc.). Notice that
+[`TXT] (i.e. raw text) is not included in this polymorphic
+variant type, which means that [<head>] cannot contain raw text.
 
-=== Attributes
+{2 Attributes}
 
-Attributes are given to functions using optional argument {{{?a}}}.
+Attributes are given to functions using optional argument [?a].
 
 Example:
-<<code language="ocaml"|
+{@ocaml[
 div ~a:[a_id "the_id"; a_class ["firstclass"; "secondclass"]]
   [ txt "blah" ]
->>
+]}
 
-== OCaml node and DOM nodes
+{1 OCaml node and DOM nodes}
 
-=== Conversions
+{2 Conversions}
 
 Tyxml builds OCaml nodes. If you are using it server side,
 they are serialized as an XML text before being sent to the browser.
 On client side, if you want to get the DOM node corresponding to
-an OCaml node, use functions from module {{{Eliom.Content.Html.To_dom}}},
-for example {{{Eliom.Content.Html.To_dom.of_element}}},
-or {{{Eliom.Content.Html.To_dom.of_input}}},
-{{{Eliom.Content.Html.To_dom.of_textarea}}}, etc.
+an OCaml node, use functions from module [Eliom.Content.Html.To_dom],
+for example [Eliom.Content.Html.To_dom.of_element],
+or [Eliom.Content.Html.To_dom.of_input],
+[Eliom.Content.Html.To_dom.of_textarea], etc.
 
-If the node has been created with {{{Eliom.Content.Html.F}}}
+If the node has been created with [Eliom.Content.Html.F]
 (functional nodes),
 a new DOM node will be created every time you call such a conversion
 function.
 
-If the node has been created with {{{Eliom.Content.Html.D}}},
+If the node has been created with [Eliom.Content.Html.D],
 the conversion function will return the exact DOM node that exists
 in the page (and always the same one). If this "D" node is created
 server-side, Eliom will automatically add a identifier in the HTML
 page to be able to find it back.
 
 Example:
-<<code language="ocaml"|
+{@ocaml[
 [%%shared
   open Eliom.Content.Html
 ]
@@ -120,38 +122,38 @@ let%server create_widget () =
     Lwt.async (fun () ->
       Lwt_js_events.clicks (To_dom.of_element ~%d) (fun _ _ -> ... )) ];
   d
->>
+]}
 
-Here, {{{d}}} must be a "D" node, as I want to bind click events on
+Here, [d] must be a "D" node, as I want to bind click events on
 the actual node (that is already in the page), not create a new one.
 
 Remember to use "D" nodes if you want to use it in a injection
-({{{~%d}}}). If you don't to bother about "D" or "F" nodes, use "D"
+([~%d]). If you don't to bother about "D" or "F" nodes, use "D"
 nodes by default (even if it will generate too much identifiers in the page).
 But remember that, the DOM semantics implies that "D" nodes cannot be
 inserted twice in a page.
 
 
-=== Manip
+{2 Manip}
 
 Module
-<<a_api project="eliom" subproject="client"| module Eliom.Content.Html.Manip >>
+{!Eliom.Content.Html.Manip}
 makes it possible to manipulate OCaml nodes without conversions
 (add them in a page, replace a node, add as child of another node,
 add a class, etc.).
 
-=== Reactive nodes
+{2 Reactive nodes}
 
 Module
-<<a_api project="eliom" subproject="client"| module Eliom.Content.Html.R >>
+{!Eliom.Content.Html.R}
 makes it possible to create reactive nodes, that is, nodes that will
 be updated automatically when the data on which they depend change.
 
-It is based on module [[http://erratique.ch/software/react/doc/React|React]],
+It is based on module {{:http://erratique.ch/software/react/doc/React}React},
 which implements functional reactive programming for OCaml.
 
-== More documentation
+{1 More documentation}
 
-Have a look at <<a_manual project="tyxml" chapter="intro"|Tyxml's manual>>
-and <<a_manual project="eliom" chapter="clientserver-html"|Eliom's manual>>
+Have a look at {{:../tyxml/intro.html}Tyxml's manual}
+and {{:../eliom/clientserver-html.html}Eliom's manual}
 for more documentation about HTML manipulation in OCaml.
diff --git a/tutos/dev/manual/interaction.wiki b/tutos/dev/manual/interaction.mld
similarity index 68%
rename from tutos/dev/manual/interaction.wiki
rename to tutos/dev/manual/interaction.mld
index 7c9480c2..64522d54 100644
--- a/tutos/dev/manual/interaction.wiki
+++ b/tutos/dev/manual/interaction.mld
@@ -1,13 +1,13 @@
-=Implementing Web Interaction Using Eliom=
+{0 Implementing Web Interaction Using Eliom}
+
+{e The code of this tutorial has been tested with Eliom 6.0.} {%html:<br/>%}
 
-//The code of this tutorial has been tested with Eliom 6.0.// \\
 
-<<|outline target="documentation">>
 
 This chapter of the tutorial explains how to create a small web site
 with several pages, users, sessions, and other elements of classical
 web development.  Then, in
-<<a_manual project="tuto" chapter="misc" |another tutorial>>, we will incorporate the
+{{:../tuto/misc.html}another tutorial}, we will incorporate the
 features of this site into our Graffiti application, to
 demonstrate that we can combine this kind of interaction with client-side
 programs.
@@ -19,19 +19,19 @@ HTML pages.
 We will create a simple web site with one main page and a page for
 each user (assuming we have several users already created).  Then we
 will add a login/connection form. We will also add a registration
-form, in order to learn how to create //dynamically// new services,
+form, in order to learn how to create {e dynamically} new services,
 and why it is very useful.
 
-The [[https://github.com/ocsigen/tutorial/tree/master/files/tutorial/chapter2|full code]]
+The {{:https://github.com/ocsigen/tutorial/tree/master/files/tutorial/chapter2}full code}
 of the program can be downloaded.
 
-==Services==
+{1 Services}
 
-===The main page===
+{2 The main page}
 
 Let's start again from scratch with the following site.
 
-<<code language="ocaml"|
+{@ocaml[
 
 let main_service = Eliom.Content.Html.D.(
   Eliom.Registration.Html.create
@@ -42,33 +42,35 @@ let main_service = Eliom.Content.Html.D.(
         (html (head (title (txt "")) [])
            (body [h1 [txt "Hello"]])))
 )
->>
+]}
 
-Note that we are using {{{Eliom.Registration.Html}}}, as we are not building a
+Note that we are using [Eliom.Registration.Html], as we are not building a
 client side program for now.
 
-For the same reason, you may want to remove the {{{.eliom}}}-file
+For the same reason, you may want to remove the [.eliom]-file
 generated by the distillery and put the code into an
-{{{.ml}}}-file. But don't forget to add it to the server files in the
-{{{Makefile.options}}}:
+[.ml]-file. But don't forget to add it to the server files in the
+[Makefile.options]:
 
-<<code language="makefile"|
+{@makefile[
 SERVER_FILES := tuto.ml
->>
+]}
+
+{2 Adding a page for each user}
 
-===Adding a page for each user===
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-<<concepts|
 
-Services with parameters\\
+
+Services with parameters{%html:<br/>%}
 Using parts of the path as parameters
 
->>
+{%wodoc:end%}
 
 We will now create a page for each user. To do this, we will create a
 new service, taking the user name as parameter:
 
-<<code language="ocaml"|
+{@ocaml[
 let user_service = Eliom.Content.Html.D.(
   Eliom.Registration.Html.create
     ~path:(Eliom.Service.Path [""])
@@ -78,144 +80,150 @@ let user_service = Eliom.Content.Html.D.(
         (html (head (title (txt name)) [])
            (body [h1 [txt name]])))
 )
->>
+]}
 
 Add these lines to the same file, compile, start the server and verify
 that everything is working by trying, for example:
-{{{http://localhost:8080/?name=toto}}}.
+[http://localhost:8080/?name=toto].
+
+{%wodoc:aside class="concept"%}{b Concept: Paths}
+
 
-<<concept title="Paths" |
 
 Note that we are using the same path as the first service.  Eliom will
 automatically call the right service according to the parameters given
 in the request.
 
->>
+{%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: Services with parameters}
+
 
-<<concept title="Services with parameters" |
 
 To define a service that accepts parameters in the URL (GET
 parameters), just add a description of the parameters you want in the
-{{{~meth}}} argument of the {{{Eliom.Service.create}}} function. In
-our example, the service is expecting a parameter called {{{name}}},
-of type {{{string}}}.
+[~meth] argument of the [Eliom.Service.create] function. In
+our example, the service is expecting a parameter called [name],
+of type [string].
 
 The handler function (function implementing the service) always takes
 two parameters:
 
-* The first one corresponds to GET parameters (in our example, a string).
-* The second one corresponds to parameters that are sent in the body
+- The first one corresponds to GET parameters (in our example, a string).
+- The second one corresponds to parameters that are sent in the body
   of the HTTP request (POST parameters). We will see soon how to make
   services with POST parameters.
 
-The module <<a_api project="eliom" subproject="server" | module Eliom.Parameter >>
+The module {!Eliom.Parameter}
 defines the possible parameter types. For example if you write:
 
-{{{
+{v
 ~meth:(Eliom.Service.Get (Eliom.Parameter.int "i"))
-}}}
+v}
 
-Eliom will try to find a parameter called {{{i}}} and to translate it
-into an {{{int}}}.  In that case, the handler function will accept an
-{{{int}}} as the first parameter.
+Eliom will try to find a parameter called [i] and to translate it
+into an [int].  In that case, the handler function will accept an
+[int] as the first parameter.
 
 If you want to accept several parameters, you can do, for example:
 
-{{{
+{v
 ~meth:(Eliom.Service.Get Eliom.Parameter.(int "i" ** string "s"))
-}}}
+v}
 
-In that case, the handler function takes a pair of type {{{(int * string)}}}.
+In that case, the handler function takes a pair of type [(int * string)].
 
-//Warning:// The operator {{{**}}} is an infix //binary// operator.
+{e Warning:} The operator [**] is an infix {e binary} operator.
 It will always create pairs, and not triples or other tuples.
 
-The module <<a_api project="eliom" subproject="server" | module Eliom.Parameter >> also
+The module {!Eliom.Parameter} also
 defines other parameter types: for example floats, 64 bits integers,
 sum types, but also more complex types, like sets or lists of values.
 It is also possible to define your own parameter types.
 
->> <<| END "encadre" >>
+{%wodoc:end%} 
 
 For our program, we would prefer to take one part of the URL path as the parameter
 describing the name of the user.
 To achieve this we change the definition of the previous service this way:
 
-<<code language="ocaml"|
+{@ocaml[
 let user_service =
   Eliom.Registration.Html.create
     ~path:(Eliom.Service.Path ["users"])
     ~meth:(Eliom.Service.Get (
       Eliom.Parameter.(suffix (string "name"))))
     (fun name () -> ... )
->>
+]}
+
+The user pages are now available at URLs {%wodoc:span class="code"%}~http:~{e localhost:8080/users~}/username{e {%wodoc:end%}.
 
-The user pages are now available at URLs <<span
-class="code"|~http:~//localhost:8080/users~///username//>>.
+{%wodoc:aside class="concept"%}{b Concept: Using parts of the path as page parameters}
 
-<<concept title="Using parts of the path as page parameters" |
 
-The module <<a_api project="eliom" subproject="server" | module Eliom.Parameter >> makes
+
+The module {!Eliom.Parameter} makes
 it possible to use parts of the path as service (GET) parameters.
 
-In addition to <<a_api project="eliom" subproject="server" | val Eliom.Parameter.suffix
->>, there are many other values allowing you to specify your expected
+In addition to {!Eliom.Parameter.suffix}, there are many other values allowing you to specify your expected
 parameters: for example, you may access the full suffix as a string,
 as a list of string, or you may want to mix suffix parameters with
 standard GET parameters. You can also accept, as parameters, parts of
-the path that are not a suffix of the path (using <<a_api
-project="eliom" subproject="server" | val Eliom.Parameter.const >>).  See more information
-on suffixes in <<a_manual
-project="eliom" chapter="server-params" fragment="suffixes"|Eliom's manual>>.
+the path that are not a suffix of the path (using {!Eliom.Parameter.const}).  See more information
+on suffixes in {{:../eliom/server-params.html#suffixes}Eliom's manual}.
 
-//Warning:// Even if it is not displayed in the URL, suffix parameters
+}Warning:{e  Even if it is not displayed in the URL, suffix parameters
 have a parameter name. This allows one to make forms that point to
 those kind of services.  Actually each "suffix service" has an
 equivalent without suffix (which is by default automatically
 redirected towards the suffix version if it is a GET request).
 
->> <<| END "encadre" >>
+{%wodoc:end%} 
+
+{2 Links}
 
-===Links===
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-<<concepts|
-Links \\
+
+Links {%html:<br/>%}
 Database libraries
->>
+{%wodoc:end%}
 
 We now want to add a link on each user page to go back to the main
 page.
 
-Change the handler of {{{user_service}}} into:
+Change the handler of [user_service] into:
 
-<<code language="ocaml"|
+{@ocaml[
 (fun name () -> Lwt.return
   (html
     (head (title (txt name)) [])
     (body [h1 [txt name];
            p [a ~service:main_service [txt "Home"] ()]])))
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Creating hyperlinks}
 
-<<concept title="Creating hyperlinks" |
 
-The function <<a_api project="eliom" subproject="server" | val
-Eliom.Content.Html.D.a >> accepts the following parameters:
-* the service
-* the content of the link
-* URL parameters to be given to the service
+
+The function {!val
+Eliom.Content.Html.D.a} accepts the following parameters:
+- the service
+- the content of the link
+- URL parameters to be given to the service
 
 Thus, you don't have to know the precise URL of the service you want
 to link to, and if the URL changes, all links will remain valid.
-Using this function has a wonderful consequence: //You will never have
-broken links!//
+Using this function has a wonderful consequence: }You will never have
+broken links!{e 
 
->> <<| END "encadre" >>
+{%wodoc:end%} 
 
-====Links towards services with parameters====
+{3 Links towards services with parameters}
 
-In our example above, the last parameter is {{{()}}} because the
+In our example above, the last parameter is [()] because the
 service does not expect any parameter. If the service expects, for
-example, a pair {{{(int * string)}}}, you must provide a matching
+example, a pair [(int * string)], you must provide a matching
 value as last parameter.  OCaml checks at compile time that the type
 of the parameters in a link corresponds to the type expected by the
 service. Also parameter names are generated
@@ -226,7 +234,7 @@ To show an example of a link with parameters, we will display the list
 of user pages on the main page. Here is the new version of the full
 program:
 
-<<code language="ocaml"|
+{@ocaml[
 
 (* Services *)
 let main_service = Eliom.Service.create
@@ -268,81 +276,89 @@ let () = Eliom.Content.Html.D.(
            (body [h1 [txt name];
                   p [a ~service:main_service [txt "Home"] ()]])))
 )
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Mutually recursive services}
+
 
-<<concept title="Mutually recursive services" |
 
 As our two services are mutually recursive (the first one contains
 links towards the second one and vice versa), we split the
-{{{create}}} function application in two steps:
+[create] function application in two steps:
 
-* First we create all the services using
-  <<a_api project="eliom" subproject="server" | val Eliom.Service.create >>
-  or <<a_api project="eliom" subproject="server" | val Eliom.Service.App.service >>
+- First we create all the services using
+  {!Eliom.Service.create}
+  or {!Eliom.Service.App.service}
   (depending on the type of services you want)
-* Then we register the handlers using the {{{register}}} function from
+- Then we register the handlers using the [register] function from
   the right module.
 
-The function {{{create}}} we previously used is just a shortcut for these two functions (we create the service, then we register the handler).
+The function [create] we previously used is just a shortcut for these two functions (we create the service, then we register the handler).
+
+{%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: Database libraries}
 
->>
 
-<<concept title="Database libraries" |
 
 Ultimately we'll want to use a more sophisticated database module for
 managing user information, which we will write later in this tutorial.
 You can use any OCaml database binding (for example
-[[http://pgocaml.forge.ocamlcore.org/|PGOcaml]] to program
+{{:http://pgocaml.forge.ocamlcore.org/}PGOcaml} to program
 database queries). We will use our own database library called
-[[https://github.com/ocsigen/macaque|Macaque]], which implements typed requests using
-//comprehensions//.
+{{:https://github.com/ocsigen/macaque}Macaque}, which implements typed requests using
+}comprehensions{e .
 
-//Just remember that your query functions must be cooperative with
-Lwt!// For example PGOcaml is now implemented in monadic way, which
+}Just remember that your query functions must be cooperative with
+Lwt!{e  For example PGOcaml is now implemented in monadic way, which
 makes it 100% compatible with Lwt. Macaque (the library we use later
 in this tutorial) is as well.
 
 If your database module is not Lwt-cooperative but is thread-safe (for
-preemptive threads), you can use the <<a_api project="lwt" | val
-Lwt_preemptive.detach >> function to make the blocking function be
+preemptive threads), you can use the {!val
+Lwt_preemptive.detach} function to make the blocking function be
 executed by a separate preemptive thread.
 
->>
+{%wodoc:end%}
+
+{1 Sessions}
+
+{2 Connection service}
 
-==Sessions==
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-===Connection service===
 
-<<concepts|
 
-Services with hidden (POST) parameters\\
+Services with hidden (POST) parameters{%html:<br/>%}
 Fallback service
 
->>
+{%wodoc:end%}
 
 Now we want to add a connection form.  First, we create a service
 for checking the name and password.  Since we don't want the username
-and password to be shown in the URL, we use //hidden parameters//
+and password to be shown in the URL, we use }hidden parameters{e 
 (or POST parameters).  Thus, we need to create a new service taking
 these parameters:
 
-<<code language="ocaml"|
+{@ocaml[
 let connection_service = Eliom.Service.create_attached_post
   ~fallback:main_service
   ~post_params:Eliom.Parameter.(string "name" ** string "password")
   ()
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Hidden (POST) services}
+
 
-<<concept title="Hidden (POST) services" |
 
 Services using the POST HTTP method are created using the function
-<<a_api project="eliom" subproject="server" | val Eliom.Service.create >>
-or <<a_api project="eliom" subproject="server" | val Eliom.Service.create_attached_post >>
+{!Eliom.Service.create}
+or {!Eliom.Service.create_attached_post}
 (depending on what type of service you want to create).
 As you can see, there is a major
 difference from the way we created our previous services.
-Instead of providing a path for the {{{~path}}} argument, we gave a
-//fallback// service. This //fallback// is the service that will be used
+Instead of providing a path for the [~path] argument, we gave a
+}fallback{e  service. This }fallback{e  is the service that will be used
 if the POST parameters are missing (for example, the user sets a bookmark
 on the page and returns later without POST parameters).
 This way, we will not get 404 errors if this occurs.
@@ -352,12 +368,14 @@ and POST parameters. In that case, GET parameters will be in the URL
 and POST parameters will probably come from a form. In HTML, it is not
 possible to mix GET and POST parameters in the same form.
 
-See also [[basics|the cheat-sheet]] for an
+See also {{:basics.html}the cheat-sheet} for an
 comprehensive overview on the different types of services.
 
->>
+{%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: POST or GET?}
+
 
-<<concept title="POST or GET?" |
 
 POST parameters are sent in the body of the HTTP request (whereas GET
 parameters are sent in the URL).  It is important to understand that
@@ -365,21 +383,20 @@ they have very different semantics.
 
 Remember:
 
-* Use GET parameters when you want your page to be bookmarkable.
-* Use POST parameters when you do not want the page to be
+- Use GET parameters when you want your page to be bookmarkable.
+- Use POST parameters when you do not want the page to be
   bookmarkable, for example, because it performs a side effect on the
   server (connecting a user, add something in a database, perform a
   payment, etc.).
 
-//Warning:// Even if POST parameters are not shown in the URL, they
+}Warning:{e  Even if POST parameters are not shown in the URL, they
 are sent as plain text. If you want to transmit private data (like a password),
 you must
-use HTTPS (see <<a_manual project="ocsigenserver" chapter="config" |
-the Ocsigen server manual >>).  >>
+use HTTPS (see {{:../ocsigenserver/config.html}the Ocsigen server manual}).  {%wodoc:end%}
 
 Now we can register a handler for the new service:
 
-<<code language="ocaml"|
+{@ocaml[
   Eliom.Registration.Html.register
     ~service:connection_service
     (fun () (name, password) ->
@@ -392,29 +409,31 @@ Now we can register a handler for the new service:
         (html (head (title (txt "")) [])
            (body [h1 [txt message];
                   user_links ()])));
->>
+]}
 
-where {{{check_pwd}}} is defined by:
+where [check_pwd] is defined by:
 
-<<code language="ocaml"|
+{@ocaml[
 let check_pwd name pwd =
   try List.assoc name !users = pwd with Not_found -> false
->>
+]}
+
+{2 Connection form}
+
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-===Connection form===
 
-<<concepts|
 
 Forms
 
->>
+{%wodoc:end%}
 
 For now, we will add the connection form only on the main page of the
 site.
 
 Let's create a function for generating the form:
 
-<<code language="ocaml"|
+{@ocaml[
 let connection_box () = Eliom.Content.Html.D.(
   Form.post_form ~service:connection_service
     (fun (name1, name2) ->
@@ -434,62 +453,56 @@ let connection_box () = Eliom.Content.Html.D.(
             Form.string
          ]]) ()
 )
->>
+]}
 
 Now, add a call to this function in the handler of the main service
 (for example just before the user links).
 
-<<concept title="Forms" |
+{%wodoc:aside class="concept"%}{b Concept: Forms}
+
+
 
 Form creation is very similar to link creation, using the functions
-<<a_api project="eliom" subproject="server"
-text="val Eliom.Content.Html.D.Form.get_form"
-| val Eliom.Content_sigs.LINKS_AND_FORMS.Form.get_form >> and
-<<a_api project="eliom" subproject="server"
-text="val Eliom.Content.Html.D.Form.post_form"
-| val Eliom.Content_sigs.LINKS_AND_FORMS.Form.post_form >>.
+{{!Eliom.Content_sigs.LINKS_AND_FORMS.Form.get_form}val Eliom.Content.Html.D.Form.get_form} and
+{{!Eliom.Content_sigs.LINKS_AND_FORMS.Form.post_form}val Eliom.Content.Html.D.Form.post_form}.
 
 The first parameter is the service, and the last parameter (only for
-{{{post_form}}}) is for GET parameters you want sent in the URL, if
+[post_form]) is for GET parameters you want sent in the URL, if
 the fallback of your POST service takes GET parameters.
 
 The only difference is how we write form content: instead of simply
-giving the content as parameter to the {{{get_form}}} or
-{{{post_form}}} functions, you supply a function that creates the form
+giving the content as parameter to the [get_form] or
+[post_form] functions, you supply a function that creates the form
 from the names of the parameters the service is expecting.  Thus, you
 don't need to remember the parameter names you chose while creating
 the service, and you can change them easily without having to update
 every form in your application.
 
 In the example, note that the service is expecting a pair
-{{{(string * string)}}}.  The function given to {{{post_form}}} takes two
+[(string * string)].  The function given to [post_form] takes two
 parameters corresponding to the names of each field.
 
 Functions building widgets, like
-<<a_api project="eliom" subproject="server"
-text="val Eliom.Content.Html.D.Form.input"
-| val Eliom.Content_sigs.LINKS_AND_FORMS.Form.input >>,
+{{!Eliom.Content_sigs.LINKS_AND_FORMS.Form.input}val Eliom.Content.Html.D.Form.input},
 expect an argument of type
-<<a_api project="eliom" subproject="server"
-text="type Eliom.Content.Html.D.Form.param"
-| type Eliom.Content_sigs.LINKS_AND_FORMS.Form.param >>
+{{!Eliom.Content_sigs.LINKS_AND_FORMS.Form.param}type Eliom.Content.Html.D.Form.param}
 (e.g.,
-{{{ Eliom.Content.Html.D.Form.int : int Eliom.Content.Html.D.Form.param}}})
+[Eliom.Content.Html.D.Form.int : int Eliom.Content.Html.D.Form.param])
 specifying the parameter type.  OCaml checks that the name you use
 matches the field.  For example the names above need to be used with
-<<a_api project="eliom" subproject="server"
-text="val Eliom.Content.Html.D.Form.string"
-| val Eliom.Content_sigs.LINKS_AND_FORMS.Form.string >>.
+{{!Eliom.Content_sigs.LINKS_AND_FORMS.Form.string}val Eliom.Content.Html.D.Form.string}.
 
->>
+{%wodoc:end%}
+
+{2 Opening a session}
+
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-===Opening a session===
 
-<<concepts|
 
 Session data, Eliom references
 
->>
+{%wodoc:end%}
 
 Now we want to remember that the user is successfully connected.  To do
 that we will set a reference when the user successfully connects, and
@@ -497,14 +510,14 @@ we will restrict the scope of this reference to the session (that is,
 to the browser).
 
 Define your Eliom reference with a default value:
-<<code language="ocaml"|
+{@ocaml[
 let username =
   Eliom.Reference.eref ~scope:Eliom.Common.default_session_scope None
->>
+]}
 
-Here is the new {{{connection_box}}} function:
+Here is the new [connection_box] function:
 
-<<code language="ocaml"|
+{@ocaml[
 let connection_box () = Eliom.Content.Html.D.(
   let%lwt u = Eliom.Reference.get username in
   Lwt.return
@@ -529,11 +542,11 @@ let connection_box () = Eliom.Content.Html.D.(
                   Form.string
                ]]) ())
 )
->>
+]}
 
 ...~ and replace the registration of the main service and the connection service by:
 
-<<code language="ocaml"|
+{@ocaml[
   Eliom.Registration.Html.register
     ~service:main_service
     (fun () () ->
@@ -560,109 +573,119 @@ let connection_box () = Eliom.Content.Html.D.(
         (html (head (title (txt "")) [])
            (body [h1 [txt message];
                   user_links ()])));
->>
+]}
+
 
+{%wodoc:aside class="concept"%}{b Concept: Eliom references and extended sessions}
 
-<<concept title="Eliom references and extended sessions" id="eref"|
 
-Session data is stored in what we call //Eliom references//.
+
+Session data is stored in what we call }Eliom references{e .
 It is a type of reference whose value depend on the session the user
 belongs to.
 
 Eliom is making the notion of session much more powerful by adding
-other //scopes// for Eliom references. Instead of limiting the scope
+other }scopes{e  for Eliom references. Instead of limiting the scope
 to a session (that is: one browser), it is also possible to create
 Eliom references with scope
-* "client-side process"
-({{{~scope:Eliom.Common.default_process_scope}}}),
-* or "group of sessions" (see
-later) ({{{~scope:Eliom.Common.default_group_scope}}}),
-* or "current
-request" ({{{~scope:Eliom.Common.request_scope}}})
+- "client-side process"
+([~scope:Eliom.Common.default_process_scope]),
+- or "group of sessions" (see
+later) ([~scope:Eliom.Common.default_group_scope]),
+- or "current
+request" ([~scope:Eliom.Common.request_scope])
 (for example to cache the data during the request,
-or for //actions// to give information to subsequent service -- see below).
+or for }actions{e  to give information to subsequent service -- see below).
 
 Example: Say you want to implement a game, and make possible to have several instances of the game running in several tabs of the browser. Store the score on server side, as a "client side process" Eliom reference.
 
 Example: Grouping all the sessions for one user in a group of session makes possible to share a shopping basket between several devices (your mobile phone and your laptop for example).
 
 An Eliom reference is defined with the function
-{{{Eliom.Reference.eref}}}, specifying the scope of this reference
-and the default value. The function {{{Eliom.Reference.get}}}
+[Eliom.Reference.eref], specifying the scope of this reference
+and the default value. The function [Eliom.Reference.get]
 retrieves the value of this reference for the current scope.
 The default value is used for
 all sessions (or client process or group of sessions) for which it has not
-been changed using {{{Eliom.Reference.set}}}.
+been changed using [Eliom.Reference.set].
 
 By default, Eliom references are kept in memory and will disappear if
 you shut down the server. It is possible, however, to create
-//persistent Eliom references// that will survive even a server
-restart. To do that, add the optional parameter {{{persistent}}} to
-the {{{eref}}} function, with a string value corresponding to the name
+}persistent Eliom references{e  that will survive even a server
+restart. To do that, add the optional parameter [persistent] to
+the [eref] function, with a string value corresponding to the name
 of the table that will contain the values on disk.
 
 You need to rename this table every time you change the type
 of your Eliom reference, otherwise the server will crash (we are using
-OCaml's {{{Marshal}}} module).
+OCaml's [Marshal] module).
 
 It is not possible to create Eliom references containing functions
 (closures), due to limitations in OCaml's serialization mechanism.
 
->> <<| END "encadre" >>
+{%wodoc:end%} 
+
+{2 Display the usual page after connection}
+
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-===Display the usual page after connection===
 
-<<concepts|
 
 Actions
 
->>
+{%wodoc:end%}
 
 As you can see, our connection service is displaying a welcome page
 which is different from the main page in connected mode.  We would
 rather display the same page.  One solution is to call the same
 handler after registering session data.
 
-A cleaner solution is to use an //action//, that is: a service which will
+A cleaner solution is to use an }action{e , that is: a service which will
 just perform a side effect.  Replace the registration
 of the connection service by:
 
-<<code language="ocaml"|
+{@ocaml[
   Eliom.Registration.Action.register
     ~service:connection_service
     (fun () (name, password) ->
       if check_pwd name password
       then Eliom.Reference.set username (Some name)
       else Lwt.return ());
->>
+]}
 
 Now the main page is displayed after connection.
 
-<<concept title="Actions" |
+{%wodoc:aside class="concept"%}{b Concept: Actions}
+
 
-An //action// is a service that performs a side effect and redisplays
-the current page. The handler function returns {{{()}}}.
 
->>
+An }action{e  is a service that performs a side effect and redisplays
+the current page. The handler function returns [()].
 
-===Putting a connection form on each page===
+{%wodoc:end%}
 
-<<concepts|
+{2 Putting a connection form on each page}
 
-Non-attached coservices\\
+{%wodoc:aside class="concepts"%}{b Concepts}
+
+
+
+Non-attached coservices{%html:<br/>%}
 Redirections
 
->>
+{%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: Non-attached coservices}
+
 
-<<concept title="Non-attached coservices" |
 
 With many web programming frameworks, adding a connection form on each
 page of a site is complicated, and is approached in one of two ways:
 
-* A first solution is similar to what we did for the main service, but
+- A first solution is similar to what we did for the main service, but
   for all services (meaning that each page usually checks the presence
   of POST parameters). This is clumsy.
-* Another solution would be to create a special page on a separate
+- Another solution would be to create a special page on a separate
   path to handle the registration, with some way to do a redirection
   to the page we came from after connection. (Of course we want to
   stay on the same page after sending the connection form!) This is
@@ -670,37 +693,37 @@ page of a site is complicated, and is approached in one of two ways:
 
 With Eliom, this is more straightforward:
 
-* For the connection service, we use a kind of service called
-  //non-attached coservice//, which means that it is not attached to
+- For the connection service, we use a kind of service called
+  }non-attached coservice{e , which means that it is not attached to
   any path in particular. Calling this kind of service will not change
-  the //path// you see in the browser URL bar (just add parameters if
+  the }path{e  you see in the browser URL bar (just add parameters if
   you use the GET method).
-* Use an action to connect the user and redisplay the page
+- Use an action to connect the user and redisplay the page
   corresponding to the current URL.
 
 By default, a random identifier will be generated automatically by
 Eliom for the non-attached coservice. If you want this identifier to
 be fixed, you can specify it yourself while creating the service using
-the {{{?name}}} optional parameter. This identifier is added
+the [?name] optional parameter. This identifier is added
 automatically by Eliom in each form (as hidden field) and link.
 
->>
+{%wodoc:end%}
 
 We transform the connection service into a non_attached coservice,
-to do so we replace the path we specified earlier for the {{{~path}}} parameter:
+to do so we replace the path we specified earlier for the [~path] parameter:
 
-<<code language="ocaml"|
+{@ocaml[
 let connection_service = Eliom.Service.create
   ~path:(Eliom.Service.No_path)
   ~meth:(Eliom.Service.Post (
     Eliom.Parameter.unit,
     Eliom.Parameter.(string "name" ** string "password")))
   ()
->>
+]}
 
 Now you can add the connection box on user pages.
 
-<<code language="ocaml"|
+{@ocaml[
   Eliom.Registration.Html.register
     ~service:user_service
     (fun name () ->
@@ -710,21 +733,22 @@ Now you can add the connection box on user pages.
               (body [h1 [txt name];
 		     cf;
                      p [a ~service:main_service [txt "Home"] ()]])));
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Alternative: register a redirection}
+
 
-<<concept title="Alternative: register a redirection" |
 
 Usually, after sending a POST form, it is good practice to do a
 redirection.  This avoids reposting the data if the user reloads the
 page.
 
-Eliom provides the module <<a_api project="eliom" subproject="server" |
-module Eliom.Registration.Redirection >> to register services doing
+Eliom provides the module {!Eliom.Registration.Redirection} to register services doing
 redirections.  Such services return a service without parameter.
 
 Example:
 
-<<code language="ocaml"|
+{@ocaml[
 
 let redir_service = Eliom.Service.create
     ~path:(Eliom.Service.Path ["redir"])
@@ -748,28 +772,24 @@ let () =
   Eliom.Registration.Any.register
   ~service:service_to_redirect
   (fun () something -> ..... )
->>
+]}
 
-(If you want to give parameters to the service you return, use <<a_api
-project="eliom" subproject="server" | val Eliom.Service.preapply >> ---
-more information in the <<a_manual project="eliom" chapter="server-services"
-fragment="p3preapplied" | Eliom manual >>.)
+(If you want to give parameters to the service you return, use {!Eliom.Service.preapply} ---
+more information in the {{:../eliom/server-services.html#p3preapplied}Eliom manual}.)
 
 If you want to do a redirection towards the current page (as in our
-case), use the special service {{{~path}}} parameter <<a_api project="eliom" subproject="server" |
-val Eliom.Service.No_path >>, which is some kind of POST
-non-attached coservice without parameter at all.  >>
+case), use the special service [~path] parameter {!Eliom.Service.No_path}, which is some kind of POST
+non-attached coservice without parameter at all.  {%wodoc:end%}
 
-===Disconnection===
+{2 Disconnection}
 
 To create a logout/disconnection form, we create another non-attached
 coservice using POST method, and register another action.  We call the
-function <<a_api project="eliom" subproject="server" | val
-Eliom.State.discard >> with scope <<a_api project="eliom" subproject="server"
-| val Eliom.Common.default_session_scope >> to remove all session
+function {!val
+Eliom.State.discard} with scope {!Eliom.Common.default_session_scope} to remove all session
 data.
 
-<<code language="ocaml"|
+{@ocaml[
 let disconnection_service = Eliom.Service.create
   ~path:(Eliom.Service.No_path)
   ~meth:(Eliom.Service.Post (Eliom.Parameter.unit, Eliom.Parameter.unit))
@@ -787,11 +807,11 @@ let () =
   Eliom.Registration.Action.register
     ~service:disconnection_service
     (fun () () -> Eliom.State.discard ~scope:Eliom.Common.default_session_scope ())
->>
+]}
 
 Then add this form in the connection box:
 
-<<code language="ocaml"|
+{@ocaml[
 let connection_box () =
   let%lwt u = Eliom.Reference.get username in
   Lwt.return
@@ -799,24 +819,26 @@ let connection_box () =
       | Some s -> div [p [txt "You are connected as "; txt s; ];
                        disconnect_box () ]
       | None -> ...
->>
+]}
+
+{1 Registration of users}
 
-==Registration of users==
+{2 Basic registration form}
+
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-===Basic registration form===
 
-<<concepts|
 
 Attached coservice
 
->>
+{%wodoc:end%}
 
 We now add a registration form to the application.  We create a
-new regular service, attached to the path {{{/registration}}}, that
+new regular service, attached to the path [/registration], that
 displays a registration form, and an action that will add the user to
 the "database":
 
-<<code language="ocaml"|
+{@ocaml[
 let new_user_form_service = Eliom.Service.create
   ~path:(Eliom.Service.Path ["registration"])
   ~meth:(Eliom.Service.Get Eliom.Parameter.unit)
@@ -857,11 +879,11 @@ let _ = Eliom.Content.Html.D.(
       users := (name, pwd)::!users;
       Lwt.return ())
 )
->>
+]}
 
 Then add the link to this service in the connection box:
 
-<<code language="ocaml"|
+{@ocaml[
 let connection_box () = Eliom.Content.Html.D.(
   let%lwt u = Eliom.Reference.get username in
   Lwt.return
@@ -877,12 +899,14 @@ let connection_box () = Eliom.Content.Html.D.(
                   [txt "Create an account"] ()]]
             )
 )
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Attached coservice}
+
 
-<<concept title="Attached coservice" |
 
 Now we want to return to the main page after account creation.  We are
-using an //attached coservice//, that is, a service that is identified
+using an }attached coservice{e , that is, a service that is identified
 by both the path in the URL and a special coservice number (or name).
 A form to such a service will change the path and send parameters
 together with the coservice identifier (added automatically in an
@@ -894,7 +918,7 @@ may want to distinguish between several services registered at the
 same path (and with same parameters).  That's what attached coservices
 are made for.
 
->>
+{%wodoc:end%}
 
 It looks great, but if we refresh the page after creating an account,
 we can see there is a problem. We are creating the same account over and
@@ -903,27 +927,29 @@ we refresh the page, obviously we don't want that. To solve this issue we will
 implement a dynamically created and registered service with limited lifespan and
 number of uses.
 
-===Registration form with confirmation===
+{2 Registration form with confirmation}
 
-<<concepts|
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-Dynamic registration of services\\
-Session services\\
+
+
+Dynamic registration of services{%html:<br/>%}
+Session services{%html:<br/>%}
 Limited services
 
->>
+{%wodoc:end%}
 
 Now we want to add a confirmation page before actually creating the
-account.  We //replace// the service {{{create_account_service}}} by a
-new POST attached coservice called {{{account_confirmation_service}}}:
+account.  We }replace{e  the service [create_account_service] by a
+new POST attached coservice called [account_confirmation_service]:
 
-<<code language="ocaml"|
+{@ocaml[
 let account_confirmation_service =
   Eliom.Service.create_attached_post
     ~fallback:new_user_form_service
     ~post_params:(Eliom.Parameter.(string "name" **  string "password"))
     ()
->>
+]}
 
 and we make the account creation form point at this new service.
 
@@ -931,7 +957,7 @@ We register an HTML handler on this service, with the confirmation
 page.  As a side effect, this page will create the actual account
 creation service:
 
-<<code language="ocaml"|
+{@ocaml[
 
   Eliom.Registration.Html.register
     ~service:account_confirmation_service
@@ -959,79 +985,83 @@ creation service:
                   txt " ";
                   a ~service:main_service [txt "No"] ()]
               ])));
->>
+]}
 
-Also remove the registration of the {{{create_account_service}}}
+Also remove the registration of the [create_account_service]
 service and modify the user creation form to make it points towards
-{{{account_confirmation_service}}}.
+[account_confirmation_service].
 
 We created dynamically a service with a limited lifespan as specified by the
-{{{?timeout}}} parameter and a limited number of uses of this service defined
-by the {{{?max_use}}} parameter. Now if we refresh the page after creating the
+[?timeout] parameter and a limited number of uses of this service defined
+by the [?max_use] parameter. Now if we refresh the page after creating the
 account, it works as intended.
 
-<<concept title="Dynamic creation of services" |
+{%wodoc:aside class="concept"%}{b Concept: Dynamic creation of services}
+
+
 
 In this example, we are dynamically creating a new service (here a
 coservice that does an action).  This is done by the same
-{{{register}}} function as usual.
+[register] function as usual.
 
 Dynamic creation of new services allows one to create services that
 depend on previous interaction with the user.  Here the
-{{{create_account_service}}} service depends on {{{name}}} and
-{{{pwd}}}, that were previously sent by a form.
+[create_account_service] service depends on [name] and
+[pwd], that were previously sent by a form.
 
 In this simple example, an alternative would have been to send
-{{{name}}} and {{{pwd}}} again to the same service as in the "basic
+[name] and [pwd] again to the same service as in the "basic
 registration form" example. But this solution is not possible when you
 have too much data.
 
-//Saving {{{name}}} and {{{pwd}}} as session data is a wrong
-solution!// If the user duplicates his browser window and fills out
+}Saving [name] and [pwd] as session data is a wrong
+solution!{e  If the user duplicates his browser window and fills out
 the user creation form in both, then the confirmation link must create
 the right account!
 
 A working alternative would have been to generate a random key, and
-associate {{{name}}} and {{{pwd}}} with that key in a database table
+associate [name] and [pwd] with that key in a database table
 on the server. This is the way such kind of web interaction is usually
 implemented. However, Eliom's solution is much simpler.
 
 The ability to register new services dynamically is implemented in few
 web frameworks, even though it simplifies a lot the programmating
 involved with that type of web interaction.  This feature is a variant
-of what is called //continuation based web programming//.  Think about
-it when you want to //create a page that depends on previous
-interaction with the user//. Dynamic registration of services will
+of what is called }continuation based web programming{e .  Think about
+it when you want to }create a page that depends on previous
+interaction with the user{e . Dynamic registration of services will
 automatically record the "history" of the interaction, and make
 possible to use the "back button" or to have several tabs on the same
 site.
 
 Examples of uses:
-* displaying the results of a search
-* programming a "several step form" (when a form points at another
+- displaying the results of a search
+- programming a "several step form" (when a form points at another
   one, etc., like our registration form with confirmation).
 
-On the other hand, if you want to implement a //shopping basket//, you
+On the other hand, if you want to implement a }shopping basket{e , you
 want it to be shared between all tabs of your web site.  To do that,
 you will use session data.
 
-//Warning:// Services are kept in memory. To avoid memory leaks, you
+}Warning:{e  Services are kept in memory. To avoid memory leaks, you
 probably want to put a timeout on your dynamic coservices. Just add
-the optional parameter {{{?timeout}}} to the service creation
+the optional parameter [?timeout] to the service creation
 function.
 
->> <<| END "encadre" >>
+{%wodoc:end%} 
+
+{%wodoc:aside class="concept"%}{b Concept: Session services}
+
 
-<<concept title="Session services" |
 
 Eliom also makes it possible to restrict the scope of services to a
 session, a group of sessions, or even a client side process (if you
 have a client side program running).  It works exactly like the scope
 of Eliom references.  To do that, just add the optional parameter
-{{{~scope}}} to the registration function.  By default, the value is
-{{{Eliom.Common.global_scope}}} (visible for everyone).  Other possible
-values: {{{Eliom.Common.default_session_scope}}}, {{{Eliom.Common.default_group_scope}}},
-or {{{Eliom.Common.default_process_scope}}}.
+[~scope] to the registration function.  By default, the value is
+[Eliom.Common.global_scope] (visible for everyone).  Other possible
+values: [Eliom.Common.default_session_scope], [Eliom.Common.default_group_scope],
+or [Eliom.Common.default_process_scope].
 
 It is possible to register again for a session, tab or group, services
 that have already been registered with public (site) visibility.  In
@@ -1040,32 +1070,34 @@ then group services, and finally site services.  This makes possible
 to register specialized versions of a service for one user, for
 example when she logs in.
 
->>
+{%wodoc:end%}
+
+{1 A few enhancements}
+
+{2 Displaying a "wrong password" message}
 
-==A few enhancements==
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-===Displaying a "wrong password" message===
 
-<<concepts|
 Scope "request"
->>
+{%wodoc:end%}
 
 In the current version, our web site fails silently when the password
 is wrong.  Let's improve this behavior by displaying an error message.
 To do that, we need to pass information to the service occurring after
 the action. We record this information in an Eliom reference with
-scope {{{Eliom.Common.request_scope}}}.
+scope [Eliom.Common.request_scope].
 
 Define an Eliom reference:
 
-<<code language="ocaml"|
+{@ocaml[
 let wrong_pwd =
   Eliom.Reference.eref ~scope:Eliom.Common.request_scope false
->>
+]}
 
 Modify the connection box this way:
 
-<<code language="ocaml"|
+{@ocaml[
 let connection_box () = Eliom.Content.Html.D.(
   let%lwt u = Eliom.Reference.get username in
   let%lwt wp = Eliom.Reference.get wrong_pwd in
@@ -1094,37 +1126,39 @@ let connection_box () = Eliom.Content.Html.D.(
         else div l
     )
 )
->>
+]}
 
-...~ and modify the {{{connection_service}}} handler:
+...~ and modify the [connection_service] handler:
 
-<<code language="ocaml"|
+{@ocaml[
   Eliom.Registration.Action.register
     ~service:connection_service
     (fun () (name, password) ->
       if check_pwd name password
       then Eliom.Reference.set username (Some name)
       else Eliom.Reference.set wrong_pwd true);
->>
+]}
 
-===Sending 404 errors for non-existing users===
+{2 Sending 404 errors for non-existing users}
 
-<<concepts|
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-Sending 404\\
-{{{Eliom.Registration.Any}}}
 
->>
 
-Our service {{{user_service}}} responds to any request parameter, even
+Sending 404{%html:<br/>%}
+[Eliom.Registration.Any]
+
+{%wodoc:end%}
+
+Our service [user_service] responds to any request parameter, even
 if the user does not exist in the database.  We want to check that the
 user is in the database before displaying the page, and send a 404
 error if the user is not.  To do that, we will replace module
-{{{ Eliom.Registration.Html }}}
-by <<a_api project="eliom" subproject="server" | module
-Eliom.Registration.Any >> to register the service {{{user_service}}}:
+[Eliom.Registration.Html]
+by {!module
+Eliom.Registration.Any} to register the service [user_service]:
 
-<<code language="ocaml"|
+{@ocaml[
   Eliom.Registration.Any.register
     ~service:user_service
     (fun name () ->
@@ -1144,45 +1178,46 @@ Eliom.Registration.Any >> to register the service {{{user_service}}}:
              (body [h1 [txt "404"];
                     p [txt "That page does not exist"]]))
     );
->>
+]}
+
+
 
-<<| BB
-  Why not {{{raise_lwt Eliom.Common.Eliom_404}}}?
-  >>
+{%wodoc:aside class="concept"%}{b Concept: Eliom.Registration.Any}
 
-<<concept title="Eliom.Registration.Any" |
 
-The module <<a_api project="eliom" subproject="server" | module
-Eliom.Registration.Any >> can be used to create services that are
+
+The module {!module
+Eliom.Registration.Any} can be used to create services that are
 flexible to choose the kind of output they want to send.
 
-Use the {{{send}}} function from the module you want to send the
+Use the [send] function from the module you want to send the
 output.  That function also allows, for example, to specify the HTTP
 response code (here, we choose to use 404) or to set HTTP headers.
 
->>
+{%wodoc:end%}
+
+{%wodoc:aside class="wip"%}{b Work in progress}
+
 
-<<wip|
 
-In the future, we may add functions like {{{set_http_code}}} or
-{{{set_http_header}}} to personalize the answer without using
-{{{Eliom.Registration.Any}}}.
+In the future, we may add functions like [set_http_code] or
+[set_http_header] to personalize the answer without using
+[Eliom.Registration.Any].
 
->>
+{%wodoc:end%}
 
-=== Wrapping the server handler to easily get the user data
+{2 Wrapping the server handler to easily get the user data}
 
 When you want to assume that you have information available in
 sessions, for instance when a site is mainly available to connected
 users, it becomes tedious to check everywhere that a reference is not
-{{{None}}}.  A simple way to distinguish authenticated and anonymous
-requests lies in the usage of <<a_api project="eliom"
-subproject="server"|val Eliom.Tools.wrap_handler>>. It allows you to
+[None].  A simple way to distinguish authenticated and anonymous
+requests lies in the usage of {!Eliom.Tools.wrap_handler}. It allows you to
 provide two handler functions, one is called if a certain
 information is not made available by the first argument, the other is
 called when that information is available.
 
-<<code language="ocaml"|
+{@ocaml[
 
 let authenticated_handler f = Eliom.Content.Html.D.(
   let handle_anonymous _get _post =
@@ -1220,7 +1255,7 @@ let () = Eliom.Content.Html.D.(
               (head (title (txt "")) [])
               (body [h1 [txt ("Hello " ^ username) ]]))))
 )
->>
+]}
 
-[[wiki:manual/application|prev]]
-[[wiki:manual/misc|next]]
+{{:wiki:manual/application}prev}
+{{:wiki:manual/misc}next}
diff --git a/tutos/dev/manual/intro.mld b/tutos/dev/manual/intro.mld
new file mode 100644
index 00000000..04a8f2a4
--- /dev/null
+++ b/tutos/dev/manual/intro.mld
@@ -0,0 +1,139 @@
+
+{0 Introduction}
+
+Ocsigen is a complete framework for developing Web and mobile apps
+using cutting edge techniques. It can be used to write simple server side
+Web sites, client-side programs, or complex client-server Web
+and mobile apps.
+Its main characteristics are:
+
+- The use of a strongly typed language, {e OCaml}, and a very advanced use
+of its type system to check many properties of a program at compile time.
+This allows to drastically reduce the development time of complex apps,
+and makes it easier to refactor the code to follow evolutions of its features.
+As an example, the conformance of generated HTML is checked at compile time,
+which makes it almost impossible to generate invalid pages.
+- {e Multi-tier programming}: client and server sides of the application are
+written using the same language, and as a {e single code}. Annotations in
+the code are used indicate on which side the code is to be run.
+The client side parts are automatically extracted and compiled into JavaScript
+to be executed in the browser.
+This gives a lot of flexibility to the programmer, allowing for example to
+generate some parts of pages either on client or server code according
+to your needs. It also makes communication between server and client
+straightforward, as you can use server side variables in client code,
+or call a server side OCaml functions from client code.
+- {e Web and mobile multi-platform apps}: Android and iOS apps are
+generated from the exact same code as the Web app, and run in a webview.
+
+To see some examples of mobile or Web apps written with Ocsigen, have a look
+at the {{:https://www.besport.com/news}Be Sport social network} (available in
+{{:https://play.google.com/store/apps/details?id=com.besport.www.mobile}Google Play Store} and {{:https://apps.apple.com/fr/app/be-sport/id1104216922}Apple app store}), or
+{{:http://ocsigen-1.inria.fr/ocsigen-start/demo/}Ocsigen Start's demo app}
+(available on {{:https://play.google.com/store/apps/details?id=com.osdemo.mobile}Google Play store}).
+
+Ocsigen consists of several quite independent projects, all
+released as open source software on {{:https://github.com/ocsigen}Github}.
+The main projects are:
+- {{:../lwt/}Lwt}, a general purpose concurrent programming library for OCaml,
+- {{:../tyxml/}TyXML} for generating typed XML,
+- the {{:../js_of_ocaml/}Js_of_ocaml} compiler (from Ocaml bytecode to JavaScript),
+- {{:../eliom/}Eliom}, the multi-tier framework for client-server
+Web and mobile apps,
+- {{:../ocsigenserver/}Ocsigen Server}, a full-featured Web server,
+- {{:../ocsigen-toolkit/}Ocsigen Toolkit}, a client-server widget library written for Eliom and Js_of_ocaml,
+- {{:../ocsigen-start/}Ocsigen Start}, an application template with
+many code examples, to be used as a basis for your apps, or to learn.
+
+The {{:../install}installation is described here}.
+
+Ocsigen originates from a research project by the CNRS, Université de Paris
+and Inria. It innovates in many aspects, and you will have to learn several
+new programming techniques to become autonomous.
+Depending on your level and goals, we suggest to continue by reading
+some of the following chapters:
+
+- Chapter {{:wiki:manual/basics}Client-server application programming guide} can be used as your training plan.
+It provides a wide overview of each main concept, with links to more detailed
+documentation.
+- If you want to start with a server-side only Web site, read {{:wiki:manual/basics-server}Server-side website programming guide} instead.
+- Then, a good starting point is this
+{{:wiki:manual/start}Ocsigen Start tutorial},
+if you plan to build a client-server Web (and/or mobile) app.
+It will help you to build your first app very quickly,
+with many code samples to study.
+- If you are fluent in OCaml and want a quick introduction to
+client-server Web programming with Eliom,
+read tutorial
+{{:wiki:manual/tutowidgets}Eliom apps basics: writing client server widgets}.
+It illusrates the client-server syntax with an example,
+and is a good starting point for understanding Eliom's client-server features.
+- If you want a full step-by-step tutorial on how to write a client-server Web
+application, read tutorial
+{{:wiki:manual/application}Client-server application}.
+It describes step by step how to write a client/server
+{{:../graffiti/}collaborative drawing application}. You will learn,
+from the very beginning, how to:
+- Create new {e services}
+- Output {e valid HTML}
+- Send {e OCaml code} to be executed {e on the client}
+- Call {e JavaScript methods} from OCaml
+- Catch {e mouse events}
+- {e Communicate} with the server, in both directions
+- Create services with {e non-HTML output}
+- If you want to build mobile applications,
+read tutorial {{:wiki:manual/mobile}Mobile applications with Ocsigen}.
+It describes how to build a mobile app (e.g., for Android)
+with the same codebase as for your Web application.
+- If you want to write a more traditional Web site, with pages, forms, and sessions, read tutorial {{:wiki:manual/interaction}Service based Web programming}.
+It is devoted to server side programming.
+It shows how to
+create a new Web site with several pages and user connections.
+You will learn how to:
+- Create a {e link} towards another service
+- Create {e forms}
+- Register {e session data} or {e session services}
+- Create services performing {e actions} (with no output)
+- Dynamically register new services ({e continuation based} Web programming)
+- If you want to learn more details about Ocsigen
+read tutorial {{:wiki:manual/misc}Miscellaneous features}.
+It will mix the client-server drawing application
+with the session mechanism and user management
+to produce a multi-user collaborative drawing
+application.  In this chapter, you will learn how to:
+- Integrate a typical Web interaction (links, forms,~ …) with a client side program.
+- Add {e sounds or videos} to your application
+- Change pages {e without stopping the client side program}
+- Connect with external accounts ({e openID})
+- Add an Atom feed
+- If you want to have a full application with user management
+(registration, activation emails, authentication),
+have a look at {{:../ocsigen-start/}Ocsigen-start}.
+Ocsigen-start is a library and a template for Eliom distillery that
+contains a working Eliom application with user and right
+management.
+- For a more comprehensive understanding refer to the manual of each project,
+and/or the API documentation.
+- You will also find more tutorials in the menu on the left.
+
+
+
+
+
+
+
+
+
+
+We recommend to ask your questions on
+{{:https://discuss.ocaml.org}discuss.ocaml.org} with tag [ocsigen].
+You can also come and chat with us on
+IRC in channel [#ocsigen] on [freenode.net] (e.g. by using
+their {{:http://webchat.freenode.net/?channels=ocsigen}webchat})!
+
+
+Now, we recommend to read, chapter
+{{:wiki:manual/basics}All Ocsigen in one page}
+for a wide and complete overview.
+
+
diff --git a/tutos/dev/manual/intro.wiki b/tutos/dev/manual/intro.wiki
deleted file mode 100644
index 01fec817..00000000
--- a/tutos/dev/manual/intro.wiki
+++ /dev/null
@@ -1,157 +0,0 @@
-
-=Introduction=
-
-Ocsigen is a complete framework for developing Web and mobile apps
-using cutting edge techniques. It can be used to write simple server side
-Web sites, client-side programs, or complex client-server Web
-and mobile apps.
-Its main characteristics are:
-
-* The use of a strongly typed language, //OCaml//, and a very advanced use
-of its type system to check many properties of a program at compile time.
-This allows to drastically reduce the development time of complex apps,
-and makes it easier to refactor the code to follow evolutions of its features.
-As an example, the conformance of generated HTML is checked at compile time,
-which makes it almost impossible to generate invalid pages.
-* //Multi-tier programming//: client and server sides of the application are
-written using the same language, and as a //single code//. Annotations in
-the code are used indicate on which side the code is to be run.
-The client side parts are automatically extracted and compiled into JavaScript
-to be executed in the browser.
-This gives a lot of flexibility to the programmer, allowing for example to
-generate some parts of pages either on client or server code according
-to your needs. It also makes communication between server and client
-straightforward, as you can use server side variables in client code,
-or call a server side OCaml functions from client code.
-* //Web and mobile multi-platform apps//: Android and iOS apps are
-generated from the exact same code as the Web app, and run in a webview.
-
-To see some examples of mobile or Web apps written with Ocsigen, have a look
-at the [[https://www.besport.com/news|Be Sport social network]] (available in
-[[https://play.google.com/store/apps/details?id=com.besport.www.mobile|Google Play Store]] and [[https://apps.apple.com/fr/app/be-sport/id1104216922|Apple app store]]), or
-[[http://ocsigen-1.inria.fr/ocsigen-start/demo/|Ocsigen Start's demo app]]
-(available on [[https://play.google.com/store/apps/details?id=com.osdemo.mobile|Google Play store]]).
-
-Ocsigen consists of several quite independent projects, all
-released as open source software on [[https://github.com/ocsigen|Github]].
-The main projects are:
-* [[wiki("lwt"):|Lwt]], a general purpose concurrent programming library for OCaml,
-* [[wiki("tyxml"):|TyXML]] for generating typed XML,
-* the [[wiki("js_of_ocaml"):|Js_of_ocaml]] compiler (from Ocaml bytecode to JavaScript),
-* [[wiki("eliom"):|Eliom]], the multi-tier framework for client-server
-Web and mobile apps,
-* [[wiki("ocsigenserver"):|Ocsigen Server]], a full-featured Web server,
-* [[wiki("ocsigen-toolkit"):|Ocsigen Toolkit]], a client-server widget library written for Eliom and Js_of_ocaml,
-* [[wiki("ocsigen-start"):|Ocsigen Start]], an application template with
-many code examples, to be used as a basis for your apps, or to learn.
-
-The [[site:install|installation is described here]].
-
-Ocsigen originates from a research project by the CNRS, Université de Paris
-and Inria. It innovates in many aspects, and you will have to learn several
-new programming techniques to become autonomous.
-Depending on your level and goals, we suggest to continue by reading
-some of the following chapters:
-
-* Chapter [[wiki:manual/basics|Client-server application programming guide]] can be used as your training plan.
-It provides a wide overview of each main concept, with links to more detailed
-documentation.
-* If you want to start with a server-side only Web site, read [[wiki:manual/basics-server|Server-side website programming guide]] instead.
-* Then, a good starting point is this
-[[wiki:manual/start|Ocsigen Start tutorial]],
-if you plan to build a client-server Web (and/or mobile) app.
-It will help you to build your first app very quickly,
-with many code samples to study.
-* If you are fluent in OCaml and want a quick introduction to
-client-server Web programming with Eliom,
-read tutorial
-[[wiki:manual/tutowidgets|Eliom apps basics: writing client server widgets]].
-It illusrates the client-server syntax with an example,
-and is a good starting point for understanding Eliom's client-server features.
-* If you want a full step-by-step tutorial on how to write a client-server Web
-application, read tutorial
-[[wiki:manual/application|Client-server application]].
-It describes step by step how to write a client/server
-[[site:graffiti/|collaborative drawing application]]. You will learn,
-from the very beginning, how to:
-** Create new //services//
-** Output //valid HTML//
-** Send //OCaml code// to be executed //on the client//
-** Call //JavaScript methods// from OCaml
-** Catch //mouse events//
-** //Communicate// with the server, in both directions
-** Create services with //non-HTML output//
-* If you want to build mobile applications,
-read tutorial [[wiki:manual/mobile|Mobile applications with Ocsigen]].
-It describes how to build a mobile app (e.g., for Android)
-with the same codebase as for your Web application.
-* If you want to write a more traditional Web site, with pages, forms, and sessions, read tutorial [[wiki:manual/interaction|Service based Web programming]].
-It is devoted to server side programming.
-It shows how to
-create a new Web site with several pages and user connections.
-You will learn how to:
-** Create a //link// towards another service
-** Create //forms//
-** Register //session data// or //session services//
-** Create services performing //actions// (with no output)
-** Dynamically register new services (//continuation based// Web programming)
-* If you want to learn more details about Ocsigen
-read tutorial [[wiki:manual/misc|Miscellaneous features]].
-It will mix the client-server drawing application
-with the session mechanism and user management
-to produce a multi-user collaborative drawing
-application.  In this chapter, you will learn how to:
-** Integrate a typical Web interaction (links, forms,~ …) with a client side program.
-** Add //sounds or videos// to your application
-** Change pages //without stopping the client side program//
-** Connect with external accounts (//openID//)
-** Add an Atom feed
-* If you want to have a full application with user management
-(registration, activation emails, authentication),
-have a look at [[wiki("ocsigen-start"):|Ocsigen-start]].
-Ocsigen-start is a library and a template for Eliom distillery that
-contains a working Eliom application with user and right
-management.
-* For a more comprehensive understanding refer to the manual of each project,
-and/or the API documentation.
-* You will also find more tutorials in the menu on the left.
-
-
-<<|[[http://www.dailymotion.com/video/k3m1rZBWQCWBCL693Y5|{{files/2014-epita-video.png|video}}]]
-If you want a wide overview about Ocsigen, for beginners, in french
-look at  [[href:http://www.dailymotion.com/video/k3m1rZBWQCWBCL693Y5|this video]]
->>
-
-<<|div class="tutocase"|
-[[https://www.irill.org/videos/OUPS-2014-07/Meetup_OCaml_Oscigen|OUPS meeting at Mozilla Paris]]
-;A short talk, in english, that highlights a few features of Js~_of~_ocaml
-and Eliom.
-:Look at [[https://www.irill.org/videos/OUPS-2014-07/Meetup_OCaml_Oscigen|this video]]
->>
-
-<<|div class="tutocase"|
-[[http://www.irill.org/videos/oups-december-2014/Ocsigen|OUPS meeting at IRILL]]
-;A short talk, in english, that shows how to write a small client-server reactive application with Js~_of~_ocaml and Eliom.
-:Look at [[http://www.irill.org/videos/oups-december-2014/Ocsigen|this video]]
-and read this [[wiki:manual/tutoreact|tutorial]].
-It describes the most recent features of Eliom.
->>
-
-
-
-We recommend to ask your questions on
-[[https://discuss.ocaml.org|discuss.ocaml.org]] with tag {{{ocsigen}}}.
-You can also come and chat with us on
-IRC in channel {{{#ocsigen}}} on {{{freenode.net}}} (e.g. by using
-their [[http://webchat.freenode.net/?channels=ocsigen|webchat]])!
-
-
-Now, we recommend to read, chapter
-[[wiki:manual/basics|All Ocsigen in one page]]
-for a wide and complete overview.
-
-<<|wip|
-Manuals are permanently under evolution.
-Please report any error, mistake, for example by doing pull requests
-on Github, and send us your comments and suggestions!
->>
diff --git a/tutos/dev/manual/lwt.wiki b/tutos/dev/manual/lwt.mld
similarity index 57%
rename from tutos/dev/manual/lwt.wiki
rename to tutos/dev/manual/lwt.mld
index fc48edeb..86dae89c 100644
--- a/tutos/dev/manual/lwt.wiki
+++ b/tutos/dev/manual/lwt.mld
@@ -1,10 +1,12 @@
-<<header| = Lwt in 5 minutes >>
+{%wodoc:header%}
+{0 Lwt in 5 minutes}
+{%wodoc:end%}
 
-== Principles
+{1 Principles}
 
 The Lwt library implements cooperative threads for OCaml.  Cooperative
 threads are an alternative to preemptive threads (used in many
-languages and in OCaml's {{{Thread}}} module) that solve most common
+languages and in OCaml's [Thread] module) that solve most common
 issues with preemptive threads: with Lwt, there is very limited risk
 of deadlocks and very limited need for locks.  Lwt threads are even
 usable in programs compiled to JavaScript using Js_of_ocaml.
@@ -13,137 +15,137 @@ Lwt is based on the fact that most programs spend most of their time
 waiting for inputs, e.g., keys, data coming from sockets, and mouse
 events. Instead of relying on a preemptive scheduler that switches
 between threads at arbitrary moments, Lwt uses these waiting times as
-//cooperation points//. This means that instead of blocking (for
-example on a {{{read}}}), Lwt resumes another waiting thread, if there
+{e cooperation points}. This means that instead of blocking (for
+example on a [read]), Lwt resumes another waiting thread, if there
 is one that is ready to continue. All you have to do is to use the
 cooperative version of each blocking function, for example
-{{{Lwt_unix.sleep}}} instead of {{{Unix.sleep}}}
-and {{{Lwt_unix.read}}} instead of {{{Unix.read}}}.
+[Lwt_unix.sleep] instead of [Unix.sleep]
+and [Lwt_unix.read] instead of [Unix.read].
 If one of your computations takes a lot of time, it is also possible
 to manually insert cooperation points using the function
-{{{Lwt_main.yield}}}.
+[Lwt_main.yield].
 
-== Promises
+{1 Promises}
 
-Lwt defines a type {{{'a Lwt.t}}}, which is the type of promises.
+Lwt defines a type ['a Lwt.t], which is the type of promises.
 For example, the function:
 
-<<code language="ocaml"|
+{@ocaml[
 val f : unit -> int Lwt.t
->>
+]}
 
-immediately returns a promise of {{{int}}}, that is, something that
+immediately returns a promise of [int], that is, something that
 will eventually become an integer once the computation is finished.
 
-The following code will launch the computation of {{{f ()}}}
+The following code will launch the computation of [f ()]
 (asynchronously). If the code reaches a cooperation point (for example
 when the integer is requested via the network), it will continue the
 program (print "hello") and resume at a subsequent cooperation point,
 when the data is available.
 
-<<code language="ocaml"|
+{@ocaml[
 let g1 () =
   let p = f () in
   print_endline "hello"
->>
+]}
 
-== Bind: Using the value of promises
+{1 Bind: Using the value of promises}
 
 It is possible to tell Lwt to execute a function once a promise is
 completed, by using the function:
 
-<<code language="ocaml"|
+{@ocaml[
 Lwt.bind : 'a Lwt.t -> ('a -> 'b Lwt.t) -> 'b Lwt.t
->>
+]}
 
-For instance {{{Lwt.bind p h}}} will call the function {{{h}}} with
-the return value of the promise {{{p}}} as soon as the value is known.
-The expression {{{(Lwt.bind p h)}}} is also a promise (it may take
-time to complete). Function {{{h}}} must return a promise.
+For instance [Lwt.bind p h] will call the function [h] with
+the return value of the promise [p] as soon as the value is known.
+The expression [(Lwt.bind p h)] is also a promise (it may take
+time to complete). Function [h] must return a promise.
 
-To create a (terminated) promise from a value, use {{{Lwt.return}}}.
+To create a (terminated) promise from a value, use [Lwt.return].
 
 Example:
-<<code language="ocaml"|
+{@ocaml[
 let g2 () =
   let p = f () in
   Lwt.bind p (fun i -> print_int i; Lwt.return ())
->>
-Function {{{g2}}} calls function {{{f}}} to create a promise.
+]}
+Function [g2] calls function [f] to create a promise.
 Then it waits (in a cooperative manner) for the result,
-and prints the result. The expression {{{g2 ()}}} has type {{{unit Lwt.t}}}.
+and prints the result. The expression [g2 ()] has type [unit Lwt.t].
 
 
-== Syntax extension
+{1 Syntax extension}
 
 A PPX (and also camlp4) syntax extension is available.
 
-<<code language="ocaml"|
+{@ocaml[
 let%lwt i = f () in
 ...
->>
+]}
 
 is equivalent to
 
-<<code language="ocaml"|
+{@ocaml[
 Lwt.bind (f ()) (fun i -> ...)
->>
+]}
 
-== Examples
+{1 Examples}
 
-=== A function that prints "tic" every second forever, without blocking the rest of the program
+{2 A function that prints "tic" every second forever, without blocking the rest of the program}
 
-<<code language="ocaml"|
+{@ocaml[
 let rec tic () =
     print_endline "tic";
     let%lwt () = Lwt_unix.sleep 1.0 in
     tic ()
->>
+]}
 
-Replace {{{Lwt_unix.sleep}}} by {{{Lwt_js.sleep}}} if your program is
+Replace [Lwt_unix.sleep] by [Lwt_js.sleep] if your program is
 running in a browser.
 
 
-=== Launching concurrent threads and waiting for their results
+{2 Launching concurrent threads and waiting for their results}
 
 Suppose you have two cooperative functions:
-<<code language="ocaml"|
+{@ocaml[
 val f : unit -> unit Lwt.t
 val g : unit -> unit Lwt.t
->>
+]}
 
-The following code runs {{{f ()}}} and {{{g ()}}} sequentially:
-<<code language="ocaml"|
+The following code runs [f ()] and [g ()] sequentially:
+{@ocaml[
 let%lwt () = f () in
 let%lwt () = g () in
 ...
->>
+]}
 
-The following code launches {{{f ()}}} and {{{g ()}}} concurrently,
+The following code launches [f ()] and [g ()] concurrently,
 then waits for both to terminate before continuing:
-<<code language="ocaml"|
+{@ocaml[
 let p1 = f () in
 let p2 = g () in
 let%lwt () = p1 in
 let%lwt () = p2 in
 ...
->>
+]}
 
 To detach a thread, it is recommended to use
-<<code language="ocaml"|
+{@ocaml[
 Lwt.async (fun () -> f ())
->>
+]}
 instead of
-<<code language="ocaml"|
+{@ocaml[
 ignore (f ())
->>
+]}
 to catch exceptions properly.
 
-=== Serial and concurrent map on lists
+{2 Serial and concurrent map on lists}
 
 The following map function runs all computation concurrently
 on all list elements:
-<<code language="ocaml"|
+{@ocaml[
 let rec map f l =
   match l with
   | [] -> Lwt.return []
@@ -153,11 +155,11 @@ let rec map f l =
       let%lwt v' = t in
       let%lwt l' = rt in
       Lwt.return (v' :: l')
->>
+]}
 
 whereas the following one waits for the one to complete before
 launching the next one:
-<<code language="ocaml"|
+{@ocaml[
 let rec map_serial f l =
   match l with
   | [] -> return []
@@ -165,14 +167,14 @@ let rec map_serial f l =
       let%lwt v' = f v in
       let%lwt l' = map_serial f r in
       Lwt.return (v' :: l')
->>
+]}
 
 
-== More documentation
+{1 More documentation}
 
-Have a look at <<a_manual project="lwt" chapter="manual"|Lwt's manual>>
+Have a look at {{:../lwt/manual.html}Lwt's manual}
 for more details about Lwt.
-You will learn how to handle exceptions (using {{{Lwt.fail}}}
-and {{{Lwt.catch}}} or {{{try%lwt}}}).
+You will learn how to handle exceptions (using [Lwt.fail]
+and [Lwt.catch] or [try%lwt]).
 You will also learn for example how to create a thread that waits until it is
-awaken (using {{{Lwt.wait}}} and {{{Lwt.wakeup}}}).
+awaken (using [Lwt.wait] and [Lwt.wakeup]).
diff --git a/tutos/dev/manual/macaque.wiki b/tutos/dev/manual/macaque.mld
similarity index 69%
rename from tutos/dev/manual/macaque.wiki
rename to tutos/dev/manual/macaque.mld
index 97d9eb23..9345f4c6 100644
--- a/tutos/dev/manual/macaque.wiki
+++ b/tutos/dev/manual/macaque.mld
@@ -1,10 +1,12 @@
-=Type safe database requests using Macaque=
+{0 Type safe database requests using Macaque}
 
-<<concepts |Type safe database requests>>
+{%wodoc:aside class="concepts"%}{b Concepts}
+
+Type safe database requests{%wodoc:end%}
 
 The Macaque library allows easy manipulation of Postgresql
 database fully compatible with Lwt. (For more information see
-[[https://github.com/ocsigen/macaque| Macaque manual]]).
+{{:https://github.com/ocsigen/macaque} Macaque manual}).
 
 Macaque is fuly compatible with PGOcaml, and both can be used
 in the same application. PGOcaml requires database access at compile
@@ -12,32 +14,32 @@ time and makes difficult to generate queries at compile time.
 Macaque uses its own syntax, whereas PGOcaml uses SQL.
 Macaque supports only a small subset of Postgresql features.
 
-Warning: Macaque's syntax extension uses camlp4, which is not compatible with ppx. If you want to use macaque with Eliom's ppx, place your macaque code in an isolated file. Some details can be found in <<a_manual project="eliom" chapter="ppx-migration"|the ppx migration guide>>.
+Warning: Macaque's syntax extension uses camlp4, which is not compatible with ppx. If you want to use macaque with Eliom's ppx, place your macaque code in an isolated file. Some details can be found in {{:../eliom/ppx-migration.html}the ppx migration guide}.
 
 This tutorial shows how to store the login and the password
 f users in a Postgresql
 database. For more information on how to set up and run it, see
-[[http://www.postgresql.org/docs/9.0/static/index.html|Postgresql
-manual]].
+{{:http://www.postgresql.org/docs/9.0/static/index.html}Postgresql
+manual}.
 
 When the base is up and running, we create the base by running in a shell:
-<<code language="sh"|
+{@sh[
 $ createdb testbase
->>
+]}
 
-Then we create the {{{users}}} table, by executing this sql script:
+Then we create the [users] table, by executing this sql script:
 
-<<code language="sql"| CREATE TABLE users (
+{@sql[ CREATE TABLE users (
        login text NOT NULL,
        password text NOT NULL
 );
->>
+]}
 
-We save it under {{{create_table.sql}}} and run
+We save it under [create_table.sql] and run
 
-<<code language="sh"|
+{@sh[
 $ psql -d testbase -f create_table.sql
->>
+]}
 
 Macaque can use any thread library that provides a monadic
 interface. The default one provides simple blocking access to the
@@ -46,66 +48,66 @@ user will prevent the server from handling anything else until the
 request is finished. We need a version of Macaque specialised for
 Lwt. It is obtained by
 
-<<code language="ocaml"|
+{@ocaml[
 module Lwt_thread = struct
   include Lwt
   include Lwt_chan
 end
 module Lwt_PGOCaml = PGOCaml_generic.Make(Lwt_thread)
 module Lwt_Query = Query.Make_with_Db(Lwt_thread)(Lwt_PGOCaml)
->>
+]}
 
-We can now open the database with our newly created {{{Lwt_PGOCaml.connect}}}.
+We can now open the database with our newly created [Lwt_PGOCaml.connect].
 
-<<code language="ocaml"|
+{@ocaml[
 let get_db : unit -> unit Lwt_PGOCaml.t Lwt.t =
   let db_handler = ref None in
   fun () ->
     match !db_handler with
       | Some h -> Lwt.return h
       | None -> Lwt_PGOCaml.connect ~database:"testbase" ()
->>
+]}
 
 Then we declare the table on which we will work and the different
 requests we do on it.
 
-<<code language="ocaml"|
+{@ocaml[
 let table = <:table< users (
   login text NOT NULL,
   password text NOT NULL
-) ~>>
+) >>
 
 let find name =
-  (get_db () ~>>= fun dbh ->
+  (get_db () >>= fun dbh ->
    Lwt_Query.view dbh
    <:view< {password = user_.password} |
             user_ in $table$;
-            user_.login = $string:name$; ~>>)
+            user_.login = $string:name$; >>)
 
 let insert name pwd =
-  get_db () ~>>= fun dbh ->
+  get_db () >>= fun dbh ->
   Lwt_Query.query dbh
   <:insert< $table$ :=
-    { login = $string:name$; password = $string:pwd$; } ~>>
+    { login = $string:name$; password = $string:pwd$; } >>
 
->>
+]}
 
 Finally, we modify the handling code :
 
-<<code language="ocaml"|
+{@ocaml[
 let check_pwd name pwd =
-  (get_db () ~>>= fun dbh ->
+  (get_db () >>= fun dbh ->
    Lwt_Query.view dbh
    <:view< {password = user_.password} |
             user_ in $table$;
             user_.login = $string:name$;
-	    user_.password = $string:pwd$ ~>>)
+	    user_.password = $string:pwd$ >>)
   >|= (function [] -> false | _ -> true)
 
 let () = Eliom.Registration.Action.register
   ~service:create_account_service
   (fun () (name, pwd) ->
-    find name ~>>=
+    find name >>=
       (function
 	| [] -> insert name pwd
 	| _ -> Lwt.return ()) )
@@ -113,17 +115,17 @@ let () = Eliom.Registration.Action.register
 let () = Eliom.Registration.Action.register
   ~service:connection_service
   (fun () (name, password) ->
-    check_pwd name password ~>>=
+    check_pwd name password >>=
       (function
 	| true -> Eliom.Reference.set username (Some name)
 	| false -> Lwt.return ()))
->>
+]}
 
-We need to reference {{{macaque}}} in the {{{Makefile}}} (or in {{{Makefile.option}}} if you used {{{eliom-distillery}}}) :
-{{{
+We need to reference [macaque] in the [Makefile] (or in [Makefile.option] if you used [eliom-distillery]) :
+{v
 SERVER_PACKAGE := macaque.syntax
-}}}
-and in {{{ocsigenserver.conf}}} (only if you don't use {{{eliom-distillery}}}) :
-{{{
+v}
+and in [ocsigenserver.conf] (only if you don't use [eliom-distillery]) :
+{v
 <extension findlib-package="macaque"/>
-}}}
+v}
diff --git a/tutos/dev/manual/migration.mld b/tutos/dev/manual/migration.mld
new file mode 100644
index 00000000..7f2c3676
--- /dev/null
+++ b/tutos/dev/manual/migration.mld
@@ -0,0 +1,138 @@
+{%wodoc:header%}
+{0 Migrating to new module names}
+{%wodoc:end%}
+
+Starting with Eliom 13, Ocsigen Server 8, Ocsigen Toolkit 5, and
+Ocsigen Start 9, all Ocsigen projects use hierarchical module names:
+
+{t
+ | Old name | New name |
+ | [Eliom_service] | [Eliom.Service] |
+ | [Eliom_content] | [Eliom.Content] |
+ | [Eliom_registration] | [Eliom.Registration] |
+ | [Eliom_parameter] | [Eliom.Parameter] |
+ | [Ot_popup] | [Ot.Popup] |
+ | [Ot_carousel] | [Ot.Carousel] |
+ | [Os_session] | [Os.Session] |
+ | [Os_user] | [Os.User] |
+ | [Ocsigen_extensions] | [Ocsigen.Extensions] |
+ | [Ocsigen_config] | [Ocsigen.Config] |
+ | [Ocsigen_lib] | [Ocsigen_base.Lib] |
+}
+
+{1 Using compatibility packages}
+
+To migrate progressively, you can use the compatibility packages.
+They provide the old module names as aliases to the new ones, so
+your existing code compiles without changes.
+
+Install the compat packages you need:
+
+{@shell[
+opam install eliom-compat ocsigenserver-compat \
+  ocsigen-toolkit-compat ocsigen-start-compat
+]}
+
+Then add them to the [(libraries ...)] in your [dune] file:
+
+{@lisp[
+; Server library
+(libraries
+  eliom.server
+  eliom-compat.server
+  ocsigenserver-compat
+  ocsigenserver-compat.baselib
+  ocsigen-start.server
+  ocsigen-start-compat.server
+  ocsigen-toolkit-compat.server
+  ...)
+
+; Client executable or library
+(libraries
+  eliom.client
+  eliom-compat.client
+  ocsigen-start-compat.client
+  ocsigen-toolkit-compat.client
+  ...)
+]}
+
+Your code will compile as before, using the old module names.
+
+{1 Migrating your code}
+
+Once the compat packages are in place, you can migrate your code
+file by file, replacing old names with new ones. When a file is
+fully migrated, you can remove the compat libraries it depended on.
+
+The following renaming patterns apply:
+
+- {b Eliom}: [Eliom_xxx] becomes [Eliom.Xxx]
+  (e.g. [Eliom_content.Html.F] → [Eliom.Content.Html.F])
+
+- {b Ocsigen Server}: [Ocsigen_xxx] becomes [Ocsigen.Xxx]
+  (e.g. [Ocsigen_extensions.Configuration] → [Ocsigen.Extensions.Configuration])
+
+- {b Ocsigen Server baselib}: [Ocsigen_lib] becomes [Ocsigen_base.Lib],
+  [Ocsigen_cache] becomes [Ocsigen_base.Cache]
+
+- {b Ocsigen Toolkit}: [Ot_xxx] becomes [Ot.Xxx]
+  (e.g. [Ot_popup.popup] → [Ot.Popup.popup])
+
+- {b Ocsigen Start}: [Os_xxx] becomes [Os.Xxx]
+  (e.g. [Os_session.connected_fun] → [Os.Session.connected_fun])
+
+A few modules keep their old name because of conflicts with
+other libraries:
+- [Eliom.Eliom_react] (conflict with [react] library)
+- [Eliom.Eliom_form] (conflict with [js_of_ocaml])
+- [Eliom.Eliom_lazy] (conflict with [Stdlib.Lazy])
+- [Eliom.Eliom_uri] (conflict with [uri] library)
+
+{2 [module type of] on wrapped modules}
+
+Because the new module names live inside a dune-wrapped library, OCaml's
+type strengthening exposes the internal mangled prefix
+([Eliom__Content.Html.D] rather than [Eliom.Content.Html.D])
+when you use [module type of]. As a consequence, code like
+
+{@ocaml[
+module Make (A : module type of Eliom_content.Html.F) = struct ... end
+module D = Make (Eliom_content.Html.D)
+]}
+
+stops type-checking, even with [eliom-compat] installed: the
+functor parameter type and the application argument become
+incompatible, with errors mentioning [Eliom__Content.Html...].
+
+To work around this, Eliom now exposes named module types that
+[eliom-compat] re-exports under the legacy paths:
+
+- [Eliom.Content.Html.T] (alias: [Eliom_content.Html.T])
+
+Use them instead of [module type of]:
+
+{@ocaml[
+module Make (A : Eliom_content.Html.T) = struct ... end
+module D = Make (Eliom_content.Html.D)
+]}
+
+This is the same pattern adopted internally by [Ot.Icons.Make].
+
+{2 Top-level values cannot be shimmed}
+
+[eliom-compat] can re-export legacy module names but not
+top-level values of the wrapper module itself: dune's auto-generated
+wrapper module can only contain submodules, not [val] declarations.
+You must update such call sites by hand:
+
+- [Eliom.run ()] → [Eliom.App.run ()]
+
+{2 Other changes}
+
+- [ocsigen-i18n] 5.0 now adds [[@@deriving json]] automatically
+  in [--eliom] mode. Remove any [sed] hack that was adding it
+  manually.
+- [ocsigen-i18n-generator] reads its TSV input from stdin in
+  [--eliom] mode. In [dune] rules, pipe the input via
+  [(with-stdin-from %{deps} (run ocsigen-i18n-generator --eliom ...))]
+  rather than passing it as a positional argument.
diff --git a/tutos/dev/manual/migration.wiki b/tutos/dev/manual/migration.wiki
deleted file mode 100644
index 14105a77..00000000
--- a/tutos/dev/manual/migration.wiki
+++ /dev/null
@@ -1,134 +0,0 @@
-<<header| =Migrating to new module names>>
-
-Starting with Eliom 13, Ocsigen Server 8, Ocsigen Toolkit 5, and
-Ocsigen Start 9, all Ocsigen projects use hierarchical module names:
-
-|=Old name|=New name|
-|{{{Eliom_service}}}|{{{Eliom.Service}}}|
-|{{{Eliom_content}}}|{{{Eliom.Content}}}|
-|{{{Eliom_registration}}}|{{{Eliom.Registration}}}|
-|{{{Eliom_parameter}}}|{{{Eliom.Parameter}}}|
-|{{{Ot_popup}}}|{{{Ot.Popup}}}|
-|{{{Ot_carousel}}}|{{{Ot.Carousel}}}|
-|{{{Os_session}}}|{{{Os.Session}}}|
-|{{{Os_user}}}|{{{Os.User}}}|
-|{{{Ocsigen_extensions}}}|{{{Ocsigen.Extensions}}}|
-|{{{Ocsigen_config}}}|{{{Ocsigen.Config}}}|
-|{{{Ocsigen_lib}}}|{{{Ocsigen_base.Lib}}}|
-
-==Using compatibility packages==
-
-To migrate progressively, you can use the compatibility packages.
-They provide the old module names as aliases to the new ones, so
-your existing code compiles without changes.
-
-Install the compat packages you need:
-
-<<code language="shell"|
-opam install eliom-compat ocsigenserver-compat \
-  ocsigen-toolkit-compat ocsigen-start-compat
->>
-
-Then add them to the {{{(libraries ...)}}} in your {{{dune}}} file:
-
-<<code language="lisp"|
-; Server library
-(libraries
-  eliom.server
-  eliom-compat.server
-  ocsigenserver-compat
-  ocsigenserver-compat.baselib
-  ocsigen-start.server
-  ocsigen-start-compat.server
-  ocsigen-toolkit-compat.server
-  ...)
-
-; Client executable or library
-(libraries
-  eliom.client
-  eliom-compat.client
-  ocsigen-start-compat.client
-  ocsigen-toolkit-compat.client
-  ...)
->>
-
-Your code will compile as before, using the old module names.
-
-==Migrating your code==
-
-Once the compat packages are in place, you can migrate your code
-file by file, replacing old names with new ones. When a file is
-fully migrated, you can remove the compat libraries it depended on.
-
-The following renaming patterns apply:
-
-* **Eliom**: {{{Eliom_xxx}}} becomes {{{Eliom.Xxx}}}
-  (e.g. {{{Eliom_content.Html.F}}} → {{{Eliom.Content.Html.F}}})
-
-* **Ocsigen Server**: {{{Ocsigen_xxx}}} becomes {{{Ocsigen.Xxx}}}
-  (e.g. {{{Ocsigen_extensions.Configuration}}} → {{{Ocsigen.Extensions.Configuration}}})
-
-* **Ocsigen Server baselib**: {{{Ocsigen_lib}}} becomes {{{Ocsigen_base.Lib}}},
-  {{{Ocsigen_cache}}} becomes {{{Ocsigen_base.Cache}}}
-
-* **Ocsigen Toolkit**: {{{Ot_xxx}}} becomes {{{Ot.Xxx}}}
-  (e.g. {{{Ot_popup.popup}}} → {{{Ot.Popup.popup}}})
-
-* **Ocsigen Start**: {{{Os_xxx}}} becomes {{{Os.Xxx}}}
-  (e.g. {{{Os_session.connected_fun}}} → {{{Os.Session.connected_fun}}})
-
-A few modules keep their old name because of conflicts with
-other libraries:
-* {{{Eliom.Eliom_react}}} (conflict with {{{react}}} library)
-* {{{Eliom.Eliom_form}}} (conflict with {{{js_of_ocaml}}})
-* {{{Eliom.Eliom_lazy}}} (conflict with {{{Stdlib.Lazy}}})
-* {{{Eliom.Eliom_uri}}} (conflict with {{{uri}}} library)
-
-==={{{module type of}}} on wrapped modules===
-
-Because the new module names live inside a dune-wrapped library, OCaml's
-type strengthening exposes the internal mangled prefix
-({{{Eliom__Content.Html.D}}} rather than {{{Eliom.Content.Html.D}}})
-when you use {{{module type of}}}. As a consequence, code like
-
-<<code language="ocaml"|
-module Make (A : module type of Eliom_content.Html.F) = struct ... end
-module D = Make (Eliom_content.Html.D)
->>
-
-stops type-checking, even with {{{eliom-compat}}} installed: the
-functor parameter type and the application argument become
-incompatible, with errors mentioning {{{Eliom__Content.Html...}}}.
-
-To work around this, Eliom now exposes named module types that
-{{{eliom-compat}}} re-exports under the legacy paths:
-
-* {{{Eliom.Content.Html.T}}} (alias: {{{Eliom_content.Html.T}}})
-
-Use them instead of {{{module type of}}}:
-
-<<code language="ocaml"|
-module Make (A : Eliom_content.Html.T) = struct ... end
-module D = Make (Eliom_content.Html.D)
->>
-
-This is the same pattern adopted internally by {{{Ot.Icons.Make}}}.
-
-===Top-level values cannot be shimmed===
-
-{{{eliom-compat}}} can re-export legacy module names but not
-top-level values of the wrapper module itself: dune's auto-generated
-wrapper module can only contain submodules, not {{{val}}} declarations.
-You must update such call sites by hand:
-
-* {{{Eliom.run ()}}} → {{{Eliom.App.run ()}}}
-
-===Other changes===
-
-* {{{ocsigen-i18n}}} 5.0 now adds {{{[@@deriving json]}}} automatically
-  in {{{--eliom}}} mode. Remove any {{{sed}}} hack that was adding it
-  manually.
-* {{{ocsigen-i18n-generator}}} reads its TSV input from stdin in
-  {{{--eliom}}} mode. In {{{dune}}} rules, pipe the input via
-  {{{(with-stdin-from %{deps} (run ocsigen-i18n-generator --eliom ...))}}}
-  rather than passing it as a positional argument.
diff --git a/tutos/dev/manual/misc.wiki b/tutos/dev/manual/misc.mld
similarity index 83%
rename from tutos/dev/manual/misc.wiki
rename to tutos/dev/manual/misc.mld
index 01c817c7..31598bbe 100644
--- a/tutos/dev/manual/misc.wiki
+++ b/tutos/dev/manual/misc.mld
@@ -1,20 +1,22 @@
-=Traditional web interaction in a client-server app=
+{0 Traditional web interaction in a client-server app}
 
-<<|outline target="documentation">>
 
-//The code of this tutorial has been tested with Eliom 6.0.// \\
 
-==Multi-user collaborative drawing application==
+{e The code of this tutorial has been tested with Eliom 6.0.} {%html:<br/>%}
+
+{1 Multi-user collaborative drawing application}
 
 We now want to turn our collaborative drawing application into a
 multi-user one. Each user will have their own drawing, where everyone
 can draw.
 
 See the
-[[https://github.com/ocsigen/graffiti/tree/master/extended/|full code of examples]].
+{{:https://github.com/ocsigen/graffiti/tree/master/extended/}full code of examples}.
+
+{2 Split application into multiple files and using several canvases}
+{%wodoc:aside class="concepts"%}{b Concepts}
 
-===Split application into multiple files and using several canvases===
-<<concepts | Complex eliom project\\Unique elements>>
+ Complex eliom project{%html:<br/>%}Unique elements{%wodoc:end%}
 
 We first build a multi-canvas drawing application. Each drawing has
 its own URL. Everyone can create a new drawing by going to the
@@ -27,32 +29,32 @@ variables, like the bus, into local ones.
 When an application grows, it becomes useful to split it into multiple
 files. For example, we will split graffiti into 4 files.
 
-* {{{common.ml}}}, which will be part of both client and server,
+- [common.ml], which will be part of both client and server,
   containing shared types and declarations,
-* {{{client.ml}}}, client-only part of the application,
-* {{{server.ml}}}, server-only part of the application, and
-* {{{graffiti.eliom}}}, which is the only part where we need to
+- [client.ml], client-only part of the application,
+- [server.ml], server-only part of the application, and
+- [graffiti.eliom], which is the only part where we need to
   include both client-side and server-side code
 
-===={{{common.ml}}}====
+{3 [common.ml]}
 
-It contains what was previously in {{{ [%shared ... ] }}}
-<<code language="ocaml"|
+It contains what was previously in [[%shared ... ]]
+{@ocaml[
 type messages =
   ((int * int * int) * int * (int * int) * (int * int))
   [@@deriving json]
 
 let width = 700
 let height = 400
->>
+]}
 
-===={{{client.ml}}}====
+{3 [client.ml]}
 
-It is almost the same code as what was enclosed in {{{ {client{ ... }}
-}}}, with the difference that what was previously in the client value
-{{{init_client}}} is now in the function {{{launch_client_canvas}}}.
+It is almost the same code as what was enclosed in {v {client{ ... }}
+v}, with the difference that what was previously in the client value
+[init_client] is now in the function [launch_client_canvas].
 
-<<code language="ocaml"|
+{@ocaml[
 open Common
 open Js_of_ocaml
 open Eliom.Content
@@ -79,15 +81,15 @@ let stop_drawing { message_thread; drawing_thread } =
   Lwt.cancel message_thread;
   (* cancelling this thread also close the bus *)
   Lwt.cancel drawing_thread
->>
+]}
+
 
-<<| WTF? Notice that the client does not keep data from pages it left.>>
-{{{Lwt.cancel t}}} stops thread t. In this case it also closes the
+[Lwt.cancel t] stops thread t. In this case it also closes the
   bus on which t is listening. For more informations see the
-  <<a_manual project="lwt"| Lwt programming guide >> and
-  <<a_api project="eliom" subproject="client" | module Eliom.Bus >>.
+  {{:../lwt/.html}Lwt programming guide} and
+  {!Eliom.Bus}.
 
-<<code language="ocaml"|
+{@ocaml[
 let launch_client_canvas bus image_elt canvas_elt slider =
   let canvas = Html.To_dom.of_canvas canvas_elt in
   let ctx = canvas##(getContext (Dom_html._2d_)) in
@@ -136,12 +138,12 @@ let launch_client_canvas bus image_elt canvas_elt slider =
   in
   { message_thread = t;
     drawing_thread = drawing_thread }
->>
+]}
 
-===={{{server.ml}}}====
+{3 [server.ml]}
 
 It contains almost all the server parts of the code.
-<<code language="ocaml"|
+{@ocaml[
 open Eliom.Content
 open Common
 open Lwt
@@ -151,10 +153,10 @@ module My_app =
     let application_name = "graffiti"
     let global_data_path = None
   end)
->>
+]}
 
 The main difference is that the bus is now local.
-<<code language="ocaml"|
+{@ocaml[
 let launch_server_canvas () =
   let bus = Eliom.Bus.create [%json: messages] in
 
@@ -220,14 +222,14 @@ let get_bus (name:string) =
       let bus,image_string = launch_server_canvas () in
       Hashtbl.add graffiti_info name (bus, image_string);
       bus
->>
+]}
 
 The main page now contains only a form to choose to which drawing you
 want to go.  The drawing will be sent by the
-{{{multigraffiti_service}}} service, registered in
-{{{graffiti.eliom}}}.
+[multigraffiti_service] service, registered in
+[graffiti.eliom].
 
-<<code language="ocaml"|
+{@ocaml[
 let main_service =
   Eliom.Service.create
     ~path:(Eliom.Service.Path [""])
@@ -279,29 +281,31 @@ let () = My_app.register ~service:main_service
   (fun () () ->
     make_page [h1 [txt "Welcome to Multigraffiti"];
 	       choose_drawing_form ()])
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Global node and scripts}
+
 
-<<concept title="Global node and scripts"|
   Sometimes we need to control when a script is loaded and reloaded on
   page change. Since clicking on links in an Eliom application do not
   reload the entire page, already loaded libraries stay loaded. But if
   we simply add a script to each page, it will be loaded each time.
   We usually don't want that.
 
-  Using <<a_api project="eliom" subproject="server"| val
-  Eliom.Content.Html.Id.create_global_elt>> we can create an xml node
+  Using {!val
+  Eliom.Content.Html.Id.create_global_elt} we can create an xml node
   manipulated 'by reference'. If a reference to a script node is
   included in a page, it will only be loaded the first time it appears
-  in the header. This is the case for {{{oclosure_script}}} above.
->>
-===={{{graffiti.eliom}}}====
+  in the header. This is the case for [oclosure_script] above.
+{%wodoc:end%}
+{3 [graffiti.eliom]}
 
 Here is the code that mixes client and server parts.
 
 We first open the corresponding modules for each parts of the
 application.
 
-<<code language="ocaml"|
+{@ocaml[
 [%%shared
     open Eliom.Content.Html.D
     open Common
@@ -310,12 +314,12 @@ application.
     open Client
 ]
 open Server
->>
+]}
 
 And then we define a function initializing the client application by
 side effects in a client value.
 
-<<code language="ocaml"|
+{@ocaml[
 let start_drawing name image canvas slider =
   let bus = get_bus name in
   ignore [%client
@@ -325,15 +329,14 @@ let start_drawing name image canvas slider =
      Eliom.Client.onunload (fun () -> stop_drawing canceller; None)
      : unit)
   ]
->>
+]}
 
-The function registered by <<a_api project="eliom"
-subproject="client"| val Eliom.Service.onunload >> will be called when
+The function registered by {!Eliom.Service.onunload} will be called when
 the page change inside the application.
 
 And we finally register the service sending a drawing:
 
-<<code language="ocaml"|
+{@ocaml[
 let counter = ref 0
 
 let () =
@@ -365,26 +368,26 @@ let () =
        choose_drawing_form ();
        canvas;
        div [slider]])
->>
+]}
 
 At this point, you can run your application on the server provided
 that you installed the css and images directories in the main
 directory of your application, build it using this
-[[https://github.com/ocsigen/graffiti/tree/master/extended/Makefile|Makefile]]
+{{:https://github.com/ocsigen/graffiti/tree/master/extended/Makefile}Makefile}
 along with the appropriate
-[[https://github.com/ocsigen/graffiti/tree/master/extended/Makefile.options|Makefile.options]],
+{{:https://github.com/ocsigen/graffiti/tree/master/extended/Makefile.options}Makefile.options},
 and configured it using
-[[https://github.com/ocsigen/graffiti/tree/master/extended/graffiti.conf.in|graffiti.conf.in]],
+{{:https://github.com/ocsigen/graffiti/tree/master/extended/graffiti.conf.in}graffiti.conf.in},
 as the basis for your configuration file.
 
-===Mixing client-server application with traditional web interaction===
+{2 Mixing client-server application with traditional web interaction}
 
 We now want to restrict the site to connected users.
 
 From the previous chapter, we copy the code handling users to
-{{{server.ml}}}:
+[server.ml]:
 
-<<code language="ocaml"|
+{@ocaml[
 let connection_service = Eliom.Service.create
     ~path:Eliom.Service.No_path
     ~meth:(Eliom.Service.Post (
@@ -457,14 +460,14 @@ let login_name_form service button_text =
            Html.D.Form.input ~input_type:`Submit ~value:button_text
              Html.D.Form.string
          ]]) ()
->>
+]}
 
 We make a customized registration module such that disconnected users
 (those for which the username reference is not set), are automaticaly
 shown a connection box. This way the other pages can assume that the
 username is always available.
 
-<<code language="ocaml"|
+{@ocaml[
 let default_content () =
   make_page
     [Html.D.h1 [Html.D.txt "Welcome to Multigraffiti"];
@@ -485,20 +488,20 @@ end
 
 module Connected =
   Eliom.Registration.Customize (My_app) (Connected_translate)
->>
+]}
 
-We replace the previous {{{main_service}}} registration :
+We replace the previous [main_service] registration :
 
-<<code language="ocaml"|
+{@ocaml[
 let () = My_app.register ~service:main_service
   (fun () () ->
     make_page [h1 [txt "Welcome to Multigraffiti"];
 	       choose_drawing_form ()])
->>
+]}
 
 by :
 
-<<code language="ocaml"|
+{@ocaml[
 let ( !% ) f = fun a b -> return (fun c -> f a b c)
 
 let () = Connected.register
@@ -507,15 +510,15 @@ let () = Connected.register
     make_page
       [Html.D.h1 [Html.D.txt ("Welcome to Multigraffiti " ^ username)];
        choose_drawing_form ()])
->>
+]}
 
-to use that, in {{{graffiti.eliom}}} we just replace add a call
-to {{{disconnect_box}}}
-<<code language="ocaml"|
+to use that, in [graffiti.eliom] we just replace add a call
+to [disconnect_box]
+{@ocaml[
       [h1 [txt name];
        disconnect_box ();
        choose_drawing_form ();
        canvas;])
->>
+]}
 
-[[wiki:manual/interaction|prev]]
+{{:wiki:manual/interaction}prev}
diff --git a/tutos/8.0/manual/mobile.wiki b/tutos/dev/manual/mobile.mld
similarity index 58%
rename from tutos/8.0/manual/mobile.wiki
rename to tutos/dev/manual/mobile.mld
index 8fce4220..64e3e78f 100644
--- a/tutos/8.0/manual/mobile.wiki
+++ b/tutos/dev/manual/mobile.mld
@@ -1,4 +1,4 @@
-= Mobile applications with Ocsigen
+{0 Mobile applications with Ocsigen}
 
 Since Eliom 6.0, the Ocsigen framework provides infrastructure for
 building mobile applications. This enables rapid development of
@@ -8,36 +8,36 @@ fact, one single codebase can be used to produce all these
 applications simultaneously.
 
 The easiest way to get started with Ocsigen-based mobile development
-is to use [[wiki("ocsigen-start"):|Ocsigen-start]].  Ocsigen-start is a
+is to use {{:../ocsigen-start/}Ocsigen-start}.  Ocsigen-start is a
 library and skeleton for building "minimum viable product" Web
 applications with standard functionality like users, notifications,
 etc. This skeleton is immediately usable as a mobile application. You
-can install {{{ocsigen-start}}} via OPAM
-( {{{opam install ocsigen-start}}} )
+can install [ocsigen-start] via OPAM
+( [opam install ocsigen-start] )
 and instantiate its template with the command
-{{{eliom-distillery -name ocsimobile -template os.pgocaml}}}.  For
+[eliom-distillery -name ocsimobile -template os].  For
 launching the mobile application, follow the instructions in the
-template's {{{README.md}}}.
+template's [README.md].
 
-== Programming style
+{1 Programming style}
 
 You need to follow a certain programming style for your Eliom code to
 work flawlessly inside an Ocsigen-start mobile app. This style is
-described in the <<a_manual project="eliom" chapter="clientserver-services"|chapter on
-client services>> from the Eliom manual. The idea is that you
+described in the {{:../eliom/clientserver-services.html}chapter on
+client services} from the Eliom manual. The idea is that you
 implement as much of your application as possible in shared sections
-({{{[%%shared ...]}}} or {{{let%shared ... = ...}}}), and that you
+([[%%shared ...]] or [let%shared ... = ...]), and that you
 register handlers for your Eliom services on both the client and the
 server. The Ocsigen-start template already uses the above programming
-style, so refer to the files generated by {{{eliom-distillery}}} for
+style, so refer to the files generated by [eliom-distillery] for
 inspiration.
 
-== Going further
+{1 Going further}
 
-* [[wiki("ocsigen-toolkit"):|Ocsigen-toolkit]] provides a set of user
+- {{:../ocsigen-toolkit/}Ocsigen-toolkit} provides a set of user
   interface widgets that are particularly useful for mobile applications.
 
-* Danny Willems provides a comprehensive set of
-  [[https://github.com/dannywillems/ocaml-cordova-plugin-list|OCaml
-  bindings to Cordova plugins]]. These can readily be used for your
+- Danny Willems provides a comprehensive set of
+  {{:https://github.com/dannywillems/ocaml-cordova-plugin-list}OCaml
+  bindings to Cordova plugins}. These can readily be used for your
   Eliom mobile application.
diff --git a/tutos/dev/manual/music.wiki b/tutos/dev/manual/music.mld
similarity index 69%
rename from tutos/dev/manual/music.wiki
rename to tutos/dev/manual/music.mld
index 8124656c..49e5783c 100644
--- a/tutos/dev/manual/music.wiki
+++ b/tutos/dev/manual/music.mld
@@ -1,5 +1,7 @@
-=Listening music=
-<<concepts |Persistence of the client application>>
+{0 Listening music}
+{%wodoc:aside class="concepts"%}{b Concepts}
+
+Persistence of the client application{%wodoc:end%}
 
 We will add an audio player to the page that will stay when page
 changes. This emphasises the fact that browsing inside an application
@@ -7,7 +9,7 @@ does not stop the client side code: the music keeps playing when the
 content of the page and the url change.
 
 We first create the player node at toplevel.
-<<code language="ocaml"|
+{@ocaml[
 let player =
   Eliom.Content.Html.Id.create_global_elt
     (audio
@@ -16,18 +18,20 @@ let player =
               [])
        ~a:[a_autoplay (`Autoplay);a_controls (`Controls)]
        [txt "Your browser does not support audio element" ])
->>
+]}
 
 And we insert the player in the page.
 
-And that's all! Since the {{{player}}} node is declared unique, no new
+And that's all! Since the [player] node is declared unique, no new
 player is created when the page changed: this is exact same node.
 
-<<wip | In fact browsers stop the player as soon as the dom
+{%wodoc:aside class="wip"%}{b Work in progress}
+
+ In fact browsers stop the player as soon as the dom
 element is manipulated. That happens when we change the page: to
 continue playing the player should not be present as an element of the
-page>>
+page{%wodoc:end%}
 
 To run this example, you will need to add an ogg file in the static directory.
 If you can't find one, there is one here:
-[[http://www.gnu.org/music/free-software-song.html]].
+{{:http://www.gnu.org/music/free-software-song.html}http://www.gnu.org/music/free-software-song.html}.
diff --git a/tutos/dev/manual/ocsipersist.wiki b/tutos/dev/manual/ocsipersist.mld
similarity index 79%
rename from tutos/dev/manual/ocsipersist.wiki
rename to tutos/dev/manual/ocsipersist.mld
index 8c4b8c12..49523cfa 100644
--- a/tutos/dev/manual/ocsipersist.wiki
+++ b/tutos/dev/manual/ocsipersist.mld
@@ -1,10 +1,12 @@
-=Lightweight database using Ocsipersist=
-<<concepts |Persistent tables with Ocsipersist>>
+{0 Lightweight database using Ocsipersist}
+{%wodoc:aside class="concepts"%}{b Concepts}
+
+Persistent tables with Ocsipersist{%wodoc:end%}
 
 Ocsipersist is a module for persistent references and tables.
 
 For persistent references, Eliom has a higher level interface,
-called //Eliom references//, and you probably want to use it instead
+called {e Eliom references}, and you probably want to use it instead
 of using Ocsipersist directly.
 For example persistent Eliom references of scope session group
 can be used to store information about a user (if the session group
@@ -16,13 +18,13 @@ if you do not need the full power of a SQL database.
 This tutorial shows how to implement a table for storing users and passwords.
 
 We first create a table:
-<<code language="ocaml"|
+{@ocaml[
 let user_table = Ocsipersist.Polymorphic.open_table "user_table"
->>
+]}
 
 Then we can easily handle the user management code:
 
-<<code language="ocaml"|
+{@ocaml[
 let check_pwd name pwd =
   try%lwt
     lwt saved_password = Ocsipersist.Polymorphic.find user_table name in
@@ -40,10 +42,12 @@ let () = Eliom.Registration.Action.register
     match%lwt check_pwd name password with
       | true -> Eliom.Reference.set username (Some name)
       | false -> Lwt.return ())
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Ocsipersist}
+
 
-<<concept title="Ocsipersist"|
  Ocsipersist implements simple typed key/value tables.
  It can use different backends (currently sqlite and dbm).
- For more information see <<a_api project="ocsigenserver"| type Ocsipersist.table >>.
->>
+ For more information see {!Ocsipersist.table}.
+{%wodoc:end%}
diff --git a/tutos/dev/manual/pictures.wiki b/tutos/dev/manual/pictures.mld
similarity index 84%
rename from tutos/dev/manual/pictures.wiki
rename to tutos/dev/manual/pictures.mld
index d9f6dd0f..d5613dcc 100644
--- a/tutos/dev/manual/pictures.wiki
+++ b/tutos/dev/manual/pictures.mld
@@ -1,24 +1,26 @@
-=Saving favorite pictures=
-<<concepts |Atom feed>>
+{0 Saving favorite pictures}
+{%wodoc:aside class="concepts"%}{b Concepts}
+
+Atom feed{%wodoc:end%}
 
 We will now add a button to the Graffiti application to save the current
 image. The images will be saved to the filesystem using the module
-<<a_api project="lwt"| module Lwt_io>>. We will then make an Atom feed
-with the saved images using [[https://github.com/Cumulus/Syndic|Syndic]].
+{!Lwt_io}. We will then make an Atom feed
+with the saved images using {{:https://github.com/Cumulus/Syndic}Syndic}.
 
 To install it, do:
-{{{
+{v
 opam install syndic
-}}}
+v}
 
 We save the images in the directory containing the static contents
-under the directory {{{images_saved/username}}}. The {{{username}}}
-directory is created if needed. If it already exists {{{mkdir}}} fails
+under the directory [images_saved/username]. The [username]
+directory is created if needed. If it already exists [mkdir] fails
 and we do nothing.
 
 We will add this code in a new file:
-===={{{feed.ml}}}====
-<<code language="ocaml"|
+{3 [feed.ml]}
+{@ocaml[
 open Eliom.Content
 open Lwt.Infix
 open Html.F
@@ -56,23 +58,23 @@ let save image name number =
   let%lwt file_name = make_filename name number in
   let%lwt out_chan = Lwt_io.open_file ~mode:Lwt_io.output file_name in
   Lwt_io.write out_chan image
->>
+]}
 
 We number images and associate to each image the time of creation. It
-is stocked in an <<a_api project="eliom" subproject="server"| module Ocsipersist >>
+is stocked in an {!Ocsipersist}
 table.
 
-<<code language="ocaml"|
+{@ocaml[
 let image_info_table = Ocsipersist.Polymorphic.open_table "image_info_table"
->>
+]}
 
-For each user, we stock a value of type\\
-{{{ int * CalendarLib.Calendar.t * ((int * CalendarLib.Calendar.t) list)}}}.
+For each user, we stock a value of type{%html:<br/>%}
+[int * CalendarLib.Calendar.t * ((int * CalendarLib.Calendar.t) list)].
 The first integer is the name under which will be saved the image, the first
 time is the last update for that user and the list contains the names and
 times of old images. We need those times to timestamp the entries of the feed.
 
-<<code language="ocaml"|
+{@ocaml[
 let save_image username =
   let now = CalendarLib.Calendar.now () in
   let%lwt image_info_table = image_info_table in
@@ -104,15 +106,14 @@ let save_image_box name =
               ~value:name Html.D.Form.string;
              Html.D.Form.button_no_value ~button_type:`Submit [txt "save"]]])
        ())
->>
+]}
 
-We find the url of the images with <<a_api project="eliom"
-subproject="server"| val Eliom.Service.static_dir >>.  It is a service
+We find the url of the images with {!Eliom.Service.static_dir}.  It is a service
 taking file path as parameter, serving the content of the static
-directory. We use <<a_api project="eliom" subproject="server"| val
-Eliom.Eliom_uri.make_string_uri >> to get the url as a string.
+directory. We use {!val
+Eliom.Eliom_uri.make_string_uri} to get the url as a string.
 
-<<code language="ocaml"|
+{@ocaml[
 let feed_service =
   Eliom.Service.create
     ~path:(Eliom.Service.Path ["feed"])
@@ -169,14 +170,14 @@ let feed name () =
              | e -> Lwt.fail e )
 
 let () = Eliom.Registration.String.register ~service:feed_service feed
->>
+]}
 
 And then use the new module as follow:
 
-<<code language="ocaml"|
+{@ocaml[
   [ a Feed.feed_service [txt "atom feed"] name;
     div (if name = username
       then [Feed.save_image_box name]
       else [txt "no saving"]);
   ]
->>
+]}
diff --git a/tutos/dev/manual/reactivemediaplayer.wiki b/tutos/dev/manual/reactivemediaplayer.mld
similarity index 64%
rename from tutos/dev/manual/reactivemediaplayer.wiki
rename to tutos/dev/manual/reactivemediaplayer.mld
index a15c2d01..a75ffc19 100644
--- a/tutos/dev/manual/reactivemediaplayer.wiki
+++ b/tutos/dev/manual/reactivemediaplayer.mld
@@ -1,33 +1,36 @@
-=Reactive Media Player=
+{0 Reactive Media Player}
 
-You should read the [[site:/tuto/manual/music|Playing Music]] tutorial before this one.
+You should read the {{:../tuto/manual/music}Playing Music} tutorial before this one.
 
 Since version 4, Eliom embeds the
-[[http://erratique.ch/logiciel/react|React]] library in order to
+{{:http://erratique.ch/logiciel/react}React} library in order to
 provide reactive HTML elements
-(<<a_api project="eliom" subproject="server"| module Eliom.Content.Html.R >>).
+({!Eliom.Content.Html.R}).
 
 
-<<webonly| The final Eliom code is available
-[[https://github.com/ocsigen/tutorial/tree/master/files/tutorial/chapter3/reactive_media_player/reactive_media_player.eliom|for download]]. >>
+ The final Eliom code is available
+{{:https://github.com/ocsigen/tutorial/tree/master/files/tutorial/chapter3/reactive_media_player/reactive_media_player.eliom}for download}. 
 
-==@@id="basics"@@ Basics==
+{1:basics Basics}
 
 A reactive element, or more generally a reactive value, depends on the
 current value of a signal. For instance :
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 [%%shared
 open Eliom.Content
 open Html
 ]
->>
+]}
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client s, set_s = React.S.create 0 (* signal creation *)
->>
+]}
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%shared example_div () =
   C.node {{R.txt (React.S.map string_of_int s)}}
 
@@ -36,48 +39,52 @@ let%shared incr_button =
       ~button_type:`Button
       ~a:[a_onclick [%client fun _ -> set_s (succ (React.S.value s)) ]]
       [txt "Increment"])
->>
+]}
 
-The signal {{{s}}} carries an int value initialized at 0 and
-{{{set_s}}} is the update function generating an occurence of the
+The signal [s] carries an int value initialized at 0 and
+[set_s] is the update function generating an occurence of the
 signal.
 
-{{{example_div}}} is a {{{<div>}}} containing a string which depends
+[example_div] is a [<div>] containing a string which depends
 on the value of s.
 
 The magic part: we never have to explicitly update
-{{{example_div}}}. Its behavior is declaratively described in its own
+[example_div]. Its behavior is declaratively described in its own
 code, and not in the code of the button.
 
-<<concept title="Client node on the server"|
-{{{C.node}}} takes a client node and brings it to the server side.
->>
+{%wodoc:aside class="concept"%}{b Concept: Client node on the server}
 
-<<concept title="Step semantics"|
-**Warning** If you haven't read the React semantics, be aware of this:
-a step occurence of a signal {{{s}}} happens when the update function
-is called on the signal or on a other signal {{{s'}}} which {{{s}}}
-depends on. But moreover, this update call must at least **modify**
+
+[C.node] takes a client node and brings it to the server side.
+{%wodoc:end%}
+
+{%wodoc:aside class="concept"%}{b Concept: Step semantics}
+
+
+{b Warning} If you haven't read the React semantics, be aware of this:
+a step occurence of a signal [s] happens when the update function
+is called on the signal or on a other signal [s'] which [s]
+depends on. But moreover, this update call must at least {b modify}
 the signal current value, otherwise it's not a step.
 
 This can be seen when there are side effects (like print) in the code
 of functions mapped to the signal. If the update function does not
 modify the signal value, the printing does not happen.
 
-The test equality function of a signal can be set in the {{{eq}}}
+The test equality function of a signal can be set in the [eq]
 optional parameters of React.S functions producing a signal (like
-{{{create}}}). >>
+[create]). {%wodoc:end%}
 
 
 
-==@@id="frp_medial_player"@@ Functional Reactive Media Player==
+{1:frp_medial_player Functional Reactive Media Player}
 
 
 
 This part explains how to create a simple media player, similar to the
-[[site:/tuto/manual/music|Playing Music]] tutorial but with custom
+{{:../tuto/manual/music}Playing Music} tutorial but with custom
 controls.We will apply
-[[https://en.wikipedia.org/wiki/Functional_reactive_programming|FRP (Functional Reactive Programming)]].
+{{:https://en.wikipedia.org/wiki/Functional_reactive_programming}FRP (Functional Reactive Programming)}.
 
 
 
@@ -85,23 +92,26 @@ In order to provide a short tutorial, we only create three controls:
 play, pause and seek/progress bar.  So, let's write the corresponding
 type:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 [%%shared
     open Eliom.Content
     open Html
 
     type action = Play | Pause | Seek of float
 ]
->>
+]}
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client media_s, set_media_s = React.S.create Pause
->>
+]}
 
 Each HTML element emits a signal value corresponding to its action.
 It is enough to create our "play" and "pause" inputs.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let pause_button () =
   D.(Form.button_no_value
        ~button_type:`Button
@@ -113,20 +123,23 @@ let play_button () =
        ~button_type:`Button
        ~a:[a_onclick  [%client  fun _ -> set_media_s Play ]]
        [txt "Play"])
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Abstract the Js events}
+
 
-<<concept title="Abstract the Js events"|
 A nice thing about FRP is that we can abstract JavaScript
 events and only use signals.
 The JS event handler is only a function raising a signal.
->>
+{%wodoc:end%}
 
 
 
 To use our buttons, we now create a media (audio or video) HTML
 element on the server side.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let media_uri =
   Html.D.make_uri
     ~service:(Eliom.Service.static_dir ())
@@ -152,20 +165,23 @@ let media_tag () =
      : unit)
   ] in
   media
->>
+]}
+
+The function [media_tag] builds an [<audio>] element.  The
+code in [[%client ... ]] is on the client part. It's an Lwt
+thread that maps a function [media_action -> unit] to the signal
+[media_s].
+
+{%wodoc:aside class="concept"%}{b Concept: Playing video}
 
-The function {{{media_tag}}} builds an {{{<audio>}}} element.  The
-code in {{{ [%client ... ] }}} is on the client part. It's an Lwt
-thread that maps a function {{{media_action -> unit}}} to the signal
-{{{media_s}}}.
 
-<<concept title="Playing video"|
 The code for playing video is conceptually similar. You just replace
-the {{{audio}}} tag by a {{{video}}} tag. But be careful, not all
+the [audio] tag by a [video] tag. But be careful, not all
 browsers are compatible with all formats.
->>
+{%wodoc:end%}
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 module React_Player_app =
   Eliom.Registration.App
     (struct
@@ -190,24 +206,26 @@ let () =
            ])
        in
        Lwt.return (Eliom.Tools.D.html ~title:"Media" ~css:[] body))
->>
+]}
 
 Now you should have an ΗΤΜL node with an audio tag, and two buttons:
 play and pause. The progress bar is slightly harder to understand, but
-thanks to FRP, very easy to write.  It's basically an {{{input}}} with
-{{{range}}} type. In our program, the progress bar must emit the
-signal {{{media_s}}} with the value {{{Seek f}}} at input handling.
+thanks to FRP, very easy to write.  It's basically an [input] with
+[range] type. In our program, the progress bar must emit the
+signal [media_s] with the value [Seek f] at input handling.
 Then, it must evolve during media playback, for which we need another
 signal. To conclude, we must check that the display (the value) of the
 progress bar is not modified when the user is seeking.
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client progress_s, set_progress_s = React.S.create (0., 0.)
 
 let%client unblock_s, set_unblock_s = React.S.create true
->>
+]}
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let progress_bar () =
   let progress_value =
     [%client
@@ -242,25 +260,28 @@ let progress_bar () =
      : unit)
   ] in
   d_input
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Reactive attributes and React.S.on}
+
 
-<<concept title="Reactive attributes and React.S.on" |
 
-The function {{{R.a_value}}}
-(under <<a_api project="eliom" subproject="server"| module Eliom.Content.Html >>)
-is a reactive attribute value. {{{React.S.on c d s}}} is equal to
-{{{s}}} when {{{c}}} is true, otherwise it is equal to {{{d}}} (in
-case {{{c}}} has never been true). Which means we update the attribute
+The function [R.a_value]
+(under {!Eliom.Content.Html})
+is a reactive attribute value. [React.S.on c d s] is equal to
+[s] when [c] is true, otherwise it is equal to [d] (in
+case [c] has never been true). Which means we update the attribute
 value of our input only if unblock is true.
 
->>
+{%wodoc:end%}
 
-To end this tutorial, you can add a {{{progress_bar ()}}} call inside
+To end this tutorial, you can add a [progress_bar ()] call inside
 the div containing play and pause. We also need a mechanism which
-emits the {{{progress_s}}} signal. We modify the media tag with an
-eventhandler on {{{timeupdate}}}.
+emits the [progress_s] signal. We modify the media tag with an
+eventhandler on [timeupdate].
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let media_tag () =
   let media = D.(audio ~src:media_uri [txt "alt"]) in
   let _ = [%client
@@ -281,11 +302,11 @@ let media_tag () =
      : unit)
   ] in
   media
->>
+]}
 
 
 
-====Exercises====
+{3 Exercises}
 
-* Add a control to set the volume
-* Add an {{{Eliom.Bus}}} to control several clients
+- Add a control to set the volume
+- Add an [Eliom.Bus] to control several clients
diff --git a/tutos/dev/manual/rest.wiki b/tutos/dev/manual/rest.mld
similarity index 76%
rename from tutos/dev/manual/rest.wiki
rename to tutos/dev/manual/rest.mld
index 08de4aea..9e10d3af 100644
--- a/tutos/dev/manual/rest.wiki
+++ b/tutos/dev/manual/rest.mld
@@ -1,5 +1,7 @@
-=RESTful JSON API using Eliom=
-<<concepts|RESTful API\\PUT and DELETE services>>
+{0 RESTful JSON API using Eliom}
+{%wodoc:aside class="concepts"%}{b Concepts}
+
+RESTful API{%html:<br/>%}PUT and DELETE services{%wodoc:end%}
 
 This tutorial will show you how to create a simple, yet complete, REST API
 using JSON as the serialization format.
@@ -9,23 +11,23 @@ locations storing a description and coordinates (latitude and longitude).
 
 To be RESTful, our interface will comply with the following principles:
 
-* URLs and GET params identify resources
-* HTTP methods are used to define actions to perform (GET, POST, PUT, DELETE)
-* GET action is safe (no side-effect)
-* PUT and DELETE actions are idempotent
-* Requests are stateless
+- URLs and GET params identify resources
+- HTTP methods are used to define actions to perform (GET, POST, PUT, DELETE)
+- GET action is safe (no side-effect)
+- PUT and DELETE actions are idempotent
+- Requests are stateless
 
 With this in mind, our goal will be to implement CRUD (Create, Read, Update,
 Delete) functions to handle our resources. We want the following requests to be
 valid:
 
-{{{GET http://localhost/}}} will return all available locations.
+[GET http://localhost/] will return all available locations.
 
-{{{GET http://localhost/ID}}} will return location associated to {{{ID}}}.
+[GET http://localhost/ID] will return location associated to [ID].
 
-{{{POST http://localhost/ID}}} with content:
+[POST http://localhost/ID] with content:
 
-<<code language="json"|
+{@json[
 {
   "description": "Paris",
   "coordinates": {
@@ -33,35 +35,35 @@ valid:
     "longitude": 2.3508
   }
 }
->>
+]}
 
 will store this location in the database.
 
-{{{PUT http://localhost/ID}}}, with some content, will update the location
-associated to {{{ID}}}.
+[PUT http://localhost/ID], with some content, will update the location
+associated to [ID].
 
-{{{DELETE http://localhost/ID}}} will delete the location associated to
-{{{ID}}}.
+[DELETE http://localhost/ID] will delete the location associated to
+[ID].
 
-==@@id="requirements"@@ Requirements==
+{1:requirements Requirements}
 
-* eliom >= 4.0
-* yojson
-* ppx_deriving
-* ppx_deriving_yojson
+- eliom >= 4.0
+- yojson
+- ppx_deriving
+- ppx_deriving_yojson
 
 You need some knowledge about Eliom to be able to fully understand this
 tutorial. It's not meant to be an Eliom introduction.
 
 The following browser extensions are useful to manually test your REST APIs:
 
-* [[https://addons.mozilla.org/en-US/firefox/addon/restclient/|RESTClient]] for
+- {{:https://addons.mozilla.org/en-US/firefox/addon/restclient/}RESTClient} for
 Firefox
 *
-[[https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm|Postman]]
+{{:https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm}Postman}
 for Chrome
 
-==@@id="types"@@ Data types==
+{1:types Data types}
 
 We start by defining our database types, that is to say the way we will
 represent our locations and associated information. Each location will be
@@ -70,15 +72,15 @@ information: a description and coordinates (made of a latitude and a
 longitude).
 
 We represent coordinates with decimal degrees, and use the
-{{{ppx_deriving_yojson}}} library to parse and generate JSON serialization of our
+[ppx_deriving_yojson] library to parse and generate JSON serialization of our
 types.
 
-We use a dedicated {{{error}}} type returned when something is wrong with the
+We use a dedicated [error] type returned when something is wrong with the
 request itself or with the processing of the request.
 
-As for the database, we use a simple {{{Ocsipersist}}} table.
+As for the database, we use a simple [Ocsipersist] table.
 
-<<code language="ocaml"|
+{@ocaml[
 type coordinates = {
   latitude : float;
   longitude : float;
@@ -100,62 +102,64 @@ type error = {
 
 let db : location Ocsipersist.table Lwt.t =
   Ocsipersist.Polymorphic.open_table "locations"
->>
+]}
+
+{%wodoc:aside class="concept"%}{b Concept: Syntax extensions}
+
 
-<<concept title="Syntax extensions"|
 
 In order to successfully build this tutorial's source code, your
-{{{Makefile.options}}} must contain the following settings:
-<<code language="makefile"|
+[Makefile.options] must contain the following settings:
+{@makefile[
 # OCamlfind packages for the server
 SERVER_PACKAGES := ppx_deriving_yojson lwt_ppx js_of_ocaml-ppx.deriving
 # OCamlfind packages for the client
 CLIENT_PACKAGES := lwt_ppx ppx_deriving_yojson js_of_ocaml-ppx js_of_ocaml-ppx.deriving
->>
+]}
 
 This is due to the fact, that in the code snippet above we use a syntax extension
-provided by the {{{ppx_deriving_yojson}}} package.//
->>
+provided by the [ppx_deriving_yojson] package.{e 
+{%wodoc:end%}
 
-==@@id="services"@@ Services definition==
+{1:services Services definition}
 
 First, let's define common service parameters:
 
-* The {{{path}}} of the API: it's the same for all services.
+- The [path] of the API: it's the same for all services.
 
-* The GET parameter, which is an optional identifier given as a URL suffix. We
+- The GET parameter, which is an optional identifier given as a URL suffix. We
 set it as optional so we can distinguish GET requests for all resources or a
 single one, and return a detailed error if the identifier is missing in POST,
 PUT and DELETE requests. An alternative would be to use two services at the same
 path (one with id and the other without).
 
-<<code language="ocaml"|
+{@ocaml[
 let path = Eliom.Service.Path [""]
 
 let get_params =
   Eliom.Parameter.(suffix (neopt (string "id")))
->>
+]}
 
 Next step is to define our API services. We define four of them with the same
 path, using the four HTTP methods at our disposal:
 
-* GET method will be used to access the database, either all of it if no
+- GET method will be used to access the database, either all of it if no
 identifier is provided, or a single resource otherwise. An error will be
 returned if no resource matches the identifier.
 
-* POST method will be used to create a new resource (or update it if it already
-exists). We set a single POST parameter: {{{Eliom.Parameter.raw_post_data}}},
+- POST method will be used to create a new resource (or update it if it already
+exists). We set a single POST parameter: [Eliom.Parameter.raw_post_data],
 in order to retrieve raw JSON and bypass POST parameters decoding.
 
-* PUT method will be used to update an existing resource. An error will be
+- PUT method will be used to update an existing resource. An error will be
 returned if no resource matches the identifier. We don't need to define POST
-parameter, PUT services takes {{{Eliom.Parameter.raw_post_data}}} as default
+parameter, PUT services takes [Eliom.Parameter.raw_post_data] as default
 content.
 
-* DELETE method will be used to delete an existing resource. An error will be
+- DELETE method will be used to delete an existing resource. An error will be
 returned if no resource matches the identifier.
 
-<<code language="ocaml"|
+{@ocaml[
 let read_service =
   Eliom.Service.create
     ~path
@@ -179,26 +183,26 @@ let delete_service =
     ~path
     ~meth:(Eliom.Service.Delete get_params)
     ()
->>
+]}
 
-==@@id="handlers"@@ Handlers==
+{1:handlers Handlers}
 
 Let's start the handlers definition with a few helper values and functions
 used by handlers.
 
-Since we use the low-level {{{Eliom.Registration.String.send}}} function to
-send our response, we wrap it in three specialized functions: {{{send_json}}},
-{{{send_error}}} and {{{send_success}}} (this one only send the 200 OK status
+Since we use the low-level [Eliom.Registration.String.send] function to
+send our response, we wrap it in three specialized functions: [send_json],
+[send_error] and [send_success] (this one only send the 200 OK status
 code, without any content).
 
-Another function helps us to check the received {{{Content-type}}} is the
+Another function helps us to check the received [Content-type] is the
 expected one, by matching it against a MIME type. In our example, we'll verify
 that we are receiving JSON.
 
-The {{{read_raw_content}}} function retrieve at most {{{length}}} characters
-from the {{{raw_content}}} Ocsigen stream.
+The [read_raw_content] function retrieve at most [length] characters
+from the [raw_content] Ocsigen stream.
 
-<<code language="ocaml"|
+{@ocaml[
 let json_mime_type = "application/json"
 
 let send_json ~code json =
@@ -220,38 +224,38 @@ let check_content_type ~mime_type content_type =
 let read_raw_content ?(length = 4096) raw_content =
   let content_stream = Ocsigen_stream.get raw_content in
   Ocsigen_stream.string_of_stream length content_stream
->>
+]}
 
 Then we define our handlers in order to perform the required actions and
 return a response.
 
-POST and PUT handlers will read raw body content as JSON and use {{{Yojson}}}
+POST and PUT handlers will read raw body content as JSON and use [Yojson]
 to convert it to our types.
 
 We use HTTP status codes in responses, with these meaning:
 
-* 200 (OK): the request succeeded.
-* 400 (Bad request): something is wrong with the request (missing parameter,
+- 200 (OK): the request succeeded.
+- 400 (Bad request): something is wrong with the request (missing parameter,
 parsing error...).
-* 404 (Not found): no resource matches the provided identifier.
+- 404 (Not found): no resource matches the provided identifier.
 
 The GET handler either returns a single location if an identifier is provided,
 or a list of all existing locations otherwise.
 
-<<code language="ocaml"|
+{@ocaml[
 let read_handler id_opt () =
   let%lwt db = db in
   match id_opt with
   | None ->
     Ocsipersist.Polymorphic.fold_step
       (fun id loc acc -> Lwt.return ((id, loc) :: acc)) db []
-    ~>>= fun locations ->
+    >>= fun locations ->
     let json = Yojson.Safe.to_string (locations_to_yojson locations) in
     send_json ~code:200 json
   | Some id ->
     catch
       (fun () ->
-         Ocsipersist.Polymorphic.find db  id ~>>= fun location ->
+         Ocsipersist.Polymorphic.find db  id >>= fun location ->
          let json =
            Yojson.Safe.to_string (location_to_yojson location) in
          send_json ~code:200 json)
@@ -260,7 +264,7 @@ let read_handler id_opt () =
           (* [id] hasn't been found, return a "Not found" message *)
           send_error ~code:404 ("Resource not found: " ^ id)
         | _ ->  send_error ~code:500 "Internal server error" )
->>
+]}
 
 Next, let's create a common function for POST and PUT handlers, which have a
 very similar behaviour. The only difference is that a PUT request with a
@@ -268,7 +272,7 @@ non-existing identifier will fail (thus only accepting update requests, and
 rejecting creations), whereas the same request with POST method will succeed (a
 new location associated to the identifier will be created).
 
-<<code language="ocaml"|
+{@ocaml[
 let edit_handler_aux ?(create = false) id_opt (content_type, raw_content_opt) =
   let%lwt db = db in
   if not (check_content_type ~mime_type:json_mime_type content_type) then
@@ -280,20 +284,20 @@ let edit_handler_aux ?(create = false) id_opt (content_type, raw_content_opt) =
     | _, None ->
       send_error ~code:400 "Body content is missing"
     | Some id, Some raw_content ->
-      read_raw_content raw_content ~>>= fun location_str ->
+      read_raw_content raw_content >>= fun location_str ->
       catch (fun () ->
           (if create then
             Lwt.return_unit
            else
-            Ocsipersist.Polymorphic.find db id ~>>= fun _ -> Lwt.return_unit)
-          ~>>= fun () ->
+            Ocsipersist.Polymorphic.find db id >>= fun _ -> Lwt.return_unit)
+          >>= fun () ->
           let location =
             (let open Result in
             let loc_result = location_of_yojson (Yojson.Safe.from_string location_str) in
             match loc_result with
               Ok loc-> loc
             | Error _ -> raise Deriving_Yojson.Failed )  in
-          Ocsipersist.Polymorphic.add db  id location ~>>= fun () ->
+          Ocsipersist.Polymorphic.add db  id location >>= fun () ->
           send_success ())
       (function
         | Not_found ->
@@ -307,40 +311,40 @@ let create_handler id_opt content =
 
 let update_handler id_opt content =
   edit_handler_aux ~create:false id_opt content
->>
+]}
 
 We need a fourth handler to delete locations:
 
-<<code language="ocaml"|
+{@ocaml[
 let%lwt db = db in
   match id_opt with
   | None ->
     send_error ~code:400 "An id must be provided to delete a location"
   | Some id ->
-    Ocsipersist.Polymorphic.remove db id ~>>= fun () ->
+    Ocsipersist.Polymorphic.remove db id >>= fun () ->
     send_success ()
->>
+]}
 
-==@@id="registration"@@ Services registration==
+{1:registration Services registration}
 
-Finally we register services with the {{{Eliom.Registration.Any}}} module in
+Finally we register services with the [Eliom.Registration.Any] module in
 order to have full control on the sent response. This way, we'll be able to
 send an appropriate HTTP status code depending on what happens during the
 request processing (parsing error, resource not found...), as seen above when
 defining handlers.
 
-<<code language="ocaml"|
+{@ocaml[
 let () =
   Eliom.Registration.Any.register read_service read_handler;
   Eliom.Registration.Any.register create_service create_handler;
   Eliom.Registration.Any.register update_service update_handler;
   Eliom.Registration.Any.register delete_service delete_handler;
   ()
->>
+]}
 
-==@@id="source"@@ Full source==
+{1:source Full source}
 
-<<code language="ocaml"|
+{@ocaml[
 open Lwt
 
 (**** Data types ****)
@@ -431,13 +435,13 @@ let read_handler id_opt () =
   | None ->
     Ocsipersist.Polymorphic.fold_step
       (fun id loc acc -> Lwt.return ((id, loc) :: acc)) db []
-    ~>>= fun locations ->
+    >>= fun locations ->
     let json = Yojson.Safe.to_string (locations_to_yojson locations) in
     send_json ~code:200 json
   | Some id ->
     catch
       (fun () ->
-         Ocsipersist.Polymorphic.find db  id ~>>= fun location ->
+         Ocsipersist.Polymorphic.find db  id >>= fun location ->
          let json =
            Yojson.Safe.to_string (location_to_yojson location) in
          send_json ~code:200 json)
@@ -458,20 +462,20 @@ let edit_handler_aux ?(create = false) id_opt (content_type, raw_content_opt) =
     | _, None ->
       send_error ~code:400 "Body content is missing"
     | Some id, Some raw_content ->
-      read_raw_content raw_content ~>>= fun location_str ->
+      read_raw_content raw_content >>= fun location_str ->
       catch (fun () ->
           (if create then
             Lwt.return_unit
            else
-            Ocsipersist.Polymorphic.find db id ~>>= fun _ -> Lwt.return_unit)
-          ~>>= fun () ->
+            Ocsipersist.Polymorphic.find db id >>= fun _ -> Lwt.return_unit)
+          >>= fun () ->
           let location =
             (let open Result in
             let loc_result = location_of_yojson (Yojson.Safe.from_string location_str) in
             (function
               Ok loc-> loc
             | Error _ -> raise Deriving_Yojson.Failed ) loc_result)  in
-          Ocsipersist.Polymorphic.add db  id location ~>>= fun () ->
+          Ocsipersist.Polymorphic.add db  id location >>= fun () ->
           send_success ())
       (function
         | Not_found ->
@@ -492,7 +496,7 @@ let delete_handler id_opt _ =
   | None ->
     send_error ~code:400 "An id must be provided to delete a location"
   | Some id ->
-    Ocsipersist.Polymorphic.remove db id ~>>= fun () ->
+    Ocsipersist.Polymorphic.remove db id >>= fun () ->
     send_success ()
 
 (* Register services *)
@@ -503,4 +507,4 @@ let () =
   Eliom.Registration.Any.register update_service update_handler;
   Eliom.Registration.Any.register delete_service delete_handler;
   ()
->>
+]}
diff --git a/tutos/dev/manual/start.mld b/tutos/dev/manual/start.mld
new file mode 100644
index 00000000..96ca7c57
--- /dev/null
+++ b/tutos/dev/manual/start.mld
@@ -0,0 +1,111 @@
+{%wodoc:header%}
+{0 Your first app in 5 minutes}
+{%wodoc:end%}
+
+{e The code of this tutorial has been tested against Eliom 6.0.} {%html:<br/>%}
+
+
+
+This tutorial describes how to get started with Ocsigen
+quickly. Thanks to an application template provided by the Ocsigen
+team, you will get to a working application with standard
+functionality like users and notifications in only a few minutes. This
+template can be used for learning purposes, or even as a starting
+point for your own product.
+
+The template you will use comes from {{:../ocsigen-start/}Ocsigen Start}.
+Ocsigen Start provides a complete mechanism for adding and managing
+users, including activation links and password reset. It additionally
+contains a module for displaying tips, a module for sending
+notifications to your users, and other utilities typically needed in
+modern Web applications.
+
+The template comes with a default style (developed with
+SASS) that follows modern Web practices, e.g., it is responsive and
+thus mobile-friendly. Of course, you are free to modify the style to
+match your own brand or personality.
+
+The template is multi-platform. This means that it can run on a Web
+browser or as a mobile app for Android, iOS, or Windows.
+
+{%wodoc:div class="screenshots"%}
+{{:files/screenshots/start1.png}
+{{files/screenshots/start1.png|Ocsigen Start}}}
+{{:files/screenshots/start2.png}
+{{files/screenshots/start2.png|Ocsigen Start}}}
+{%wodoc:end%}
+
+{%wodoc:div class="screenshots"%}
+{{:files/screenshots/start-mobile-1.png}
+{{files/screenshots/start-mobile-1.png|Ocsigen Start}}}
+{{:files/screenshots/start-mobile-2.png}
+{{files/screenshots/start-mobile-2.png|Ocsigen Start}}}
+{{:files/screenshots/start-mobile-4.png}
+{{files/screenshots/start-mobile-4.png|Ocsigen Start}}}
+{%wodoc:end%}
+
+{1 Installation}
+
+Install the dependencies ([postgresql] and one of [sass], [sassc]).
+On Debian-based systems:
+{v
+apt install postgresql ruby-sass
+v}
+
+Install Ocsigen Start and all its OCaml dependencies using OPAM:
+{v
+opam install ocsigen-start
+v}
+
+Create your application using Eliom distillery:
+{v
+eliom-distillery -name myapp -template os
+v}
+
+Have a look at the
+{{:https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/README.md}README}
+file to learn how to compile it
+and, possibly, to generate the mobile applications.
+
+{1 I installed it and compiled it, what next?}
+
+It is now time to learn Ocsigen! The template is a great way to get
+started, because it comes with multiple runnable examples that show
+you:
+
+- How to do remote procedure calls (RPCs);
+- How to save session data (in {e Eliom references});
+- How to use the notification system;
+- How to create reactive pages;
+- Many examples of widgets from {{:../ocsigen-toolkit/}Ocsigen Toolkit}:
+- Carousel
+- Pages with several tabs
+- Time and date pickers
+- ...
+
+The corresponding files are well-commented, so you can quickly find
+out how things work.
+
+{%wodoc:div class="screenshots"%}
+{{:files/screenshots/start3.png}
+{{files/screenshots/start3.png|Ocsigen Start}}}
+{{:files/screenshots/start4.png}
+{{files/screenshots/start4.png|Ocsigen Start}}}
+{{:files/screenshots/start5.png}
+{{files/screenshots/start5.png|Ocsigen Start}}}
+{{:files/screenshots/start6.png}
+{{files/screenshots/start6.png|Ocsigen Start}}}
+{%wodoc:end%}
+
+{%wodoc:div class="screenshots"%}
+{{:files/screenshots/start-mobile-3.png}
+{{files/screenshots/start-mobile-3.png|Ocsigen Start}}}
+{{:files/screenshots/start-mobile-6.png}
+{{files/screenshots/start-mobile-6.png|Ocsigen Start}}}
+{{:files/screenshots/start-mobile-7.png}
+{{files/screenshots/start-mobile-7.png|Ocsigen Start}}}
+{{:files/screenshots/start-mobile-8.png}
+{{files/screenshots/start-mobile-8.png|Ocsigen Start}}}
+{%wodoc:end%}
+
+Have fun!
diff --git a/tutos/dev/manual/start.wiki b/tutos/dev/manual/start.wiki
deleted file mode 100644
index 91289045..00000000
--- a/tutos/dev/manual/start.wiki
+++ /dev/null
@@ -1,109 +0,0 @@
-<<header| =Your first app in 5 minutes >>
-
-//The code of this tutorial has been tested against Eliom 6.0.// \\
-
-<<|wip|This tutorial is work in progress. Please send us any corrections or comments./>>
-
-This tutorial describes how to get started with Ocsigen
-quickly. Thanks to an application template provided by the Ocsigen
-team, you will get to a working application with standard
-functionality like users and notifications in only a few minutes. This
-template can be used for learning purposes, or even as a starting
-point for your own product.
-
-The template you will use comes from [[wiki("ocsigen-start"):|Ocsigen Start]].
-Ocsigen Start provides a complete mechanism for adding and managing
-users, including activation links and password reset. It additionally
-contains a module for displaying tips, a module for sending
-notifications to your users, and other utilities typically needed in
-modern Web applications.
-
-The template comes with a default style (developed with
-SASS) that follows modern Web practices, e.g., it is responsive and
-thus mobile-friendly. Of course, you are free to modify the style to
-match your own brand or personality.
-
-The template is multi-platform. This means that it can run on a Web
-browser or as a mobile app for Android, iOS, or Windows.
-
-<<div class="screenshots"|
-[[files/screenshots/start1.png|
-{{files/screenshots/start1.png|Ocsigen Start}}]]
-[[files/screenshots/start2.png|
-{{files/screenshots/start2.png|Ocsigen Start}}]]
->>
-
-<<div class="screenshots"|
-[[files/screenshots/start-mobile-1.png|
-{{files/screenshots/start-mobile-1.png|Ocsigen Start}}]]
-[[files/screenshots/start-mobile-2.png|
-{{files/screenshots/start-mobile-2.png|Ocsigen Start}}]]
-[[files/screenshots/start-mobile-4.png|
-{{files/screenshots/start-mobile-4.png|Ocsigen Start}}]]
->>
-
-== Installation
-
-Install the dependencies ({{{postgresql}}} and one of {{{sass}}}, {{{sassc}}}).
-On Debian-based systems:
-{{{
-apt install postgresql ruby-sass
-}}}
-
-Install Ocsigen Start and all its OCaml dependencies using OPAM:
-{{{
-opam install ocsigen-start
-}}}
-
-Create your application using Eliom distillery:
-{{{
-eliom-distillery -name myapp -template os
-}}}
-
-Have a look at the
-[[https://github.com/ocsigen/ocsigen-start/blob/master/template.distillery/README.md|README]]
-file to learn how to compile it
-and, possibly, to generate the mobile applications.
-
-== I installed it and compiled it, what next?
-
-It is now time to learn Ocsigen! The template is a great way to get
-started, because it comes with multiple runnable examples that show
-you:
-
-* How to do remote procedure calls (RPCs);
-* How to save session data (in //Eliom references//);
-* How to use the notification system;
-* How to create reactive pages;
-* Many examples of widgets from [[wiki("ocsigen-toolkit"):|Ocsigen Toolkit]]:
-** Carousel
-** Pages with several tabs
-** Time and date pickers
-* ...
-
-The corresponding files are well-commented, so you can quickly find
-out how things work.
-
-<<div class="screenshots"|
-[[files/screenshots/start3.png|
-{{files/screenshots/start3.png|Ocsigen Start}}]]
-[[files/screenshots/start4.png|
-{{files/screenshots/start4.png|Ocsigen Start}}]]
-[[files/screenshots/start5.png|
-{{files/screenshots/start5.png|Ocsigen Start}}]]
-[[files/screenshots/start6.png|
-{{files/screenshots/start6.png|Ocsigen Start}}]]
->>
-
-<<div class="screenshots"|
-[[files/screenshots/start-mobile-3.png|
-{{files/screenshots/start-mobile-3.png|Ocsigen Start}}]]
-[[files/screenshots/start-mobile-6.png|
-{{files/screenshots/start-mobile-6.png|Ocsigen Start}}]]
-[[files/screenshots/start-mobile-7.png|
-{{files/screenshots/start-mobile-7.png|Ocsigen Start}}]]
-[[files/screenshots/start-mobile-8.png|
-{{files/screenshots/start-mobile-8.png|Ocsigen Start}}]]
->>
-
-Have fun!
diff --git a/tutos/dev/manual/tutoreact.wiki b/tutos/dev/manual/tutoreact.mld
similarity index 68%
rename from tutos/dev/manual/tutoreact.wiki
rename to tutos/dev/manual/tutoreact.mld
index c475cf7a..54bfec46 100644
--- a/tutos/dev/manual/tutoreact.wiki
+++ b/tutos/dev/manual/tutoreact.mld
@@ -1,4 +1,4 @@
-= Client server reactive application with Ocsigen
+{0 Client server reactive application with Ocsigen}
 
 This is a short tutorial showing how to implement a simple reactive
 client-server application using Js_of_ocaml, Eliom and
@@ -9,82 +9,84 @@ that allows connected users to add new messages.
 
 You will learn:
 
-* How to use Ocsigen Start to quickly build an application with user
+- How to use Ocsigen Start to quickly build an application with user
   management.
-* How to create a client-server reactive interface: the HTML is
+- How to create a client-server reactive interface: the HTML is
   generated indifferently server-side or client-side, and
   contains reactive parts that are updated automatically when the data
   change.
-* How to implement a notification system for your application. Users
+- How to implement a notification system for your application. Users
   are notified when a new item (a message in our case) arrives.
 
 
 
-== First step: a basic application with user management
+{1 First step: a basic application with user management}
 
 Ocsigen Start contains a set of higher level libraries for Eliom
 (user management, tips, notifications). It also contains a template
-for {{{eliom-distillery}}} that creates an application with user
+for [eliom-distillery] that creates an application with user
 management. You can use this template as a starting point for your
 project.
 
-{{{
+{v
 eliom-distillery -name tutoreact -template os
-}}}
+v}
 
 This template is using PostgreSQL to store the data. You need a recent
 version of Postgresql installed on your system.  With that available,
 you can create the local database and start the database server:
 
-{{{
+{v
 make db-init
 make db-create
 make db-schema
-}}}
+v}
 
 Compile and run the program:
-{{{
+{v
 make test.byte
-}}}
+v}
 
-Go to {{{http://localhost:8080}}}, you should see the welcome page. You can now
+Go to [http://localhost:8080], you should see the welcome page. You can now
 register a user and log in. Because the send mail function is not configured,
 the activation links will be printed on the console you started the server with.
 
 At any point, if you want to get back to this tutorial later, you may need to
 start the database again:
-{{{
+{v
 make db-start
-}}}
+v}
 
 While doing this tutorial, if you plan to work on another Ocsigen project
 requiring a database, do not forget to stop the tutorial's database beforehand:
-{{{
+{v
 make db-stop
-}}}
+v}
 
 
 
-== Display messages from db
+{1 Display messages from db}
 
 To make this example more realistic, let's suppose that we do not want to
 display all the messages in the database, but only a few of them.
 
 In this tutorial, we will not focus on the implementation details of the
-database part. Create a new file named {{{tutoreact_messages.eliom}}}. From now
+database part. Create a new file named [tutoreact_messages.eliom]. From now
 on, if not explicitly specified, the code we are going to write will go there.
-We are going to create a module {{{Db}}} containing these functions:
+We are going to create a module [Db] containing these functions:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 val get_messages : unit -> int list Lwt.t
 val get_message : int -> string Lwt.t
 val add_message : string -> int Lwt.t
->>
+]}
 
 You can try to make your own implementation using for instance pgocaml.
 Here's our implementation using Ocsipersist:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 [%%server
 module Db = struct
   let db = Ocsipersist.Polymorphic.open_table "messages"
@@ -115,16 +117,18 @@ module Db = struct
     let%lwt () = Ocsipersist.Polymorphic.add db (string_of_int index) v in
     Lwt.return index
 end]
->>
+]}
 
 Add the following code:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 [%%shared
     open Eliom.Content.Html
     open Eliom.Content.Html.D]
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server display userid_o =
   let%lwt messages = Db.get_messages () in
   let%lwt l =
@@ -135,44 +139,46 @@ let%server display userid_o =
       messages
   in
   Lwt.return [ul l]
->>
+]}
 
 Depending on your database, it is probably more efficient to
 fetch all messages and their identifiers using only one request.
-Here we use {{{Lwt_list.map_s}}} to do the requests sequentially.
+Here we use [Lwt_list.map_s] to do the requests sequentially.
 
 The content of the main page is defined in
-the file {{{tutoreact_handlers.eliom}}}.
-Replace the code of {{{main_service_handler}}} by:
+the file [tutoreact_handlers.eliom].
+Replace the code of [main_service_handler] by:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server main_service_handler userid_o () () =
   let%lwt content = Tutoreact_messages.display userid_o in
   Tutoreact_container.page userid_o content
->>
+]}
 
-The {{{main_service_handler}}} you just replaced was in a shared section.
+The [main_service_handler] you just replaced was in a shared section.
 Therefore, we also need to change two other files to take into consideration
 this modification.
 
-In the file {{{tutoreact_handlers.eliomi}}}, move the definition of
-{{{main_service_handler}}} from the shared section to the server section.
+In the file [tutoreact_handlers.eliomi], move the definition of
+[main_service_handler] from the shared section to the server section.
 
-In the file {{{tutoreact.eliom}}}, move the registration of {{{main_service}}}
+In the file [tutoreact.eliom], move the registration of [main_service]
 from the shared section to the server section.
 
 Try to compile in order to see if everything is fine.
 
 
 
-== Adding new messages
+{1 Adding new messages}
 
-=== Add an input in the page, for connected users
+{2 Add an input in the page, for connected users}
 
 To add an input in the page for connected users,
-replace the function {{{display}}} by the following version:
+replace the function [display] by the following version:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server display_messages () =
   let%lwt messages = Db.get_messages () in
   let%lwt l =
@@ -193,34 +199,36 @@ let%server display userid_o =
                           a_style "border-style:solid"] ()]
   in
   Lwt.return (messages :: l)
->>
+]}
 
-=== Make function {{{Db.add_message}}} accessible from the client
+{2 Make function [Db.add_message] accessible from the client}
 
 To be able to call a function from the client-side program,
-use {{{let%rpc}}}:
-<<code language="ocaml" class="shared"|
+use [let%rpc]:
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc add_message (value : string) : unit Lwt.t =
   let%lwt _ = Os.Current_user.get_current_userid () (* fails if not connected *) in
   Db.add_message value
->>
+]}
 
-The parameter {{{[%json: string]}}} describes the type of
+The parameter [[%json: string]] describes the type of
 the function parameter. This exhibits the syntax provided by
-[[https://github.com/whitequark/ppx_deriving|ppx_deriving]] extended
+{{:https://github.com/whitequark/ppx_deriving}ppx_deriving} extended
 with our JSON plugin. We use this for safe server-side unmarshalling of data
 sent by the client.
 
-=== Bind the input to call the function
+{2 Bind the input to call the function}
 
 To call the function from the client program, we will define a
-//client value//, a client-side expression that is accessible
+{e client value}, a client-side expression that is accessible
 server-side. The client value will be executed client-side
 after the page is loaded. The syntax for client values of type
-{{{t}}} is {{{[%client (... : t)]}}}.
+[t] is [[%client (... : t)]].
 
-Replace the second branch of the {{{match}}} in the function {{{display}}} by:
-<<code language="ocaml" class="server"|
+Replace the second branch of the [match] in the function [display] by:
+{%wodoc:@ class=server%}
+{@ocaml[
 let inp = Raw.input ~a:[a_input_type `Text; a_style "border-style:solid"] () in
 let _ = [%client
   (let open Js_of_ocaml_lwt.Lwt_js_events in
@@ -233,16 +241,16 @@ let _ = [%client
    : unit)
 ] in
 [inp]
->>
-
-* We use module {{{Lwt_js_events}}} to manage events.
-* The syntax {{{~%v}}} allows using a server-side value {{{v}}} client-side.
-* {{{To_dom.of_input}}} returns the JS element corresponding to the
-  OCaml value {{{~%inp}}}.
-* {{{Lwt_js_events.async}}} is similar to {{{Lwt.async}}}.
-* {{{obj##.a}}} allows the access to the field {{{a}}}
-  of the JavaScript object {{{obj}}} (see Js_of_ocaml PPX extension).
-* {{{changes}}} takes a JS element and a function that will be
+]}
+
+- We use module [Lwt_js_events] to manage events.
+- The syntax [~%v] allows using a server-side value [v] client-side.
+- [To_dom.of_input] returns the JS element corresponding to the
+  OCaml value [~%inp].
+- [Lwt_js_events.async] is similar to [Lwt.async].
+- [obj##.a] allows the access to the field [a]
+  of the JavaScript object [obj] (see Js_of_ocaml PPX extension).
+- [changes] takes a JS element and a function that will be
   executed every time a "change" event is received on this element.
 
 This function gets the value of the input, resets the content of the
@@ -255,7 +263,7 @@ display them.
 
 
 
-== Structure of a client-server application
+{1 Structure of a client-server application}
 
 We have seen how to send data to the server without stopping the
 client-side program. Now we want to automatically update the page
@@ -273,16 +281,16 @@ generate pages indifferently (and with the same code) from both sides.
 
 In this section, we will see how to implement this kind of applications
 very concisely thanks to three notions:
-* The client-server cache of data
-* Reactive pages
-* Notification system
+- The client-server cache of data
+- Reactive pages
+- Notification system
 
 You will be able to test once you finish the three following sections!
 
-=== Client-server cache
+{2 Client-server cache}
 
 The module
-<<a_api project="eliom" subproject="server"| module Eliom.Cscache >>
+{!Eliom.Cscache}
 implements a cache of data, an association table where you
 will put the data of your application client-side. For the sake of
 uniformity (as we want to use it in shared sections), the
@@ -291,23 +299,25 @@ cache is also implemented server-side, with scope
 twice for the same request.
 
 We create a client-server cache by calling the function
-<<a_api project="eliom" subproject="server"| val Eliom.Cscache.create >>
-server-side. The server-side cache {{{cache}}} created by this
-function will be accessible client-side through an injection {{{~%cache}}}.
+{!Eliom.Cscache.create}
+server-side. The server-side cache [cache] created by this
+function will be accessible client-side through an injection [~%cache].
 
-We implement a function {{{get_data}}} to fetch the
+We implement a function [get_data] to fetch the
 data from the database. This function must have an implementation both
 server-side and client-side:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc get_data (id : int) : string Lwt.t = Db.get_message id
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server cache : (int, string) Eliom.Cscache.t =
   Eliom.Cscache.create ()
->>
+]}
 
-=== Reactive interface
+{2 Reactive interface}
 
 Updating the interface when some data change is usually not
 straightforward. This is usually done by putting identifiers on
@@ -318,50 +328,52 @@ A very elegant solution to simplify this consists in using Functional
 Reactive Programming (FRP). In reactive programming, you define
 relations between different pieces of data once, and each update
 automatically produces the recomputation of all the dependent data. In
-Ocsigen we use the module [[http://erratique.ch/logiciel/react|React]]
-combined with [[https://github.com/ocsigen/reactiveData/|ReactiveData]],
-which extends {{{React}}} to deal with incremental updates in
+Ocsigen we use the module {{:http://erratique.ch/logiciel/react}React}
+combined with {{:https://github.com/ocsigen/reactiveData/}ReactiveData},
+which extends [React] to deal with incremental updates in
 lists. Have a look at the documentation of the above modules if you
 are not familiar with FRP.
 
 The client-side module
-<<a_api project="eliom" subproject="client"| module Eliom.Content.Html.R >>
+{!Eliom.Content.Html.R}
 enables defining reactive page elements.
 
-The module <<a_api project="eliom" subproject="server"| module Eliom.Shared >>
+The module {!Eliom.Shared}
 enables defining shared reactive signals server-side.
-In order to do that, we use //shared values//, values defined
+In order to do that, we use {e shared values}, values defined
 both server-side and client-side. The server-side module
-<<a_api project="eliom" subproject="server"| module Eliom.Content.Html.R >>
+{!Eliom.Content.Html.R}
  enables constructing HTML5 elements that get updated automatically
-based on the signals of {{{Eliom.Shared}}}. The modules
-<<a_api project="eliom" subproject="server"| module Eliom.Shared.React >>
+based on the signals of [Eliom.Shared]. The modules
+{!Eliom.Shared.React}
 and
-<<a_api project="eliom" subproject="server"| module Eliom.Shared.ReactiveData >>
-implement interfaces very similar to {{{React}}} and
-{{{ReactiveData}}}, but operate on shared signals.
+{!Eliom.Shared.ReactiveData}
+implement interfaces very similar to [React] and
+[ReactiveData], but operate on shared signals.
 
-=== Implementation of the reactive interface
+{2 Implementation of the reactive interface}
 
-{{{display_message}}} now needs to be implemented in a shared fashion and take
+[display_message] now needs to be implemented in a shared fashion and take
 its data from the cache. In order to do that,
-we call {{{Eliom.Cscache.find cache get_data key}}} from either side to get the
-value associated to {{{key}}}. If the value is not present in the cache, it will
-be fetched using the function {{{get_data}}} and added to the cache.
+we call [Eliom.Cscache.find cache get_data key] from either side to get the
+value associated to [key]. If the value is not present in the cache, it will
+be fetched using the function [get_data] and added to the cache.
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%shared display_message id =
   let%lwt msg = Eliom.Cscache.find ~%cache get_data id in
   Lwt.return (li [txt msg])
->>
+]}
 
-The function {{{display_messages}}} now creates a reactive list of
+The function [display_messages] now creates a reactive list of
 message identifiers, and maps page content from this reactive value
-using module {{{Eliom.Shared.ReactiveData}}}. Note that {{{rmessage}}} is
+using module [Eliom.Shared.ReactiveData]. Note that [rmessage] is
 a tuple, the first element is the list, the second element is the update
 function.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server display_messages () =
   let%lwt messages = Db.get_messages () in
   let rmessages = Eliom.Shared.ReactiveData.RList.create messages in
@@ -371,47 +383,50 @@ let%server display_messages () =
       (fst rmessages)
   in
   Lwt.return (R.ul content)
->>
+]}
 
-== Notifications
+{1 Notifications}
 
 We now want to be notified when a message has been added. To do that
-easily, we use the module {{{Os.Notif}}} from Ocsigen Start.
+easily, we use the module [Os.Notif] from Ocsigen Start.
 
 We first define a notification module for the type of data we want
 clients to be able to listen on (here the lists of message identifiers):
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 [%%server
 module Forum_notif = Os.Notif.Make_Simple (struct
   type key = unit
   type notification = int
 end)
 ]
->>
+]}
 
-{{{key}}} is the type of the identifier of the data we want to listen
-on. In our case, there is a single message list (thus {{{unit}}}
+[key] is the type of the identifier of the data we want to listen
+on. In our case, there is a single message list (thus [unit]
 suffices as the identifier since we don't need to be specific).
 
-{{{notification}}} is the type of the notifications to send. Here: the
+[notification] is the type of the notifications to send. Here: the
 identifier of the new message to be added in the list.
 
 We define a function to handle notifications. It adds the new
 identifier in the reactive list of messages:
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client handle_notif_message_list rmessages (_, msgid) =
   Eliom.Shared.ReactiveData.RList.cons msgid (snd rmessages)
->>
+]}
 
 We notify the server that we are listening on this piece of data by
-calling {{{Forum_notif.listen}}} (server-side). Notifications are
-received client-side through a {{{React}}} event
-{{{Forum_notif.client_ev ()}}}. We map this event to the function
-{{{handle_notif_message_list}}}, meaning that we will execute this function
+calling [Forum_notif.listen] (server-side). Notifications are
+received client-side through a [React] event
+[Forum_notif.client_ev ()]. We map this event to the function
+[handle_notif_message_list], meaning that we will execute this function
 when this event happens.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server display_messages () =
   Forum_notif.listen ();
   let%lwt messages = Db.get_messages () in
@@ -428,17 +443,18 @@ let%server display_messages () =
       (fst rmessages)
   in
   Lwt.return (R.ul content)
->>
+]}
 
 When we add a message, we notify all the clients listening on this
 piece of data:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc add_message (value : string) : unit Lwt.t =
    let%lwt id = Db.add_message value in
    Forum_notif.notify () id;
    Lwt.return ()
->>
+]}
 
 The program is now fully functional, you can now test it! You should see the
 messages being added without the need to reload the page, even if messages are
@@ -446,37 +462,39 @@ added by another user! Try with several browser windows.
 
 
 
-== More information on cache and client-server reactive data
+{1 More information on cache and client-server reactive data}
 
 In this section we will demonstrate additional Eliom functionality for
 client-server programming by implementing some new features in our
 forum:
-* Multi-page forum
-* Client-side spinner while loading data
+- Multi-page forum
+- Client-side spinner while loading data
 
-=== Multi-page forum
+{2 Multi-page forum}
 
 We now want a forum with several pages, located at URLs
-{{{http://localhost:8080/}}}//i//, where //i// represents the {{{forumid}}}
+[http://localhost:8080/]{e i}, where {e i} represents the [forumid]
 as an integer.
 
-==== Services
+{3 Services}
 
-In the file {{{tutoreact_services.eliom}}}, we define the new following service:
+In the file [tutoreact_services.eliom], we define the new following service:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server forum_service =
   Eliom.Service.create
     ~path:(Eliom.Service.Path [""])
     ~meth:(Eliom.Service.Get
             (Eliom.Parameter.(suffix (int "i"))))
     ()
->>
+]}
 
-In the file {{{tutoreact_services.eliomi}}}, we define its signature, do not
+In the file [tutoreact_services.eliomi], we define its signature, do not
 forget to put it in a server section:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 [%%server.start]
 
 val forum_service
@@ -492,92 +510,101 @@ val forum_service
     , unit
     , Eliom.Service.non_ocaml )
     Eliom.Service.t
->>
+]}
 
-In the file {{{tutoreact_handlers.eliom}}}, we define the handler we will
+In the file [tutoreact_handlers.eliom], we define the handler we will
 associate to our new service:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server forum_service_handler userid_o forumid () =
   let%lwt content = Tutoreact_messages.display userid_o forumid in
   Tutoreact_container.page userid_o content
->>
+]}
 
-In the file {{{tutoreact_handlers.eliomi}}}, we define its signature, in the
+In the file [tutoreact_handlers.eliomi], we define its signature, in the
 server section:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 val forum_service_handler
   :  Os.Types.User.id option
   -> int
   -> unit
   -> Os.Page.content Lwt.t
->>
+]}
 
-In the file {{{tutoreact.eliom}}}, we register our handler to our new service in
+In the file [tutoreact.eliom], we register our handler to our new service in
 the server section:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
   Tutoreact_base.App.register ~service:Tutoreact_services.forum_service
     (Tutoreact_page.Opt.connected_page Tutoreact_handlers.forum_service_handler)
->>
+]}
 
-Since we have a new parameter {{{forumid}}}, we need to take it into
+Since we have a new parameter [forumid], we need to take it into
 consideration in many places.
 
-In the file {{{tutoreact_messages.eliom}}}, the functions {{{display_messages}}}
-and {{{display}}} take it as a new parameter. Do not forget to also replace
-the latter in the call of {{{display_messages}}} in function {{{display}}}:
+In the file [tutoreact_messages.eliom], the functions [display_messages]
+and [display] take it as a new parameter. Do not forget to also replace
+the latter in the call of [display_messages] in function [display]:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server display_messages forumid =
   ...
->>
+]}
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server display userid_o forumid =
   let%lwt messages = display_messages forumid in
   ...
->>
+]}
 
-In the file {{{tutoreact_handlers.eliom}}}, update the code of
-{{{main_service_handler}}}:
+In the file [tutoreact_handlers.eliom], update the code of
+[main_service_handler]:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server main_service_handler forumid userid_o () () =
   let%lwt content = Tutoreact_messages.display userid_o forumid in
   Tutoreact_container.page userid_o content
->>
+]}
 
-In the file {{{tutoreact_handlers.eliomi}}}, update its signature:
+In the file [tutoreact_handlers.eliomi], update its signature:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 val main_service_handler
   :  int
   -> Os.Types.User.id option
   -> unit
   -> unit
   -> Os.Page.content Lwt.t
->>
+]}
 
-In the file {{{tutoreact.eliom}}}, in the {{{main_service}}}, we have to specify
+In the file [tutoreact.eliom], in the [main_service], we have to specify
 the forumid of the forum we want to reach when we arrive in our application.
 We will take 0 for instance and give it as the parameter of
-{{{main_service_handler}}}. We update the registration of {{{main_service}}}:
+[main_service_handler]. We update the registration of [main_service]:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
   Tutoreact_base.App.register
     ~service:Os.Services.main_service
     (Tutoreact_page.Opt.connected_page
     (Tutoreact_handlers.main_service_handler 0));
->>
+]}
 
-==== Db
+{3 Db}
 
-The functions {{{Db.get_messages}}} and {{{Db.add_message}}} now take the forum
+The functions [Db.get_messages] and [Db.add_message] now take the forum
 identifier:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 [%%server
 module Db = struct
 
@@ -618,37 +645,40 @@ module Db = struct
 
 end
 ]
->>
+]}
 
-==== Message type
+{3 Message type}
 
-Since we are now adding besides the message, the {{{forumid}}} as well in our
+Since we are now adding besides the message, the [forumid] as well in our
 database, we need to specify a new type:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 [%%shared
     type add_message_type = int * string [@@deriving json]
 ]
->>
+]}
 
 We don't forget to take that into consideration in the function
-{{{add_message}}}.
+[add_message].
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%rpc add_message ((forumid, value) : add_message_type) : unit Lwt.t =
    let%lwt id = Db.add_message forumid value in
    Forum_notif.notify () id;
    Lwt.return ()
->>
+]}
 
-In the function {{{display}}}, in the client section:
-<<code language="ocaml" class="client"|
+In the function [display], in the client section:
+{%wodoc:@ class=client%}
+{@ocaml[
   ...
   add_message (~%forumid, value)
 ...
->>
+]}
 
-==== Cache of forum message identifiers
+{3 Cache of forum message identifiers}
 
 We must send the notifications only to the clients listening on the
 same forum.
@@ -656,29 +686,31 @@ same forum.
 We will create a new client-server cache to keep the reactive list of
 message identifiers for each forums:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server forumcache :
   (int,
    int Eliom.Shared.ReactiveData.RList.t *
    int Eliom.Shared.ReactiveData.RList.handle) Eliom.Cscache.t =
   Eliom.Cscache.create ()
->>
+]}
 
-We will now implement the equivalent of {{{get_data}}} for this new cache.
+We will now implement the equivalent of [get_data] for this new cache.
 
-**Be very careful:**
+{b Be very careful:}
 
-In {{{get_data_forum}}}, we must find the reactive list of messages in
+In [get_data_forum], we must find the reactive list of messages in
 the new cache —if it exists — instead of creating a new one!
 Otherwise you will have several reactive data for the same forum and
 the page updates will fail!
 
-To do that, we provide an optional argument {{{?default}}} to the function
-{{{Eliom.Shared.ReactiveData.RList.create}}}, a client value
+To do that, we provide an optional argument [?default] to the function
+[Eliom.Shared.ReactiveData.RList.create], a client value
 (optionally) containing the current reactive list. If it does not
 exist in the cache, a new one will be created like previously:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc get_data_forum (forumid : int) : _ Lwt.t =
   let%lwt messages = Db.get_messages forumid in
   let default = [%client
@@ -687,87 +719,94 @@ let%rpc get_data_forum (forumid : int) : _ Lwt.t =
      : 'a option)
   ] in
   Lwt.return (Eliom.Shared.ReactiveData.RList.create ~default messages)
->>
+]}
 
-{{{display_messages}}} now takes the reactive list from the cache:
-<<code language="ocaml" class="server"|
+[display_messages] now takes the reactive list from the cache:
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server display_messages forumid =
   Forum_notif.listen ();
   let%lwt rmessages =
     Eliom.Cscache.find forumcache get_data_forum forumid
   in
   ...
->>
+]}
 
-==== Notifications dependent on forum ID
+{3 Notifications dependent on forum ID}
 Since we now want to be specific about the data we want to listen to, the unit
 parameter we defined can't be used anymore. Indeed, notifications now depend on
 the identifier. We want to receive notifications only for the forums present in
-the client-side cache of forums. Therefore, we just change the type {{{key}}} of
-module {{{Forum_notif}}} to use an integer (instead of {{{unit}}}):
+the client-side cache of forums. Therefore, we just change the type [key] of
+module [Forum_notif] to use an integer (instead of [unit]):
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 [%%server
 module Forum_notif = Os.Notif.Make_Simple (struct
   type key = int
   type notification = int
 end)
 ]
->>
+]}
 
-The function {{{Forum_notif.notify}}} used in the function {{{add_message}}}
-now takes the {{{forumid}}} parameter.
+The function [Forum_notif.notify] used in the function [add_message]
+now takes the [forumid] parameter.
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc add_message ... =
   ...
   Forum_notif.notify forumid id;
   ...
->>
+]}
 
-In the function {{{display_messages}}}, we need to take care of the
-{{{forumid}}} parameter and the type annotation of {{{client_ev}}}:
+In the function [display_messages], we need to take care of the
+[forumid] parameter and the type annotation of [client_ev]:
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server display_messages forumid =
   Forum_notif.listen (forumid : int);
   ...
   ~%(Forum_notif.client_ev () : (int * int) Eliom_react.Down.t))
   ...
->>
+]}
 
-We annotate the type of {{{forumid}}} in the call of the function {{{listen}}}
+We annotate the type of [forumid] in the call of the function [listen]
 to help the typing system.
 
-The function {{{handle_notif_message}}} now takes the reactive
-list {{{rmessage}}} from the cache, therefore we no longer need it as a
+The function [handle_notif_message] now takes the reactive
+list [rmessage] from the cache, therefore we no longer need it as a
 parameter:
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client handle_notif_message_list (forumid, msgid) =
   try
     let rmessages = Eliom.Cscache.find_if_ready ~%forumcache forumid in
     Eliom.Shared.ReactiveData.RList.cons msgid (snd rmessages)
   with Not_found | Eliom.Cscache.Not_ready -> ()
->>
+]}
 
-In the function {{{display_messages}}}, do not forget to remove the injection
-of {{{rmessage}}} in the call of {{{handle_notif_message_list}}} in the client
+In the function [display_messages], do not forget to remove the injection
+of [rmessage] in the call of [handle_notif_message_list] in the client
 section:
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 ...
 (React.E.map handle_notif_message_list
 ...
->>
+]}
 
-=== Display a spinner while loading the messages
+{2 Display a spinner while loading the messages}
 
 Retrieving messages from server can take time.
 To display a spinner while loading the messages when you send them, replace
-the function {{{display_message}}} by:
+the function [display_message] by:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%shared display_message id =
   let th =
     let%lwt msg = Eliom.Cscache.find ~%cache get_data id in
@@ -775,29 +814,32 @@ let%shared display_message id =
   in
   let%lwt v = Ot.Spinner.with_spinner th in
   Lwt.return (li [v])
->>
+]}
 
-To simulate network latency, you can add a {{{Lwt_unix.sleep}}} in the
-server-side {{{get_data}}} function.
+To simulate network latency, you can add a [Lwt_unix.sleep] in the
+server-side [get_data] function.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server get_data id =
   let%lwt () = Lwt_unix.sleep 2.0 in
   Db.get_message id
->>
+]}
 
 
 
-== The full code ({{{tutoreact_messages.eliom}}}):
+{1 The full code ([tutoreact_messages.eliom]):}
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 [%%shared
     open Eliom.Content.Html
     open Eliom.Content.Html.D
 ]
->>
+]}
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 [%%server
 module Db = struct
   let db = Ocsipersist.Polymorphic.open_table "messages"
@@ -837,22 +879,25 @@ module Forum_notif = Os.Notif.Make_Simple (struct
   type notification = int
 end)
 ]
->>
+]}
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 [%%shared
     type add_message_type = int * string [@@deriving json]
 ]
->>
+]}
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc add_message ((forumid, value) : add_message_type) : unit Lwt.t =
    let%lwt id = Db.add_message forumid value in
    Forum_notif.notify forumid (id : int);
    Lwt.return ()
->>
+]}
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server cache : (int, string) Eliom.Cscache.t = Eliom.Cscache.create ()
 
 let%server forumcache :
@@ -860,15 +905,17 @@ let%server forumcache :
    int Eliom.Shared.ReactiveData.RList.t *
    int Eliom.Shared.ReactiveData.RList.handle) Eliom.Cscache.t =
   Eliom.Cscache.create ()
->>
+]}
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 ler%rpc get_data (id : int) : string Lwt.t =
   let%lwt () = Lwt_unix.sleep 2.0 in
   Db.get_message id
->>
+]}
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%rpc get_data_forum (forumid : int) : _ Lwt.t =
   let%lwt messages = Db.get_messages forumid in
   let default = [%client
@@ -879,9 +926,10 @@ let%rpc get_data_forum (forumid : int) : _ Lwt.t =
        : 'a option)
   ] in
   Lwt.return (Eliom.Shared.ReactiveData.RList.create ~default messages)
->>
+]}
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%shared display_message id =
   let th =
     let%lwt msg = Eliom.Cscache.find ~%cache get_data id in
@@ -889,17 +937,19 @@ let%shared display_message id =
   in
   let%lwt v = Ot.Spinner.with_spinner th in
   Lwt.return (li [v])
->>
+]}
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client handle_notif_message_list (forumid, msgid) =
   try
     let rmessages = Eliom.Cscache.find_if_ready ~%forumcache forumid in
     Eliom.Shared.ReactiveData.RList.cons msgid (snd rmessages)
   with Not_found | Eliom.Cscache.Not_ready -> ()
->>
+]}
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server display_messages forumid =
   Forum_notif.listen (forumid : int);
   let%lwt rmessages =
@@ -942,4 +992,4 @@ let%server display userid_o forumid =
         [inp]
   in
   Lwt.return (messages :: l)
->>
+]}
diff --git a/tutos/dev/manual/tutowidgets.wiki b/tutos/dev/manual/tutowidgets.mld
similarity index 69%
rename from tutos/dev/manual/tutowidgets.wiki
rename to tutos/dev/manual/tutowidgets.mld
index a0154cac..eb1d2b9c 100644
--- a/tutos/dev/manual/tutowidgets.wiki
+++ b/tutos/dev/manual/tutowidgets.mld
@@ -1,4 +1,4 @@
-= Mini-tutorial: client-server widgets =
+{0 Mini-tutorial: client-server widgets}
 
 This short tutorial is an example of client-server Eliom application.
 It gives an example of client-server widgets.
@@ -7,7 +7,7 @@ It is probably a good starting point if you know OCaml well, and want
 to quickly learn how to write a client-server Eliom application with a
 short example and concise explanations.  For more detailed explanations, see
 the
-<<a_manual project="tuto" chapter="application"|"graffiti" tutorial>>,
+{{:../tuto/application.html}"graffiti" tutorial},
 or read the manuals.
 
 The goal is to show that, unlike many JavaScript libraries that build
@@ -26,26 +26,27 @@ content. Furthermore, it is possible to group some of the boxes
 together to make them behave like radio buttons: when you open one of
 them, the previously opened one is closed.
 
-@@class="screenshot"@@{{files/tutorial/tutowidgets/ex-final.png|screenshot}}
+{%wodoc:@ class="screenshot"%}{%wodoc:img src="files/tutorial/tutowidgets/ex-final.png" alt="screenshot"%}
 
-<<outline| <<header| **Table of contents** >> >>
 
-== First step: define an application with a basic service ==
+
+{1 First step: define an application with a basic service}
 
 The following code defines a client-server Web application with only
-one service, registered at URL {{{/}}} (the root of the website).
+one service, registered at URL [/] (the root of the website).
 
-The code also defines a client-side application ({{{let%client}}} or section
-{{{ [%%client ... ] }}})
+The code also defines a client-side application ([let%client] or section
+[[%%client ... ]])
 that appends a client-side generated widget to the page.
-Section {{{ [%%shared ... ] }}} is compiled on both the server and the
+Section [[%%shared ... ]] is compiled on both the server and the
 client-side programs.
-Inside such a section, you can write {{{ let%server }}} or
-{{{ let%client }}} to override {{{ [%%shared ... ] }}}
+Inside such a section, you can write [let%server] or
+[let%client] to override [[%%shared ... ]]
 and define a server-only or client-only value (similarly for
-{{{ [%%server ... ] }}} and {{{ [%%client ... ] }}}).
+[[%%server ... ]] and [[%%client ... ]]).
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 
 module%server Ex_app =
   Eliom.Registration.App (struct
@@ -62,8 +63,9 @@ let%server _ = Eliom.Content.Html.D.(
          (Eliom.Tools.D.html ~title:"tutowidgets" ~css:[["css"; "ex.css"]]
             (body [h2 [txt "Welcome to Ocsigen!"]])))
 )
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 
 let%client mywidget s1 s2 = Eliom.Content.Html.D.(
   let button  = div ~a:[a_class ["button"]] [txt s1] in
@@ -77,61 +79,62 @@ let%client _ =
     (Js_of_ocaml.Dom_html.document##.body)
     (Eliom.Content.Html.To_dom.of_element (mywidget "Click me" "Hello!"));
   Lwt.return ()
->>
+]}
 
 To compile it, first create a project by calling
 
-{{{
+{v
   eliom-distillery -name ex -template client-server.basic
-}}}
+v}
 
 The name of the project must match the name given to the functor
-{{{Eliom.Registration.App}}}.
+[Eliom.Registration.App].
 
-After you adapt the file {{{ex.eliom}}},
-you can compile by calling {{{make}}},
-and run the server by calling {{{make test.byte}}}.
+After you adapt the file [ex.eliom],
+you can compile by calling [make],
+and run the server by calling [make test.byte].
 Download the
-[[files/tutorial/tutowidgets/ex.css|CSS file]]
-and place it in directory {{{static/css}}}.
-Then open a browser window and go to URL {{{http://localhost:8080}}}.
+{{:files/tutorial/tutowidgets/ex.css}CSS file}
+and place it in directory [static/css].
+Then open a browser window and go to URL [http://localhost:8080].
 
-@@class="screenshot"@@{{files/tutorial/tutowidgets/ex1.png|screenshot}}
+{%wodoc:@ class="screenshot"%}{%wodoc:img src="files/tutorial/tutowidgets/ex1.png" alt="screenshot"%}
 
-=== More explanations
+{2 More explanations}
 
 This section gives very quick explanations on the rest of the program.
 For more detailed explanations, see the tutorial for the graffiti app
 or the manual of each of the projects.
 
-* The client side program is sent with the first page belonging to the
-  application (registered through module {{{Ex_app}}}).
-* The {{{##}}} is used to call a JS method from OCaml
-  and {{{##.}}} to access a JS object field
+- The client side program is sent with the first page belonging to the
+  application (registered through module [Ex_app]).
+- The [##] is used to call a JS method from OCaml
+  and [##.] to access a JS object field
   (See Js_of_ocaml's documentation:
-  <<a_api project="js_of_ocaml" subproject="js_of_ocaml-ppx" | module Ppx_js >>).
-* If there are several services in your application, the client-side
+  {!Ppx_js}).
+- If there are several services in your application, the client-side
   program will be sent only with the first page, and will not stop if
   you go to another page of the application.
-* {{{Lwt}}} is the concurrent library used to program threads on both
-  client and server sides. The syntax {{{let%lwt a = e1 in e2}}}
+- [Lwt] is the concurrent library used to program threads on both
+  client and server sides. The syntax [let%lwt a = e1 in e2]
   allows waiting (without blocking the rest of the program) for an Lwt
-  thread to terminate before continuing. {{{e2}}} must ben a Lwt
-  thread itself. {{{Lwt.return}}} enables creating an
+  thread to terminate before continuing. [e2] must ben a Lwt
+  thread itself. [Lwt.return] enables creating an
   already-terminated Lwt thread.
-* {{{Js_of_ocaml_lwt.Lwt_js_events}}} defines a convenient way to program
+- [Js_of_ocaml_lwt.Lwt_js_events] defines a convenient way to program
   interface events (mouse, keyboard, ...).
 
-{{{Js_of_ocaml_lwt.Lwt_js_events.onload}}} is a Lwt thread that waits until the page
+[Js_of_ocaml_lwt.Lwt_js_events.onload] is a Lwt thread that waits until the page
 is loaded. There are similar functions to wait for other events, e.g.,
 for a click on an element of the page, or for a key press.
 
-== Second step: bind the button ==
+{1 Second step: bind the button}
 
 To make the widget work, we must bind the click event.
-Replace function {{{mywidget}}} by the following lines:
+Replace function [mywidget] by the following lines:
 
-<<code language="ocaml" class="client"|
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client switch_visibility elt =
   let elt = Eliom.Content.Html.To_dom.of_element elt in
   if Js_of_ocaml.Js.to_bool (elt##.classList##contains (Js_of_ocaml.Js.string "hidden")) then
@@ -147,37 +150,38 @@ let%client mywidget s1 s2 = Eliom.Content.Html.D.(
       (fun _ _ -> switch_visibility content; Lwt.return ()));
   div ~a:[a_class ["mywidget"]] [button; content]
 )
->>
+]}
 
-* Once again, we use {{{Js_of_ocaml_lwt.Lwt_js_events}}}. Function {{{clicks}}} is
+- Once again, we use [Js_of_ocaml_lwt.Lwt_js_events]. Function [clicks] is
   used to bind a handler to clicks on a specific element.
-* Function {{{async}}} runs an {{{Lwt}}} thread asynchronously
+- Function [async] runs an [Lwt] thread asynchronously
   (without waiting for its result).
-* {{{Js_of_ocaml_lwt.Lwt_js_events.clicks elt f}}} calls function {{{f}}} for each
-  mouseclick on element {{{elt}}}.
-* {{{Eliom.Content.Html.To_dom.of_element}}}, {{{Js_of_ocaml.Js.string}}} and {{{Js_of_ocaml.Js.to_bool}}} are
+- [Js_of_ocaml_lwt.Lwt_js_events.clicks elt f] calls function [f] for each
+  mouseclick on element [elt].
+- [Eliom.Content.Html.To_dom.of_element], [Js_of_ocaml.Js.string] and [Js_of_ocaml.Js.to_bool] are
   conversion functions between OCaml values and JS values.
 
-== Third step: Generating the widget on server side ==
+{1 Third step: Generating the widget on server side}
 
 The following version of the program shows how to generate the widget
 on server side, before sending it to the client.
 
 The code is exactly the same, with the following modifications:
-* We place function {{{mywidget}}} in server section.
-* The portion of code that must be run on client side (binding the
-  click event) is written as a //client value//, inside
-  {{{ [%client (... : unit) ] }}}.
+- We place function [mywidget] in server section.
+- The portion of code that must be run on client side (binding the
+  click event) is written as a {e client value}, inside
+  [[%client (... : unit) ]].
   This code will be executed by the client-side program when it
   receives the page. Note that you must give the type (here
-  {{{unit}}}), as the type inference for client values is currently
+  [unit]), as the type inference for client values is currently
   very limited. The client section may refer to server side values,
-  using the {{{~%x}}} syntax. These values will be serialized and sent
+  using the [~%x] syntax. These values will be serialized and sent
   to the client automatically with the page.
-* We include the widget on the server side generated page instead of
+- We include the widget on the server side generated page instead of
   adding it to the page from client side.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 
 module%server Ex_app =
   Eliom.Registration.App (struct
@@ -185,8 +189,9 @@ module%server Ex_app =
     let global_data_path = None
   end)
 
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client switch_visibility elt =
   let elt = Eliom.Content.Html.To_dom.of_element elt in
   if Js_of_ocaml.Js.to_bool (elt##.classList##(contains (Js_of_ocaml.Js.string "hidden"))) then
@@ -194,8 +199,9 @@ let%client switch_visibility elt =
   else
     elt##.classList##add (Js_of_ocaml.Js.string "hidden")
 
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server mywidget s1 s2 = Eliom.Content.Html.D.(
   let button  = div ~a:[a_class ["button"]] [txt s1] in
   let content = div ~a:[a_class ["content"]] [txt s2] in
@@ -218,27 +224,29 @@ let%server _ = Eliom.Content.Html.D.(
             (body [h2 [txt "Welcome to Ocsigen!"];
                    mywidget "Click me" "Hello!"])))
 )
->>
+]}
 
-== Fourth step: widget usable either on client or server sides ==
+{1 Fourth step: widget usable either on client or server sides}
 
-If you make function {{{mywidget}}} //shared//, it will be available
+If you make function [mywidget] {e shared}, it will be available
 both on server and client sides:
 
-<<code language="ocaml" class="shared"|
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%shared mywidget s1 s2 =
   ...
->>
+]}
 
-@@class="screenshot"@@{{files/tutorial/tutowidgets/ex2.png|screenshot}}
+{%wodoc:@ class="screenshot"%}{%wodoc:img src="files/tutorial/tutowidgets/ex2.png" alt="screenshot"%}
 
 
-== Fifth step: close last window when opening a new one ==
+{1 Fifth step: close last window when opening a new one}
 
 To implement this, we record a client-side reference to a function for
 closing the currently opened window.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 
 module%server Ex_app =
   Eliom.Registration.App (struct
@@ -246,8 +254,9 @@ module%server Ex_app =
     let global_data_path = None
   end)
 
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client close_last = ref (fun () -> ())
 
 let%client switch_visibility elt =
@@ -257,8 +266,9 @@ let%client switch_visibility elt =
   else
     elt##.classList##add (Js_of_ocaml.Js.string "hidden")
 
->>
-<<code language="ocaml" class="shared"|
+]}
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%shared mywidget s1 s2 = Eliom.Content.Html.D.(
   let button  = div ~a:[a_class ["button"]] [txt s1] in
   let content = div ~a:[a_class ["content"]] [txt s2] in
@@ -274,8 +284,9 @@ let%shared mywidget s1 s2 = Eliom.Content.Html.D.(
   ] in
   div ~a:[a_class ["mywidget"]] [button; content]
 )
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server _ = Eliom.Content.Html.D.(
   Ex_app.create
     ~path:(Eliom.Service.Path [""])
@@ -297,18 +308,19 @@ let%server _ = Eliom.Content.Html.D.(
              mywidget "Click me" "server side"
            ])))
 )
->>
+]}
 
-== Last step: several sets of widgets ==
+{1 Last step: several sets of widgets}
 
 Now we want to enable several sets of widgets in the same page. A
 single reference no longer suffices. In the following version, the
 server-side program asks the client-side program to generate two
-different references, by calling function {{{new_set}}}. This function
-returns what we call a //client value//.  On server side, it is not
+different references, by calling function [new_set]. This function
+returns what we call a {e client value}.  On server side, it is not
 evaluated, and it has an abstract type.
 
-<<code language="ocaml" class="server"|
+{%wodoc:@ class=server%}
+{@ocaml[
 
 module%server Ex_app =
   Eliom.Registration.App (struct
@@ -318,8 +330,9 @@ module%server Ex_app =
 
 let%server new_set () = [%client ( ref (fun () -> ()) : (unit -> unit) ref)]
 
->>
-<<code language="ocaml" class="client"|
+]}
+{%wodoc:@ class=client%}
+{@ocaml[
 let%client switch_visibility elt =
   let elt = Eliom.Content.Html.To_dom.of_element elt in
   if Js_of_ocaml.Js.to_bool (elt##.classList##(contains (Js_of_ocaml.Js.string "hidden"))) then
@@ -327,8 +340,9 @@ let%client switch_visibility elt =
   else
     elt##.classList##add (Js_of_ocaml.Js.string "hidden")
 
->>
-<<code language="ocaml" class="shared"|
+]}
+{%wodoc:@ class=shared%}
+{@ocaml[
 let%shared mywidget set s1 s2 = Eliom.Content.Html.D.(
   let button  = div ~a:[a_class ["button"]] [txt s1] in
   let content = div ~a:[a_class ["content"; "hidden"]] [txt s2] in
@@ -344,8 +358,9 @@ let%shared mywidget set s1 s2 = Eliom.Content.Html.D.(
   div ~a:[a_class ["mywidget"]] [button; content]
 )
 
->>
-<<code language="ocaml" class="server"|
+]}
+{%wodoc:@ class=server%}
+{@ocaml[
 let%server _ = Eliom.Content.Html.D.(
   Ex_app.create
     ~path:(Eliom.Service.Path [""])
@@ -368,22 +383,21 @@ let%server _ = Eliom.Content.Html.D.(
              mywidget set2 "Click me" "server side"
            ])))
 )
->>
+]}
 
-@@class="screenshot"@@{{files/tutorial/tutowidgets/ex-final.png|screenshot}}
+{%wodoc:@ class="screenshot"%}{%wodoc:img src="files/tutorial/tutowidgets/ex-final.png" alt="screenshot"%}
 
 
-== And now? ==
+{1 And now?}
 
-===Calling server functions===
+{2 Calling server functions}
 An important feature missing from this tutorial is the ability
 to call server functions from the client-side program ("server functions").
 You can find a quick description of this
-in <<a_manual project="tuto" chapter="how-to-call-a-server-side-function-from-client-side"|this mini HOWTO>> or
-in <<a_manual project="eliom" chapter="clientserver-communication" fragment="rpc"|
-Eliom's manual>>.
+in {{:../tuto/how-to-call-a-server-side-function-from-client-side.html}this mini HOWTO} or
+in {{:../eliom/clientserver-communication.html#rpc}Eliom's manual}.
 
-===Services===
+{2 Services}
 
 For many applications, you will need several services. By default,
 client-side Eliom programs do not stop when you follow a link or send
@@ -392,11 +406,11 @@ music, animations, stateful applications~ ...)  with traditional Web
 interaction (links, forms, bookmarks, back button~ ...).  Eliom
 proposes several ways to identify services, either by the URL (and
 parameters), or by a session identifier (we call this kind of service
-a //coservice//). Eliom also allows creating new (co-)services
+a {e coservice}). Eliom also allows creating new (co-)services
 dynamically, for example coservices depending on previous interaction
 with a user. More information on the service identification mechanism
-in <<a_manual project="eliom" chapter="server-services"|Eliom's manual>>.
+in {{:../eliom/server-services.html}Eliom's manual}.
 
-===Sessions===
-Eliom also offers a rich session mechanism, with //scopes//
-(see <<a_manual project="eliom" chapter="server-state"|Eliom's manual>>).
+{2 Sessions}
+Eliom also offers a rich session mechanism, with {e scopes}
+(see {{:../eliom/server-state.html}Eliom's manual}).

From 4e3f2fc3534760284b39875a614c8feae2b71474 Mon Sep 17 00:00:00 2001
From: Vincent Balat <vincent.balat@vblt.org>
Date: Mon, 8 Jun 2026 21:52:04 +0200
Subject: [PATCH 2/2] manual: fix dead wiki: links to flattened sibling pages

The mld sources kept the old html_of_wiki 'wiki:manual/<page>'
abbreviation as the link URL, which 404'd. Point them at the sibling
<page>.html, matching the flattened wodoc layout.
---
 tutos/8.0/manual/application.mld               |  4 ++--
 tutos/8.0/manual/custom-conf.mld               |  2 +-
 .../how-does-a-page-s-source-code-look.mld     |  2 +-
 tutos/8.0/manual/how-to-add-a-div.mld          |  2 +-
 tutos/8.0/manual/how-to-add-a-list.mld         |  4 ++--
 ...w-to-add-a-select-or-other-form-element.mld |  2 +-
 .../how-to-make-hello-world-in-ocsigen.mld     |  8 ++++----
 ...es-or-other-attributes-to-html-elements.mld |  2 +-
 tutos/8.0/manual/how-to-write-forms.mld        |  2 +-
 .../how-to-write-titles-and-paragraphs.mld     |  2 +-
 tutos/8.0/manual/interaction.mld               |  4 ++--
 tutos/8.0/manual/intro.mld                     | 18 +++++++++---------
 tutos/8.0/manual/misc.mld                      |  2 +-
 tutos/dev/manual/application.mld               |  4 ++--
 tutos/dev/manual/custom-conf.mld               |  2 +-
 .../how-does-a-page-s-source-code-look.mld     |  2 +-
 tutos/dev/manual/how-to-add-a-div.mld          |  2 +-
 tutos/dev/manual/how-to-add-a-list.mld         |  4 ++--
 ...w-to-add-a-select-or-other-form-element.mld |  2 +-
 .../how-to-make-hello-world-in-ocsigen.mld     |  8 ++++----
 ...es-or-other-attributes-to-html-elements.mld |  2 +-
 tutos/dev/manual/how-to-write-forms.mld        |  2 +-
 .../how-to-write-titles-and-paragraphs.mld     |  2 +-
 tutos/dev/manual/interaction.mld               |  4 ++--
 tutos/dev/manual/intro.mld                     | 18 +++++++++---------
 tutos/dev/manual/misc.mld                      |  2 +-
 26 files changed, 54 insertions(+), 54 deletions(-)

diff --git a/tutos/8.0/manual/application.mld b/tutos/8.0/manual/application.mld
index d2c83151..366d21fd 100644
--- a/tutos/8.0/manual/application.mld
+++ b/tutos/8.0/manual/application.mld
@@ -1013,7 +1013,7 @@ You can then test your application ([make test.byte]).
   from server side, through module Eliom_shared.
 
   This basic program does not show the full power of reactive
-  programming, however. See {{:wiki:manual/tutoreact}this tutorial}
+  programming, however. See {{:tutoreact.html}this tutorial}
   for a better introduction to reactive programming with Eliom.
 
 {%wodoc:end%}
@@ -1169,4 +1169,4 @@ The first version of the program is now complete.
 
 If you want to continue learning client-server programming with Eliom
 and build your first application, we suggest to read
-{{:wiki:manual/start}the tutorial about Ocsigen Start}.
+{{:start.html}the tutorial about Ocsigen Start}.
diff --git a/tutos/8.0/manual/custom-conf.mld b/tutos/8.0/manual/custom-conf.mld
index 56e12642..3c774634 100644
--- a/tutos/8.0/manual/custom-conf.mld
+++ b/tutos/8.0/manual/custom-conf.mld
@@ -6,7 +6,7 @@ Custom configuration options{%wodoc:end%}
 It is not convenient to have to edit the code to change some
 configurations, like the location where are saved the favorite
 images in the Graffiti tutorial
-(see: {{:wiki:pictures}Saving favorite pictures}).
+(see: {{:pictures.html}Saving favorite pictures}).
 Fortunately Ocsigen provides a mechanism to extend its
 configuration file.
 
diff --git a/tutos/8.0/manual/how-does-a-page-s-source-code-look.mld b/tutos/8.0/manual/how-does-a-page-s-source-code-look.mld
index e1ac3868..f3342c4d 100644
--- a/tutos/8.0/manual/how-does-a-page-s-source-code-look.mld
+++ b/tutos/8.0/manual/how-does-a-page-s-source-code-look.mld
@@ -31,7 +31,7 @@ The path is a list of string corresponding to the url. Here, the list is empty b
 If, for example, the list is ["hello";"world"], the page will be accessed using the address:
 {[http://website.com/hello/world/]}
 
-More information about parameters: {{:wiki:manual/how-to-use-get-parameters-or-parameters-in-the-url}How to use GET parameters (parameters in the URL)?}
+More information about parameters: {{:how-to-use-get-parameters-or-parameters-in-the-url.html}How to use GET parameters (parameters in the URL)?}
 
 Now that our service has been declared, we associate to it an OCaml function that will generate the page. We call this {e service registration}. If the service belongs to the application, we use the registrations functions from module [Example] defined above.
 
diff --git a/tutos/8.0/manual/how-to-add-a-div.mld b/tutos/8.0/manual/how-to-add-a-div.mld
index e1d9ef6b..12da7b39 100644
--- a/tutos/8.0/manual/how-to-add-a-div.mld
+++ b/tutos/8.0/manual/how-to-add-a-div.mld
@@ -8,7 +8,7 @@ div ~a:[a_class ["firstclass"; "secondclass"]] [txt "Hello!"]
 (Details of available elements in type
 {!Html_types.flow5}).
 
-{b Optional parameter} for attributes "a" ({{:wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements}How to set and id, classes or other attributes to HTML elements?}).
+{b Optional parameter} for attributes "a" ({{:how-to-set-and-id-classes-or-other-attributes-to-html-elements.html}How to set and id, classes or other attributes to HTML elements?}).
 
 {2 Download full code}
 
diff --git a/tutos/8.0/manual/how-to-add-a-list.mld b/tutos/8.0/manual/how-to-add-a-list.mld
index 3154f369..2e070c1e 100644
--- a/tutos/8.0/manual/how-to-add-a-list.mld
+++ b/tutos/8.0/manual/how-to-add-a-list.mld
@@ -23,7 +23,7 @@
 
 {b Required parameter}: list containing {b li} elements ({{:../tyxml/api/Html_types#TYPEli_attrib}Details of li content}).
 
-{b Optional parameter} for attributes "a" ({{:wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements}How to set and id, classes or other attributes to HTML elements?}).
+{b Optional parameter} for attributes "a" ({{:how-to-set-and-id-classes-or-other-attributes-to-html-elements.html}How to set and id, classes or other attributes to HTML elements?}).
 
 {3 Definition list}
 
@@ -53,7 +53,7 @@ Details:
 - {{:../tyxml/api/Html_types#TYPEphrasing}dd content}
 - {{:../tyxml/api/Html_types#TYPEflow5}dt content}
 
-{b Optional parameter} for attributes "a" ({{:wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements}How to set and id, classes or other attributes to HTML elements?}).
+{b Optional parameter} for attributes "a" ({{:how-to-set-and-id-classes-or-other-attributes-to-html-elements.html}How to set and id, classes or other attributes to HTML elements?}).
 
 {2 Download full code}
 
diff --git a/tutos/8.0/manual/how-to-add-a-select-or-other-form-element.mld b/tutos/8.0/manual/how-to-add-a-select-or-other-form-element.mld
index 34924117..fd014d8e 100644
--- a/tutos/8.0/manual/how-to-add-a-select-or-other-form-element.mld
+++ b/tutos/8.0/manual/how-to-add-a-select-or-other-form-element.mld
@@ -35,7 +35,7 @@ Raw.select [option (txt "hello");
 
 {2 Links}
 
-- {{:wiki:manual/how-to-write-forms}How to write forms}
+- {{:how-to-write-forms.html}How to write forms}
 - {{:../eliom/server-links.html}Eliom forms and links}
 - API
   {!Eliom_content.Html.D.Form}
diff --git a/tutos/8.0/manual/how-to-make-hello-world-in-ocsigen.mld b/tutos/8.0/manual/how-to-make-hello-world-in-ocsigen.mld
index 78930bda..4b1339c1 100644
--- a/tutos/8.0/manual/how-to-make-hello-world-in-ocsigen.mld
+++ b/tutos/8.0/manual/how-to-make-hello-world-in-ocsigen.mld
@@ -37,13 +37,13 @@ let _ =
 {2 }
 
 - To {e understand} this code, have a look at
-{{:wiki:manual/how-does-a-page-s-source-code-look}How does a page's source code look?}
+{{:how-does-a-page-s-source-code-look.html}How does a page's source code look?}
 - Or directly continue by compiling this code:
-{{:wiki:manual/how-to-compile-my-ocsigen-pages}How to compile my Ocsigen pages?}
+{{:how-to-compile-my-ocsigen-pages.html}How to compile my Ocsigen pages?}
 
 
 
 {2 Links}
 
-- {{:wiki:manual/application}Tutorial to write a client/server application}
-- {{:wiki:manual/interaction}Tutorial to write a server side web site}
+- {{:application.html}Tutorial to write a client/server application}
+- {{:interaction.html}Tutorial to write a server side web site}
diff --git a/tutos/8.0/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.mld b/tutos/8.0/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.mld
index a3fbe1de..5da7351a 100644
--- a/tutos/8.0/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.mld
+++ b/tutos/8.0/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.mld
@@ -36,7 +36,7 @@ The style attribute specifies an inline style for an element. The style attribut
 
 Using this attribute to stylish elements is not a good practice.
 You should rather use
-{{:wiki:manual/how-to-add-css-stylesheet}an external CSS file}.
+{{:how-to-add-css-stylesheet.html}an external CSS file}.
 
 Its parameter is a string.
 {@ocaml[~a:[a_style "color: pink; padding: 10px;"]]}
diff --git a/tutos/8.0/manual/how-to-write-forms.mld b/tutos/8.0/manual/how-to-write-forms.mld
index 9440e907..0ac55120 100644
--- a/tutos/8.0/manual/how-to-write-forms.mld
+++ b/tutos/8.0/manual/how-to-write-forms.mld
@@ -107,4 +107,4 @@ using standard tyxml constructors.
 Use module {{:../eliom/api/server/Eliom_content.Html.D.Raw}Eliom_content.Html.D.Raw}.
 
 {2 Links}
-- {{:wiki:manual/how-to-add-a-select-or-other-form-element}How to write a select (or other form element)?}
+- {{:how-to-add-a-select-or-other-form-element.html}How to write a select (or other form element)?}
diff --git a/tutos/8.0/manual/how-to-write-titles-and-paragraphs.mld b/tutos/8.0/manual/how-to-write-titles-and-paragraphs.mld
index 151c2382..7bf08b4f 100644
--- a/tutos/8.0/manual/how-to-write-titles-and-paragraphs.mld
+++ b/tutos/8.0/manual/how-to-write-titles-and-paragraphs.mld
@@ -16,7 +16,7 @@ p [txt "Some text, blah blah blah"]
 
 {b Required parameter}: list containing other elements (content: {!Html_types.flow5} elements).
 
-{b Optional parameter} for attributes "a" ({{:wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements}How to set and id, classes or other attributes to HTML elements?}).
+{b Optional parameter} for attributes "a" ({{:how-to-set-and-id-classes-or-other-attributes-to-html-elements.html}How to set and id, classes or other attributes to HTML elements?}).
 
 {2 Download full code}
 
diff --git a/tutos/8.0/manual/interaction.mld b/tutos/8.0/manual/interaction.mld
index 26926714..94e2cb34 100644
--- a/tutos/8.0/manual/interaction.mld
+++ b/tutos/8.0/manual/interaction.mld
@@ -1257,5 +1257,5 @@ let () = Eliom_content.Html.D.(
 )
 ]}
 
-{{:wiki:manual/application}prev}
-{{:wiki:manual/misc}next}
+{{:application.html}prev}
+{{:misc.html}next}
diff --git a/tutos/8.0/manual/intro.mld b/tutos/8.0/manual/intro.mld
index 04a8f2a4..8831fc71 100644
--- a/tutos/8.0/manual/intro.mld
+++ b/tutos/8.0/manual/intro.mld
@@ -53,24 +53,24 @@ new programming techniques to become autonomous.
 Depending on your level and goals, we suggest to continue by reading
 some of the following chapters:
 
-- Chapter {{:wiki:manual/basics}Client-server application programming guide} can be used as your training plan.
+- Chapter {{:basics.html}Client-server application programming guide} can be used as your training plan.
 It provides a wide overview of each main concept, with links to more detailed
 documentation.
-- If you want to start with a server-side only Web site, read {{:wiki:manual/basics-server}Server-side website programming guide} instead.
+- If you want to start with a server-side only Web site, read {{:basics-server.html}Server-side website programming guide} instead.
 - Then, a good starting point is this
-{{:wiki:manual/start}Ocsigen Start tutorial},
+{{:start.html}Ocsigen Start tutorial},
 if you plan to build a client-server Web (and/or mobile) app.
 It will help you to build your first app very quickly,
 with many code samples to study.
 - If you are fluent in OCaml and want a quick introduction to
 client-server Web programming with Eliom,
 read tutorial
-{{:wiki:manual/tutowidgets}Eliom apps basics: writing client server widgets}.
+{{:tutowidgets.html}Eliom apps basics: writing client server widgets}.
 It illusrates the client-server syntax with an example,
 and is a good starting point for understanding Eliom's client-server features.
 - If you want a full step-by-step tutorial on how to write a client-server Web
 application, read tutorial
-{{:wiki:manual/application}Client-server application}.
+{{:application.html}Client-server application}.
 It describes step by step how to write a client/server
 {{:../graffiti/}collaborative drawing application}. You will learn,
 from the very beginning, how to:
@@ -82,10 +82,10 @@ from the very beginning, how to:
 - {e Communicate} with the server, in both directions
 - Create services with {e non-HTML output}
 - If you want to build mobile applications,
-read tutorial {{:wiki:manual/mobile}Mobile applications with Ocsigen}.
+read tutorial {{:mobile.html}Mobile applications with Ocsigen}.
 It describes how to build a mobile app (e.g., for Android)
 with the same codebase as for your Web application.
-- If you want to write a more traditional Web site, with pages, forms, and sessions, read tutorial {{:wiki:manual/interaction}Service based Web programming}.
+- If you want to write a more traditional Web site, with pages, forms, and sessions, read tutorial {{:interaction.html}Service based Web programming}.
 It is devoted to server side programming.
 It shows how to
 create a new Web site with several pages and user connections.
@@ -96,7 +96,7 @@ You will learn how to:
 - Create services performing {e actions} (with no output)
 - Dynamically register new services ({e continuation based} Web programming)
 - If you want to learn more details about Ocsigen
-read tutorial {{:wiki:manual/misc}Miscellaneous features}.
+read tutorial {{:misc.html}Miscellaneous features}.
 It will mix the client-server drawing application
 with the session mechanism and user management
 to produce a multi-user collaborative drawing
@@ -133,7 +133,7 @@ their {{:http://webchat.freenode.net/?channels=ocsigen}webchat})!
 
 
 Now, we recommend to read, chapter
-{{:wiki:manual/basics}All Ocsigen in one page}
+{{:basics.html}All Ocsigen in one page}
 for a wide and complete overview.
 
 
diff --git a/tutos/8.0/manual/misc.mld b/tutos/8.0/manual/misc.mld
index 7c0eb887..dcccbf79 100644
--- a/tutos/8.0/manual/misc.mld
+++ b/tutos/8.0/manual/misc.mld
@@ -521,4 +521,4 @@ to [disconnect_box]
        canvas;])
 ]}
 
-{{:wiki:manual/interaction}prev}
+{{:interaction.html}prev}
diff --git a/tutos/dev/manual/application.mld b/tutos/dev/manual/application.mld
index 89083b6e..4a603b8e 100644
--- a/tutos/dev/manual/application.mld
+++ b/tutos/dev/manual/application.mld
@@ -1013,7 +1013,7 @@ You can then test your application ([make test.byte]).
   from server side, through module Eliom.Shared.
 
   This basic program does not show the full power of reactive
-  programming, however. See {{:wiki:manual/tutoreact}this tutorial}
+  programming, however. See {{:tutoreact.html}this tutorial}
   for a better introduction to reactive programming with Eliom.
 
 {%wodoc:end%}
@@ -1169,4 +1169,4 @@ The first version of the program is now complete.
 
 If you want to continue learning client-server programming with Eliom
 and build your first application, we suggest to read
-{{:wiki:manual/start}the tutorial about Ocsigen Start}.
+{{:start.html}the tutorial about Ocsigen Start}.
diff --git a/tutos/dev/manual/custom-conf.mld b/tutos/dev/manual/custom-conf.mld
index 636ad9d0..128995fe 100644
--- a/tutos/dev/manual/custom-conf.mld
+++ b/tutos/dev/manual/custom-conf.mld
@@ -6,7 +6,7 @@ Custom configuration options{%wodoc:end%}
 It is not convenient to have to edit the code to change some
 configurations, like the location where are saved the favorite
 images in the Graffiti tutorial
-(see: {{:wiki:pictures}Saving favorite pictures}).
+(see: {{:pictures.html}Saving favorite pictures}).
 Fortunately Ocsigen provides a mechanism to extend its
 configuration file.
 
diff --git a/tutos/dev/manual/how-does-a-page-s-source-code-look.mld b/tutos/dev/manual/how-does-a-page-s-source-code-look.mld
index 8674a2f7..66a07798 100644
--- a/tutos/dev/manual/how-does-a-page-s-source-code-look.mld
+++ b/tutos/dev/manual/how-does-a-page-s-source-code-look.mld
@@ -31,7 +31,7 @@ The path is a list of string corresponding to the url. Here, the list is empty b
 If, for example, the list is ["hello";"world"], the page will be accessed using the address:
 {[http://website.com/hello/world/]}
 
-More information about parameters: {{:wiki:manual/how-to-use-get-parameters-or-parameters-in-the-url}How to use GET parameters (parameters in the URL)?}
+More information about parameters: {{:how-to-use-get-parameters-or-parameters-in-the-url.html}How to use GET parameters (parameters in the URL)?}
 
 Now that our service has been declared, we associate to it an OCaml function that will generate the page. We call this {e service registration}. If the service belongs to the application, we use the registrations functions from module [Example] defined above.
 
diff --git a/tutos/dev/manual/how-to-add-a-div.mld b/tutos/dev/manual/how-to-add-a-div.mld
index bb28a08b..27192496 100644
--- a/tutos/dev/manual/how-to-add-a-div.mld
+++ b/tutos/dev/manual/how-to-add-a-div.mld
@@ -8,7 +8,7 @@ div ~a:[a_class ["firstclass"; "secondclass"]] [txt "Hello!"]
 (Details of available elements in type
 {!Html_types.flow5}).
 
-{b Optional parameter} for attributes "a" ({{:wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements}How to set and id, classes or other attributes to HTML elements?}).
+{b Optional parameter} for attributes "a" ({{:how-to-set-and-id-classes-or-other-attributes-to-html-elements.html}How to set and id, classes or other attributes to HTML elements?}).
 
 {2 Download full code}
 
diff --git a/tutos/dev/manual/how-to-add-a-list.mld b/tutos/dev/manual/how-to-add-a-list.mld
index f20e65d7..4761de3b 100644
--- a/tutos/dev/manual/how-to-add-a-list.mld
+++ b/tutos/dev/manual/how-to-add-a-list.mld
@@ -23,7 +23,7 @@
 
 {b Required parameter}: list containing {b li} elements ({{:../tyxml/api/Html_types#TYPEli_attrib}Details of li content}).
 
-{b Optional parameter} for attributes "a" ({{:wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements}How to set and id, classes or other attributes to HTML elements?}).
+{b Optional parameter} for attributes "a" ({{:how-to-set-and-id-classes-or-other-attributes-to-html-elements.html}How to set and id, classes or other attributes to HTML elements?}).
 
 {3 Definition list}
 
@@ -53,7 +53,7 @@ Details:
 - {{:../tyxml/api/Html_types#TYPEphrasing}dd content}
 - {{:../tyxml/api/Html_types#TYPEflow5}dt content}
 
-{b Optional parameter} for attributes "a" ({{:wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements}How to set and id, classes or other attributes to HTML elements?}).
+{b Optional parameter} for attributes "a" ({{:how-to-set-and-id-classes-or-other-attributes-to-html-elements.html}How to set and id, classes or other attributes to HTML elements?}).
 
 {2 Download full code}
 
diff --git a/tutos/dev/manual/how-to-add-a-select-or-other-form-element.mld b/tutos/dev/manual/how-to-add-a-select-or-other-form-element.mld
index f05e7b8c..d4bfe5a3 100644
--- a/tutos/dev/manual/how-to-add-a-select-or-other-form-element.mld
+++ b/tutos/dev/manual/how-to-add-a-select-or-other-form-element.mld
@@ -35,7 +35,7 @@ Raw.select [option (txt "hello");
 
 {2 Links}
 
-- {{:wiki:manual/how-to-write-forms}How to write forms}
+- {{:how-to-write-forms.html}How to write forms}
 - {{:../eliom/server-links.html}Eliom forms and links}
 - API
   {!Eliom.Content.Html.D.Form}
diff --git a/tutos/dev/manual/how-to-make-hello-world-in-ocsigen.mld b/tutos/dev/manual/how-to-make-hello-world-in-ocsigen.mld
index 89b3d3f3..c0adc196 100644
--- a/tutos/dev/manual/how-to-make-hello-world-in-ocsigen.mld
+++ b/tutos/dev/manual/how-to-make-hello-world-in-ocsigen.mld
@@ -37,13 +37,13 @@ let _ =
 {2 }
 
 - To {e understand} this code, have a look at
-{{:wiki:manual/how-does-a-page-s-source-code-look}How does a page's source code look?}
+{{:how-does-a-page-s-source-code-look.html}How does a page's source code look?}
 - Or directly continue by compiling this code:
-{{:wiki:manual/how-to-compile-my-ocsigen-pages}How to compile my Ocsigen pages?}
+{{:how-to-compile-my-ocsigen-pages.html}How to compile my Ocsigen pages?}
 
 
 
 {2 Links}
 
-- {{:wiki:manual/application}Tutorial to write a client/server application}
-- {{:wiki:manual/interaction}Tutorial to write a server side web site}
+- {{:application.html}Tutorial to write a client/server application}
+- {{:interaction.html}Tutorial to write a server side web site}
diff --git a/tutos/dev/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.mld b/tutos/dev/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.mld
index a3fbe1de..5da7351a 100644
--- a/tutos/dev/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.mld
+++ b/tutos/dev/manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements.mld
@@ -36,7 +36,7 @@ The style attribute specifies an inline style for an element. The style attribut
 
 Using this attribute to stylish elements is not a good practice.
 You should rather use
-{{:wiki:manual/how-to-add-css-stylesheet}an external CSS file}.
+{{:how-to-add-css-stylesheet.html}an external CSS file}.
 
 Its parameter is a string.
 {@ocaml[~a:[a_style "color: pink; padding: 10px;"]]}
diff --git a/tutos/dev/manual/how-to-write-forms.mld b/tutos/dev/manual/how-to-write-forms.mld
index 7ac8eb2d..b7152277 100644
--- a/tutos/dev/manual/how-to-write-forms.mld
+++ b/tutos/dev/manual/how-to-write-forms.mld
@@ -107,4 +107,4 @@ using standard tyxml constructors.
 Use module {{:../eliom/api/server/Eliom.Content.Html.D.Raw}Eliom.Content.Html.D.Raw}.
 
 {2 Links}
-- {{:wiki:manual/how-to-add-a-select-or-other-form-element}How to write a select (or other form element)?}
+- {{:how-to-add-a-select-or-other-form-element.html}How to write a select (or other form element)?}
diff --git a/tutos/dev/manual/how-to-write-titles-and-paragraphs.mld b/tutos/dev/manual/how-to-write-titles-and-paragraphs.mld
index 817e109e..adce9db2 100644
--- a/tutos/dev/manual/how-to-write-titles-and-paragraphs.mld
+++ b/tutos/dev/manual/how-to-write-titles-and-paragraphs.mld
@@ -16,7 +16,7 @@ p [txt "Some text, blah blah blah"]
 
 {b Required parameter}: list containing other elements (content: {!Html_types.flow5} elements).
 
-{b Optional parameter} for attributes "a" ({{:wiki:manual/how-to-set-and-id-classes-or-other-attributes-to-html-elements}How to set and id, classes or other attributes to HTML elements?}).
+{b Optional parameter} for attributes "a" ({{:how-to-set-and-id-classes-or-other-attributes-to-html-elements.html}How to set and id, classes or other attributes to HTML elements?}).
 
 {2 Download full code}
 
diff --git a/tutos/dev/manual/interaction.mld b/tutos/dev/manual/interaction.mld
index 64522d54..c2c48c15 100644
--- a/tutos/dev/manual/interaction.mld
+++ b/tutos/dev/manual/interaction.mld
@@ -1257,5 +1257,5 @@ let () = Eliom.Content.Html.D.(
 )
 ]}
 
-{{:wiki:manual/application}prev}
-{{:wiki:manual/misc}next}
+{{:application.html}prev}
+{{:misc.html}next}
diff --git a/tutos/dev/manual/intro.mld b/tutos/dev/manual/intro.mld
index 04a8f2a4..8831fc71 100644
--- a/tutos/dev/manual/intro.mld
+++ b/tutos/dev/manual/intro.mld
@@ -53,24 +53,24 @@ new programming techniques to become autonomous.
 Depending on your level and goals, we suggest to continue by reading
 some of the following chapters:
 
-- Chapter {{:wiki:manual/basics}Client-server application programming guide} can be used as your training plan.
+- Chapter {{:basics.html}Client-server application programming guide} can be used as your training plan.
 It provides a wide overview of each main concept, with links to more detailed
 documentation.
-- If you want to start with a server-side only Web site, read {{:wiki:manual/basics-server}Server-side website programming guide} instead.
+- If you want to start with a server-side only Web site, read {{:basics-server.html}Server-side website programming guide} instead.
 - Then, a good starting point is this
-{{:wiki:manual/start}Ocsigen Start tutorial},
+{{:start.html}Ocsigen Start tutorial},
 if you plan to build a client-server Web (and/or mobile) app.
 It will help you to build your first app very quickly,
 with many code samples to study.
 - If you are fluent in OCaml and want a quick introduction to
 client-server Web programming with Eliom,
 read tutorial
-{{:wiki:manual/tutowidgets}Eliom apps basics: writing client server widgets}.
+{{:tutowidgets.html}Eliom apps basics: writing client server widgets}.
 It illusrates the client-server syntax with an example,
 and is a good starting point for understanding Eliom's client-server features.
 - If you want a full step-by-step tutorial on how to write a client-server Web
 application, read tutorial
-{{:wiki:manual/application}Client-server application}.
+{{:application.html}Client-server application}.
 It describes step by step how to write a client/server
 {{:../graffiti/}collaborative drawing application}. You will learn,
 from the very beginning, how to:
@@ -82,10 +82,10 @@ from the very beginning, how to:
 - {e Communicate} with the server, in both directions
 - Create services with {e non-HTML output}
 - If you want to build mobile applications,
-read tutorial {{:wiki:manual/mobile}Mobile applications with Ocsigen}.
+read tutorial {{:mobile.html}Mobile applications with Ocsigen}.
 It describes how to build a mobile app (e.g., for Android)
 with the same codebase as for your Web application.
-- If you want to write a more traditional Web site, with pages, forms, and sessions, read tutorial {{:wiki:manual/interaction}Service based Web programming}.
+- If you want to write a more traditional Web site, with pages, forms, and sessions, read tutorial {{:interaction.html}Service based Web programming}.
 It is devoted to server side programming.
 It shows how to
 create a new Web site with several pages and user connections.
@@ -96,7 +96,7 @@ You will learn how to:
 - Create services performing {e actions} (with no output)
 - Dynamically register new services ({e continuation based} Web programming)
 - If you want to learn more details about Ocsigen
-read tutorial {{:wiki:manual/misc}Miscellaneous features}.
+read tutorial {{:misc.html}Miscellaneous features}.
 It will mix the client-server drawing application
 with the session mechanism and user management
 to produce a multi-user collaborative drawing
@@ -133,7 +133,7 @@ their {{:http://webchat.freenode.net/?channels=ocsigen}webchat})!
 
 
 Now, we recommend to read, chapter
-{{:wiki:manual/basics}All Ocsigen in one page}
+{{:basics.html}All Ocsigen in one page}
 for a wide and complete overview.
 
 
diff --git a/tutos/dev/manual/misc.mld b/tutos/dev/manual/misc.mld
index 31598bbe..1771e2f0 100644
--- a/tutos/dev/manual/misc.mld
+++ b/tutos/dev/manual/misc.mld
@@ -521,4 +521,4 @@ to [disconnect_box]
        canvas;])
 ]}
 
-{{:wiki:manual/interaction}prev}
+{{:interaction.html}prev}