* Two reasons:
-- Limit bug: Limit can't be enforced if the two are together
because only page_title is limited, the namespace prefix
is not part of the title. Plus even then, there is still
ambiguity with the various ways to denote namespaces (aliases)
and whitespace freedom between namespace, colon and title.
-- Extra feature: Now that the two are separate it' s easier
for users to move across namespaces as one doesn't have to type,
can't make spelling mistakes. Also, in the future we could exclude
certain target namespaces that are not possible or not allowed (now one can
perfectly submit a request to move from NS_CATEGORY or NS_FILE, only to
get a warning on submission). By showing them disabled in the drop down
this becomes clearer).
* Keeps backwards compatibility for gadgets and permalinks generated
by templates on wikis so that they can still pre-set the "new title"
from a url the old way. The new way can also be pre-set from the url,
and allows them to be set separately (wpNewTitleNs=10&wpNewTitleMain=Infobox)
* Gadgets and templates linking to Special:MovePage with a preset target
-- Old way (still works): wpNewTitle=Template:Infobox
-- New way: wpNewTitleNs=10 (and/or) wpNewTitleMain=Infobox
* Fixes bug 29454; Depends on r109990;
-- (bug 29454) Enforce byteLimit for page title input on Special:MovePage
This just puts a maxlength on the field (+ byte counter js) which is much
nicer and clearer feedback to the user if they went over the limit then:
"The requested page title was invalid, empty, or an incorrectly linked inter-language or inter-wiki title. It may contain one or more characters which cannot be used in titles"
Which doesn't exactly indicate a length error.
* 'this' in a fn/prototype context already points to the jQuery object. Calling $(this) is redundant and goes through $.fn.init again untill it reaches the last else case (luckily $.fn.init() has a failsafe case for that, but also makes it harder to spot)
* Adding support for using the current attribute value (to avoid having to duplicate the values between PHP and JavaScript). Fully backwards compatible, I think it's a very handy feature to be able to pass a custom length, but using the maxLength attribute as a default makes sense.
