That’s the thing - many website owners, especially those who use WordPress, don’t know basic HTML. So they may be inclined to install a plugin instead of putting a couple of simple lines of HTML into their theme.
Plugins aren’t inherently bad, but they add unnecessary bloat. Especially for something as simple as this.
because if there is no article about it, this “obvious” knowledge becomes lost, overcomplicated solutions float to the top of search results, and everyone starts doing it the stupid way.
As someone who recently had to start doing frontend work at my job, I just want to say this is non-obvious to me and I appreciate the article and comments.
The id attribute can be given to any element so it could be done with a <header> or <article> element if that suits the page better. The name attribute on anchor elements is now considered obsolete.
I don’t recall for sure which browsers support which, but I remember for sure that the <a name=foo> [...] <a href="#foo">foo</a> is by far the most compatible way of doing it, while other methods do not work across all browsers.
Would be interesting to know which browser doesn’t support the standard #-method. Don’t think I’ve ever noticed it not work in any substantial browsers.
I hate these use-ids & fragments for magical behavior - it messes up my browsing history and it’s annoying.
I would expect a JS solution if JS is possible and an optional fallback to ids only when no JS is executed.
This is literally plain HTML. If something is magical here, it is the usage of javascript to emulate a behavior that has been standard in the web since the nineties.
I wanted to ask you what kind of browser would do such a silly thing, but apparently that’s (also?) what Firefox does: fragments do get added to history, and all the “back” button does is dropping the fragment.
I still find it peculiar that there’s even a need for such button (on PC I have a Home button, and on mobile providing one should be the browser’s job imo), but seems like there is a good reason why people use JS for this after all.
That was when HTML5 pushState was still too poorly supported and too buggy to be usable. But we’re now stuck with some sites still relying on the hashbang URLs, so removing them from history would be a breaking change.
It’s always crazy to see how people abuse the anchor tag. My favourite personal abuse is I kept finding that SysAdmins and IT were always just emailing cleartext credentials for password resets and during pentests I’d often use this to my advantage (mass watching for password reset emails for example). So I jokingly ended up writing a stupid “password” share system that embedded crypto keys in the hash url and would delete itself on the backend after being viewed once: https://blacknote.aerstone.com/
Again, this is stupid for so many reasons, but I did enjoy abusing it for the “doesn’t send server side” use case. EDIT: I originally had much more aggressive don’t use this messages, but corporate gods don’t like that.
One useful trait of hash-bang URLs is that your path is not sent to the server. This is useful for things like encryption keys. MEGA and others definitely use this as lawful deniability that they cannot reveal the contents of past-requested content. Though, if given a court order I suppose they can be forced to reveal future requests by placing a backdoor in the decryption JS.
Or simpler without the need for additional
<a>:I don’t even understand why there was article written for this…It’s so obvious to anyone with any basic HTML understanding.
That’s the thing - many website owners, especially those who use WordPress, don’t know basic HTML. So they may be inclined to install a plugin instead of putting a couple of simple lines of HTML into their theme.
Plugins aren’t inherently bad, but they add unnecessary bloat. Especially for something as simple as this.
… then maybe don’t use WordPress. ;)
/s
because if there is no article about it, this “obvious” knowledge becomes lost, overcomplicated solutions float to the top of search results, and everyone starts doing it the stupid way.
As someone who recently had to start doing frontend work at my job, I just want to say this is non-obvious to me and I appreciate the article and comments.
Apoarently “#top” or just “#” not only works (I remember #top from… The early days. Netscape 4.x?) - but it’s in the standard:
“Note: You can use href=”#top” or the empty fragment (href=”#”) to link to the top of the current page, as defined in the HTML specification.”
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a
Where the spec is… I’d say more than a little obtuse: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-the-fragment-identifier
Ed2: not sure why the author felt a need to define a html4 style named anchor for #top..
Ed: Also TIL: in HTML5 linking directly to an ID is preferred over an explicit named anchor.
According to whatwg and MDN this is the preferred method
Problem with that is it would take you to the title of the page, which isn’t necessarily the top of the page.
The id attribute can be given to any element so it could be done with a <header> or <article> element if that suits the page better. The name attribute on anchor elements is now considered obsolete.
If you force “smooth scrolling” on your users you’re a monster
On one hand, I kind of agree.
On the other hand, it seems like for a good proportion of users, smooth-scrolling, at least from the “back to top” button, is less confusing?
Fwiw, I think I prefer the abrupt jump.
I’ll take my 200ms of time over the slick experience.
In a userstyle:
I just use
<a href="#">Top</a>on my website, always have. https://hultner.se/Is there any reason to use a defined id/name instead?
I don’t recall for sure which browsers support which, but I remember for sure that the
<a name=foo> [...] <a href="#foo">foo</a>is by far the most compatible way of doing it, while other methods do not work across all browsers.Would be interesting to know which browser doesn’t support the standard
#-method. Don’t think I’ve ever noticed it not work in any substantial browsers.I hate these use-ids & fragments for magical behavior - it messes up my browsing history and it’s annoying. I would expect a JS solution if JS is possible and an optional fallback to ids only when no JS is executed.
This is literally plain HTML. If something is magical here, it is the usage of javascript to emulate a behavior that has been standard in the web since the nineties.
I gave up on the back button roughly a decade ago.
I wanted to ask you what kind of browser would do such a silly thing, but apparently that’s (also?) what Firefox does: fragments do get added to history, and all the “back” button does is dropping the fragment.
I still find it peculiar that there’s even a need for such button (on PC I have a Home button, and on mobile providing one should be the browser’s job imo), but seems like there is a good reason why people use JS for this after all.
I like that it gets added to the history. You can press a link to a reference or footnote, and then press back to go to where you were.
There has been a craze for “hash-bang URLs” that abused URL fragments for keeping state and performing navigation. This let JS take over the whole site and make it painfully slow in the name of being a RESTful web application.
That was when HTML5
pushStatewas still too poorly supported and too buggy to be usable. But we’re now stuck with some sites still relying on the hashbang URLs, so removing them from history would be a breaking change.It’s always crazy to see how people abuse the anchor tag. My favourite personal abuse is I kept finding that SysAdmins and IT were always just emailing cleartext credentials for password resets and during pentests I’d often use this to my advantage (mass watching for password reset emails for example). So I jokingly ended up writing a stupid “password” share system that embedded crypto keys in the hash url and would delete itself on the backend after being viewed once: https://blacknote.aerstone.com/
Again, this is stupid for so many reasons, but I did enjoy abusing it for the “doesn’t send server side” use case. EDIT: I originally had much more aggressive don’t use this messages, but corporate gods don’t like that.
One useful trait of hash-bang URLs is that your path is not sent to the server. This is useful for things like encryption keys. MEGA and others definitely use this as lawful deniability that they cannot reveal the contents of past-requested content. Though, if given a court order I suppose they can be forced to reveal future requests by placing a backdoor in the decryption JS.
Hmmm that’s a good point, and not something I had considered. Thanks for the feedback.
Very nice, though it seems my browser (Chromium 81.0.4044.129) ignores
scroll-behavior.Interesting. I tested it with Brave (also based on Chromium) and it worked.
[Comment removed by author]