--- a/devtools/server/docs/actor-hierarchy.md
+++ b/devtools/server/docs/actor-hierarchy.md
@@ -2,17 +2,18 @@
 
 To start with, actors are living within /devtools/server/actors/ folder.
 They are organized in a hierarchy for easier lifecycle/memory management:
 once a parent is removed from the pool, its children are removed as well.
 (See actor-registration.md for more information about how to implement one)
 
 The overall hierarchy of actors looks like this:
 
-  RootActor: First one, automatically instantiated when we start connecting.
+```
+RootActor: First one, automatically instantiated when we start connecting.
    |         Mostly meant to instantiate new actors.
    |
    |--> Global-scoped actors:
    |    Actors exposing features related to the main process,
    |    that are not specific to any particular context (document, tab, app,
    |    add-on, or worker).
    |    A good example is the preference actor.
    |
@@ -22,26 +23,28 @@ The overall hierarchy of actors looks li
           |    one of these for each thing you can point a toolbox at.
           |
           \--> Tab-scoped actors:
                Actors exposing one particular feature set, this time,
                specific to a given context (document, tab, app, add-on, or
                worker).  Examples include the console and inspector actors.
                These actors may extend this hierarchy by having their
                own children, like LongStringActor, WalkerActor, etc.
+```
 
 ## RootActor
 
 The root actor is special. It is automatically created when a client connects.
 It has a special `actorID` which is unique and is "root".
 All other actors have an `actorID` which is computed dynamically,
 so that you need to ask an existing actor to create an Actor
 and returns its `actorID`. That's the main role of RootActor.
 
-  RootActor (root.js)
+```
+RootActor (root.js)
    |
    |-- BrowserTabActor (webbrowser.js)
    |   Targets tabs living in the parent or child process. Note that this is
    |   just a proxy for ContentActor, which is loaded via the tab's message
    |   manager as a frame script in the process containing the tab. This proxy
    |   via message manager is always used, even when e10s is disabled.
    |   Returned by "listTabs" or "getTab" requests.
    |   |
@@ -73,16 +76,17 @@ and returns its `actorID`. That's the ma
    |-- ChildProcessActor (child-process.js)
    |   Targets the chrome of the child process (e10s).
    |   Returned by "getProcess" request with a id argument,
    |   matching the targeted process.
    |
    \-- BrowserAddonActor (addon.js)
        Targets the javascript of add-ons.
        Returned by "listAddons" request.
+```
 
 ## "TabActor"
 
 Those are the actors exposed by the root actors which are meant to track the
 lifetime of a given context: tab, app, process, add-on, or worker. It also
 allows to fetch the tab-scoped actors connected to this context. Actors like
 console, inspector, thread (for debugger), styleinspector, etc. Most of them
 inherit from TabActor (defined in tab.js) which is document centric. It