From 44a177035777a792424bed563136fa20aa8dcf99 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stanis=C5=82aw=20Ma=C5=82olepszy?= Date: Mon, 6 Nov 2023 20:54:21 +0100 Subject: [PATCH 1/3] Add an alternative: new declarations and a familiar syntax --- exploration/open-close-expressions.md | 68 +++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) diff --git a/exploration/open-close-expressions.md b/exploration/open-close-expressions.md index 4e853a5888..d1ee25f5d3 100644 --- a/exploration/open-close-expressions.md +++ b/exploration/open-close-expressions.md @@ -8,6 +8,7 @@ Status: **Proposed**
Contributors
@eemeli
@aphillips
+
@stasm
First proposed
2023-09-05
Pull Request
@@ -220,3 +221,70 @@ Rendered as React this could become: _What other solutions are available?_ _How do they compare against the requirements?_ _What other properties they have?_ + +### New declarations and a familiar syntax + +The goal of this solution is to avoid adding new sigils to the syntax. +Instead, it leverages *keywords* as the tool for qualifying certain placeholders as open, close, or standalone, +combined with familiar HTML-inspired syntax. + +This solution consists of adding: + +* Two new declaration types called `openclose` and `standalone`. +* New placeholder syntax: `{foo}`, `{/foo}`, and `{foo/}`. + + +> [!NOTE] +> This require dropping unquoted literals as operands, +> so that `{foo}` is not parsed as `{|foo|}`. + +``` +{{ + openclose {html:strong class=foo onclick=bar} + standalone {html:img src=http://example.com} + {{This is {html:strong}bold{/html:strong} and this is {html:img alt=|an image|/}.}} +}} +``` + +Similar to `input` declarations, markup declarations are optional. +If they’re absent, then any `{foo}` is interpreted as a span-open, any `{/foo}` as a span-close, and `{foo/}` as a standalone element. +If declarations are present, they specify the kind of markup precisely, +making `{strong/}` and `{img}` and `{/img}` invalid in the example above. +Additionally, declarations allow adding non-localizable attributes to markup elements. + +Declarations could optionally specify a local element name bound to a particular element expression. +This would allow creating shorter aliases for namespaced elements, +as well as binding more than one element expression. + +``` +{{ + standalone img1 = {html:img src=http://example.com/image1.png} + standalone img2 = {html:img src=http://example.com/image2.png} + {{There are {img1/} and {img2/} here.}} +}} +``` + +#### Pros + +* Doesn't add new sigils except for `/`, + which is universally known thanks to the wide-spread use of HTML. + +* Leverages an existing mechanism of using optional declarations to aid the tooling usecases. + Compare how `input` declarations can be used to augment messages. + +* Using syntax inspired by HTML should make 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. + +* Avoids the issues of using JSX-style syntax, ``...``, + 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. + +* Using declarations is verbose. From dba9f5a83c6beef6c3bb173568ae1e190a4f827c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stanis=C5=82aw=20Ma=C5=82olepszy?= Date: Tue, 7 Nov 2023 22:11:39 +0100 Subject: [PATCH 2/3] Remove open/close declarations; I'll create a new design for them --- exploration/open-close-expressions.md | 54 +++++++++------------------ 1 file changed, 17 insertions(+), 37 deletions(-) diff --git a/exploration/open-close-expressions.md b/exploration/open-close-expressions.md index d1ee25f5d3..3f6c7a51a7 100644 --- a/exploration/open-close-expressions.md +++ b/exploration/open-close-expressions.md @@ -222,59 +222,41 @@ _What other solutions are available?_ _How do they compare against the requirements?_ _What other properties they have?_ -### New declarations and a familiar syntax +### HTML-like syntax The goal of this solution is to avoid adding new sigils to the syntax. -Instead, it leverages *keywords* as the tool for qualifying certain placeholders as open, close, or standalone, -combined with familiar HTML-inspired syntax. +Instead, it leverages the familiarity of the `foo`...`/foo` idiom, +inspired by HTML and BBCode. -This solution consists of adding: +This solution consists of adding new placeholder syntax: +`{foo}`, `{/foo}`, and `{foo/}`. -* Two new declaration types called `openclose` and `standalone`. -* New placeholder syntax: `{foo}`, `{/foo}`, and `{foo/}`. +``` +This is {html:strong}bold{/html:strong} and this is {html:img alt=|an image|/}. +``` +Markup names are *effectively namespaced* due to their not using any sigils; +they are distinct from `$variables`, `:functions`, and `|literals|`. > [!NOTE] -> This require dropping unquoted literals as operands, +> This requires dropping unquoted literals as operands, > so that `{foo}` is not parsed as `{|foo|}`. -``` -{{ - openclose {html:strong class=foo onclick=bar} - standalone {html:img src=http://example.com} - {{This is {html:strong}bold{/html:strong} and this is {html:img alt=|an image|/}.}} -}} -``` - -Similar to `input` declarations, markup declarations are optional. -If they’re absent, then any `{foo}` is interpreted as a span-open, any `{/foo}` as a span-close, and `{foo/}` as a standalone element. -If declarations are present, they specify the kind of markup precisely, -making `{strong/}` and `{img}` and `{/img}` invalid in the example above. -Additionally, declarations allow adding non-localizable attributes to markup elements. +The exact meaning of the new placeholer types is as follows: -Declarations could optionally specify a local element name bound to a particular element expression. -This would allow creating shorter aliases for namespaced elements, -as well as binding more than one element expression. - -``` -{{ - standalone img1 = {html:img src=http://example.com/image1.png} - standalone img2 = {html:img src=http://example.com/image2.png} - {{There are {img1/} and {img2/} here.}} -}} -``` +* `{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. -* Leverages an existing mechanism of using optional declarations to aid the tooling usecases. - Compare how `input` declarations can be used to augment messages. - -* Using syntax inspired by HTML should make it familiar to most translators. +* 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, ``...``, which looks *exactly* like HTML, but has different semantics and behavior. @@ -286,5 +268,3 @@ as well as binding more than one element expression. * 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. - -* Using declarations is verbose. From d38e9541cb9db673be6707891af9c478c2c5d975 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stanis=C5=82aw=20Ma=C5=82olepszy?= Date: Thu, 9 Nov 2023 10:23:32 +0100 Subject: [PATCH 3/3] Add a link to 518 about unquoted literals as operands --- exploration/open-close-expressions.md | 1 + 1 file changed, 1 insertion(+) diff --git a/exploration/open-close-expressions.md b/exploration/open-close-expressions.md index 3f6c7a51a7..fe22fc3c8c 100644 --- a/exploration/open-close-expressions.md +++ b/exploration/open-close-expressions.md @@ -241,6 +241,7 @@ they are distinct from `$variables`, `:functions`, and `|literals|`. > [!NOTE] > This requires dropping unquoted literals as operands, > so that `{foo}` is not parsed as `{|foo|}`. +> See [#518](https://github.com/unicode-org/message-format-wg/issues/518). The exact meaning of the new placeholer types is as follows: