doc: Fix formatting

Replace tabs with spaces, and use proper Markdown verbatim syntax.

Mark the JSON and CSS code blocks as such for proper syntax highlighting
and inline editor validation, and fix the various comma and quoting
errors.

doc/anaconda.md

@@ -26,7 +26,7 @@ Anaconda needs to tell Cockpit which devices can be used to install
 the OS on. This is done with the "available_devices" entry, which is
 an array of strings.
 
-```
+```json
 {
   "available_devices": [ "/dev/sda" ]
 }
@@ -42,7 +42,7 @@ Mount point prefix
 Cockpit can be put into a kind of "chroot" environment by giving it a
 mount point prefix like so:
 
-```
+```json
 {
   "mount_point_prefix": "/sysroot"
 }
@@ -68,7 +68,7 @@ created easily.
 
 This is done by setting the "efi" flag to true or false:
 
-```
+```json
 {
   "efi": true
 }
@@ -83,7 +83,7 @@ back to the type of the filesystem mounted as "/". When in Anaconda
 mode, there might not be anything assigned to "/" yet, and in this
 case, Cockpit will use the type from "default_fsys_type".
 
-```
+```json
 {
   "default_fsys_type": "xfs"
 }
@@ -99,11 +99,11 @@ is mostly information from fstab.
 The "cockpit_mount_points" entry in local storage will have a JSON
 encoded object, for example:
 
-```
+```json
 {
   "/dev/sda": {
     "type": "filesystem",
-    "dir": "/",
+    "dir": "/"
   },
   "/dev/sdb": {
     "type": "swap"
@@ -113,7 +113,7 @@ encoded object, for example:
     "content": {
       "type": "filesystem",
       "subvolumes": {
-        "home": { dir: "/home" }
+        "home": { "dir": "/home" }
       }
     }
   }
@@ -160,5 +160,4 @@ Cockpit also remembers and exports encryption passphrases in session
 storage, in the "cockpit_passphrases" entry. This is a map from device
 names to cleartext passphrases. This is only done when Cockpit runs in
 a "secure context", see
-
-    https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts
+https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts

doc/branding.md

@@ -10,7 +10,7 @@ system itself, and are incorporated into the branding.
 
 ## How Cockpit Selects Branding
 
-In ```$prefix/share/cockpit/branding``` are multiple directories, each of which
+In `$prefix/share/cockpit/branding` are multiple directories, each of which
 contain branding information. Branding files are served from the directories
 based in the order below, if a file is not present in the first directory on
 the list, the second will be consulted, and so on.
@@ -20,8 +20,8 @@ the list, the second will be consulted, and so on.
     $prefix/share/cockpit/branding/default
     $prefix/share/cockpit/static
 
-The ```$ID``` and ```$VARIANT_ID``` variables are those listed in ```/etc/os-release```,
-and ```$prefix``` is usually ```/usr```.
+The `$ID` and `$VARIANT_ID` variables are those listed in `/etc/os-release`,
+and `$prefix` is usually `/usr`.
 
 All of the files served from these directories are available over HTTP
 without authentication. This is required since these resources will be used
@@ -43,32 +43,34 @@ on the system.
 
 ## Branding Styles
 
-The Cockpit login screen and navigation area loads a ```branding.css``` file
+The Cockpit login screen and navigation area loads a `branding.css` file
 from the above directories.
 
 The branding.css file should override the following areas of the login screen:
 
-    /* Background of the login prompt */
-    body.login-pf {
-        background: url("my-background-image.jpg");
-        background-size: cover;
-    }
-
-    /* Upper right logo of login screen */
-    #badge {
-        width: 225px;
-        height: 80px;
-        background-image: url("logo.png");
-        background-size: contain;
-        background-repeat: no-repeat;
-    }
-
-    /* The brand text above the login fields */
-    #brand {
-        font-size: 18pt;
-        text-transform: uppercase;
-        content: "${NAME} <b>${VARIANT}</b>";
-    }
-
-Notice how we can use variables from ```/etc/os-release``` in the branding.
+```css
+/* Background of the login prompt */
+body.login-pf {
+    background: url("my-background-image.jpg");
+    background-size: cover;
+}
+
+/* Upper right logo of login screen */
+#badge {
+    width: 225px;
+    height: 80px;
+    background-image: url("logo.png");
+    background-size: contain;
+    background-repeat: no-repeat;
+}
+
+/* The brand text above the login fields */
+#brand {
+    font-size: 18pt;
+    text-transform: uppercase;
+    content: "${NAME} <b>${VARIANT}</b>";
+}
+```
+
+Notice how we can use variables from `/etc/os-release` in the branding.
 The value for these variables come from the machine that cockpit is logged into.

doc/login.md

@@ -10,12 +10,12 @@ header is built like this.
 Basic base64(user:password)
 ```
 
-A successful response is a 200 http code with a json body that contains a ```user``` field with the user
+A successful response is a 200 http code with a json body that contains a `user` field with the user
 name of the user that was just logged in. Additional fields may be present
 
 Other http codes are considered errors. Generally these are 401 or 403 http status codes.
 In most cases the error can detrived from the status text. Examples are
- ```authentication-failed```, ```authentication-unavailable``` or ```access-denied```
+`authentication-failed`, `authentication-unavailable` or `access-denied`
  In some cases additional error messages may be included.
 
 In some authentication setups additional steps are required. When this happens cockpit will