Added line breaks, other formatting changes (microsoft#685)

* Added line breaks, other formatting changes

* additional formatting change

Author: Ron Petrusha

Documentation/compatibility/connection-pool-blocking-period-for-azure-sql-databases-is-removed.md

@@ -11,14 +11,14 @@ Investigating
 
 ### Change Description
 Starting with the .NET Framework 4.6.2, for connection open requests to known
-Azure SQL databases (*.database.windows.net, *.database.chinacloudapi.cn,
-*.database.usgovcloudapi.net, *.database.cloudapi.de), the connection pool
+Azure SQL databases (\*.database.windows.net, \*.database.chinacloudapi.cn,
+\*.database.usgovcloudapi.net, \*.database.cloudapi.de), the connection pool
 blocking period is removed, and connection open errors are not cached. Attempts
 to retry connection open requests will occur almost immediately after transient
 connection errors. This change allows the connection open attempt to be retried
 immediately for Azure SQL databases, thereby improving the performance of cloud-
 enabled apps. For all other connection attempts, the connection pool blocking
-period continues to be enforced.   
+period continues to be enforced.<p/>
 
 In the .NET Framework 4.6.1 and earlier versions, when an app encounters a
 transient connection failure when connecting to a database, the connection

Documentation/compatibility/horizontal-scrolling-and-virtualization.md

@@ -18,16 +18,16 @@ own virtualization in the direction orthogonal to the main scrolling direction
 <xref:System.Windows.Controls.DataGrid?displayProperty=name> with
 EnableColumnVirtualization="True").  The outcome of certain horizontal scrolling
 operations has been changed to produce results that are more intuitive and more
-analogous to the results of comparable vertical operations.
+analogous to the results of comparable vertical operations.<p/>
 
 The operations include "Scroll Here" and "Right Edge", to use the names from the
 menu obtained by right-clicking a horizontal scrollbar.  Both of these compute a
 candidate offset and call
-<xref:System.Windows.Controls.Primitives.IScrollInfo.SetHorizontalOffset(System.Double)>.
+<xref:System.Windows.Controls.Primitives.IScrollInfo.SetHorizontalOffset(System.Double)>.<p/>
 
 After scrolling to the new offset, the notion of "here" or "right edge" may have
 changed because newly de-virtualized content has changed the value of
-<xref:System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth?displayProperty=name>.
+<xref:System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth?displayProperty=name>.<p/>
 
 Prior to .NET Framework 4.6.2, the scroll operation simply uses the candidate offset, even
 though it may not be "here" or at the "right edge" any more.  This results in
@@ -39,10 +39,10 @@ virtualized; let's suppose they are very wide, so that the
 <xref:System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth?displayProperty=name>
 changes to 2000.  The scroll ends with HorizontalOffset=800, and the thumb
 "bounces" back to near the middle of the scrollbar - precisely at 800/2000 =
-40%.
+40%.<p/>
 
 The change is to recompute a new candidate offset when this situation occurs,
-and try again. (This is how vertical scrolling works already.)
+and try again. (This is how vertical scrolling works already.) <p/>
 
 The change produces a more predictable and intuitive experience for the end
 user, but it could also affect any app that depends on the exact value of

Documentation/compatibility/previewlostkeyboardfocus-is-called-repeatedly-if-its-handler-shows-a-message-box.md

@@ -12,7 +12,7 @@ Available
 ### Change Description
 
 Beginning in the .NET Framework 4.5, calling
-`System.Windows.Forms.MessageBox.Show` from a
+<xref:System.Windows.Forms.MessageBox.Show?displayProperty=nameWithType> from a
 <xref:System.Windows.UIElement.PreviewLostKeyboardFocus>
 handler will cause the handler to re-fire when the message box is closed,
 potentially resulting in an infinite loop of message boxes.
@@ -21,10 +21,11 @@ potentially resulting in an infinite loop of message boxes.
 - [ ] Build-time break
 
 ### Recommended Action
-There are two options to work around this issue -
+There are two options to work around this issue:
 
 1. It may be avoided by calling `System.Windows.MessageBox.Show` instead of `System.Windows.Forms.MessageBox.Show`.
-2. It may be avoided by showing the message box from a <xref:System.Windows.UIElement.LostKeyboardFocus> event handler (as opposed to a <xref:System.Windows.UIElement.PreviewLostKeyboardFocus?displayProperty=name> event handler).
+2. 
+3. It may be avoided by showing the message box from a <xref:System.Windows.UIElement.LostKeyboardFocus> event handler (as opposed to a <xref:System.Windows.UIElement.PreviewLostKeyboardFocus?displayProperty=name> event handler).
 
 ### Affected APIs
 * `M:System.Windows.ContentElement.add_PreviewLostKeyboardFocus(System.Windows.Input.KeyboardFocusChangedEventHandler)`

Documentation/compatibility/unicode-data-now-support-standard-v8_0-categories.md

@@ -10,9 +10,9 @@ Minor
 Planned
 
 ### Change Description
-In .NET Framework 4.6.2, Unicode data in the framework has been
-upgraded from Unicode standard version 6.3 to version 8.0.  When
-requesting Unicode character category in .NET Framework 4.6.2, some
+In .NET Framework 4.6.2, Unicode data has been
+upgraded from Unicode Standard version 6.3 to version 8.0.  When
+requesting Unicode character categories in .NET Framework 4.6.2, some
 results might not match the results in previous .NET Framework
 versions.  This change mostly affects Cherokee syllables and New Tai
 Lue vowels signs and tone marks.

Documentation/compatibility/x509certificate2_tostring(bool)-does-not-throw-now-when-_net-cannot-handle-the-certificate.md

@@ -1,4 +1,4 @@
-## X509Certificate2.ToString(bool) does not throw now when .NET cannot handle the certificate
+## X509Certificate2.ToString(Boolean) does not throw now when .NET cannot handle the certificate
 
 ### Scope
 Edge
@@ -11,7 +11,7 @@ Available
 
 ### Change Description
 
-Previously, this method would throw if `true` was passed for the verbose
+In .NET Framework 4.5.2 and earlier versions, this method would throw if `true` was passed for the verbose
 parameter and there were certificates installed that weren't supported by the
 .NET Framework. Now, the method will succeed and return a valid string that
 omits the inaccessible portions of the certificate.
@@ -22,7 +22,7 @@ omits the inaccessible portions of the certificate.
 ### Recommended Action
 
 Any code depending on
-<xref:System.Security.Cryptography.X509Certificates.X509Certificate2.ToString(System.Boolean)>
+<xref:System.Security.Cryptography.X509Certificates.X509Certificate2.ToString(System.Boolean)?displayProperty=nameWithType>
 should be updated to expect that the returned string may exclude some
 certificate data (such as public key, private key, and extensions) in some cases
 in which the API would have previously thrown.