From c5acea75aabb9f8238a35b53ac23f1bdb0c51f07 Mon Sep 17 00:00:00 2001
From: Kevin Decker <kpdecker@gmail.com>
Date: Mon, 25 Aug 2014 23:37:40 -0500
Subject: [PATCH] Update FAQ.md

---
 FAQ.md | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/FAQ.md b/FAQ.md
index 3b1cbd80..0bd0997d 100644
--- a/FAQ.md
+++ b/FAQ.md
@@ -1,18 +1,23 @@
 # Frequently Asked Questions
 
 1. How can I file a bug report:
+
   See our guidelines on [reporting issues](https://github.com/wycats/handlebars.js/blob/master/CONTRIBUTING.md#reporting-issues).
 
 1. Why isn't my Mustache template working?
+
   Handlebars deviates from Mustache slightly on a few behaviors. These variations are documented in our [readme](https://github.com/wycats/handlebars.js#differences-between-handlebarsjs-and-mustache).
 
 1. Why is it slower when compiling?
+
   The Handlebars compiler must parse the template and construct a JavaScript program which can then be run. Under some environments such as older mobile devices this can have a performance impact which can be avoided by precompiling. Generally it's recommended that precompilation and the runtime library be used on all clients.
 
 1. Why doesn't this work with Content Security Policy restrictions?
+
   When not using the precompiler, Handlebars generates a dynamic function for each template which can cause issues with pages that have enabled Content Policy. It's recommended that templates are precompiled or the `unsafe-eval` policy is enabled for sites that must generate dynamic templates at runtime.
 
 1. How can I include script tags in my template?
+
   If loading the template via an inlined `<script type="text/x-handlebars">` tag then you may need to break up the script tag with an empty comment to avoid browser parser errors:
 
   ```html
@@ -25,6 +30,7 @@
   It's generally recommended that templates are served through external, precompiled, files, which do not suffer from this issue.
 
 1. Why are my precompiled scripts throwing exceptions?
+
   When using the precompiler, it's important that a supporting version of the Handlebars runtime be loaded on the target page. In version 1.x there were rudimentary checks to compare the version but these did not always work. This is fixed under 2.x but the version checking does not work between these two versions. If you see unexpected errors such as `undefined is not a function` or similar, please verify that the same version is being used for both the precompiler and the client. This can be checked via:
 
   ```sh
@@ -42,9 +48,11 @@
   Should these match, please file an issue with us, per our [issue filing guidelines](https://github.com/wycats/handlebars.js/blob/master/CONTRIBUTING.md#reporting-issues).
 
 1. Why doesn't IE like the `default` name in the AMD module?
+
   Some browsers such as particular versions of IE treat `default` as a reserved word in JavaScript source files. To safely use this you need to reference this via the `Handlebars['default']` lookup method. This is an unfortunate side effect of the shims necessary to backport the Handlebars ES6 code to all current browsers.
 
 1. How do I load the runtime library when using AMD?
+
   There are two options for loading under AMD environments. The first is to use the `handlebars.runtime.amd.js` file. This may require a [path mapping](https://github.com/wycats/handlebars.js/blob/master/spec/amd-runtime.html#L31) as well as access via the `default` field.
 
   The other option is to load the `handlebars.runtime.js` UMD build, which might not require path configuration and exposes the library as both the module root and the `default` field for compatibility.