diff --git a/docs/_posts/2017-04-27-building-skype-on-reactxp.md b/docs/_posts/2017-04-27-building-skype-on-reactxp.md
index 05b2c54e..74fe19a3 100644
--- a/docs/_posts/2017-04-27-building-skype-on-reactxp.md
+++ b/docs/_posts/2017-04-27-building-skype-on-reactxp.md
@@ -27,7 +27,7 @@ Background tasks, such as fetching new messages, are handled by modules we refer
 
 In some cases, a service was so tightly bound to the operation of a particular store that we merged their functionality into a single module. For example, we created a ConfigurationStore to track app-level configuration settings (e.g. which features are enabled for a particular user). We could have implemented a corresponding ConfigurationService that fetches configuration updates, but we opted to implement this functionality within the ConfigurationStore out of pragmatism.
 
-At startup time, the app needs to instantiate all of its singleton stores and services, some of which have dependencies on others. To facilitate this startup process, we created a startup manager. Each store or service that wants to be started must implement an interface called "Startupable", which includes a "startup" method that returns a promise. Modules register themselves with the startup manager and specify which other modules (if any) they depend upon. This allows the startup manager to run startup routines in parallel. Once a startup promise is resolved, it unblocks the startup of any dependent modules. This continues until all registered modules have been started.
+At startup time, the app needs to instantiate all of its singleton stores and services, some of which have dependencies on others. To facilitate this startup process, we created a startup manager. Each store or service that wants to be started must implement an interface called "IStartupable", which includes a "startup" method that returns a promise. Modules register themselves with the startup manager and specify which other modules (if any) they depend upon. This allows the startup manager to run startup routines in parallel. Once a startup promise is resolved, it unblocks the startup of any dependent modules. This continues until all registered modules have been started.
 
 Here is a startup routine that populates its store with data from the database. Note that the startup routine returns a promise, which isn't resolved until after the async database access is completed.
 
diff --git a/docs/css/reactxp.scss b/docs/css/reactxp.scss
index 9676fb6a..6d72efa0 100644
--- a/docs/css/reactxp.scss
+++ b/docs/css/reactxp.scss
@@ -69,6 +69,8 @@ html {
 .container {
   padding-top: $navHeight;
   width: 100%;
+  background-color: white;
+  font-size: 14px;
 }
 
 .wrap {