diff --git a/sdk/fidl/fuchsia.media/README.md b/sdk/fidl/fuchsia.media/README.md
index c1c119a..ee104f5 100644
--- a/sdk/fidl/fuchsia.media/README.md
+++ b/sdk/fidl/fuchsia.media/README.md
@@ -177,7 +177,7 @@
 CreateAudioCapturer method, which may be used by clients to capture audio
 from either the current default audio input device, or the current default
 audio output device depending on the flags passed during creation.</p>
-<p>** Format support **</p>
+<p><strong>Format support</strong></p>
 <p>See (Get|Set)StreamType below. By default, the captured stream type will be
 initially determined by the currently configured stream type of the source
 that the AudioCapturer was bound to at creation time. Users may either fetch
@@ -186,7 +186,7 @@
 Note: the stream type may only be set while the system is not running,
 meaning that there are no pending capture regions (specified using CaptureAt)
 and that the system is not currently running in 'async' capture mode.</p>
-<p>** Buffers and memory management **</p>
+<p><strong>Buffers and memory management</strong></p>
 <p>Audio data is captured into a shared memory buffer (a VMO) supplied by the
 user to the AudioCapturer during the AddPayloadBuffer call.  Please note the
 following requirements related to the management of the payload buffer.</p>
@@ -207,11 +207,11 @@
 writable, mappable and transferable.</li>
 <li>Users should always treat the payload buffer as read-only.</li>
 </ul>
-<p>** Synchronous vs. Asynchronous capture mode **</p>
+<p><strong>Synchronous vs. Asynchronous capture mode</strong></p>
 <p>The AudioCapturer interface can be used in one of two mutually exclusive
 modes: Synchronous and Asynchronous.  A description of each mode and their
 tradeoffs is given below.</p>
-<p>** Synchronous mode **</p>
+<p><strong>Synchronous mode</strong></p>
 <p>By default, AudioCapturer instances are running in 'sync' mode.  They will
 only capture data when a user supplies at least one region to capture into
 using the CaptureAt method.  Regions supplied in this way will be filled in
@@ -233,7 +233,7 @@
 overwrite any region of the payload buffer after a completed region is
 returned, it may overwrite the unfilled portions of a partially filled
 buffer which has been returned as a result of a DiscardAllPackets operation.</p>
-<p>** Asynchronous mode **</p>
+<p><strong>Asynchronous mode</strong></p>
 <p>While running in 'async' mode, clients do not need to explicitly supply
 shared buffer regions to be filled by the AudioCapturer instance. Instead, a
 client enters into 'async' mode by calling StartAsyncCapture and supplying a
@@ -259,7 +259,7 @@
 <li>To attempt any operation except for SetGain while in the process of
 stopping.</li>
 </ul>
-<p>** Synchronizing with a StopAsyncCapture operation **</p>
+<p><strong>Synchronizing with a StopAsyncCapture operation</strong></p>
 <p>Stopping asynchronous capture mode and returning to synchronous capture mode
 is an operation which takes time.  Aside from SetGain, users may not call any
 other methods on the AudioCapturer interface after calling StopAsyncCapture
@@ -282,7 +282,7 @@
 in order to deliver a packet with the end-of-stream flag set on it.  Once
 users have seen the end-of-stream flag after calling stop, the AudioCapturer
 has finished the stop operation and returned to synchronous operating mode.</p>
-<p>** Timing and Overflows **</p>
+<p><strong>Timing and Overflows</strong></p>
 <p>All media packets produced by an AudioCapturer instance will have their PTS
 field filled out with the capture time of the audio expressed as a timestamp
 given by the reference clock timeline. Note: this timestamp is actually a
@@ -332,7 +332,7 @@
 In practice, however, if it does, the next produced packet will be flagged
 as being discontinuous.</li>
 </ol>
-<p>** Synchronous vs. Asynchronous Trade-offs **</p>
+<p><strong>Synchronous vs. Asynchronous Trade-offs</strong></p>
 <p>The choice of operating in synchronous vs. asynchronous mode is up to the
 user, and depending on the user's requirements, there are some advantages and
 disadvantages to each choice.</p>
diff --git a/sdk/fidl/fuchsia.sysmem/README.md b/sdk/fidl/fuchsia.sysmem/README.md
index a46ff07..174a7ac 100644
--- a/sdk/fidl/fuchsia.sysmem/README.md
+++ b/sdk/fidl/fuchsia.sysmem/README.md
@@ -3857,7 +3857,10 @@
             <td>
                 <code>uint32</code>
             </td>
-            <td></td>
+            <td><p>Stride in bytes of plane 0.  Planes beyond plane 0 (if any, depending on
+pixel_format) have a known fixed relationship with plane 0's stride.
+For Intel tiled textures, the stride is for the linearized version of the texture.</p>
+</td>
             <td>No default</td>
         </tr>
         <tr id="ImageFormat_2.display_width">