Skip to content

Open/close design: A familiar HTML-like syntax as an alternative #516

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Nov 17, 2023
Merged

Open/close design: A familiar HTML-like syntax as an alternative #516

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
44a1770
Add an alternative: new declarations and a familiar syntax
stasm Nov 6, 2023
dba9f5a
Remove open/close declarations; I'll create a new design for them
stasm Nov 7, 2023
d38e954
Add a link to 518 about unquoted literals as operands
stasm Nov 9, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions exploration/open-close-expressions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@ Status: **Proposed**
<dt>Contributors</dt>
<dd>@eemeli</dd>
<dd>@aphillips</dd>
<dd>@stasm</dd>
<dt>First proposed</dt>
<dd>2023-09-05</dd>
<dt>Pull Request</dt>
Expand Down Expand Up @@ -220,3 +221,51 @@ Rendered as React this could become:
_What other solutions are available?_
_How do they compare against the requirements?_
_What other properties they have?_

### HTML-like syntax

The goal of this solution is to avoid adding new sigils to the syntax.
Instead, it leverages the familiarity of the `foo`...`/foo` idiom,
inspired by HTML and BBCode.

This solution consists of adding new placeholder syntax:
`{foo}`, `{/foo}`, and `{foo/}`.

```
This is {html:strong}bold{/html:strong} and this is {html:img alt=|an image|/}.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we required the namespace prefix for spannables, that eliminates the problem with unquoted literals (at the cost of some lookahead when parsing). But it would make for some confusion in the regular syntax. Don't forget that we allow {:function no=operand} and this looks like an open (is it a syntax error to omit the / at the end?)

```

Markup names are *effectively namespaced* due to their not using any sigils;
they are distinct from `$variables`, `:functions`, and `|literals|`.

> [!NOTE]
> This requires dropping unquoted literals as operands,
> so that `{foo}` is not parsed as `{|foo|}`.
Comment on lines +241 to +243
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is relatively difficult to contemplate. We will want unquoted literals for keys. Is unquoted literals for operands different enough a use case?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I think I agree. Expressions basically break down into

  • literal with optional function
  • variable with optional function
  • operand-free function
  • spannable open/close

If both variables and functions use a sigil, then I think spannables should as well, leaving literals as the sole sigil-free expression contents (and with consistent quoting requirements regardless of where they appear).

Copy link
Collaborator Author

@stasm stasm Nov 8, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I filed #518 to discuss this further, orthogonally to this PR.

> See [#518](https://github.com/unicode-org/message-format-wg/issues/518).

The exact meaning of the new placeholer types is as follows:

* `{foo}` is a span-open.
* `{/foo}` is a span-close.
* `{foo/}` is a standalone element.

#### Pros

* Doesn't add new sigils except for `/`,
which is universally known thanks to the wide-spread use of HTML.

* Using syntax inspired by HTML makes it familiar to most translators.
Prior art for a similar inspiration can be found in the [BBCode](https://en.wikipedia.org/wiki/BBCode) syntax,
which uses `[foo]` and `[/foo]` as tags.
Despite being a niche language, BBCode can be argued to be many people's first introduction to markup-like syntax.

* Avoids the issues of using JSX-style syntax, `<foo>`...`</foo>`,
which looks *exactly* like HTML, but has different semantics and behavior.

#### Cons

* May still be confusing because it looks almost like HTML, but doesn't use the familiar angle brackets.

* Requires changes to the existing MF2 syntax: dropping unquoted literals as expression operands.

* Regular placeholders, e.g. `{$var}`, use the same `{...}` syntax, and may be confused for *open* elements.