Skip to content

Conversation

@agl
Copy link

@agl agl commented Dec 6, 2020

Specifications often have algorithms with many (nested) ordered lists.
In those algorithms, steps often refer to other steps by number. But
those numbers currently have to be maintained manually and, when steps
are inserted, that can lead to a cascade of updated step number
references below. Worse, when two changes are in-flight to the same
algorithm, the step numbers are almost ensured to go wrong because
neither change need textually conflict with the other.

This change to bikeshed permits items in an ordered list to be given an
ID and referenced by name.

  1. This is a traditional item.
  2. {#myid} This is an item with an ID.
  3. This item references [[#myid]].

The reference is turned into the string “step 2”. This also works for
nested steps where the reference will say something like “step 2.1.3”.

Specifications often have algorithms with many (nested) ordered lists.
In those algorithms, steps often refer to other steps by number. But
those numbers currently have to be maintained manually and, when steps
are inserted, that can lead to a cascade of updated step number
references below. Worse, when two changes are in-flight to the same
algorithm, the step numbers are almost ensured to go wrong because
neither change need textually conflict with the other.

This change to bikeshed permits items in an ordered list to be given an
ID and referenced by name.

1. This is a traditional item.
1. {#myid} This is an item with an ID.
1. This items references [[#myid]].

The reference is turned into the string “step 2”. This also works for
nested steps where the reference will say something like “step 2.1.3”.
@agl
Copy link
Author

agl commented Dec 6, 2020

I have no idea what I'm doing, and sticking information in HTML attributes like this for later consumption is probably silly, but this issue comes up a bunch for WebAuthn / CTAP stuff and I figured I'd give this a shot.

@equalsJeffH to see whether I'm actually solving the right problem, or whether what we need is slightly different.

@equalsJeffH
Copy link

equalsJeffH commented Dec 8, 2020

to see whether I'm actually solving the right problem, or whether what we need is slightly different

Thanks for doing this. I'll have to figure out how to play with it once we ship the current on-deadline spec.

Nominally, what this supplies appears useful, especially if the resultant HTML is correct. We've been up-to-this-point hacking this sort of thing into bikeshed source by using explict <li id="foo"> markup, but bikeshed does weird things with that—such as altering the depth of the list item—more than occasionally such that the latter technique is not reliable, unfortunately. If this provides reliable results, then it is definitely useful.

@ve7jtb
Copy link

ve7jtb commented Dec 8, 2020

Thanks, but we won't delay RD02 to refactor quire yet if that is OK.

This will save a bunch of time and mistakes later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants