873512 - Enable KumaScript to send options & flags back to Kuma

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: General, defect, P2)

Description

[Les Orchard [:lorchard]]

What problems would this solve?
===============================
As an example, control over the table of contents for a document is currently done with a drop down in the editor.

What might be interesting is if it instead worked by adding a macro like {{ ShowToc }} or {{ ShowToc({level: 2}) }} to the top of the document content.

That macro would then call an internal API that sends a ShowToc: true or ShowToc: 2 option back to Kuma that it would use at rendering time, rather than the document's database column

This convention would allow us to add further "global" document options without adding a pile of checkboxes and dropdown to the editor, and more flags in the database.

Of course, this means the options would need to be documented, and would not be discoverable as UI elements. But, that might be an alright tradeoff

Who would use this?
===================
Wiki authors

What would users see?
=====================
Fewer UI elements on the editor page

What would users do? What would happen as a result?
===================================================
Wiki authors could use kumascript macros in documents that affect overall document layout beyond the content area.

Is there anything else we should know?
======================================
KumaScript has a request headers mechanism to accept options & metadata from Kuma on page rendering. We use this to pass information like tags, title, URL, author, etc.

The reverse also exists - i.e. sending data from kumascript back to kuma in the response. We just haven't used it for anything other than errors, so far. This bug would rely on that channel.

Comment 1

[Eric Shepherd [:sheppy]]

I suspect this would be useful for the zone system, so making this a blocker for that.