diff --git a/doc/html_generated/benchmarks.html b/doc/html_generated/benchmarks.html
index 32b90cb..9b97c8f 100644
--- a/doc/html_generated/benchmarks.html
+++ b/doc/html_generated/benchmarks.html
@@ -6,16 +6,19 @@
 # Compile time benchmarks
 
 The benchmarks are done with [**this**](../../scripts/bench/bench.py) script using CMake. There are 2 benchmarking scenarios:
+
 - [the cost of including the header](#cost-of-including-the-header)
 - [the cost of an assertion macro](#cost-of-an-assertion-macro)
 
 Compilers used:
+
 - WINDOWS: Microsoft Visual Studio Community 2015 - Version 14.0.25431.01 Update 3
 - WINDOWS: gcc 6.2.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)
 - LINUX: gcc 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)
 - LINUX: clang 3.6.2-1 (tags/RELEASE_362/final) (based on LLVM 3.6.2) Ubuntu - Target: x86_64-pc-linux-gnu
 
-Environment used (Intel i7 3770k, 16g RAM)
+Environment used (Intel i7 3770k, 16g RAM):
+
 - Windows 7 - on an SSD
 - Ubuntu 15.10 in a VirtualBox VM - on a HDD
 
diff --git a/doc/html_generated/faq.html b/doc/html_generated/faq.html
index 2fb234b..1dc3d75 100644
--- a/doc/html_generated/faq.html
+++ b/doc/html_generated/faq.html
@@ -51,6 +51,7 @@
 Using the [**fast**](assertions.html#fast-asserts) asserts in combination with [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) yelds the [**fastest**](benchmarks.html#cost-of-an-assertion-macro) compile times.
 
 There are only 2 drawbacks of this approach:
+
 - using fast asserts (40-80% [**faster**](benchmarks.html#cost-of-an-assertion-macro) than ```CHECK(a==b)```) means that there is no ```try/catch``` block in each assert so if an expression throws the whole test case ends.
 - defining the [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) config identifier will result in even [**faster**](benchmarks.html#cost-of-an-assertion-macro) fast asserts (30-80%) at the cost of only one thing: when an assert fails and a debugger is present - the framework will break inside a doctest function so the user will have to go 1 level up in the callstack to see where the actual assert is in the source code.
 
@@ -68,13 +69,14 @@
 
 ### Why are my tests in a static library not getting registered?
 
-This is a [**common**](https://github.com/google/googletest/blob/master/googletest/docs/V1_7_Primer.html#important-note-for-visual-c-users) [**problem**](https://groups.google.com/forum/#!msg/catch-forum/FV0Qo62DvgY/jxEO6c9_q3kJ) and it affects all modern compilers on all platforms.
+This is a [**common problem**](https://groups.google.com/forum/#!msg/catch-forum/FV0Qo62DvgY/jxEO6c9_q3kJ) and it affects all modern compilers on all platforms.
 
 The problem is that when a static library is being linked to a binary (executable or dll) - only object files from the static library that define a synbol being required from the binary will get pulled in (this is a linker/dependency optimization).
 
 I have created a CMake function that forces every object file from a static library to be linked into a binary target - it is called [**```doctest_force_link_static_lib_in_target()```**](../../examples/exe_with_static_libs/doctest_force_link_static_lib_in_target.cmake). It is unintrusive - no source file gets changed - everything is done with compiler flags per source files. An example project using it can be found [**here**](../../examples/exe_with_static_libs).
 
 It doesn't work in 2 scenarios:
+
 - either the target or the library uses a precompiled header - see [**this**](https://github.com/onqtam/doctest/issues/21#issuecomment-247001423) issue for details
 - either the target or the library is an imported target (pre-built) and not built within the current cmake tree