Copied from https://gerrit.wikimedia.org/r/c/mediawiki/core/+/434544/32/includes/Revision/SlotRoleRegistry.php#183, for further discussion here:

@Anomie:

I'm not so sure of this. A TemplateStyles stylesheet slot on a template should be allowed, but probably shouldn't be "desired" (most templates don't need one), but we certainly don't want to force TemplateStyles to make its own special page for adding and editing it and we do want to allow edits to templates that have a stylesheet to change both slots at once.

@daniel:

The intended use of "desired" is "automatically offered when creating and editing". If you want this to "just work" for TemplateStyles without any special cases or hooks, "then TemplateStyles would indeed be "desired".

Maybe "desired" sounds too strong, but I can't think of anything better. "Offered" would be then question when and where.

@Anomie:

I may have been misinterpreting the meaning of "desired". It sounds like you're saying that the difference between "desired" and "allowed" is just whether you can manipulate it via EditPage?

You have four levels defined here: "required", "desired", "allowed", and a default fourth level that I guess would be "disallowed". It seems like you may be conflating two different things in these levels that perhaps should be separate: whether the slot is required/optional/disallowed, and whether the slot can be manipulated by EditPage.

 "required": Slot is required. Whether it can be manipulated by EditPage is not clear.
"desired": Slot is optional, and can be manipulated by EditPage.
 "allowed": Slot is optional, and cannot be manipulated by EditPage.
 default: Slot is not allowed, and presumably cannot be manipulated by EditPage (other than deleting it, I guess). >

Perhaps what we should have here would be more like:

"required": Slot is required.
"recommended": Slot is optional. It should be added to new pages unless the user says not to.
"allowed": Slot is optional. It shouldn't be added to new pages unless the user says to.
Default is "disallowed": Slot isn't allowed.

plus

"editable": Slot may be editable via EditPage and ApiEditPage.
Default is "ignored": Slot is ignored by EditPage and ApiEditPage.

What "editable" actually means is intentionally non-specific at this level. When we get to the point of making EditPage's UI able to handle MCR, we'll probably wind up with a per-slot replacement for the 'AlternateEdit' hook that somehow defines an "editor" (which might not actually allow editing) for each editable slot on the page.

"editable": Slot may be editable via EditPage and ApiEditPage.
Default is "ignored": Slot is ignored by EditPage and ApiEditPage.

On second thought, maybe we should switch that. Have the default be "editable" and allow code to specify "ignored" as the special case.

FYI, my current vague conception for an EditPage UI is that it would include edit fields[1] for the slots currently on the page (maybe as a tabbed interface?[2]). Each optional slot would have a widget (a button or checkbox?) to allow it to be marked for deletion. And the UI would have a widget (a dropdown with an "Add" button?) for adding a new slot to the page if there are any optional slots that aren't already present.

[1]: Normally a textarea, or an enhanced textarea-like thing. But there's no particular reason it couldn't be a custom form, or even a notice that the slot isn't editable with a standalone rendering of the slot's content for reference. I'm not sure how VE would/should work, presenting a visual editor for the one slot versus continuing to override EditPage entirely.
[2]: For no-JS clients, we might just show all the tabs' contents serially as fieldsets, or make each "tab" a submit button so the server can serve the changed UI.

As stated in the task description, my idea was to somehow communicate which slots should be offered for editing. It's however unclear how that should be done for slots that do not support direct (text based) editing, unless we also provide a mechanism for EditPage plug-ins. Pragmatically, we'll need some way to determine for which slots to show text areas on edit page.

Note that this does not always mean that they can be edited atomically with the rest of the content, or that they can be edited using the standard EditPage at all. It just means that editing them should be offered to the user somehow.

This makes no sense to me. What does "offered for editing" actually mean in a practical sense? Why would some code somewhere call getDesiredSlots() instead of getAllowedSlots()?

In T209927#4763519, @Anomie wrote:

This makes no sense to me. What does "offered for editing" actually mean in a practical sense? Why would some code somewhere call getDesiredSlots() instead of getAllowedSlots()?

My thinking was that getAllowedSlots() may get you a rather long list of mostly irrelevant stuff, and would include that have no editing UI, or are intended for internal use. getDesiredSlots() is intended to provide a choice that is actually relevant to the user. But I agree that "relevant" depends on context, and trying to come up with something generic here was probably premature.

If we implement a multi-slot EditPage, we will however need some way to decide for which slots to show input fields, especially during page creation. Showing them for all allowed text based slots would quickly become overwhelming. At least on some types of pages, the user should not only be offered an input area for the main slot. And if we provide a way to add more input areas dynamically by letting the user pick from a list of slots to add, we may not want to offer all allowed slots there.

In T209927#4769515, @daniel wrote:

If we implement a multi-slot EditPage, we will however need some way to decide for which slots to show input fields, especially during page creation. Showing them for all allowed text based slots would quickly become overwhelming. At least on some types of pages, the user should not only be offered an input area for the main slot.

As I mentioned in T209927#4762624, I'd say we should show input fields (even if it's a read-only "field" of some sort) for any slot that's actually present on the page unless code specifically wants to hide it.

For page creations we'd need some way to specify which optional slots should be present in new revisions, which is what I originally thought your "desired" was for.

And if we provide a way to add more input areas dynamically by letting the user pick from a list of slots to add, we may not want to offer all allowed slots there.

We should indeed provide such a way, having input fields present for every non-existent slot would be strange and might confuse people into thinking they have to put something there.

Unless maybe a slot is specifically hidden or is strongly deprecated, why not offer it?