Skip to content

Design document for Open/Close Expressions #470

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.

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 17 commits into from
Nov 6, 2023
Merged

Conversation

eemeli
Copy link
Collaborator

@eemeli eemeli commented Sep 5, 2023

This is submitted as a draft, as it currently only considers the use case (HTML-ish markup) that I care about, its requirements, and proposes a minimal design that fulfills my needs.

I invite everyone to contribute here, as discussed on yesterday's call. Especially when adding new items or paragraphs to the doc, please do directly commit to the document rather than supplying suggestions.

Having contributed my part, I don't consider myself as the owner here, so have added a couple of assignees instead.

@eemeli eemeli added requirements Issues related with MF requirements list syntax Issues related with syntax or ABNF design Design document or issues related to design labels Sep 5, 2023
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.
@eemeli eemeli marked this pull request as ready for review September 10, 2023 16:39
eemeli and others added 4 commits September 10, 2023 18:52
Editing for typos and consistency and adding some of the discussion we had yesterday (2023-09-10)
@stasm stasm mentioned this pull request Sep 18, 2023
@eemeli eemeli requested review from aphillips and stasm October 8, 2023 10:54
@eemeli
Copy link
Collaborator Author

eemeli commented Oct 8, 2023

@aphillips @stasm Would you be ok with this landing as "Proposed"?

Comment on lines 162 to 164
markup-standalone = "#" name
markup-open = "+" name
markup-close = "-" name
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

These sigils will need further consideration before we eventually accept this proposed design. As we evolve the syntax, # may get used for statements, and some other alternative open/close pair may end up being preferred.

@stasm
Copy link
Collaborator

stasm commented Nov 6, 2023

I’ve been thinking about an alternative design for this. I’m going to take note of it here briefly and add a new section in the doc later this week. I'm also fine with this PR landing as "Proposed" before I edit it -- I'll open a new PR then. (Actually, that may be preferable.)

Also, please be gentle, it’s a work-in-progress which I’m sharing early to see if there’s any support for it.

My goal is, as usual, to avoid adding new sigils to the syntax. Instead, I’d like to leverage the fact that we already have the concept of keywords in the syntax. Furthermore, with #469, we were able to find a good solution by adding a new keyword (input). I think we can try to do the same here.

I’d like to propose we add two new declaration types called openclose and standalone, along with new placeholder syntax: {foo}, {/foo}, and {foo/}. I've come to think that the only good syntax for spannables is one that looks like a markup language. There's also vast prior art in using some sort of [foo] and [/foo] in various web forums. Note that this would require dropping unquoted literals as operands, which I think is an acceptable trade-off.

{{
    openclose {strong :html class=foo onclick=bar}
    standalone {img :html src=http://…}
    {{This is {strong}bold{/strong} and this is {img alt=|an image|/}.}}
}}

The declarations are optional (similar to input). 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 kinds of markup precisely, making {strong/} and {img} and {/img} invalid in the example above. Additionally, they allow to add non-localizable attributes to makrup.

I’m not yet sure how to allow more than one element of the same name but with different attributes. Probably something like:

standalone img1 = {img :html src=http://a}
standalone img2 = {img :html src=http://b}

@aphillips aphillips merged commit c853f51 into main Nov 6, 2023
@aphillips aphillips deleted the design-open-close branch November 6, 2023 18:24
@stasm
Copy link
Collaborator

stasm commented Nov 6, 2023

I opened #513 which adds the above idea as an alternative to the design doc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Design document or issues related to design requirements Issues related with MF requirements list syntax Issues related with syntax or ABNF
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants