Idea: Make merged/landed proposals redirect to corresponding parts of the ES current draft #360
Comments
|
There's not usually a single fragment of the ES spec to which a given proposal corresponds - most proposals touch parts across many sections. |
Yes, I understand that. What my suggestion would cause is that all the fragment IDs for all parts of the proposal would redirect to the exact same fragment IDs in the current ES draft. For example, https://tc39.es/proposal-class-fields/#prod-PrivateIdentifier would redirect to https://tc39.es/ecma262/#prod-PrivateIdentifier — or preferably, to https://tc39.es/ecma262/multipage/ecmascript-language-lexical-grammar.html#prod-PrivateIdentifier. This would work because y’all seem to have a policy/practice/convention of all (I’ve edited/updated the issue description to include the info from this comment.) |
|
personally, I get a lot of value from the diff view on the proposal pages - I wouldn't want to see that go away. for example, if someone links me to the |
|
(separately, the single-page, not the multi page, version of the spec is the canonical one and ideally everyone external only links to the single-page version) |
It's true that the single-page version is canonical, but I disagree strongly with the claim that this implies everyone ought to link to it. The two documents have the same content, by construction, and the multi-page one is friendlier for many users. |
In places such as https://github.com/w3c/browser-specs/blob/master/specs.json#L67 and https://github.com/tobie/specref/blob/main/refs/biblio.json#L1098, we’re now very intentionally referencing the multipage ES spec rather than the single-page. And for MDN, we’re following a policy of only linking to the multipage version — just as for links to the HTML spec, we have a policy of only linking to the similar multipage version of that. In the cases of both specs, the primary reason for linking to the multipage versions is better user experience:
I suspect you’d likely not have great success getting third-party sites to avoid linking to the multipage version. |
|
@sideshowbarker thats not my experience outside of chrome, which has a particularly poor experience for the single-page version. |
and others
After a proposal has gone through all the stages and gets merged into the spec, change the body start tag in the HTML source of the proposal to this:
…or better yet — now that there’s a multipage version:
In other words, make the proposal document redirect to the corresponding fragment of the current ES draft.
That way, any existing links anywhere to the proposal that have fragment parts will get redirected to the corresponding anchors in the current ES draft (while fragment-less links to the proposal itself won’t get redirected).
For example, https://tc39.es/proposal-class-fields/#prod-PrivateIdentifier would redirect to https://tc39.es/ecma262/#prod-PrivateIdentifier — or preferably, to https://tc39.es/ecma262/multipage/ecmascript-language-lexical-grammar.html#prod-PrivateIdentifier.
This would work because y’all seem to have a policy/practice/convention of all
idattributes in the proposal source being preserved as-is when you merge them into the ES spec source.The text was updated successfully, but these errors were encountered: