You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Require a hash in HTML spec URLs for <link rel=help> (and elsewhere) #63371
The first pattern causes a (scripted) redirect. The second pattern is not necessarily stable since things are sometimes moved around (the link should still work given the scripted redirect). The third option is shortest and has no redirect.
My preference would be to always link to the single-page version, and add a lint check for this. This makes it clear for contributors and avoids review time about which URL to use.
Edit: per discussion below, instead only require a hash in the lint, and fix currently broken/old links.
Wait why is https://html.spec.whatwg.org/C/#navigate bad? Scripted redirects help SO much when you're on the go, or investigating things on crappy networks on a mobile device. Actually, we should standardize everything to that!
With C it means test writers need to always change the URL copied from the spec since it redirects somewhere else.
Maybe the "I prefer multipage on this device" use case could be solved with a cookie-based redirect in the spec, so you always go the multipage while the cookie is present?
Mostly consistency and that a multipage link without a hash can't easily be translated to the single-page equivalent. Maybe "require a hash" is sufficient?
There are also mistakes like multipage/multipage/ and multipage/C, but those can be fixed.
I think I'd personally prefer "require a hash" since that helps normalize definitions in the most useful way, without favoring one page variant over an other. All of this is just personal preference though.
changed the title [-]Standardize on single-page HTML for `<link rel=help>`[/-][+]Require a hash in HTML spec URLs for `<link rel=help>` (and elsewhere)[/+]on Oct 8, 2026
Activity
Link to the single-page HTML spec and lint against multipage links
Link to the single-page HTML spec instead of multipage
zcorpan commentedon Oct 7, 2026
Rewrite: #63375
Lint check, to be landed some time later: #63377
domfarolino commentedon Oct 8, 2026
Wait why is
https://html.spec.whatwg.org/C/#navigatebad? Scripted redirects help SO much when you're on the go, or investigating things on crappy networks on a mobile device. Actually, we should standardize everything to that!zcorpan commentedon Oct 8, 2026
With
Cit means test writers need to always change the URL copied from the spec since it redirects somewhere else.Maybe the "I prefer multipage on this device" use case could be solved with a cookie-based redirect in the spec, so you always go the multipage while the cookie is present?
domfarolino commentedon Oct 8, 2026
That's one option, but I'm still struggling to see the motivation for this in the first place.
It seems like
/C/#fooand/multipage/#fooare the same. Is it an issue if test authors link to these URLs (or even fully-qualified multipage URLs)?zcorpan commentedon Oct 8, 2026
Mostly consistency and that a multipage link without a hash can't easily be translated to the single-page equivalent. Maybe "require a hash" is sufficient?
There are also mistakes like
multipage/multipage/andmultipage/C, but those can be fixed.domfarolino commentedon Oct 8, 2026
I think I'd personally prefer "require a hash" since that helps normalize definitions in the most useful way, without favoring one page variant over an other. All of this is just personal preference though.
zcorpan commentedon Oct 8, 2026
OK, let's do that instead. Converting all links to single-page and trying to land a lint while new changes are coming in is non-trivial churn. Thanks!
[-]Standardize on single-page HTML for `<link rel=help>`[/-][+]Require a hash in HTML spec URLs for `<link rel=help>` (and elsewhere)[/+]