That's effectively security through obscurity. If someone got one of your passwords, he could try to figure out f()^-1 and reverse your funciton, supossing its inversible; that would grant him all of your passwords with the same salt. Specially since you just now published an outline of your scheme.
All passwords are effectively security through obscurity, with varying sizes of trapdoors. If someone got a hold of your piece of paper that has all of your passwords written down on it, then you're hosed as well. If you're being targetted, you're basically in trouble no matter what. Sometimes security just has to be good enough, for most users, good enough is such that having one password compromised by a trawling operation is sufficiently firewalled against having the other passwords compromised by an automated agent.
Even so, you can bet that for things I really care about that are difficult to reverse (such as, like, say a bitcoin wallet) I'm not going to use this scheme.
Can you programmatically enforce your password generation scheme? No. Can you at least encourage it via system design? Unlikely. So essentially you're just saying "users, you should do it my way". This is what most developers have been saying for decades, and it simply does not help.
but that's exactly what the xkcd article did. I'm just pointing out a deficiency in the xkcd scheme, and offering an alternative. Some people may have a better arbitrary associative memory than I have, and for them, the xkcd scheme is a better choice.
Edit:
Although the original xkcd was specifically complaining about silly practices that arbitrarily restrict the xkcd scheme.
What I do is the following:
I have a function that reliably converts the name of a service -> some string, easy to compute in the brain
passwords are salt + f(service)
where salt is a strong string of characters for critical services (financial, personal info, etc)
and a weak string of characters for stuff i don't care about.