Hope everyone's having a wonderful Mothers' Day weekend.
Here is a first pass at a specification for "invisible" twig extension. I omitted a reference to an example implementation since I expect we'll factor it into its own function.
Currently it is hard-coded into the twig extensions that use it.
Please let me know your thoughts.
Cheers,
Andrew Thorp
---
specifications/twig-extensions/invisible/index.md | 9 +++++++++specifications/twig-extensions/invisible/spec.toml | 5 +++++
2 files changed, 14 insertions(+)
create mode 100644 specifications/twig-extensions/invisible/index.md
create mode 100644 specifications/twig-extensions/invisible/spec.toml
diff --git a/specifications/twig-extensions/invisible/index.md b/specifications/twig-extensions/invisible/index.md
new file mode 100644
index 0000000..1557a4a
--- /dev/null+++ b/specifications/twig-extensions/invisible/index.md
@@ -0,0 +1,9 @@
+# Active Status+Twig metadata which indicates whether or not a message is intended to be rendered.+Field specification in [spec.toml](spec.toml).
I've been having a devil of a time making these relative links work.
Not sure what to do about them. This is more of an observation than
a request. I used this syntax in the other files. It's broken on the
man.sr.ht UI, but I don't know what else to do.
++## Usage+If a message is intended to be strictly metadata or is otherwise not supposed to+be rendered as a chat message, add the invisibility twig metadata to mark a+message as invisible. It is up to the client to implement how it handles an+"invisible" message, or if it even enforces it.
diff --git a/specifications/twig-extensions/invisible/spec.toml b/specifications/twig-extensions/invisible/spec.toml
new file mode 100644
index 0000000..9e6ab3a
--- /dev/null+++ b/specifications/twig-extensions/invisible/spec.toml
@@ -0,0 +1,5 @@
+key-name = "invisible"++[version.1.data]+type = "Byte Array"+description = "No additional metadata is provided, so these bytes are unused and usually empty."
I would prefer to require that the array contain no data. I can't think of
a use-case for putting data in there that isn't better addressed by a
separate twig extension or a new version of this one.