-
-
Notifications
You must be signed in to change notification settings - Fork 36
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
Conversation
…s & proposed design
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.
Editing for typos and consistency and adding some of the discussion we had yesterday (2023-09-10)
@aphillips @stasm Would you be ok with this landing as "Proposed"? |
markup-standalone = "#" name | ||
markup-open = "+" name | ||
markup-close = "-" name |
There was a problem hiding this comment.
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.
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 ( I’d like to propose we add two new declaration types called
The declarations are optional (similar to input). If they’re absent, then any I’m not yet sure how to allow more than one element of the same name but with different attributes. Probably something like:
|
I opened #513 which adds the above idea as an alternative to the design doc. |
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.