Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Clarify that open-close elements are placeholders, not expressions #540

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 2 commits into from
Dec 3, 2023
Merged

Clarify that open-close elements are placeholders, not expressions #540

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c819f48
Clarify that open-close elements are placeholders, not expressions
eemeli Nov 29, 2023
109b316
Add PR link
eemeli Nov 29, 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
17 changes: 9 additions & 8 deletions exploration/open-close-expressions.md → exploration/open-close-placeholders.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# Open/Close Expressions
# Open/Close Placeholders
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 we would be better off calling this design "spannable" but don't care that much about it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

All of the options currently being considered are placeholders in a pattern; hence my suggested name for this.

Copy link
Collaborator

Choose a reason for hiding this comment

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

+1 to titling this design doc "Spannables". If you agree, please also rename the file.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I would prefer "placeholders".


Status: **Proposed**

Expand All @@ -16,14 +16,15 @@ Status: **Proposed**
<dd><a href="https://github.com/unicode-org/message-format-wg/pull/516">#516</a></dd>
<dd><a href="https://github.com/unicode-org/message-format-wg/pull/517">#517</a></dd>
<dd><a href="https://github.com/unicode-org/message-format-wg/pull/535">#535</a></dd>
<dd><a href="https://github.com/unicode-org/message-format-wg/pull/540">#540</a></dd>
</dl>
</details>

## Objective

_What is this proposal trying to achieve?_

Describe the use cases and requirements for _expressions_
Describe the use cases and requirements for _placeholders_
that enclose parts of a pattern
and develop a design that satisfies these needs.

Expand All @@ -33,7 +34,7 @@ _What context is helpful to understand this proposal?_

## Use-Cases

- Representing markup, such as HTML, as expressions in a pattern
- Representing markup, such as HTML, as placeholders 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.
Expand Down Expand Up @@ -128,7 +129,7 @@ _What context is helpful to understand this proposal?_
## Requirements

Be able to indicate that some identified markup applies to
a non-empty sequence of pattern parts (text, expressions).
a non-empty sequence of pattern parts (text, placeholders).

Markup spans may be nested,
as in `<b>Bold and <i>also italic</i></b>`.
Expand All @@ -145,7 +146,7 @@ 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,
the resolution of the value of a _placeholder_ may only depend on its own contents,
without access to the other parts of the selected pattern.

## Proposed Design
Expand Down Expand Up @@ -179,7 +180,7 @@ Markup names are _namespaced_ by their use of the pound sign `#` and the forward
They are distinct from `$variables`, `:functions`, and `|literals|`.

This allows for placeholders like `{#b}`, `{#img}`, and `{#a title=|Link tooltip|}`.
Unlike annotations, markup expressions may not have operands.
Unlike annotations, markup _placeholders_ may not have operands.

Markup is not valid in _declarations_ or _selectors_.

Expand Down Expand Up @@ -219,7 +220,7 @@ markup placeholders format to an object including the following properties:
- The `type` of the markup: `"markup" | "markup-close"`
- The `name` of the markup, e.g. `"b"` for `{#b}`
- For _markup_,
the `options` with the resolved key-value pairs of the expression options
the `options` with the resolved key-value pairs of the placeholder options

To make use of _markup_,
the message should be formatted to parts or to some other target supported by the implementation,
Expand Down Expand Up @@ -403,7 +404,7 @@ This is {+strong}bold{-strong} and this is {#img alt=|an image|/}.

#### Cons

* Adds two new sigils to the expression syntax (three with `#standalone`).
* Adds two new sigils to the placeholder syntax (three with `#standalone`).

* Because they're agnostic, the meaning of the sigils must be learned or deduced.

Expand Down