To avoid detection, terrorists purposely sent emails with spammy subject lines

[Mr. Analog]

So simple, yet so clever:

http://qz.com/326927/to-avoid-detection-terrorists-purposely-sent-emails-with-spammy-subject-lines/

Classic wolf in sheep's clothing

[Thorin]

And here all the cryptologists were trying figure out what messages were hidden in the bits and bytes of images...

[Mr. Analog]

Heh, find things people ignore, hide in them

[Thorin]

Like barrels: http://youtu.be/kvAzB_dAhNs?t=2m20s

[Darren Dirt]

That URL in OP, weird site, visiting it in Firefox I noticed that as I scrolled to the 2nd story the URL ADDRESS CHANGED but the page did not reload (it's like Tumblr, where more content loads as you scroll down) ... so is that neat (and weird!) effect due to how the server parses the URL and all done with AJAX or something? Doesn't work the same in IE of course (it keeps the original URL, even as you scroll fully into the 2nd story).

If you did not notice this effect, try it again with FF (or Chrome!) and see for yourself. Unsettling (because it goes against what we are used to) but then it kinda hits you that it's neato. Basically seems like the entire website is a SPA, and the URl instead of changing to "website.domain.tld/#PageXyzIdentifier" it does not have the "#". Which to me should mean it does a full page reload when that URL changes, but it doesn't.


URL1 (OP) http://qz.com/326927/to-avoid-detection-terrorists-purposely-sent-emails-with-spammy-subject-lines/
URL2 http://qz.com/328217/hacks-to-help-you-stick-with-your-new-years-resolutions/ (and when I had CUT to the clipboard URL1, it did NOT visibly change to URL2, but the webpage TITLE DID get updated to the title of the 2nd story).

Weird, cool. Want to learn new trick whenever I see a new trick. #sickness

[Darren Dirt]

That URL in OP, weird site, visiting it in Firefox I noticed that as I scrolled to the 2nd story the URL ADDRESS CHANGED but the page did not reload

...

Weird, cool. Want to learn new trick whenever I see a new trick. #sickness

I guess I could just hit F12 and go to the Network tracing tab and reload and see what HTTP calls occur and what data moves around...

[Mr. Analog]

Use Fiddler2

[Lazybones]

Firebug network tab if you use Firefox.

[Tom]

chrome has a network tab too iirc.

[Mr. Analog]

Can also go to the source (I'm not sure which library they're using but most are the same)

http://airbnb.github.io/infinity/

[Darren Dirt]

Can also go to the source (I'm not sure which library they're using but most are the same)

http://airbnb.github.io/infinity/

Was saying it acts "similarly" to the way Tumblr loads infinitely. The difference is that unlike Tumblr which is a single URL always (and has a long, growing list of contents -- usually images) this website (and a few others I have seen lately) has lengthy articles, and instead of one-article-per page it does the "load the next article" thing (like Tumblr" but also once you scroll to the end of the old article and hit the start of the next one THE URL CHANGES IN THE ADDRESS BAR. So that's what I found weird/neat.

Was saying I guess when I have time if I really am that curious re. the HOW, since sometimes it's a bit of a challenge to "Inspect Element's EVENTS", I could just enable the Network tracing in FF/Chrome (as others mentioned) to see exactly what HTTP calls are occurring during that transition into Article #2.

Clearer than mud now?



...


update:

PS: had a look at the view-source, I see a mention of some custom code that was inspired in part by https://github.com/zuk/jquery.inview/ and sorta-related http://www.appelsiini.net/projects/lazyload

So obviously there is some jQuery .bind("inview") event handling for the "infinite scrolling" effect, but the real weirdness to me was always the URL changing but the web browser not visibly reloading anything.


After more glancing, my guess is (imo) that the contents are wrapped inside an IFRAME container or similar, and the URL in the addres bar is kinda just there for show.
That would explain how there is no VISIBLE "reload" even when the browser is told there is a new URL -- perhaps there is a cookie to keep track of the actual page and context the user is currently in, and the IFRAME (or whatever) is populated as you scroll ala "lazy load" etc. ... while the outer main page (with the "changing" URL) is empty other than the code needed to load the IFRAME and the supporting JS code.

My guess anyway.

[Mr. Analog]

More likely through Controller routes / actions

There's a good description of how most platforms do this via the Rails guide:
http://guides.rubyonrails.org/routing.html

As different action methods are called in the controller, new content is served

[Darren Dirt]

More likely through Controller routes / actions

There's a good description of how most platforms do this via the Rails guide:
http://guides.rubyonrails.org/routing.html

As different action methods are called in the controller, new content is served

It's not about how the new content is being served, what intrigued me in the OP is how the URL can change but not trigger an obvious visible reload of the entire page contents (or vice versa, how additional content can be added to existing page contents but still trigger a new URL in the address bar).

But the unconventional effect makes sense if the "main" page is virtually empty, and all of the visible content is actually inside an IFRAME.

[Mr. Analog]

Ahh okay

Pretty slick hey?