Yesterday's best-practices are today's HTTP/2 anti-patterns

Re:Yesterday's best-practices are today's HTTP/2 anti-patterns by glitch on Sunday May 31, 2015 @02:29AM (#9633290)

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, 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.

[ Parent | on HN ]

Re:Yesterday's best-practices are today's HTTP/2 anti-patterns by maxlaumeister on Sunday May 31, 2015 @02:33AM (#9633299)

I 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.

[ Parent | on HN ]

Re:Yesterday's best-practices are today's HTTP/2 anti-patterns by glitch on Sunday May 31, 2015 @02:36AM (#9633305)

Scrolling 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.

[ Parent | on HN ]