diff --git a/docs/XCB_Cheatsheet.md b/docs/XCB_Cheatsheet.md
index abbc7e4..50f5344 100644
--- a/docs/XCB_Cheatsheet.md
+++ b/docs/XCB_Cheatsheet.md
@@ -16,9 +16,9 @@ string predates the URL standard.
 
 Part of the problem with untangling the hierarchy in X-Windows is that
 it's meant to be extremely malleable and re-usable.  [The Wikipedia
-article](https://en.wikipedia.org/wiki/X_Window_System_protocols_and_architecture)
+article](/uri https://en.wikipedia.org/wiki/X_Window_System_protocols_and_architecture)
 says that the `display` has a top-level window; The [Xlib
-Tutorial](https://tronche.com/gui/x/xlib/introduction/overview.html)
+Tutorial](/uri https://tronche.com/gui/x/xlib/introduction/overview.html)
 says a `screen` is a physical monitor, and a workstation can have more
 than one screen, but each screen has its own top-level window. But
 both of these statements are inaccurate!
@@ -39,10 +39,10 @@ them, assigning `crtc` devices to each `output`, and choosing a
 default set-up that will support running your
 instance of GTK or KDE or whatever.
 
-<aside>You kids have it easy.  Before the existence of modern,
-self-describing hardware, we had to hand-enter every single one of
-these details, and if you got a detail wrong it was possible to burn
-out your video card or monitor!</aside>
+> ASIDE: You kids have it easy.  Before the existence of modern,
+> self-describing hardware, we had to hand-enter every single one of
+> these details, and if you got a detail wrong it was possible to burn
+> out your video card or monitor!
 
 For example, in a two-monitor set up X will have a single `screen`
 with a single root `window` spanning both monitors, but there would be
@@ -63,21 +63,21 @@ currently tracking to the new orientation.  Most modern window
 managers are pretty good about re-arranging the screen to manage this
 change!
 
-<aside>It makes no sense for a virtualized `output` device, one which
-has no actual display visible to the human eye, to have a `crtc`.
-It's orientation doesn't matter.  If it ever _is_ displayed to a human
-being it will be in a virtualizing environment such as
-[Xephyr](https://en.wikipedia.org/wiki/Xephyr), in which case it will
-be getting its `crtc` information from the host **X** display.</aside>
-
-<aside>I'm still not sure how all this interacts with a window manager
-that has 'workspaces', such as Gnome-Mate.  Which means I could be
-entirely wrong about this whole thing! On the other hand, it could be
-as simple as every workspace having it's own pseudo-root-window, and
-being dependent upon the `crtc` object for screen dimensions and pixel
-mapping. [I have to read this
-carefully](https://jichu4n.com/posts/how-x-window-managers-work-and-how-to-write-one-part-i/).</aside>
+> ASIDE: It makes no sense for a virtualized `output` device, one which
+> has no actual display visible to the human eye, to have a `crtc`.
+> It's orientation doesn't matter.  If it ever _is_ displayed to a human
+> being it will be in a virtualizing environment such as
+> [Xephyr](/uri https://en.wikipedia.org/wiki/Xephyr), in which case it will
+> be getting its `crtc` information from the host **X** display.</aside>
 
+> ASIDE: I'm still not sure how all this interacts with a window manager
+> that has 'workspaces', such as Gnome-Mate.  Which means I could be
+> entirely wrong about this whole thing! On the other hand, it could be
+> as simple as every workspace having it's own pseudo-root-window, and
+> being dependent upon the `crtc` object for screen dimensions and pixel
+> mapping. [I have to read this
+> carefully](/uri https://jichu4n.com/posts/how-x-window-managers-work-and-how-to-write-one-part-i/).</aside>
+> 
 TODO: I haven't yet figured out the bit about remapping the tablet's
 touchscreen inputs, so that when you place your finger or stylus on
 the screen **X** maps the pointer location to the right place.