respond to pr feedback. Use _x_ instead of *x* for emphasis

files/en-us/web/api/readablestream/tee/index.md

@@ -24,12 +24,12 @@ a response from the server and stream it to the browser, but also stream it to t
 ServiceWorker cache. Since a response body cannot be consumed more than once, you'd need
 two copies to do this.
 
-A teed stream will partially signal backpressure at the rate of the *faster* consumer
+A teed stream will partially signal backpressure at the rate of the _faster_ consumer
 of the two `ReadableStream` branches,
 and unread data is enqueued internally on the slower consumed `ReadableStream`
 without any limit or backpressure.
-That is, when *both* branches have an unread element in their internal queue,
-then the original `ReadableStream`’s controller’s queue will start to fill up,
+That is, when _both_ branches have an unread element in their internal queue,
+then the original `ReadableStream`’s controller’s internal queue will start to fill up,
 and once its {{domxref("ReadableStreamDefaultController.desiredSize", "desiredSize")}} ≤ 0
 or byte stream controller {{domxref("ReadableByteStreamController.desiredSize", "desiredSize")}} ≤ 0,
 then the controller will stop calling `pull(controller)` on the
@@ -38,7 +38,7 @@ If only one branch is consumed, then the entire body will be enqueued in memory.
 Therefore, you should not use the built-in `tee()` to read very large streams
 in parallel at different speeds.
 Instead, search for an implementation that fully backpressures
-to the speed of the *slower* consumed branch.
+to the speed of the _slower_ consumed branch.
 
 To cancel the stream you then need to cancel both resulting branches. Teeing a stream
 will generally lock it for the duration, preventing other readers from locking it.

files/en-us/web/api/request/clone/index.md

@@ -16,7 +16,7 @@ The **`clone()`** method of the {{domxref("Request")}} interface creates a copy
 
 Like the underlying {{domxref("ReadableStream.tee")}} api,
 the {{domxref("Request.body", "body")}} of a cloned `Response`
-will signal backpressure at the rate of the *faster* consumer of the two bodies,
+will signal backpressure at the rate of the _faster_ consumer of the two bodies,
 and unread data is enqueued internally on the slower consumed `body`
 without any limit or backpressure.
 Beware when you construct a `Request` from a stream and then `clone` it.

files/en-us/web/api/response/clone/index.md

@@ -16,7 +16,7 @@ The **`clone()`** method of the {{domxref("Response")}} interface creates a clon
 
 Like the underlying {{domxref("ReadableStream.tee")}} api,
 the {{domxref("Response.body", "body")}} of a cloned `Response`
-will signal backpressure at the rate of the *faster* consumer of the two bodies,
+will signal backpressure at the rate of the _faster_ consumer of the two bodies,
 and unread data is enqueued internally on the slower consumed `body`
 without any limit or backpressure.
 Backpressure refers to the mechanism by which the streaming consumer of data