Update EIP-1: Add WHATWG as a permissible origin #7117
Conversation
File
|
eth-bot
changed the title
|
fine by me 👍 |
| @@ -252,6 +252,24 @@ Permitted Networking Specifications URLs must anchor to a specific commit, and s | |||
| ^https://github.com/ethereum/devp2p/blob/[0-9a-f]{40}/.*$ | |||
| ``` | |||
|
|
|||
| ### Web Hypertext Application Technology Working Group (WHATWG) | |||
There was a problem hiding this comment.
| ### Web Hypertext Application Technology Working Group (WHATWG) | |
| ### WHATWG |
I weakly prefer the abbreviation.
There was a problem hiding this comment.
We require authors to expand abbreviations, so I figured we should probably too 🤣
Can we do that in a separate PR? I think it'll require some thought (eg. subsections & anchor links, colons/dashes/spaces, just the identifier vs. the whole title, etc.) |
|
Should we be adding a comment regarding this? It seems like a bad idea to do exactly what the authoritative body on the standard is telling us not to do. |
They do an excellent job explaining in their banner! We have
I think we fit into the "historical reference" exception? Imagine some EIP gets finalized, and on-chain implementations written. Some years go by, and the WHATWG standard has evolved, but the contracts are frozen on-chain. A new implementer comes along. If we link to the living standard, then important context will be lost, but if we link to the commit, the implementer can make an informed decision about what to do: use the old version or the current living edition. |
|
Yeah I think a little note in here to clarify this in EIP-1 would be good to at least document our rationale for using commitments. It also just occurred to me that if they rewrite their commit history (I'd venture to guess they won't do this) then some commit links could be broken here. So I don't think we'll find a perfect solution here anyways and the next best thing is probably the commit and document why were ignoring their suggestions approach. We may find this wasn't the right approach later and have to update to the living standards link in the future, but we can cross that bridge when we need to. |
|
|
||
| [HTML](https://html.spec.whatwg.org/commit-snapshots/578def68a9735a1e36610a6789245ddfc13d24e0/) | ||
|
|
||
| Permitted WHATWG specification URLs must anchor to a specification defined in the `spec` subdomain (idea specifications are not allowed) and to a commit snapshot, and so must match this regular expression: |
There was a problem hiding this comment.
| Permitted WHATWG specification URLs must anchor to a specification defined in the `spec` subdomain (idea specifications are not allowed) and to a commit snapshot, and so must match this regular expression: | |
| Permitted WHATWG specification URLs must anchor to a specification defined in the `spec` subdomain (idea specifications are not allowed) and to a commit snapshot. While anchoring to a particular snapshot is not recommended by WHATWG, this has been defined to do so still so that readers of specifications can be aware of the exact version of the WHATWG living standard being referenced by the author at the time they linked to it in an immutable way. This way readers can choose to implement against the version referenced by the author or the updated living standard if they choose. As such, the link must match this regular expression: |
There was a problem hiding this comment.
@SamWilsn this suggestion should address my last comment
There was a problem hiding this comment.
Updated, with different wording. What do you think of:
Although not recommended by WHATWG, EIPs must anchor to a particular commit so that future readers can refer to the exact version of the living standard that existed at the time the EIP was finalized. This gives readers sufficient information to maintain compatibility, if they so choose, with the version referenced by the EIP and the current living standard.
Originally from #6691 by @kdenhartog.
Splitting out so it can be discussed separately.
Changed slightly with my review feedback.