Add better intro to the extension doc (#281)

* Add better intro to the extension doc

extension.html

@@ -52,7 +52,29 @@ <h2>Introduction</h2>
         This document reflects incubation for APIs which are intended to be part of a future version of the Pointer Events specification. They are not yet broadly supported by implementations.
       </p>
       <p>
-	The <code>getCoalescedEvents</code> API (similar to Android <a href="https://developer.android.com/reference/android/view/MotionEvent.html#getHistoricalX(int, int)">getHistorical</a> APIs and iOS <a href="https://developer.xamarin.com/api/member/MonoTouch.UIKit.UIEvent.GetCoalescedTouches/p/MonoTouch.UIKit.UITouch/">GetCoalescedTouches</a> API) exposes all the events that were coalesced into a single event. Coalescing events into a single event enables user agents to prevent processing of the events that don’t get a chance to update the frame content visually. Basically if the javascript handlers process the events and update the screen contents faster than refresh rate only the last update will be rendered and shown in the next frame. However, some applications like drawing apps may want to take advantage of the precise history of events as user moves the pointer on the screen to be able to draw smoother and better looking curves. This API can be used in those scenarios to get all the coalesced events from the event that was dispatched to the javascript.
+	The <code>getCoalescedEvents</code> API (similar to Android <a href="https://developer.android.com/reference/android/view/MotionEvent.html#getHistoricalX(int, int)">getHistorical</a> APIs
+        and iOS <a href="https://developer.xamarin.com/api/member/MonoTouch.UIKit.UIEvent.GetCoalescedTouches/p/MonoTouch.UIKit.UITouch/">GetCoalescedTouches</a> API) exposes all the events
+        that were coalesced into a single event.
+        User agents may coalesce a stream of events into a single event sent to javascript.
+        This situation can occur when many events are generated by the hardware in between the requestAnimationFrame boundaries or for long running javascript code that misses the frame boundary.
+        Basically, if the javascript handlers process the events and update the screen contents faster than the screen refresh rate only the last update will render and show in the next frame.
+        So for example, if there were multiple <code>pointermove</code> events happened from the last requestAnimationFrame callback, UA can coalesce all of them into one event and send only
+        that event before the next requestAnimationFrame representing the last state of the pointer.
+        Most applications care only about the last coordinates and not the intermediate coordinates that occurred.
+        However, a class of applications such as drawing applications may wish precise (subframe timing) coordinates in order to draw better detailed lines.
+        The <code>getCoalescedEvents</code> API can be used in those scenarios to get all the coalesced events from the event that was dispatched to the javascript.
+      </p>
+      <p>
+       The <code>getPredictedEvents</code> API tries to achieve the minimal latency for drawing app similar to other platforms such as
+       iOS <a href="https://developer.apple.com/documentation/uikit/touches_presses_and_gestures/handling_touches_in_your_view/minimizing_latency_with_predicted_touches">prediction APIs</a>.
+       The drawing latency on the web comes from a wide variety of factors such as UA input pipeline latency and multi level bufferings of the output buffer.
+       This API exposes what UA thinks the near future state of  pointer will be and the web app can choose to use that state for example to draw those points temporarily for the current frame.
+       That would help to reduce the perception of overall latency when user interacts with the page.
+      </p>
+      <p>
+       While for most apps getting all the events and their history before rAF and drawing the result on the page is enough, more time sensitive apps care to get the event as soon as they arrive.
+       They might be sending input events over the network or play a musical note that aren't necessarily tied to the frame time and the screen refresh rate. Coalescing events or rAF-aligning them would hurt those apps.
+       The new pointerevent type <code>pointerrawupdate</code> that fires immedinatedly as they arrive introduced in this spec would help those usecases. Note that there are some considerations around this that will be discussed later in this spec.
       </p>
     </section>
     <section>
@@ -64,7 +86,7 @@ <h3>The <dfn><code>pointermove</code> event</dfn></h3>
         Additionally one <code>pointermove</code> MUST be fired when pointer changes coordinates, pressure, tangential pressure, tilt, twist, or
         contact geometry (e.g. <code>width</code> and <code>height</code>) and the circumstances produce no other pointer events defined in this specification.
         These events may be coalesced or aligned to <a href="https://html.spec.whatwg.org/#event-loop-processing-model">animation frame callbacks</a> based on UA decision.
-        The coalesced events information will be exposed via <a data-lt="getCoalescedEvents">getCoalescedEvents</a> API for the single dispatched <code>pointermove</code> event.
+        The coalesced events information will be exposed via <code><a data-lt="getCoalescedEvents">getCoalescedEvents</a></code> API for the single dispatched <code>pointermove</code> event.
         The final coordinates of such events should be used for finding the target of the event.
       </section>
       <section>