From c63f9271363b5174be5658e78302ad8b98b48e65 Mon Sep 17 00:00:00 2001 From: Eemeli Aro Date: Tue, 5 Sep 2023 12:16:34 +0300 Subject: [PATCH 01/17] Start open/close design doc with HTML markup requirements, constraints & proposed design --- exploration/0005-open-close-expressions.md | 134 +++++++++++++++++++++ 1 file changed, 134 insertions(+) create mode 100644 exploration/0005-open-close-expressions.md diff --git a/exploration/0005-open-close-expressions.md b/exploration/0005-open-close-expressions.md new file mode 100644 index 0000000000..2dfccd9ff1 --- /dev/null +++ b/exploration/0005-open-close-expressions.md @@ -0,0 +1,134 @@ +# Open/Close Expressions + +Status: **Proposed** + +
+ Metadata +
+
Contributors
+
@eemeli
+
First proposed
+
2023-09-05
+
Pull Request
+
#000
+
+
+ +## Objective + +_What is this proposal trying to achieve?_ + +## Background + +_What context is helpful to understand this proposal?_ + +## Use-Cases + +- Representing markup, such as HTML + +## Requirements + +Be able to indicate that some identified markup applies to +a non-empty sequence of pattern parts (text, expressions). + +Markup spans may be nested, +as in `Bold and also italic`. + +Markup spans may be improperly nested, +as in `Bold and italic`. + +Markup may have localisable options, +such as `Click here to continue`. + +As with function options, +markup options should be defined in a registry so that they can be validated. + +## Constraints + +Due to segmentation, +markup may be split across messages so that it opens in one and closes in another. + +Following previously established consensus, +the resolution of the value of an _expression_ may only depend on its own contents, +without access to the other parts of the selected pattern. + +## Proposed Design + +This design relies on the recognition that the formatted output of MF2 +may be further processed by other tools before presentation to a user. + +Let us add _markup_ as a new type of _expression_, +in parallel with _annotation_: + +```abnf +expression = "{" [s] expression-body [s] "}" +expression-body = (operand [s annotation]) + / annotation + / markup + +annotation = (function *(s option)) + / reserved + / private-use +markup = (markup-start *(s option)) + / markup-end + +function = ":" name +markup-start = "+" name +markup-end = "-" name +``` + +This allows for expressions like `{+b}`, `{-i}`, and `{+a title=|Link tooltip|}`. +Unlike annotations, markup expressions may not have operands. + +Markup expressions do not support selection. + +When formatting to a string, +markup expressions format to an empty string by default. +An implementation may customize this behaviour, +e.g. emitting XML-ish tags for each start/end expression. + +When formatting to parts (as proposed in #463), +markup expressions format to an object including the following properties: + +- The `type` of the markup: `"start" | "end"` +- The `name` of the markup, e.g. `"b"` for `{+b}` +- For _markup-start_, the `options` with the resolved key-value pairs of the expression options + +To make use of _markup_, +the message should be formatted to parts or to some other target supported by the implementation, +and the desired shape constructed from the parts. +For example, the message + +``` +{Click {+a title=|Link tooltip|}here{-a} to continue} +``` + +would format to parts as + +```coffee +[ + { type: "text", value: "Click " }, + { type: "start", name: "a", options: { title: "Link tooltip" } }, + { type: "text", value: "here" }, + { type: "end", name: "a" }, + { type: "text", value: " to continue" } +] +``` + +and a post-MessageFormat step could then reconstruct this into an appropriate shape, +potentially merging in non-localizable attributes such as a link URL. +Rendered as React this could become: + +```coffee +[ + "Click ", + createElement("a", { href: "/next", title: "Link tooltip" }, "here"), + " to continue" +] +``` + +## Alternatives Considered + +_What other solutions are available?_ +_How do they compare against the requirements?_ +_What other properties they have?_ From 195c9ba8cee5bd45015a4b898ae0da9d63fa94cc Mon Sep 17 00:00:00 2001 From: Addison Phillips Date: Tue, 5 Sep 2023 07:23:14 -0700 Subject: [PATCH 02/17] Update 0005-open-close-expressions.md Add some of the use cases we discussed previously (in a way that makes their relationship to the proposed design clear). Flesh out some text. --- exploration/0005-open-close-expressions.md | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/exploration/0005-open-close-expressions.md b/exploration/0005-open-close-expressions.md index 2dfccd9ff1..5c61a807bf 100644 --- a/exploration/0005-open-close-expressions.md +++ b/exploration/0005-open-close-expressions.md @@ -7,6 +7,7 @@ Status: **Proposed**
Contributors
@eemeli
+
@aphillips
First proposed
2023-09-05
Pull Request
@@ -18,13 +19,30 @@ Status: **Proposed** _What is this proposal trying to achieve?_ +Describe the use cases and requirements for _expressions_ +that enclose parts of a pattern +and develop a design that satisfies these needs. + ## Background _What context is helpful to understand this proposal?_ ## Use-Cases -- Representing markup, such as HTML +- Representing markup, such as HTML, as expressions in a pattern + rather than as plain character sequences embedded in the _text_ + of a pattern. This also allows parts of a markup sequence to be + programmable. + +**_Non-markup use cases to consider (which are not addressed by the design)_** + +- Represent templating language constructs so that they can pass through + the translation process and are not exposed to translation. For example, + Mustache templates. + +- Represent translation metadata, such as XLIFF placeholders, so that + portions of a message are "protected" or otherwise hinted in the + translation process. ## Requirements From 24bdb4cb19c1966419081a69f748a6bbb49f3b0a Mon Sep 17 00:00:00 2001 From: Eemeli Aro Date: Tue, 5 Sep 2023 18:06:25 +0300 Subject: [PATCH 03/17] Fix links --- exploration/0005-open-close-expressions.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/exploration/0005-open-close-expressions.md b/exploration/0005-open-close-expressions.md index 5c61a807bf..5cd91e844f 100644 --- a/exploration/0005-open-close-expressions.md +++ b/exploration/0005-open-close-expressions.md @@ -11,7 +11,7 @@ Status: **Proposed**
First proposed
2023-09-05
Pull Request
-
#000
+
#470
@@ -105,7 +105,7 @@ markup expressions format to an empty string by default. An implementation may customize this behaviour, e.g. emitting XML-ish tags for each start/end expression. -When formatting to parts (as proposed in #463), +When formatting to parts (as proposed in #463), markup expressions format to an object including the following properties: - The `type` of the markup: `"start" | "end"` From dfdbc63618a67e5e01852c71823c14e9cb57f750 Mon Sep 17 00:00:00 2001 From: Addison Phillips Date: Tue, 5 Sep 2023 08:29:29 -0700 Subject: [PATCH 04/17] Address comment --- exploration/0005-open-close-expressions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/exploration/0005-open-close-expressions.md b/exploration/0005-open-close-expressions.md index 5cd91e844f..aa9da608f8 100644 --- a/exploration/0005-open-close-expressions.md +++ b/exploration/0005-open-close-expressions.md @@ -34,7 +34,7 @@ _What context is helpful to understand this proposal?_ of a pattern. This also allows parts of a markup sequence to be programmable. -**_Non-markup use cases to consider (which are not addressed by the design)_** +**_Non-markup use cases to consider (which may or may not be addressed by the design)_** - Represent templating language constructs so that they can pass through the translation process and are not exposed to translation. For example, From 3368146cd7daa56a1efae7db2913ac2f38960f32 Mon Sep 17 00:00:00 2001 From: Eemeli Aro Date: Sun, 10 Sep 2023 17:48:43 +0200 Subject: [PATCH 05/17] Restrict markup to placeholders only --- exploration/0005-open-close-expressions.md | 32 +++++++++------------- 1 file changed, 13 insertions(+), 19 deletions(-) diff --git a/exploration/0005-open-close-expressions.md b/exploration/0005-open-close-expressions.md index aa9da608f8..f510397fd8 100644 --- a/exploration/0005-open-close-expressions.md +++ b/exploration/0005-open-close-expressions.md @@ -75,38 +75,32 @@ without access to the other parts of the selected pattern. This design relies on the recognition that the formatted output of MF2 may be further processed by other tools before presentation to a user. -Let us add _markup_ as a new type of _expression_, -in parallel with _annotation_: +Let us add _markup_ as a new type of _placeholder_, +in parallel with _expression_: ```abnf -expression = "{" [s] expression-body [s] "}" -expression-body = (operand [s annotation]) - / annotation - / markup - -annotation = (function *(s option)) - / reserved - / private-use -markup = (markup-start *(s option)) - / markup-end - -function = ":" name +pattern = "{" *(text / placeholder) "}" +placeholder = expression / markup + +markup = "{" [s] markup-body [s] "}" +markup-body = (markup-start *(s option)) + / markup-end markup-start = "+" name markup-end = "-" name ``` -This allows for expressions like `{+b}`, `{-i}`, and `{+a title=|Link tooltip|}`. +This allows for placeholders like `{+b}`, `{-i}`, and `{+a title=|Link tooltip|}`. Unlike annotations, markup expressions may not have operands. -Markup expressions do not support selection. +Markup is not valid in _declarations_ or _selectors_. When formatting to a string, -markup expressions format to an empty string by default. +markup placholders format to an empty string by default. An implementation may customize this behaviour, -e.g. emitting XML-ish tags for each start/end expression. +e.g. emitting XML-ish tags for each start/end placeholder. When formatting to parts (as proposed in #463), -markup expressions format to an object including the following properties: +markup placeholders format to an object including the following properties: - The `type` of the markup: `"start" | "end"` - The `name` of the markup, e.g. `"b"` for `{+b}` From 1e0057e2843ec0365d59fb0bb54a10d9aa0c50c7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stanis=C5=82aw=20Ma=C5=82olepszy?= Date: Sun, 10 Sep 2023 18:04:03 +0200 Subject: [PATCH 06/17] Draft of use-cases from the face to face --- exploration/0005-open-close-expressions.md | 43 ++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/exploration/0005-open-close-expressions.md b/exploration/0005-open-close-expressions.md index f510397fd8..b02fdefd01 100644 --- a/exploration/0005-open-close-expressions.md +++ b/exploration/0005-open-close-expressions.md @@ -34,6 +34,49 @@ _What context is helpful to understand this proposal?_ of a pattern. This also allows parts of a markup sequence to be programmable. +- As an app author, I want to be able to use minimal markup for formatting. + On runtime, I expect these markup elements to produce live UI elements. + + > ``` + > {Click {+link}here{-link}.} + > ``` + +- I want to be able to use minimal markup to inform XLIFF interchange. + + > ``` + > {Click {+ph}here{-ph}.} + > ``` + +- As an app author, I want to be able to pass certain attributes to markup elements, including dynamic values, such as coming from varriables. + + > ``` + > {Click {+link href=$url}here{-link}.} + > ``` + +- As a translator, I want to be able to translate content around and between markup elements. + + > ``` + > {Kliknij {+link}tutaj{-link}.} + > ``` + +- As a translator, I want to be able to translate certain markup attributes. + + > ``` + > {Click {+link title=|Hey you!|}here{-link}} + > ``` + +- As developers and translators, I want to protect placeholders from modification and deletion. + +- Paired markup elements should be protected from reordering, i.e. an open element must always come before the close element (if they are both present in the message). + +- Use TTS annotations. + +- Attributed strings (overlapping, enclosing). + +- TTY formatting escapes (?!) + +- Segmented markup. + **_Non-markup use cases to consider (which may or may not be addressed by the design)_** - Represent templating language constructs so that they can pass through From 53ad7e3879540b77bef6ea4612a1205920b65aa9 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Sun, 10 Sep 2023 16:04:41 +0000 Subject: [PATCH 07/17] style: Apply Prettier --- exploration/0005-open-close-expressions.md | 30 +++++++++++----------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/exploration/0005-open-close-expressions.md b/exploration/0005-open-close-expressions.md index b02fdefd01..cd55ac773f 100644 --- a/exploration/0005-open-close-expressions.md +++ b/exploration/0005-open-close-expressions.md @@ -37,33 +37,33 @@ _What context is helpful to understand this proposal?_ - As an app author, I want to be able to use minimal markup for formatting. On runtime, I expect these markup elements to produce live UI elements. - > ``` - > {Click {+link}here{-link}.} - > ``` + > ``` + > {Click {+link}here{-link}.} + > ``` - I want to be able to use minimal markup to inform XLIFF interchange. - > ``` - > {Click {+ph}here{-ph}.} - > ``` + > ``` + > {Click {+ph}here{-ph}.} + > ``` - As an app author, I want to be able to pass certain attributes to markup elements, including dynamic values, such as coming from varriables. - > ``` - > {Click {+link href=$url}here{-link}.} - > ``` + > ``` + > {Click {+link href=$url}here{-link}.} + > ``` - As a translator, I want to be able to translate content around and between markup elements. - > ``` - > {Kliknij {+link}tutaj{-link}.} - > ``` + > ``` + > {Kliknij {+link}tutaj{-link}.} + > ``` - As a translator, I want to be able to translate certain markup attributes. - > ``` - > {Click {+link title=|Hey you!|}here{-link}} - > ``` + > ``` + > {Click {+link title=|Hey you!|}here{-link}} + > ``` - As developers and translators, I want to protect placeholders from modification and deletion. From 0f3d76d468d5f6f525cd626a473b5a2ed7b1d463 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stanis=C5=82aw=20Ma=C5=82olepszy?= Date: Sun, 10 Sep 2023 18:36:15 +0200 Subject: [PATCH 08/17] Updates to use cases from the face to face --- exploration/0005-open-close-expressions.md | 24 ++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/exploration/0005-open-close-expressions.md b/exploration/0005-open-close-expressions.md index cd55ac773f..f378bda00d 100644 --- a/exploration/0005-open-close-expressions.md +++ b/exploration/0005-open-close-expressions.md @@ -41,6 +41,13 @@ _What context is helpful to understand this proposal?_ > {Click {+link}here{-link}.} > ``` +- As an app author, I want to be able to interpolate standalone markup elements into the translation: `img`, `hr`, `input`. + On runtime, I expect these markup elements to produce live UI elements. + + > ``` + > {This is a giraffe: {:img src=giraffe.gif}.} + > ``` + - I want to be able to use minimal markup to inform XLIFF interchange. > ``` @@ -77,6 +84,23 @@ _What context is helpful to understand this proposal?_ - Segmented markup. +- Leveraging. + +- CAT tools support the concepts of open, close, and standalone, to provide certain functionalities above. + +- As a developer, I want to connect message markup with existing element instances in the UI. + +- As a developer, I want to sanitize translations without removing the markup important to the message. + + > Source HTML: + > ``` + > + > ``` + > Message: + > ``` + > {+popup-info img=|img/alt.png| data-text=|Your card validation code (CVC) is an extra security feature — it is the last 3 or 4 numbers on the back of your card.|}{-popup-info} + > ``` + **_Non-markup use cases to consider (which may or may not be addressed by the design)_** - Represent templating language constructs so that they can pass through From 3a3a614c0bb9a6d79933fe4243aeb3af6fee0cf5 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Sun, 10 Sep 2023 16:36:40 +0000 Subject: [PATCH 09/17] style: Apply Prettier --- exploration/0005-open-close-expressions.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/exploration/0005-open-close-expressions.md b/exploration/0005-open-close-expressions.md index f378bda00d..ce013e689a 100644 --- a/exploration/0005-open-close-expressions.md +++ b/exploration/0005-open-close-expressions.md @@ -92,14 +92,17 @@ _What context is helpful to understand this proposal?_ - As a developer, I want to sanitize translations without removing the markup important to the message. - > Source HTML: - > ``` - > - > ``` - > Message: - > ``` - > {+popup-info img=|img/alt.png| data-text=|Your card validation code (CVC) is an extra security feature — it is the last 3 or 4 numbers on the back of your card.|}{-popup-info} - > ``` + > Source HTML: + > + > ``` + > + > ``` + > + > Message: + > + > ``` + > {+popup-info img=|img/alt.png| data-text=|Your card validation code (CVC) is an extra security feature — it is the last 3 or 4 numbers on the back of your card.|}{-popup-info} + > ``` **_Non-markup use cases to consider (which may or may not be addressed by the design)_** From 1f52b7278e37564c98aa91eb97b34414c95c0619 Mon Sep 17 00:00:00 2001 From: Eemeli Aro Date: Sun, 10 Sep 2023 18:52:31 +0200 Subject: [PATCH 10/17] Add {#standalone} markup --- exploration/0005-open-close-expressions.md | 23 ++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/exploration/0005-open-close-expressions.md b/exploration/0005-open-close-expressions.md index ce013e689a..f922210d8e 100644 --- a/exploration/0005-open-close-expressions.md +++ b/exploration/0005-open-close-expressions.md @@ -153,13 +153,15 @@ pattern = "{" *(text / placeholder) "}" placeholder = expression / markup markup = "{" [s] markup-body [s] "}" -markup-body = (markup-start *(s option)) - / markup-end -markup-start = "+" name -markup-end = "-" name +markup-body = (markup-standalone *(s option)) + / (markup-open *(s option)) + / markup-close +markup-standalone = "#" name +markup-open = "+" name +markup-close = "-" name ``` -This allows for placeholders like `{+b}`, `{-i}`, and `{+a title=|Link tooltip|}`. +This allows for placeholders like `{+b}`, `{#img}`, and `{+a title=|Link tooltip|}`. Unlike annotations, markup expressions may not have operands. Markup is not valid in _declarations_ or _selectors_. @@ -167,14 +169,15 @@ Markup is not valid in _declarations_ or _selectors_. When formatting to a string, markup placholders format to an empty string by default. An implementation may customize this behaviour, -e.g. emitting XML-ish tags for each start/end placeholder. +e.g. emitting XML-ish tags for each open/close placeholder. When formatting to parts (as proposed in #463), markup placeholders format to an object including the following properties: -- The `type` of the markup: `"start" | "end"` +- The `type` of the markup: `"open" | "close" | "stnadalone"` - The `name` of the markup, e.g. `"b"` for `{+b}` -- For _markup-start_, the `options` with the resolved key-value pairs of the expression options +- For _markup-open_ and _markup-standalone_, + the `options` with the resolved key-value pairs of the expression options To make use of _markup_, the message should be formatted to parts or to some other target supported by the implementation, @@ -190,9 +193,9 @@ would format to parts as ```coffee [ { type: "text", value: "Click " }, - { type: "start", name: "a", options: { title: "Link tooltip" } }, + { type: "open", name: "a", options: { title: "Link tooltip" } }, { type: "text", value: "here" }, - { type: "end", name: "a" }, + { type: "close", name: "a" }, { type: "text", value: " to continue" } ] ``` From 3700430158f1217d4ee8b9af9a4dc21a37899f91 Mon Sep 17 00:00:00 2001 From: Eemeli Aro Date: Sun, 10 Sep 2023 23:11:02 +0200 Subject: [PATCH 11/17] Fix typo --- exploration/0005-open-close-expressions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/exploration/0005-open-close-expressions.md b/exploration/0005-open-close-expressions.md index f922210d8e..57342eef0d 100644 --- a/exploration/0005-open-close-expressions.md +++ b/exploration/0005-open-close-expressions.md @@ -174,7 +174,7 @@ e.g. emitting XML-ish tags for each open/close placeholder. When formatting to parts (as proposed in #463), markup placeholders format to an object including the following properties: -- The `type` of the markup: `"open" | "close" | "stnadalone"` +- The `type` of the markup: `"open" | "close" | "standalone"` - The `name` of the markup, e.g. `"b"` for `{+b}` - For _markup-open_ and _markup-standalone_, the `options` with the resolved key-value pairs of the expression options From 53f81b412a208bc0fe589c67ed7c4616982ecb27 Mon Sep 17 00:00:00 2001 From: Addison Phillips Date: Mon, 11 Sep 2023 09:14:54 +0200 Subject: [PATCH 12/17] Fleshing out use cases Editing for typos and consistency and adding some of the discussion we had yesterday (2023-09-10) --- exploration/0005-open-close-expressions.md | 25 +++++++++++++--------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/exploration/0005-open-close-expressions.md b/exploration/0005-open-close-expressions.md index 57342eef0d..f7a542d605 100644 --- a/exploration/0005-open-close-expressions.md +++ b/exploration/0005-open-close-expressions.md @@ -45,16 +45,16 @@ _What context is helpful to understand this proposal?_ On runtime, I expect these markup elements to produce live UI elements. > ``` - > {This is a giraffe: {:img src=giraffe.gif}.} + > {This is a giraffe: {#img src=giraffe.gif}.} > ``` - I want to be able to use minimal markup to inform XLIFF interchange. > ``` - > {Click {+ph}here{-ph}.} + > {Click {+ph}{-ph}here{+ph}{-ph}.} > ``` -- As an app author, I want to be able to pass certain attributes to markup elements, including dynamic values, such as coming from varriables. +- As an app author, I want to be able to pass certain attributes to markup elements, including dynamic values, such as coming from variables. > ``` > {Click {+link href=$url}here{-link}.} @@ -72,21 +72,26 @@ _What context is helpful to understand this proposal?_ > {Click {+link title=|Hey you!|}here{-link}} > ``` -- As developers and translators, I want to protect placeholders from modification and deletion. +- As a developer or as a translator, I want to protect placeholders from modification and deletion. - Paired markup elements should be protected from reordering, i.e. an open element must always come before the close element (if they are both present in the message). -- Use TTS annotations. +- As a developer working in certain domains, I want to be able to use markup such as TTML or SSML. -- Attributed strings (overlapping, enclosing). +- As a developer, I want to be able to produce "attributed strings" appropriate for my environment, which may include features such as overlapping or enclosing properties. -- TTY formatting escapes (?!) +- As a developer in certain environments, I want to be able to include TTY formatting escapes (?!) in my strings. -- Segmented markup. +- As a developer, I want to be able to split up text between strings, such as open or close elements are in separate strings. +- As a translator or tool, I want to be able to segment larger messages or process messages "segmented" from larger blocs of text, such that markup is split between messages or segments. -- Leveraging. +- As a translator, I want my tools to be able to leverage translations where the text differs only in markup, e.g.: + >``` + >{This is {+b}sure{-b} good.} + >{This is {+i}sure{-i}good.} + >``` -- CAT tools support the concepts of open, close, and standalone, to provide certain functionalities above. +- As a CAT tool, I want to use the concepts of open, close, and standalone that I am already familiar with, to provide certain functionalities above. - As a developer, I want to connect message markup with existing element instances in the UI. From ca67fba66a1132bac7e1a579c0e4c878741e2fe8 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Mon, 11 Sep 2023 07:15:15 +0000 Subject: [PATCH 13/17] style: Apply Prettier --- exploration/0005-open-close-expressions.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/exploration/0005-open-close-expressions.md b/exploration/0005-open-close-expressions.md index f7a542d605..024ff77c87 100644 --- a/exploration/0005-open-close-expressions.md +++ b/exploration/0005-open-close-expressions.md @@ -86,10 +86,11 @@ _What context is helpful to understand this proposal?_ - As a translator or tool, I want to be able to segment larger messages or process messages "segmented" from larger blocs of text, such that markup is split between messages or segments. - As a translator, I want my tools to be able to leverage translations where the text differs only in markup, e.g.: - >``` - >{This is {+b}sure{-b} good.} - >{This is {+i}sure{-i}good.} - >``` + + > ``` + > {This is {+b}sure{-b} good.} + > {This is {+i}sure{-i}good.} + > ``` - As a CAT tool, I want to use the concepts of open, close, and standalone that I am already familiar with, to provide certain functionalities above. From a89ca118ae560726fa56dd3e64ac8eace3c9033d Mon Sep 17 00:00:00 2001 From: Eemeli Aro Date: Sun, 8 Oct 2023 13:48:59 +0300 Subject: [PATCH 14/17] Apply suggestions from code review --- exploration/0005-open-close-expressions.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/exploration/0005-open-close-expressions.md b/exploration/0005-open-close-expressions.md index 024ff77c87..bc14ce096c 100644 --- a/exploration/0005-open-close-expressions.md +++ b/exploration/0005-open-close-expressions.md @@ -128,8 +128,6 @@ a non-empty sequence of pattern parts (text, expressions). Markup spans may be nested, as in `Bold and also italic`. -Markup spans may be improperly nested, -as in `Bold and italic`. Markup may have localisable options, such as `Click here to continue`. From e7eba4b94f15764e64a27a3804840c3bb940b196 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Sun, 8 Oct 2023 10:49:16 +0000 Subject: [PATCH 15/17] style: Apply Prettier --- exploration/0005-open-close-expressions.md | 1 - 1 file changed, 1 deletion(-) diff --git a/exploration/0005-open-close-expressions.md b/exploration/0005-open-close-expressions.md index bc14ce096c..4e853a5888 100644 --- a/exploration/0005-open-close-expressions.md +++ b/exploration/0005-open-close-expressions.md @@ -128,7 +128,6 @@ a non-empty sequence of pattern parts (text, expressions). Markup spans may be nested, as in `Bold and also italic`. - Markup may have localisable options, such as `Click here to continue`. From 36100f4ecd354020de57030f0f6535599c33f5c2 Mon Sep 17 00:00:00 2001 From: Eemeli Aro Date: Sun, 8 Oct 2023 13:51:23 +0300 Subject: [PATCH 16/17] Rename file to use PR number --- ...5-open-close-expressions.md => 0470-open-close-expressions.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename exploration/{0005-open-close-expressions.md => 0470-open-close-expressions.md} (100%) diff --git a/exploration/0005-open-close-expressions.md b/exploration/0470-open-close-expressions.md similarity index 100% rename from exploration/0005-open-close-expressions.md rename to exploration/0470-open-close-expressions.md From f92eeaf33101ff71b43e70a0eb313b167dbbc706 Mon Sep 17 00:00:00 2001 From: Eemeli Aro Date: Tue, 10 Oct 2023 11:18:34 +0300 Subject: [PATCH 17/17] Drop design doc number from filename --- .../{0470-open-close-expressions.md => open-close-expressions.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename exploration/{0470-open-close-expressions.md => open-close-expressions.md} (100%) diff --git a/exploration/0470-open-close-expressions.md b/exploration/open-close-expressions.md similarity index 100% rename from exploration/0470-open-close-expressions.md rename to exploration/open-close-expressions.md