Small fixes + displayItems (#88)

* (Deleted this edit by mistake before merged)

Redo section 10.3 intro based on 14 Dec discussion

* Edits based on recent changes and discussions

This was not a comprehensive review of the document. However, I
reviewed it in light of some recent decisions and did some updates:

* Given 4 January discussion about recommended payment apps, I reviewed
the text on that topic and made changes.
* I also cleaned up some text on registration given the new assumption
that registration IS a prerequisite for usage of a payment app that
conforms to this specification.
* It has also become clear that this specification is not designed to
address native payment apps, and so I deleted some text on native
payment apps, and also stated more clearly that those mechanisms lie
outside the scope of this document.
* IMPORTANT: It is my current understanding that a payment app
identifier will designate service worker code. Therefore, the spec now
says that; we’ll discuss whether this was the right edit at our 10
January call.
* I tried to reduce instances of the word “display” in light of recent
discussions about “enabling the user” rather than always talking bout
display of information. Nonetheless, some instances of “display” still
remain in the spec where they make sense.
* I added mention of HTTP Link headers for finding payment app manifest
files; we may or may not need that but I’m keeping this spec aligned
with the payment method stuff.
* I added mention of paymentRequestID and otherwise cleaned up
discussion of reconciliation.
* Now that we have canHandle I removed some other notes and provided a
forward reference to it.

* Edits based on recent changes and discussions

This was not a comprehensive review of the document. However, I
reviewed it in light of some recent decisions and did some updates:

* Given 4 January discussion about recommended payment apps, I reviewed
the text on that topic and made changes.
* I also cleaned up some text on registration given the new assumption
that registration IS a prerequisite for usage of a payment app that
conforms to this specification.
* It has also become clear that this specification is not designed to
address native payment apps, and so I deleted some text on native
payment apps, and also stated more clearly that those mechanisms lie
outside the scope of this document.
* IMPORTANT: It is my current understanding that a payment app
identifier will designate service worker code. Therefore, the spec now
says that; we’ll discuss whether this was the right edit at our 10
January call.
* I tried to reduce instances of the word “display” in light of recent
discussions about “enabling the user” rather than always talking bout
display of information. Nonetheless, some instances of “display” still
remain in the spec where they make sense.
* I added mention of HTTP Link headers for finding payment app manifest
files; we may or may not need that but I’m keeping this spec aligned
with the payment method stuff.
* I added mention of paymentRequestID and otherwise cleaned up
discussion of reconciliation.
* Now that we have canHandle I removed some other notes and provided a
forward reference to it.

* Updated formulation based on 10 January discussion

Comprehensive edit to clean up description of the model and how
recommended payment apps fit in:
 https://www.w3.org/2017/01/10-apps-minutes

* Move secure context note from intro to where the requirement is listed.

* Add link to issue 48 per AHB request

* - Removed quotes from names in registration example
- Add displayItems to 10.1 Payment App Request based on 17 Jan 2017 discussion
  https://www.w3.org/2017/01/17-apps-minutes.html#item05
- Typo fix

index.html

@@ -889,7 +889,7 @@ <h2>
  The <dfn
  id="payment-app-option-enabled-methods"><code>enabledMethods</code></dfn>
  member lists the <a>payment method identifiers</a> of the
- payment methods enabled by this option. See also the <a>canHandl</a> function, which enables payment app developers to specify in finer granularity the conditions under which the payment app supports a payment method.
+ payment methods enabled by this option. See also the <a>canHandle</a> function, which enables payment app developers to specify in finer granularity the conditions under which the payment app supports a payment method.
  </dd>
  </dl>
  </section>
@@ -906,12 +906,12 @@ <h3>
  name: "ExampleApp",
  icons: [
  {
- "src": "icon/lowres.webp",
- "sizes": "48x48",
- "type": "image/webp"
+ src: "icon/lowres.webp",
+ sizes: "48x48",
+ type: "image/webp"
  },{
- "src": "icon/lowres",
- "sizes": "48x48"
+ src: "icon/lowres",
+ sizes: "48x48"
  } ]
  options: [
  {
@@ -1157,9 +1157,12 @@ <h3>Payment App Request</h3>
  <code>total</code> field of the <code>PaymentDetails</code> provided
  when the corresponding <a>PaymentRequest</a> object was instantiated.
  </dd>
- <dd class="issue">Is the specification missing the top level "displayItems"?
- </dd>
- <dd class="issue">Keep an eye on <a href="https://github.com/w3c/browser-payment-api/issues/287">issue 287</a>. If the user agent generates a transaction ID, that ID must be passed to the payment app. If the merchant provides the transaction ID, that ID is already available through methodData.
+ <dt><code>displayItems</code></dt>
+ <dd>
+ The sequence of line items optionally provided by the payee. 
+ It is initialized with a <a>structured clone</a> of the
+ <code>displayItems</code> field of the <code>PaymentDetails</code> provided
+ when the corresponding <a>PaymentRequest</a> object was instantiated.
  </dd>
  <dt><code>modifiers</code> attribute</dt>
  <dd>