website: blog tweaks!

website/src/_posts/2018-12-0.29.md

@@ -8,7 +8,7 @@ published: false
 
 <img src="/images/blog/0.29/uppy-core-plugins-separate-styles.jpg">
 
-`0.29` brings bug fixes and improvements, while we are busy working on Uppy React Native support (which is already [coming to our resumable file upload protocol tus.io](https://github.com/tus/tus-js-client#react-native-support)) and a Transloadit Preset. Importantant highlights of this release are: separate Core and plugin styles, using file sizes for progress calculation, `responseType` option for XHR Upload and some visual Webcam bug fixes.  
+`0.29` brings bug fixes and improvements, while we are busy working on Uppy React Native support (which is already [coming to our resumable file upload protocol tus.io](https://github.com/tus/tus-js-client#react-native-support)) and a Transloadit Preset. The highlights of this release are: separating Core and plugin styles, using file sizes for progress calculation, adding a `responseType` option for XHR Upload and fixing some visual Webcam bugs.
 
 <!--more-->
 
@@ -16,7 +16,7 @@ published: false
 
 **⚠️ breaking**
 
-When installing `uppy` and plugins from npm, you had to include their styles. Prior to this release, you could only include the plugin’s style, say, for `@uppy/webcam` you’d include its CSS:
+When installing `uppy` and plugins from npm, you had to include their styles. Prior to this release, you could include only the plugin’s CSS, say, for `@uppy/webcam`:
 
 ```js
 import Uppy from '@uppy/core'
@@ -24,6 +24,8 @@ import Webcam from '@uppy/webcam'
 import '@uppy/webcam/dist/style.css'
 ```
 
+Each plugin's file contained the core styles. If you added multiple plugins, the core styles ended up being duplicated. This bloated file sizes and could even break styles entirely because of CSS's precedence rules.
+
 Now you have to include “general” styles from `@uppy/core` as well:
 
 ```js
@@ -33,7 +35,9 @@ import '@uppy/core/dist/style.css'
 import '@uppy/webcam/dist/style.css'
 ```
 
-Please [see documentation for the plugin](https://uppy.io/docs/plugins/) you are using to find out whether it requires a CSS file to work. Generaly UI plugins, such as Dashboard, Webcam and Status Bar need a CSS file, while utility plugins, such as Tus or XHR Upload, don’t.
+Thus the core styles are only included once. `@uppy/core` styles must be included before plugin styles.
+
+Please [see documentation for the plugin](https://uppy.io/docs/plugins/) you are using to find out whether it requires a CSS file to work. Generally UI plugins, such as Dashboard, Webcam and Status Bar need a CSS file, while utility plugins, such as Tus or XHR Upload, don’t.
 
 ⚠️ Important things to remember:
 
@@ -48,7 +52,7 @@ import Webcam from '@uppy/webcam'
 import Url from '@uppy/url'
 
 // Core and Dashboard styles, then Webcam and Url, but not for GoogleDrive —
-// those come with Dashboard 
+// those come with Dashboard
 import '@uppy/core/dist/style.css'
 import '@uppy/dashboard/dist/style.css'
 import '@uppy/webcam/dist/style.css'
@@ -57,7 +61,7 @@ import '@uppy/url/dist/style.css'
 
 ## Using File Sizes For Progress Calculation
 
-When possible, file sizes are now used for calculating the total progress. Before, we’ve used uploaded percentage for each file. That meant, if you were uploading 4 files, and 3 small were already uploaded, while one very large was still in progress, Uppy would display progress as 90%. Long story short, Uppy now has a more accurate progress bar 🚀 
+When possible, file sizes are now used for calculating the total progress. Before, we’ve used uploaded percentage for each file. That meant, if you were uploading 4 files, and 3 small were already uploaded, while one very large file was still in progress, Uppy may display progress as 90%. Long story short, Uppy now has a more accurate progress bar 🚀
 
 Some internal details, if you are interested:
 
@@ -68,7 +72,7 @@ Some internal details, if you are interested:
 
 ## responseType For XHR Upload
 
-When using XHR Upload (or S3, that uses it internally), you can now configure the XMLHttpRequest `.responseType` value. Allows the S3 plugin to tell Firefox not to log XML errors when getting empty responses, so it finally fixes bugs that were caused by this, see #518.
+When using XHR Upload, you can now configure the XMLHttpRequest `.responseType` value. This allows the S3 plugin to tell Firefox not to log XML errors when getting empty responses, so it finally fixes the spurious warnings that were caused by this, see #518.
 
 Because AwsS3 now sets responseType: 'text', we can no longer use the responseXML property. We already did text based parsing for successful responses, and now do the same for error responses.