As a backend person, sometimes I look at what's being done for front end stuff and pull back in ever so slight horror.
It's an excellent article, and the work within is very well done, but there's a part of me that screams "Why would you introduce this much complexity for what should be a simple scroll?" (overcoming technical hurdles to produce the desired end result aside).
I don't get "as a backend engineer" comments like these.
OP is doing a basic analysis on what kind of solutions exist for a typical UX edge-case. They even provide the simple solution that most people use (margin-bottom).
And for fun they go on to see if they can solve it without the minor drawback of the simple solution.
We've got to stop acting like it's a badge of honor to avoid UX consideration. We might not be people who implement UIs, we use UIs all day and should be able to muster up a few opinions about how a UX interaction should work.
I think the article does a pretty good job of explaining the gap between what can happen easily, and what a 110% over engineered "perfect" solution is to a UX problem.
Building excellent user interfaces is hard, regardless of the technical stack. You have to sweat a lot of the finer details, break out of any platform default behaviour where appropriate, and over engineer something in service of building a 'delightful' user experience.
Or, you can do as most do, and just not do this. #anchor-links with `scroll-behavior: smooth;` CSS will get you the basic smooth scrolling.
From time to time I dip my toe in and try new things, but as productive as I can get with Astro, the illusion vanishes as soon as I have to understand any of the plumbing.
Fortunately, I can still party like it’s 1999 just fine: just yesterday, I worked on a janky brutalist web app (the same way I did back in 2002, cribbing from the O’Reilly “Dynamic HTML: the Definite Reference”) and “deployed” it with rsync to pico.sh. It’s practically unstyled and I didn’t even use jquery, but it works.
Because the scroll, as you see, is not simple. The complexity of the real-world scenarios outlined in the post force the complexity of the solution. It may feel that "it's simple common sense" kind of thing, but if you ever tried to implement a simple common-sense thing, you know that it only appear simple.
By the same token, some UX person might read about the mechanics of database transactions with two-phase commits, or about MVCC, and ask why so much complexity exists around what should just be a simple write to disk.
Because the default behavior, the problem they describe in the introduction, is bad. It confuses many people, I’ve seen it firsthand many times as an observer in usability testing.
Chrome developers keep adding unhinged complicated “features” that nobody wants or asked for and immediately are abused and broken.
Numerous autoplaying video methods for example especially when they follow the mouse, play in the background, or use lazy loading to be unkillable.
Speaking of lazy loading or whatever hundreds of variations probably exist around it now, the terrible front end devs of the world have decided to use that for everything. Everything is a sliding panel full of sliding panels and there’s no way to use browser back features coherently.
Scrolling down a site now loads a new site and destroys your history. Even if you scrolled to move content up because an autoplaying video anchored to the bottom of the screen is blocking the view. Scroll down too far causes a jump and the site decides you’re done and loads the next thing with no way to navigate back.
How do these developers have a job? How are features like this even invented with no critical thought or understanding of real world use cases questioned. It’s again and again and again that we see this.
And the Google team is so proud every time with their demo videos that is painfully obvious they put no thought into it outside of their bubble of them deciding some random thing was technically possible to do as a proof of concept and should therefore be immediately released as a fully supported feature.
That's only because you are used to the over complexity of backend work. As someone who is pretty far removed from both front and backend work (or web work in general), both seem pretty complex. Frontend at least has the excuse of being at the interface between humans and computers, which is inherently much harder
You say "backend" but I'm guessing you're not talking about modern cloud infrastructure work, the complexity at which I (as a frontend person) scream in similar abject horror.
As a backend developer, I have a lot of respect for frontend developers that have to deal with edge-cases and minutiae that we don't have to. Building APIs and interfaces for computers is easy. Building them for people is HARD.
I can recommend backend people to do frontend once in a while. You don't have to like it. But it will make you a better developer. I've been in more than one team where there was this us and them dynamic and some lack of mutual understanding about why things worked a certain way or limitations and constraints. It can lead to poorly thought through APIs and API responses, which then triggers frontend work to engineer around that. Also, frontend developers tend to have better intuition for asynchronous stuff; because everything in a browser is async. Backend developers tend to be a bit naive on that front.
I'm a hands-on CTO in a very small company. So, if it's technical, I'm doing it. Websites, apps, backends, databases, devops and all the rest. Not always fun. But at this point I can fill every role in a typical product team and do a decent job.
And I agree that what passes for state of the art on the web is a bit meh. Anchors date back to the early days of the web. One of those forgotten features that is still vaguely useful but a bit underused. There's a reason mobile developers prefer native UI toolkits. Browsers are a bit limited and backwards. CSS is a bit of a straight jacket. And Javascript is a bit of a basket case as a language.
I remember the days when every new project started with "now let's write our own String class". As someone who works on both, it seems server and native software left this era in the distant past, but we're still there in web development.
One could ask: what's the UX purpose of the "active anchor" indicator on the side navigation?
One answer I can think of: if a reader is in the middle of a long section, and the heading is off the screen, it can remind them which section they're in relative to the others.
This indicates (to me, anyway) that it's not a function of which heading you've scrolled to; it's a function of which section is on screen. If you use section-screen-area or something similar to highlight the active section, fiddling with the heading positions becomes unnecessary.
If you have a tiny section at the end that can never take up the majority of the screen, then when the user is reading it, the active indicator won't really be useful anyway.
I find such active anchors incredibly distracting. It’s like something blinking at the side (or top) just because you’ve scrolled a bit.
Regarding the purported problem they solve, maybe browsers should have an option to show current-heading information, similar to how IDEs show in which function or the like you’re in within the current source file.
I clicked, thinking that it was perhaps someone who like me was annoyed by Jira's anchors/permalinks which is a <span> with a <button> with a JS event listener on click to load what would normally be an <a href> into the DOM.
But this, this is similar, but different. I can't navigate to anchors with for example the keyboard.
Question for the author: Why not use the HTML <a> element rather than a JS event listener on a non-interactive element?
I thought the same. And on this site I cannot even see the proposed anchor link because it's a badly implemented web component custom-element that is all JS defined instead of wrapping actual HTML elements/text. It's such an overengineered anchor link that unless you succssfully execute all the javascript it doesn't appear at all. Very fragile.
> But if you ever had to implement them, you might have encountered the .
Wikipedia is also bad about JS-dependent false anchor links. I can't count the number of times someone "linked" me an "anchor" to an image on a wikipedia article that simply did nothing without javascript. All wikipedia would have to do is put a real html a anchor next to the JS defined one to fix it but despite submitting bugs about this it's never been fixed.
Adding padding below the main page content seems ideal since it also fixes the issue where the tail end of the content is stuck at the bottom of the viewport instead of where you'd prefer it.
Maybe a 90vh margin for mobile and 50vh for everything larger.
Hmm, then again you'd still need TFA's solution for the latter case. The margin only solves it on mobile since a 90vh margin on desktop would look ridiculous.
In modern browsers, Text fragments let you highlight specific portions of text on a page, be it at the bottom or anywhere. In Chrome, just highlight the text and right click -> Copy link to highlight.
I use it every day instead of anchors to highlight very specific parts of the text, to avoid referring to the whole section with an anchor. Some pages don't even have anchors
It's hilarious reading the other comments. I'm on mobile but my first thought was how interesting and novel the site design was and how clearly communicated the problem they were trying to solve
Cool post! It's refreshing to read a blog that doesn't ask me to subscribe with popups etc and gets into technical weeds
Thanks! Site is still in stealth alpha and posted an article here in hopes to get -some- feedback. Didn't expect this kind of anger hahah. Very grateful for the positive comments though.
Im on the fence about pre-opening the 'tiles' on mobile. Do you (or anyone else) have any strong opinions on that?
Once I got over my fear of clicking their links, which I assumed would open a new page (but instead just expanded a pane in-line), I really enjoyed it. I’m very wary of opening new pages. (Also, I first tried to hold-click on the link to open in new tab, but it just behaved like regular text and highlighted, which led to a momentary confusion. I would have preferred a more obvious indication of what would happen when clicking, like a down chevron or something.)
> the site design was and how clearly communicated the problem they were trying to solve
I don't agree with either. Even after I enabled JS (no warning) and then after reading the whole page, finally realized that the implementation of popins was completely broken on Firefox and switched to Chrome to reread it (it doesn't help that the first 'link' is not a link†, and the link says it's 'broken' but it means broken in a different way from being actually broken so when you click on it and nothing happens, you infer that nothing was supposed to happen, which is why you were told it was broken...), I still couldn't understand WTF the problem was or how any of this could be remotely justified compared to an ordinary ToC and section headers or anchors.
† I'll just note that I have looked at many, many sidenote implementations (https://gwern.net/sidenotes) and the choice to make your sidenote/footnote link look exactly like a regular link is an... interesting choice.
The article is a neat read! The design of the blog itself is even more interesting. I don't love the right-aligned way it starts, but I love the inline activations of the left popup! So cool
Thanks! It has some cons, like worse scanability. But I think its really cool that you can have something open next to your paragraph, especially when you need to consult the popup quite often. Like, a table with a bunch of data would also be quite nice with this approach I feel.
This seems like the obvious solution to me. You don't know what the user's eyes are looking at, so making the highlighting a visual representation of what's in the viewport seems preferable than nominating a single section as "current".
In fact the final solution is pretty bad. Sure, it looks nice when I scroll down, but when I use the alternative navigation method of clicking the sidebar items, it just scrolls to unexpected places.
I don’t think this is a real problem that needs solving; or I at least think it’s a problem browser vendors should solve, but lets over engineer it while still trying to keep it simple and usable…
What I might do is something similar to what you’re suggesting. I would have the anchor tag be a regular old anchor tag. Then, I’d highlight the heading (maybe just temporarily) at the same time. I’d use CSS if I could figure that out or JS if I couldn’t. The end result would send the user to the normal place and flash a highlight on the heading for users with JS support.
Keep it simple, but over engineer it to make whoever requested this happy.
Edit: After re-reading your response we probably aren’t talking about the same thing, exactly.
Another aspect of over engineered anchor links seems to be that at least on Chrome on iOS, back navigation doesn't work properly on this site as a whole.
For my Firefox desktop, even the "beautiful solution" at the end highlights "Middle Section" even if the Conclusion is fully visible, but I'm just not quite at the bottom of the page in terms of scroll.
Surely the answer is to highlight all onscreen anchors. You don't know where my eyes are looking on a page with two headings on it.
Interesting solution. One little tip, I would advise picking a different heading for the section "The final solution". That phrase has a bit of unfortunate historical baggage.
my first instinct would be to let the triggerline move with the scrollposition, i.e. at scrollTop = 0 the triggerline is at 0vh and at scrollTop=max at 100vh... am i missing something?
I dabbled with this kind of issue in my docs and ended up using JavaScript's Intersection Observer [0]. It's not a perfect solution [1], but I think it worked well enough [2]. It just identifies when the element comes on screen and then marks it as active however you please. I do appreciate the depth the article went into though!
To see what I mean, click "Creating a Feature" then start scrolling up. Notice that "Creating a Feature" is still highlighted even though the entire screen is made up of text from the "Software" section.
I probably only noticed this because I recently implemented a similar "active anchor" solution with Intersection Observer.
My solution was to just highlight the last anchor if the user scrolled to the very bottom. Although this might skip the second last heading if its too close to the bottom.
IMO, the most important UX features for anchor links is that you should be able to send them to other people (and save them via bookmarks).
Say that you find yourself needing to check the "Control code table" section of the Wikipedia ASCII article from time to time (for some reason). Being able to bookmark that specific section[1] is much more convenient than having to always start from the top of the page[2] and then scroll down (or click some on some anchor link) to get where you actually want to go.
This thirty-five website doesn't seem to offer that functionality because it doesn't use #anchor-name URLs.
FYI on the topic of scroll position, it seems inconsistent between history navigation. For example scroll to the very bottom, click your Internship blog post, and go back - it ends up somewhere towards the end but not quite. (Chrome Mac)
On mobile just clicking the other blog post takes me to the end of that post. (Chrome iOS)
It's an interesting problem - the approach I've taken in the past is to simply highlight all sections that are on the screen. This is pretty straightforward to do nowadays with intersectionObserver.
Another potential option is to allow for multiple "active" states (everything in view). If the content is long enough, it can kinda work out. As you transition from one section to the next, both headers would be "active". For short content it would highlight too much though.
Nice read. Although I much prefer the first solution, the hotfix of adding extra padding to the bottom. UX-wise, not just because it is simpler.
On large screens I prefer to not read texts at the bottom (I always scroll things enough so I am looking at them at the middle or top of the screen). Also, the positioning of the heading relatively to the screen is always the same on every scroll.
While I usually detest giant footers, this is one use-case they lend benefit to, without causing a large empty space (which some people would then want to fill with an image). I agree from a UX perspective that I prefer when sites act the way I expect them to, and not try to do novel calculations of stuff (minus usability stuff like the ‘dead zone’ dropdown menu polygon calculation). On most pages, I expect a reading section to start when I scroll past a heading, and I prefer anchors to deliver the heading at the top of my viewport.
I find this layout extremely weird and distracting to the point that I couldn't manage to get through the article at all. I would much rather have the fancy stuff as inline callouts, with none of the giant attention-grabbing bright buttons in the middle of the text.
Seems like if you open the "he thinks" image thing at the bottom, and then go back to the "beautiful" result, then it no longer works and the Conclusion heading doesn't get activated. That's how I reproduced it anyway.
On Android, both the first and last example scroll to "Conclusion" in the exact same way for me, and the heading shows up in the same place within the div they are showing the examples in.
Nicely presented article. The way anchor opens up and not letting go the context is good. Overall visual and the ease to access information is appreciated.
The new CSS Overflow Specification 5 has scroll-marker that can replace anchor link. From my short test in Chrome 135, they seem to scroll to the right place.
I'm sorry but anything that hijacks the scrollbar in any way is just a no-go. You have to not interfere with scrolling. (Taking some other action on the page during scrolling can be okay, but actually affecting the scrolling itself in any way while you are scrolling should be verboten, in my opinion.)
Pages interfering with how scrolling works infuriates me so much that I've often considered writing an extension that tries to disable that behavior, or even compile my own Firefox if I had to.
It's something new IMO but we are definitely working on improving UX still. Fixing the overscroll issue as we speak. I'm assuming you're using mobile, would you prefer it of the 'tiles' all started in an open state?
It is not an experiment in how bad front end design can be pushed to be... Although that would be a fun blog post
I think you can look at UX like this less like a web page and more like a presentation. In that framing it's more palatable.
In general we consume blogs more like traditional web pages, so it feels ... "wrong," but in some ways it keeps all of the content at hand and lets you navigate linearly or back and forth pretty reasonably, the way you might traverse a PPT.
Terrible culture that rewards psychopathy. Every CEO is an insane individual that has no remorse for any terrible action they do. This makes perfect sense that their entire corporation would reward breaking rules. It's what they would do afterall.
So over-engineered that I cannot even see them until I enable multiple rounds of JavaScript. And the colour scheme ignores my preferences and hurts my eyes.
LinuxAmbulance|11 months ago
It's an excellent article, and the work within is very well done, but there's a part of me that screams "Why would you introduce this much complexity for what should be a simple scroll?" (overcoming technical hurdles to produce the desired end result aside).
hombre_fatal|11 months ago
OP is doing a basic analysis on what kind of solutions exist for a typical UX edge-case. They even provide the simple solution that most people use (margin-bottom).
And for fun they go on to see if they can solve it without the minor drawback of the simple solution.
We've got to stop acting like it's a badge of honor to avoid UX consideration. We might not be people who implement UIs, we use UIs all day and should be able to muster up a few opinions about how a UX interaction should work.
madeofpalk|11 months ago
Building excellent user interfaces is hard, regardless of the technical stack. You have to sweat a lot of the finer details, break out of any platform default behaviour where appropriate, and over engineer something in service of building a 'delightful' user experience.
Or, you can do as most do, and just not do this. #anchor-links with `scroll-behavior: smooth;` CSS will get you the basic smooth scrolling.
philsnow|11 months ago
From time to time I dip my toe in and try new things, but as productive as I can get with Astro, the illusion vanishes as soon as I have to understand any of the plumbing.
Fortunately, I can still party like it’s 1999 just fine: just yesterday, I worked on a janky brutalist web app (the same way I did back in 2002, cribbing from the O’Reilly “Dynamic HTML: the Definite Reference”) and “deployed” it with rsync to pico.sh. It’s practically unstyled and I didn’t even use jquery, but it works.
nine_k|11 months ago
Because the scroll, as you see, is not simple. The complexity of the real-world scenarios outlined in the post force the complexity of the solution. It may feel that "it's simple common sense" kind of thing, but if you ever tried to implement a simple common-sense thing, you know that it only appear simple.
By the same token, some UX person might read about the mechanics of database transactions with two-phase commits, or about MVCC, and ask why so much complexity exists around what should just be a simple write to disk.
"Reality has a surprising amount of detail."
nkrisc|11 months ago
bgro|11 months ago
Numerous autoplaying video methods for example especially when they follow the mouse, play in the background, or use lazy loading to be unkillable.
Speaking of lazy loading or whatever hundreds of variations probably exist around it now, the terrible front end devs of the world have decided to use that for everything. Everything is a sliding panel full of sliding panels and there’s no way to use browser back features coherently.
Scrolling down a site now loads a new site and destroys your history. Even if you scrolled to move content up because an autoplaying video anchored to the bottom of the screen is blocking the view. Scroll down too far causes a jump and the site decides you’re done and loads the next thing with no way to navigate back.
How do these developers have a job? How are features like this even invented with no critical thought or understanding of real world use cases questioned. It’s again and again and again that we see this.
And the Google team is so proud every time with their demo videos that is painfully obvious they put no thought into it outside of their bubble of them deciding some random thing was technically possible to do as a proof of concept and should therefore be immediately released as a fully supported feature.
matser|11 months ago
unknown|11 months ago
[deleted]
mardifoufs|11 months ago
tshaddox|11 months ago
paulddraper|11 months ago
The article explains the "why."
> overcoming technical hurdles to produce the desired end result
Yes.
hvs|11 months ago
jillesvangurp|11 months ago
I'm a hands-on CTO in a very small company. So, if it's technical, I'm doing it. Websites, apps, backends, databases, devops and all the rest. Not always fun. But at this point I can fill every role in a typical product team and do a decent job.
And I agree that what passes for state of the art on the web is a bit meh. Anchors date back to the early days of the web. One of those forgotten features that is still vaguely useful but a bit underused. There's a reason mobile developers prefer native UI toolkits. Browsers are a bit limited and backwards. CSS is a bit of a straight jacket. And Javascript is a bit of a basket case as a language.
megadata|11 months ago
Yeah, when you can't easily scroll anymore because it's "too far" then something has gone very, very wrong.
svachalek|11 months ago
type_enthusiast|11 months ago
One answer I can think of: if a reader is in the middle of a long section, and the heading is off the screen, it can remind them which section they're in relative to the others.
This indicates (to me, anyway) that it's not a function of which heading you've scrolled to; it's a function of which section is on screen. If you use section-screen-area or something similar to highlight the active section, fiddling with the heading positions becomes unnecessary.
If you have a tiny section at the end that can never take up the majority of the screen, then when the user is reading it, the active indicator won't really be useful anyway.
layer8|11 months ago
Regarding the purported problem they solve, maybe browsers should have an option to show current-heading information, similar to how IDEs show in which function or the like you’re in within the current source file.
swyx|11 months ago
Y-bar|11 months ago
But this, this is similar, but different. I can't navigate to anchors with for example the keyboard.
Question for the author: Why not use the HTML <a> element rather than a JS event listener on a non-interactive element?
superkuh|11 months ago
> But if you ever had to implement them, you might have encountered the .
Wikipedia is also bad about JS-dependent false anchor links. I can't count the number of times someone "linked" me an "anchor" to an image on a wikipedia article that simply did nothing without javascript. All wikipedia would have to do is put a real html a anchor next to the JS defined one to fix it but despite submitting bugs about this it's never been fixed.
hombre_fatal|11 months ago
Maybe a 90vh margin for mobile and 50vh for everything larger.
Hmm, then again you'd still need TFA's solution for the latter case. The margin only solves it on mobile since a 90vh margin on desktop would look ridiculous.
layer8|11 months ago
jopsen|11 months ago
whirlwin|11 months ago
I use it every day instead of anchors to highlight very specific parts of the text, to avoid referring to the whole section with an anchor. Some pages don't even have anchors
Ref: https://developer.mozilla.org/en-US/docs/Web/URI/Reference/F...
mhitza|11 months ago
wrsh07|11 months ago
Cool post! It's refreshing to read a blog that doesn't ask me to subscribe with popups etc and gets into technical weeds
matser|11 months ago
Im on the fence about pre-opening the 'tiles' on mobile. Do you (or anyone else) have any strong opinions on that?
noahjk|11 months ago
gwern|11 months ago
I don't agree with either. Even after I enabled JS (no warning) and then after reading the whole page, finally realized that the implementation of popins was completely broken on Firefox and switched to Chrome to reread it (it doesn't help that the first 'link' is not a link†, and the link says it's 'broken' but it means broken in a different way from being actually broken so when you click on it and nothing happens, you infer that nothing was supposed to happen, which is why you were told it was broken...), I still couldn't understand WTF the problem was or how any of this could be remotely justified compared to an ordinary ToC and section headers or anchors.
† I'll just note that I have looked at many, many sidenote implementations (https://gwern.net/sidenotes) and the choice to make your sidenote/footnote link look exactly like a regular link is an... interesting choice.
unknown|11 months ago
[deleted]
carlosdp|11 months ago
matser|11 months ago
If you have any feedback I'd love to hear it!
jer0me|11 months ago
technojamin|11 months ago
In fact the final solution is pretty bad. Sure, it looks nice when I scroll down, but when I use the alternative navigation method of clicking the sidebar items, it just scrolls to unexpected places.
Beautiful article, though.
codazoda|11 months ago
I don’t think this is a real problem that needs solving; or I at least think it’s a problem browser vendors should solve, but lets over engineer it while still trying to keep it simple and usable…
What I might do is something similar to what you’re suggesting. I would have the anchor tag be a regular old anchor tag. Then, I’d highlight the heading (maybe just temporarily) at the same time. I’d use CSS if I could figure that out or JS if I couldn’t. The end result would send the user to the normal place and flash a highlight on the heading for users with JS support.
Keep it simple, but over engineer it to make whoever requested this happy.
Edit: After re-reading your response we probably aren’t talking about the same thing, exactly.
Etheryte|11 months ago
nizarmah|11 months ago
inetknght|11 months ago
cmgriffing|11 months ago
So you could have multiple items highlighted, but it still "works" somewhat intuitively for the end user.
The drawback is that it requires JS via intersection observer. But maybe the CSS standards committee could see value in this kind of thing eventually.
robertlagrant|11 months ago
Surely the answer is to highlight all onscreen anchors. You don't know where my eyes are looking on a page with two headings on it.
jiehong|11 months ago
It’s what headings maps extension does when you click on one [0].
[0]: https://addons.mozilla.org/en-US/firefox/addon/headingsmap/
trainspottinfly|11 months ago
matser|11 months ago
immibis|11 months ago
fourseventy|11 months ago
[deleted]
johnisgood|11 months ago
daef|11 months ago
riz_|11 months ago
awayto|11 months ago
[0] https://developer.mozilla.org/en-US/docs/Web/API/Intersectio... [1] https://github.com/keybittech/awayto-v3/blob/main/landing/la... [2] https://awayto.dev/docs/0.3.0/
mason55|11 months ago
To see what I mean, click "Creating a Feature" then start scrolling up. Notice that "Creating a Feature" is still highlighted even though the entire screen is made up of text from the "Software" section.
I probably only noticed this because I recently implemented a similar "active anchor" solution with Intersection Observer.
ruduhudi|11 months ago
j_san|11 months ago
My solution was to just highlight the last anchor if the user scrolled to the very bottom. Although this might skip the second last heading if its too close to the bottom.
See here: https://sharezone.net/privacy-policy (most visible on desktop, on mobile you have to open the "Inhaltsverzeichnis" at the bottom)
DavidVoid|11 months ago
Say that you find yourself needing to check the "Control code table" section of the Wikipedia ASCII article from time to time (for some reason). Being able to bookmark that specific section[1] is much more convenient than having to always start from the top of the page[2] and then scroll down (or click some on some anchor link) to get where you actually want to go.
This thirty-five website doesn't seem to offer that functionality because it doesn't use #anchor-name URLs.
[1]: https://en.wikipedia.org/wiki/ASCII#Control_code_table
[2]: https://en.wikipedia.org/wiki/ASCII
sprobertson|11 months ago
On mobile just clicking the other blog post takes me to the end of that post. (Chrome iOS)
uses|11 months ago
hoten|11 months ago
snake-y example: https://zquestclassic.com/releases/2.55.0/
soneca|11 months ago
On large screens I prefer to not read texts at the bottom (I always scroll things enough so I am looking at them at the middle or top of the screen). Also, the positioning of the heading relatively to the screen is always the same on every scroll.
noahjk|11 months ago
crooked-v|11 months ago
Philip-J-Fry|11 months ago
Seems like if you open the "he thinks" image thing at the bottom, and then go back to the "beautiful" result, then it no longer works and the Conclusion heading doesn't get activated. That's how I reproduced it anyway.
porridgeraisin|11 months ago
jineshkrishnan|11 months ago
watersb|11 months ago
Which might be an approach for the first few examples.
I am sure there are other cases that would need anchors.
sntran|11 months ago
asynchronousx|11 months ago
layer8|11 months ago
JackYoustra|11 months ago
askew|11 months ago
hk1337|11 months ago
kubb|11 months ago
cynicalsecurity|11 months ago
encom|11 months ago
anon115|11 months ago
unknown|11 months ago
[deleted]
Georgesortiz900|11 months ago
[deleted]
miragecraft|11 months ago
unknown|11 months ago
[deleted]
meowface|11 months ago
Sohcahtoa82|11 months ago
matser|11 months ago
unknown|11 months ago
[deleted]
lugao|11 months ago
[deleted]
unknown|11 months ago
[deleted]
matser|11 months ago
It is not an experiment in how bad front end design can be pushed to be... Although that would be a fun blog post
nkozyra|11 months ago
In general we consume blogs more like traditional web pages, so it feels ... "wrong," but in some ways it keeps all of the content at hand and lets you navigate linearly or back and forth pretty reasonably, the way you might traverse a PPT.
hn_is_all_bots|11 months ago
[deleted]
NanoYohaneTSU|11 months ago
DamonHD|11 months ago
I backed right out of whatever that was.