3 ms·
I can't actually tell if that's sarcasm anymore or not. Next slide is a new URL, new page. Based on initial testing, the behavior seems fine. Same behavior as
by glitch 11y ago
I can't actually tell if that's sarcasm anymore or not. Next slide is a new URL, new page. Based on initial testing, the behavior seems fine. Same behavior as one would have for something like http://example.com/my-presentation/1.htm http://example.com/my-presentation/1.htm, 2.htm, 3.htm, etc. and navigating them with hyperlinks on each slide that link to neighboring slides.
It's not like Back/Forward browser buttons are overrode to behave and previous/next for the slide presentation.
Remember those horrible embedded Flash presentations that you couldn't directly link to a particular slide within the blob? Yeah, that "breaks the Web". Back/Forward is supposed to go back to the previous page the user was on (which is a "slide" in this case).
Using Chrome 43.0.2357.81 (64-bit) / OS X.
- maxlaumeister 11y agoI would agree except that they also use scrolling to change slides. It feels a little weird to scroll down 3 ticks of the mousewheel, then have 3 clicks of the back button do the reverse action.
- glitch 11y agoScrolling is a separate matter. I didn't even bother to scroll the first time. I just pressed the next/previous buttons on the slide navigation bar. In the scrolling case, I still don't see how it's "overriding the browser buttons", but rather having a JavaScript that advances to the next page on scroll. In the scrolling scenario, my actual back and forward browser buttons behaved as expected — just for the pages (slides) I visited. No more, no less.