-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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: use step labels rather than numbers to refer to steps #2052
Conversation
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.
etc. perhaps a better solution would be to make title
automatic when the emu-xref
is empty, and also hopefully allowing it to be self-closing (ie <emu-xref />
)?
The presence of the
Ecma262 doesn't currently use any self-closing tags. I'm fine with discussing the possibility of adopting their use, but I would not want to do that in this PR. |
Sure, set that aside; maybe |
They are; see the screenshot in tc39/ecmarkup#217, which corresponds to this file. That's the default behavior when you leave the tag empty. |
That's not what I see in this PR's build preview - maybe I just got confused because this doesn't include the ecmarkup PR yet? |
Yeah, the build preview won't look right until support for the syntax it relies on is released. |
Would it be better to have an emu-step tag rather than an xref one then? |
Thank you, this will be most useful for JSExplain. It might also solve our need to reference individual algorithms (#1800 and tc39/ecmarkup#172). |
I don't see step references as fundamentally different from any other kind of thing you can emu-xref. What would be the advantage of having a separate tag? |
Other kinds of xrefs can have custom link text which prevents automatically showing the reference's title; i don't see any use case for a link to a step without including a step number. |
That's true; I just made it a warning (to be promoted to a linting error) to include text. It doesn't seem like enough of a difference to warrant a different kind of element, to me. |
With the linting error i guess it's fine, but it seems conceptually like a different element to me. (we probably also want a warning on a non-step xref without |
How so?
That populates the link text with the clause number / figure number / etc, just as here it is populated with the step number; I don't see any particular problem with it. (We do that in ecma262.) |
I think that "step" is a more specialized subtype of "a link", and i think that merits a different type. It's not a blocking point, though - it was just an idea :-) |
@ljharb Now that ecmarkup has been bumped the deploy preview renders correctly (see below). If that addresses your concern about |
Currently, if you're looking at an Similarly, with regard to In general, I think you should avoid using not-quite-the-real-identifier in source. |
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 confirm every single step ID was linked up right, since the tooling should have our backs here.
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.
This looks great to me.
+1 on @jmdyck's searchability point. I'd prefer step labels not do any transformation of the label string.
This fixes a persistent problem where step numbers would get stale and we'd forget to update them. Now, by given the steps (somewhat arbitrarily chosen) labels, we can refer and link to them explicitly. See tc39/ecmarkup#217 for a description of the syntax.
Marked as draft until a version of ecmarkup with support for the new syntax is published.Edit: done, this should be good to go. Deploy preview looks good to me.Corresponding ecmarkdown PR at tc39/ecmarkdown#74. Corresponding ecmarkup PR at tc39/ecmarkup#217.