Bikeshed: Document Policy terminology

[clelland]

So, feature is a heavily overloaded term, and I'd at least like to not make it unnecessarily worse -- as I've been moving "features" from Feature Policy to Document Policy, I've realized that a number of them are not "features" in any real sense, they're more like changeable defaults, or configurable behaviours.

I'm proposing the term "configuration point" to describe what has previously been a "feature" in document policy -- examples in development right now would be:

• Maximum bits-per-pixel for images
• Maximum image downscaling ratio
• Image and frame loading behaviour (eager vs lazy)
• Availability of synchronous xhr
• To be maximally inclusive, the term should cover existing and new sandbox features as well (and there I go, saying 'feature' again)

In this world, specs integrating with document policy would define configuration points. A policy would be a mapping of configuration points to policy values. Configuration points have a type (int, bool, float, enum, etc) and a range, which would be a subset of all values expressible by that type, and the policy values would be elements of that range.

Opinions welcomed :)

[annevk]

Should it also be named "Configuration Policy" as presumably we also want this for workers, not just documents?

[mikewest]

Naaaaaaames. Ugh. With the caveat that we should just land on something and run with it quickly (since I think Chrome is already shipping this to allow control over text snippet navigation? Is that right, Ian?)

"Configuration Policy" is somewhat repetitive, because the policy is a configuration, and too generic, since permissions policy seems like it's also "configuring" in some relevant sense.

"WindowOrWorkerGlobalScope mixin Policy" is... verbose. And also what about worklets?

"Feature Policy" seems accurate, but would be... confusing.

"Policy That Affects a Single Global" is also verbose.

Idunno. "Global Policy" is the best of my bad ideas at the moment, but it's terrible because no one would recognize "Global" as being a thing and not everything. "Global Object Policy" isn't any better (because it can just as easily be a global object-policy).

/cc @camillelamy who I think also has thoughts here.

[camillelamy]

Would "Context Policy" cover both documents and workers? Since it configures the context in which things will execute. "WindowOrWorkerGlobalScope mixin Policy" while accurate is definitely too long :).

[annevk]

My main worry is that "Context" is somewhat overloaded, but that might also make it okay. "Environment" might be another term we could repurpose. cc @domenic

[mikewest]

"Environment" isn't bad... do environment settings objects span realms? That is, could we have more than one environment in a given document/worker? If not, it's a pretty reasonable match from a textual perspective.

[annevk]

They're 1:1 with realms and 1:1 with globals. If JavaScript gains constructable realms that would probably no longer be the case, but I think that matches what we'd want for this (in that a realm and a realm constructed in that realm would share the environment).

[otherdaniel]

I've been looking at this lately, and wonder if there's been any progress with the naming? Is document-policy: okay?

---

More proposals:

• If an individual setting is called a "configuration point" and we're happy with that, then I'd call the entire thing a "configuration set" and wiould just drop any mention of "document", or "policy", or "feature". Config-Set: would make a nice header.
• If we insist on referencing documents and workers, we could abbreviate "Document and Worker Policy" to "Dorker Policy", or just "Dorkercy". :)

[clelland]

I'd really rather not rename the whole spec, and Chrome at least has already shipped the Document-Policy header. (I'd like to think I've learned from the painful change we took everyone through with Feature → Permissions Policy), and I'd really not like the spectre of a possible rename to delay progress on other issues.

[annevk]

It's not clear to me how that name works given workers.

[annevk]

@clelland can you clarify whether that's Google's position? I guess one alternative here would be that we keep calling it document policy, but for workers we call it worker policy, and for worklets worklet policy. And they each get their own header.