Actually, this will send a POST request request to the server, so technically you aren’t mixing the two together : you are using POST with url parameters. There is nothing fundamentally wrong with this, as long as you don’t use your URL for parameters that should be in the form as hidden field.
There are simple rules : you use GET (possibly with URL parameters) for constant things that do not change the server, and POST for thing that modify the server. If your url parameters contained the ID of something you wanted to delete, then it would be bad practice.
EDIT, years later
I was asked for source, so here are the relevant part of the very spec of HTTP
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe”. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
There you go, GET should not change anything, POST is for thing that change the server (unsafe operation). I should be able to call GET any number of time. It is more than idempotent : it’s should be (as much as possible) side-effect free! With GET the request may not even reach the server if caching is involved.
So yeah : you have a form, want to know if you use GET or POST? Then change server => POST, don’t change server => GET. And since a URL can be accessed with any verbs (get or post), don’t put the data that change the server in the URL, because someone may copy that URL, do a GET and change your server without you knowing. Imagine what would happen if someone copied that URL on facebook and 10 000 people started to delete random things? Not good. Recent framework (node, ruby) are better insulated against that, but not basic PHP, so it’s a good rule of thumb for that language.