In general some ordering fixes would be good. E.g. the current spec splits up checking methodData into two locations of the algorithm, interspersing checks and processing of other arguments between them, which is just strange (and requires looping over the sequence twice). If there's a different ordering to the top-level "sections" desired, that'd be fine too. But the grouping here makes more sense than the current spec. In other words, this PR's ordering is: - allowed to use check - process payment methods - process the total - process displayItems - process shipping options - process payment details modifiers - process error Any reordering of these seems reasonable, although I think the allowed to use check should be first. But the current spec, which splits up several of these steps into two or three separate substeps which are then sprinkled around the algorithm, seems bad. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/browser-payment-api/pull/374#issuecomment-267190527
Received on Wednesday, 14 December 2016 23:34:53 UTC