Merge pull request #636 from html5rocks/rAqfixes

Fixes #621 - raq article

content/tutorials/forms/requestautocomplete/en/index.html

@@ -15,17 +15,17 @@
 <h2 id="toc-introduction">Introduction</h2>
 <p>I like the web. All in all, I think it’s a pretty good idea. As such, I get into a lot of web vs native debates. It doesn’t take long for the other person to start talking about the ease of payments through native systems. My usual response is to drop a smoke bomb and run out of the room laughing maniacally, because it’s not an argument I can win.</p>
 <p><strong>Shopping cart abandonment on the mobile web <a href="http://seewhy.com/blog/2012/10/10/97-shopping-cart-abandonment-rate-mobile-devices-concern-you/">can be as high as 97%</a></strong>. Imagine that in the real world. Imagine 97% of people in a supermarket, with a cart brimming full of things that they want, flipping their cart over and walking out.</p>
-<p>Now, some of those people are just pricing stuff up and never had an intention to buy, but horrific user experience of buying on the web is a significant contributor. We’re hitting users with a tax on their sanity.</p>
+<p>Now, some of those people are just pricing stuff up and never had an intention to buy, but the horrific user experience of buying on the web is a significant contributor. We’re hitting users with a tax on their sanity.</p>
 <p>Think of a pleasurable payment experience you had on the web, especially on mobile. It’s an app store, right? Or at least a similar closed system that already has your payment information.</p>
-<p>This is a problem. It requires sites to commit to a particular payment provider that the user may already have an account with &amp; be logged into, or commit to a platform that requires users to be logged into a particular payment provider, such as app stores which require you to code solely for that platform. If you don’t do one of these things, the user is doomed to tap away at their screen or keyboard until all their finger-skin is gone, or they give up.</p>
+<p>This is a problem. It requires sites to commit to a particular payment provider that the user must already have an account with and be logged into, or to commit to a platform that requires users to be logged into a particular payment provider, such as an app storexs that require you to code solely for that platform. If you don’t do one of these things, the user is doomed to tap away at their screen or keyboard until all their finger-skin is gone, or they give up.</p>
 <p>We need to fix that.</p>
 
 <h2 id="toc-requestautocomplete">requestAutocomplete</h2>
 
-<p>In a world of WebGL, WebRTC and other fancy web APIs that start with “Web”, <code>requestAutocomplete</code> is rather unglamorous. However, it’s a superhero in beige clothing. A tiny boring API that can stick a stake through the heart of the web payments time-vampire.</p>
+<p>In a world of WebGL, WebRTC and other fancy web APIs that start with “Web”, <code>requestAutocomplete</code> is rather unglamorous. However, it’s a superhero in beige clothing. A tiny, boring API that can stick a stake through the heart of the web payments time-vampire.</p>
 
 <div style="position: relative; padding-top: 56.25%;">
-  <iframe style="position:absolute;top:0;left:0;width:100%;height:100%;" src="//www.youtube.com/embed/VQO8hMqyn00?rel=0" frameborder="0" allowfullscreen></iframe>
+  <iframe style="position:absolute;top:0;left:0;width:100%;height:100%;" src="//www.youtube.com/watch?v=VQO8hMqyn00" frameborder="0" allowfullscreen></iframe>
 </div>
 
 <p>Rather than the site relying on a particular payment provider, it requests payment details from the browser, which stores them on the user’s behalf.</p>
@@ -96,7 +96,7 @@ <h3>Address</h3>
   <li>name - full name. Taking a full name as a single field is far better than multiple fields. Multiple fields such as first-name and last-name show a Western bias and may not make sense to other cultures, also it’s easier to type into a single field</li>
   <li>tel - full telephone number including country code, can alternatively be broken down into
     <ul>
-      <li>tel-country-code - eg +44</li>
+      <li>tel-country-code - e.g. +44</li>
       <li>tel-national - the rest</li>
     </ul>
   </li>
@@ -136,7 +136,7 @@ <h3>Address</h3>
 </pre>
 
 <p>Once again, the name attributes are examples, you can use whatever you want.</p>
-<p>Obviously not all forms should request a shipping address, eg don’t ask me where I’d like my hotel room delivered, it’s current location is often the selling point.</p>
+<p>Obviously not all forms should request a shipping address, e.g. don’t ask me where I’d like my hotel room delivered, it’s current location is often the selling point.</p>
 <p>Right, so we’ve got our form, and we know how to request <code>autocompletion</code>. But…</p>
 
 <h2 id="toc-when-to-call-rac">When should requestAutocomplete be called?</h2>
@@ -247,7 +247,7 @@ <h2 id="toc-after-calling-rac">You’ve called requestAutocomplete, what now?</h
 <h2 id="toc-data-storage">Where does the browser store my data?</h2>
 
 <p>The specification doesn’t dictate where data is stored, allowing browsers to innovate.</p>
-<p>If you’re logged into Chrome, you get the option to store details in Google Wallet, making them accessible on other devices you’re logged into. If you store your details in Wallet, your real card number won’t be dealt out by <code>requestAutocomplete</code>, instead a <a href="https://support.google.com/wallet/answer/2740044?hl=en">Google Wallet Virtual Card</a> so your actual card number isn't sent to the seller, increasing security.</p>
+<p>If you’re logged into Chrome, you get the option to store details in Google Wallet, making them accessible on other devices you’re logged into. If you store your details in Wallet, your real card number won’t be dealt out by <code>requestAutocomplete</code>, increasing security.</p>
 <p>If you aren’t logged into Chrome, or choose not to use Google Wallet, your details are optionally stored locally in the browser for reuse.</p>
 <p>This is the state of things now, but in future Chrome and other browsers may adopt additional payment providers.</p>
 
@@ -289,4 +289,4 @@ <h2 id="toc-multi-page-forms">Bonus round: Handling multi-page forms</h2>
 });
 </pre>
 
-{% endblock %}
+{% endblock %}

database/tutorials.yaml

@@ -1,13 +1,13 @@
 title: "requestAutocomplete - take my money, not my time"
 url: /tutorials/forms/requestautocomplete/
 author_id: jakearchibald
-publication_date: 2013-05-29
-description: How to squeeze performance out of script loading
+publication_date: 2013-10-03
+description: "How to squeeze performance out of script loading"
 browser_support:
 - chrome
 tags:
 - forms
-- type:tutorial
+- type:article
 - class:nuts_and_bolts
 
 ---