[mobile] Renamed "Spec in progress" into "Technologies in progress"

This is more consistent with the "Well-deployed technologies" header and some
of the content reported in that section may be about a given feature of a
spec, not necessarily about the whole spec.

mobile/adaptation.html

@@ -24,7 +24,7 @@ <h2>Well-deployed technologies</h2>
       </section>
 
       <section class="featureset in-progress">
-        <h2>Specifications in progress</h2>
+        <h2>Technologies in progress</h2>
         <div data-feature="CSS-based adaptation">
           <p><a data-featureid="css-device-adapt">CSS Device Adaptation</a> defines a set of CSS directives to define the size on which this layout should be based, relatively to the size of the underlying device — specifying what has been implemented using the <code>&lt;meta name="viewport"&gt;</code> element so far.</p>
           <p><a data-featureid="mediaqueries4">Media Queries Level 4</a> adds the availability and type of a pointing device, as well as the ability to hover over elements, to the list of capabilities that may be used to adapt the layout and behavior of a Web page. Moreover, <a data-featureid="mediaqueries5">Media Queries Level 5</a> lets developers specify media queries that react to the ambient luminosity and to <a href="https://drafts.csswg.org/mediaqueries-5/#script-custom-mq">script-defined variables</a>, making it easier to cater for more complex adaptation rules in the overall logic of the application.</p>

mobile/forms.html

@@ -19,7 +19,7 @@ <h2>Well-deployed technologies</h2>
       </section>
 
       <section class="featureset in-progress">
-        <h2>Specifications in progress</h2>
+        <h2>Technologies in progress</h2>
         <p data-feature="Customized text entries"><a data-featureid="inputdate">Date and time entries</a> can take advantage of a number of dedicated form controls (e.g. <code>&lt;input type="date"&gt;</code>) to trigger the use of a native calendar control, avoiding the need to create custom JS-based controls that cannot be easily tailored to cope for the variety of mobile devices available on the market.</p>
       </section>
 

mobile/graphics.html

@@ -31,7 +31,7 @@ <h2>Well-deployed technologies</h2>
         <p><strong>NB:</strong> a <a href="http://www.khronos.org/webgl/">3D graphic API for HTML5 <code>canvas</code>, called WebGL</a>, has been developed outside of W3C, as part of the <a href="http://www.khronos.org/">Khronos Group</a>; this API has been built to be compatible with <a href="http://www.khronos.org/opengles/">OpenGL ES</a>, i.e. for embedded systems, and is intended to work on mobile devices. The <a href="https://www.w3.org/community/gpu/">GPU for the Web Community Group</a> also started to design a new Web API to expose modern 3D graphics and computation capabilities in a performant, powerful and safe manner, with a goal to be agnostic of and compatible with existing native system platforms (such as Direct3D, Metal, or Vulkan).</p>
       </section>
       <section class="featureset in-progress">
-        <h2>Specifications in progress</h2>
+        <h2>Technologies in progress</h2>
         <div data-feature="Animations">
           <p>Animations can also be managed via scripting through the API exposed in <a data-featureid="webanimations">Web Animations</a>.</p>
           <p>To ensure optimal performances when animating parts of an app, authors can make use of the <a data-featureid="css-will-change">CSS <code>will-change</code></a> property to let browsers compute the animation ahead of its occurrence.</p>

mobile/lifecycle.html

@@ -26,7 +26,7 @@ <h2>Well-deployed technologies</h2>
       </section>
 
       <section class="featureset in-progress">
-        <h2>Specifications in progress</h2>
+        <h2>Technologies in progress</h2>
         <div data-feature="Packing">
           <p>Whether packaged or not, users rely on a variety of metadata (name, icons) to identify the apps they want to use among their list of regularly used applications. The <a data-featureid="appmanifest">Web App Manifest</a></strong> specification lets developers group all these metadata into a single JSON file.</p>
         </div>

mobile/media.html

@@ -24,7 +24,7 @@ <h2>Well-deployed technologies</h2>
         <p data-feature="Image &amp; Video analysis, modification">The <cite><a data-featureid="canvas">Canvas 2D Context</a></cite> API enables modifying images, which in turn opens up the possibility of <strong>video editing</strong>, thus bringing multimedia manipulation capabilities to the Web platform.</p>
       </section>
       <section class="featureset in-progress">
-        <h2>Specifications in progress</h2>
+        <h2>Technologies in progress</h2>
 
         <p data-feature="Audio playback">Beyond the declarative approach enabled by the <code>&lt;audio&gt;</code> element, the <a data-featureid="webaudio">Web Audio API</a> provides a full-fledged audio processing API, which includes support for low-latency playback of audio content.</p>
 

mobile/network.html

@@ -40,7 +40,7 @@ <h2>Well-deployed technologies</h2>
       </section>
 
       <section class="featureset in-progress">
-        <h2>Specifications in progress</h2>
+        <h2>Technologies in progress</h2>
         <p data-feature="HTTP Network API">The <a data-featureid="beacon">Beacon API</a></strong> aims at letting developers queue unsupervised HTTP requests, leaving it to the browser to execute them when appropriate, opening the door for better network optimizations.</p>
 
         <div data-feature="Server-pushed Requests">

mobile/payment.html

@@ -19,7 +19,7 @@ <h2>Well-deployed technologies</h2>
       </section>
 
       <section class="featureset in-progress">
-        <h2>Specifications in progress</h2>
+        <h2>Technologies in progress</h2>
 
         <p>Following a successful <a href="https://www.w3.org/2013/10/payments/">workshop on Web payments</a> in 2014 and discussions on <a href="https://www.w3.org/TR/web-payments-use-cases/">use cases and priorities for Web payments</a> in the <a href="https://www.w3.org/Payments/IG/">Web Payment Interest Group</a>, W3C <a href="https://www.w3.org/Payments/WG/charter-201510.html">chartered a Web Payments Working Group</a> to develop browser APIs to facilitate payment operations in Web applications:</p>
 

mobile/performance.html

@@ -44,7 +44,7 @@ <h2>Well-deployed technologies</h2>
       </section>
 
       <section class="featureset in-progress">
-        <h2>Specifications in progress</h2>
+        <h2>Technologies in progress</h2>
         <div data-feature="Network Prioritization">
           <p>The <a data-featureid="resource-hints">Resource Hints</a> and <a data-featureid="preload">Preload</a> specifications let developers optimize the download of resources by enabling to delay either the download or the execution of the downloaded resource.</p>
         </div>

mobile/security.html

@@ -40,7 +40,7 @@ <h2>Well-deployed technologies</h2>
       </section>
 
       <section class="featureset in-progress">
-        <h2>Specifications in progress</h2>
+        <h2>Technologies in progress</h2>
 
         <p>Many sensitive APIs, e.g. those that expose mobile device sensors, are gated by a request for user consent; while these requests give control to the user, they can be sometimes hard to integrate in the overall user experience without visibility on which permission has been granted or denied. The <a data-featureid="permissions">Permissions API</a> aims at fixing this.</p>
 

mobile/sensors.html

@@ -23,7 +23,7 @@ <h2>Well-deployed technologies</h2>
       </section>
 
       <section class="featureset in-progress">
-        <h2>Specifications in progress</h2>
+        <h2>Technologies in progress</h2>
 
         <p>The <a data-feature="Generic Sensors" data-featureid="generic-sensor">Generic Sensor API</a> defines a framework for exposing sensor data to the Web platform in a consistent way. In particular, the specification defines a blueprint for writing specifications of concrete sensors along with an abstract Sensor interface that can be extended to accommodate different sensor types.</p>
 

mobile/storage.html

@@ -21,7 +21,7 @@ <h2>Well-deployed technologies</h2>
         <p>The <a data-featureid="html5-download">HTML5 <code>download</code> attribute</a> provides a simple mechanism to trigger a file download (rather than a page navigation), with the possibility of setting a user-friendly filename.</p>
       </section>
       <section class="featureset in-progress">
-        <h2>Specifications in progress</h2>
+        <h2>Technologies in progress</h2>
 
         <div data-feature="File operations">
           <p>The <a data-featureid="fileapi">File Reader API</a> makes it possible to load the content of a file, for richer interactions with the file system. However, note discussions on a sandboxed filesystem API that could have allowed to write files onto a sandboxed file system have halted for lack of interest.</p>

mobile/userinput.html

@@ -27,7 +27,7 @@ <h2>Well-deployed technologies</h2>
       </section>
 
       <section class="featureset in-progress">
-        <h2>Specifications in progress</h2>
+        <h2>Technologies in progress</h2>
 
         <div data-feature="Touch-based interactions">
           <p>The <a href="https://www.w3.org/2012/pointerevents/">Pointer Events Working Group</a> has made good progress on an alternative approach to handle user input, <a data-featureid="pointer-events">Pointer Events</a>, that allows to handle mouse, touch and pen events under a single model. It provides a complementary and more unified  approach to the currently more widely deployed Touch Events.</p>