Retitle the Permissions spec to emphasize the infrastructure more.

[jyasskin]

Like https://storage.spec.whatwg.org/, this spec defines both an API and
common terminology and infrastructure that can underpin other
specifications.

Preview at https://rawgit.com/jyasskin/permissions/retitle/index.html.

I'll also rearrange some of the sections to more clearly separate the API from the infrastructure, but I'd like to be sure the renaming has general agreement first, so I don't need to maintain a reordering in a long-lived branch.

[martinthomson]

LGTM.

BTW, including build output in the repo adds a lot of noise to diffs; is that a common arrangement with BS specs?

[jyasskin]

Conventions vary: @domenic prefers having TravisCI auto-generate the output into the gh-pages branch, but I like showing you what the change winds up looking like. (The rawgit link would be more difficult without including the build output in the change.) It's straightforward to switch if other people prefer the opposite convention.

[marcoscaceres]

I agree with @domenic's model. In other places, we've experienced problems with people editing the output document instead of the BS doc. The generated output diff is not very useful: only useful for debugging BS, really - but not for reviewing spec changes (as the generated markup makes it very difficult to review any changes, so it verges on the meaningless).

[marcoscaceres]

(I would go a little further than @domenic and say that the generated output should not appear in the repo at all.. it should only end up on the web server)

[mounirlamouri]

I agree with @marcoscaceres. I wonder if we could make 'master' the default branch and have travis generate the HTML file and commit to gh-pages.

[mounirlamouri]

Regardless, I think we can merge this :)

[jan-ivar]

Just wanted to point out, in case it wasn't obvious to everyone involved, that this "renaming" expanded the scope of the proposed API, from a passive read-only API to an active one (emphasis mine):

From:

Abstract: The Permissions API _allows a web application to be aware of the status of a given permission_, to know whether it is granted, denied or if the user will be asked whether the permission should be granted.

To:

Abstract: The Permissions Standard defines common infrastructure for other specifications that need to interact with browser permissions. It also defines an API _to allow web applications to query and request changes to the status of a given permission_.

I clearly don't understand your consensus building process, since I've seen no activity lately other than me and others protesting this direction, but thought I'd leave a record.

[jyasskin]

@jan-ivar That part of the scope expanded in 8cd7a97 almost a year ago. This change expands a different part of the scope: we're now explicitly aiming to be critical infrastructure for other specs.

[jan-ivar]

@jyasskin I think you mean the spec has been inconsistent about its scope for almost a year. You removed this disclaimer just 7 days ago:

The initial intent of this document was to allow web applications to request and revoke permissions explicitly in addition to querying the permission status. This is an aspect of the specification that was controversial thus removed from the current document in a spirit of incremental changes: settling on a small API that can be improved.

Whenever we reach some consensus, it's surely based on the documents as written. Poor terminology and conflicting language undermines whether consensus was achieved in the first place. What percentage of participants over the last year read this document and thought they were agreeing to a passive API only?

I would argue these types of changes are substantive rather than editorial, when they alter the basis on which consensus may have been reached. I think this group needs to re-verify its assumptions.