-
Notifications
You must be signed in to change notification settings - Fork 16
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
Editorial: various edits for style and clarity #128
base: main
Are you sure you want to change the base?
Conversation
* Use consistent wording in various places (e.g., "Source Map format") * Use more spec-like language where it makes sense * Fixed a note to render correctly * Link terms more consistently * Reworded some prose for clarity * Remove <ins> tag
source-map.bs
Outdated
* <dfn><code>file</code></dfn> is an optional name of the generated code | ||
that this source map is associated with. It's not specified if this can | ||
that the source map is associated with. It is not specified if this can | ||
be a URL, relative path name, or just a base name. As such it has a mostly informal | ||
character. |
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.
I didn't adjust it yet because I'm not sure what we want to say, but I feel like the "As such it has a mostly informal character" isn't adding much information here. Should we say something about how generators can choose an appropriate interpretation for their context?
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.
Yes I prefer your solution to the current one which made little sense to me.
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.
I added some text about generators replacing this sentence. It's in a separate commit in case it's too close to non-editorial and there are any objections to changing it now.
I think these all look great! Would you mind resolving the conflicts so I can see a cleaner diff? Sorry I merged 2 things in early today that conflict. |
This PR shouldn't make any semantic changes and should be purely editorial. It adjusts markup and rewords prose for consistency, clarity, or more spec-like wording. (the commit message has more details)
It builds on PR #126 so should be rebased & merged after that.