[Discussion] {{Spannables}}

[aphillips]

Per the 2023-11-27 teleconference, this issue is for discussing the design of spannables (also known as open/close/standalone markup).

The design document lives here and should be used as a reference in this discussion.

[aphillips]

(chair hat on)

There is a proposal to use option A4 "Hash and Slash" as the design based on a tepid "lack of opposition" consensus in the 2023-11-20 call, so perhaps pay close attention to this option, even though the design document uses the +/-/# sigils in examples. We merged #535 which makes "Hash and Slash" the design option per 2023-11-27 call, but the options available for discussion remain the same.

The foregoing is not a finding of consensus. Our goal will be to choose an approach in the 2023-12-04 call. The more and better we discuss ahead of that, the better.

[eemeli]

I'm ok with the currently proposed syntax.

My personal preference order for these choices is:

1. <foo>…</foo> — In practice, this is the syntax currently used by markup in messages, and it's almost universally recognised as such. And while its origins are in XML, it's currently widely used at least as XML, HTML, and JSX, with slightly different parsing rules in each. I honestly think this would be the least surprising choice for users, and this would explicitly require those who wish to re-parse their output rather than formatting it to parts to do some heavier lifting rather than being able to default to this syntax, should we choose something else.
2. {+foo}…{-foo} — If we need to go with curly braces, this is pretty good. It's what's in the spec right now, and the +/- pairing is pretty self-evident. Yes, it means that the rules need some fiddling to still allow for the really rare literal negative number operand, but I don't see that as a real cost to humans: -foo and -42 "read" differently, with the first one seeming to have two separate tokens - and foo, while -42 is a single number.
3. {#foo}…{/foo} — It's fine, and works. It replaces the - problem by reusing what's control flow syntax elsewhere, but maybe that's not such a bad thing? It does mean that others who also wanted to span a pattern with some open/close indicators ended up with this syntax.
4. {foo}…{/foo} — Unlike with all the other options, there's nothing about a bare {foo} that primes you as the reader to expect it to 1) not render in text and 2) start something. Especially if we still allow numbers so {42} would parse and render as a placeholder. To make this option work, we need to get rid of unquoted literals, or at least the non-numeric ones. And if we do that, then I'd prefer that we use some sigil at the start, and that brings us to one of the two preceding options.
5. [foo]…[/foo] — If we're going to go beyond curly braces, let's just go with angle brackets. Outside of their use as markup, angle brackets are way less common in real-world text than square brackets (not going to dig up numbers, because it seems no-one else cares about data) and more surprising to need special treatment in syntax.

I don't have a strong stance on standalone markup, except to note that it's much less common in practice than open-close pairs, and that its use cases can be accounted for by either a purpose-built {:function} or an opening element like <foo>. With the {+foo} syntax in particular it does feel a bit clumsy as the + kinda expects the subsequent - to balance out (absolutely a feature, btw), so if we go with that I'd be more open than with the others to considering separate standalone syntax; the design doc includes {#foo} for that alternative.

As far as I can tell, the only place where using the same syntax for open & standalone adds some friction is for source message validators that do not access a registry and which do want to require open-close pairing within each single message. In all other cases, we can rely on the registry, the source message, or the implementation to tell us whether the element is open or standalone.

So for me the cost-benefit analysis of standalone markup makes it a pretty expensive addition providing rather little gain.

[aphillips]

@eemeli mentions:

… — In practice, this is the syntax currently used by markup in messages, and it's almost universally recognised as such.

Note that this "works" in our current syntax without any changes, since nothing prevents the literal part of a pattern from containing markup. However, the markup doesn't participate in formatting in any way. Making it participate in formatting would require recognizing sigils < and > and add more escaped to our syntax to account for it.

I generally agree with your other comments.

As far as I can tell, the only place where using the same syntax for open & standalone adds some friction is for source message validators that do not access a registry...

I think it would be useful to add an example, such as "If tool preparing a message for translation adds XLIFF around placeholders, it might need to know if the placeholder is paired or not, as this affects which tags are generated, even if the tool doesn't know the tag set being marked up"

[aphillips]

Some observations.

In the design doc, we currently have name for markup productions and I think this should be changed to identifier to ensure that namespaces are permitted:

markup-open  = "#" name ; should be identifier
markup-close = "/" name   ; should be identifier

---

The primary "disagreement" we have is about the fate of standalone. Hash-and-slash allows open (or close) placeholders to appear unpaired and @eemeli proposes that we just let # be standalone. Assuming that we buy into the cases for separating standalone syntax, the cost of adding standalone is simply one more sigil. Could we agree to choose one more sigil for "standalone" and made it identical to markup-open save for the "standalone" connotation in the data model?