Oh. Side comment. Can we please not do a download button that automatically tells the browser "just save this"? Because that goes into my downloads folder (I am not asked for a destination) and that's not where I want to put stuff. (see: Weasyl)

Yeah, that's why I want artist name first. I don't care too much about the ID, so I have a macro that just strips it off when I save stuff from FA. There's the occasional file name conflict (because Ruaidri and a few others don't give their images unique file names, Ru's are a lot of "x004.png" and such) but I can handle those manually just fine.

I hadn't before, but taking a look at it, it's a combination of a couple things:
1) it unloads content that is no longer visible (about 5 "pages" outside your view)

2) those unloaded sections also don't take browser height, which means that it adjusts your scroll position

3) it appears to do both of these things when it loads new content in to continuously scroll, so the jump is actually less noticable

4) it can do this because the content is of known height. Unloading 12 items that come in rows of 3, that's 4 rows, each row is N pixels high...

5) lastly, it changes the url which causes the history to update, but it also does this by removing any prior page (so your history isn't a giant chain of "page:1" "page:2" "page:3" links)

6) it then uses AJAX to load in content when navigation changes to place the browser at the correct position with the desired content visible (per 1, 2, and 4)

Oh I'm sorry, it's called pushState.

I figured anyone with a reasonable level of flexible reasoning capacity could have figured out what I meant based on the words I used. Excuse me for using "foo" when it's really called "foobar." The history is a stack. I'm sorry for using the generic collection method add when it should really be called push.

Oh I mean just the append. History.addItem()

IIRC, Firefox and IE all treat that new item as the page you just left whereas Safari and Chrome (the two WebKit browsers) treat it as the page you just got to. Now, that's not the part that screws things up.

It's that when you hit the Back button and pop an item off the stack in the former case (Firefox) you'll get the item you just added and you'll handle the data inside it and end up right where you expect. but in Chrome you'll end up two steps back.

(Mind, this is based off of having played with the history API 2 years ago: I only remember there being some funny business and that Firefox did exactly what I expected. I vaguely recall a scenario where I had to hit Back twice in order to actually go back once, but I don't recall if that was the initial behavior, or the behavior after I tried to account for Chrome's weirdness).

That's because the link got fucked up.

Try this

I think e621 has even more flexibility than this. Say you want to block all football, unless it's pokemon playing football (because that's cute).

Block: "football !pokemon"

See also, Easy way to Fave, Promote, or Delete from grid mode.

I think this is one of the areas that e621 excels at. I haven't used it myself, but apparently you can filter tag pairs. Eg. you could filter "female solo" to never show, or you could filter out every picture tagged female unless it had both "female" AND "solo."

(I realize the example isn't quite your particulars, just illustrated the feature better)

Personally I'm not a fan of dA's route, but I wouldn't deny it from those that do like it. It just isn't for me.