feat: add angus as author

Co-authored-by: Rowan Cockett <[email protected]>>

Author: agoose77

contributors.yml

@@ -49,3 +49,8 @@ project:
       orcid: 0000-0002-0760-5497
       affiliation: Curvenote Inc.
       email: [email protected]
+    - id: agoose77
+      name: Angus Hollands
+      github: agoose77
+      orcid: 0000-0003-0788-3814
+      affiliation: 2i2c

meps/mep-0003.md

@@ -6,10 +6,11 @@ title: Inline Options for Roles and Directives
 date: 2025/01/27
 authors:
   - rowanc1
+  - agoose77
 short_title: Inline Options
 description: An inline syntax for setting options on roles and directives.
 data:
-  discussion: 'https://github.com/jupyter-book/myst-enhancement-proposals/pull/28'
+  discussion: "https://github.com/jupyter-book/myst-enhancement-proposals/pull/28"
 abbreviations:
   DSL: Domain Specific Language
 ---
@@ -20,22 +21,26 @@ We propose an extension to the MyST Markdown syntax for roles and directives tha
 
 ## Context
 
-There is currently no syntax support for parametrising role definitions[^def] in MyST Markdown. This limitation has led to workarounds such as postfix role name conventions that conceptually group together related roles (e.g. `cite:ps`, `cite:t`), or the use of DSLs in the role body for parsing multiple values (e.g. `` {doc}`title <document.md>` ``). Given that these approaches are both unstandardized and limited in their extensibility, the lack of proper syntax support imposes strong contraints on the utility of roles. 
+There is currently no syntax support for parametrising role definitions[^def] in MyST Markdown. This limitation has led to workarounds such as postfix role name conventions that conceptually group together related roles (e.g. `cite:ps`, `cite:t`), or the use of DSLs in the role body for parsing multiple values (e.g. `` {doc}`title <document.md>` ``). Given that these approaches are both unstandardized and limited in their extensibility, the lack of proper syntax support imposes strong contraints on the utility of roles.
 
 [^def]: Where a role _definition_ is the appearance of the role in a MyST document, rather than the role _declaration_ which specifies its behaviour and interface.
 
 ## Proposal
 
 We propose extending the MyST Markdown syntax to support parametrisation of roles and directives. The existing syntax for defining a role and directive of the form
-````
+
+```
 {ROLE-NAME}`ROLE-BODY`
-````
+```
+
 and
+
 ````
 ```{DIRECTIVE-NAME}
 DIRECTIVE-BODY
 ```
 ````
+
 will be extended by replacing the `{NAME}` syntax of specifying role/directive names with a more general _inline attribute_ syntax of the form `{NAME .CLASS #ID KEY=VALUE}`. With this new syntax, it will be possible to directly define directive options in an inline manner, e.g. the following are equivalent:
 
 ````
@@ -54,16 +59,19 @@ Content of the tip directive.
 Content of the tip directive.
 ```
 ````
+
 where [](#new-syntax-example) is the new inline attribute syntax.
 
 ### Inline Attribute Syntax
 
-The internal inline syntax for specifying content will follow existing standards in [Pandoc](https://pandoc.org/chunkedhtml-demo/8.18-divs-and-spans.html)/[djot](https://htmlpreview.github.io/?https://github.com/jgm/djot/blob/master/doc/syntax.html#inline-attributes), with the addition of the role/directive name that already exists in MyST Markdown. 
+The internal inline syntax for specifying content will follow existing standards in [Pandoc](https://pandoc.org/chunkedhtml-demo/8.18-divs-and-spans.html)/[djot](https://htmlpreview.github.io/?https://github.com/jgm/djot/blob/master/doc/syntax.html#inline-attributes), with the addition of the role/directive name that already exists in MyST Markdown.
+
+In pseudo-grammar, the new inline attribute syntax may be expressed as
 
-In pseudo-grammar, the new inline attribute syntax may be expressed as 
 ```
 {NAME .CLASS #ID KEY=VALUE}
 ```
+
 where `NAME`, `.CLASS`, `#ID`, and `KEY=VALUE` are unique types of attribute definitions as follows:
 
 `NAME`
@@ -73,19 +81,17 @@ where `NAME`, `.CLASS`, `#ID`, and `KEY=VALUE` are unique types of attribute def
 : The name of a class to annotate the AST with. This **may** be (repeatedly) defined. Each defined class will be combined into a single whitespace-separated string and passed to the role or directive as the `class` option
 
 `#ID`
-: A unique label which will be passed to the role or directive as the `label` option. This **may** be defined **once**. If it is repeated, only the final label will be used and a warning will be raised. 
+: A unique label which will be passed to the role or directive as the `label` option. This **may** be defined **once**. If it is repeated, only the final label will be used and a warning will be raised.
 
 `KEY=VALUE`
 : A key-value pair to set as named options. A `KEY` **must** be defined **once** if the role definition marks the it as required, otherwise these **may** be defined **once**. Quotes are not needed when the`VALUE` consists entirely of ASCII alphanumeric characters or `_` or `:` or `-`. Backslash escapes may be used inside quoted values. These values are parsed according to the directive options (e.g. string, markup, number, etc.)
 
-
 Below is an example showing syntax that includes all extensions proposed here (this could apply to either a role or a directive):
 
 ```
 {name .classname #uniqueid key="value"}`some body markup`
 ```
 
-
 ## Examples
 
 ### Roles
@@ -132,7 +138,7 @@ Each of the above is useful and will continue to be supported. For example, the
 
 ## UX implications & migration
 
-The proposed syntax is an addition to existing role and directive patterns. It is a stricly non-breaking enhancement; existing MyST documents that use this syntax are currently considered invalid and should not successfully parse. It does not invalidate or change the behavior of any existing workflows. 
+The proposed syntax is an addition to existing role and directive patterns. It is a stricly non-breaking enhancement; existing MyST documents that use this syntax are currently considered invalid and should not successfully parse. It does not invalidate or change the behavior of any existing workflows.
 
 The inline attribute syntax adopts the same inline attribute syntax used by Pandoc, Quarto, and djot, with the exception that the inline attribute must start with the role/directive name. This change follows from adapting the reference syntax to MyST Markdown, which already implements extensibilty through nominal types (directives and roles) rather than compositional types (i.e. class names).
 
@@ -141,29 +147,35 @@ The inline attribute syntax adopts the same inline attribute syntax used by Pand
 We considered other approaches in this proposal and in discussion over several years. Including:
 
 1. extending the patterns used in Sphinx internal to the role content (`` {name}`content <argument .class1 key="value">` ``)
-2. attributes specified _after_ a role in addition to the name (`` {name}`content`{.class1 key="value"} ``); and 
+2. attributes specified _after_ a role in addition to the name (``{name}`content`{.class1 key="value"}``); and
 3. bracketed spans `[content]{.class}`
 
 We chose the current approach to (a) separate the options and content clearly (i.e. not 1); (b) to keep role names and options close together (i.e. not 2); and \(c) to leave future syntax options open (i.e. 3 is a possible future addition).
 
 ### Future Syntax Possibilities
 
 #### Parameterising Other Syntax Constructs
+
 This syntax is a stepping stone to other possible variants or additions to MyST, to be defined in future MEPs. For example, inline attributes for headers (e.g. `## My Header {#id .red}`), block attributes (e.g. preceding a block element with `{#id .red}=` (with or without the `=`), similar to the current `(label)=` syntax), or labelled spans/images/elements (e.g. `[content]{.red}` or `![](image.png){width="300px"}`).
 
 #### Short-hand Boolean Attibutes
+
 In certain markup languages, such as React JSX, it is possible to pass boolean `true` values simply by name, e.g.
+
 ```
 <FooComponent myProp />
 ```
+
 where `props.myProp` will be `true`. We might consider extending this syntax such that:
+
 ````
 ```{code .linenos}
 Numbered code directive
 
 Another line
 ```
 ````
+
 sets the `linenos` option to `true`.
 
 ## Questions or Objections Considered
@@ -179,4 +191,3 @@ We drew on prior art for inspiration and alignment, including:
 - Pandoc [bracketed spans](https://pandoc.org/MANUAL.html#extension-bracketed_spans)
 - MyST Python implementation [myst-parser](https://myst-parser.readthedocs.io/en/latest/syntax/optional.html#attributes)
 - https://michelf.ca/projects/php-markdown/extra/
-