cool, thanks! :)

It's more reasonable now with 70 characters than it was before with 50. Thanks!

But why 70? When the width of the search box is maximized (instead of magically-numbered) the page looks best and associates page elements best because 1) the Search button is always underneath the help link, and 2) the namespace chooser box is "with" the search box, always the same width, always the size of the window. It is critical that any use of the search box always keep the namespace-chooser box in view in order to properly interpret the search results. Having them the same width (as well as having the namespace-chooser box directly below the search box), will no-doubt help this critical association. (I'm not asking here for those two page elements to be entirely integrated visually; eventually they probably will be boxed together.)

The maximum query length is 300. I'm not asking for a new JavaScript gadget here, that would guarantees query visibility and editability. Once the search box maxes out, only the keyboard can work a query, so when this happens user experience is degraded.

Nor is mousing over to a too-distant, 200 em away, Search button ever an issue. The rare time the Search button might needed is to touch it on a touch screen, having revisiting a search.

There is no specific reason for the width, it's limited to 50 em like all OOjs UI text fields are by default. If the screen narrower than that, it will take full width. I'm not sure why this limit exists, but I like it, things that are too big sometimes don't look clickable (and the styling in the default theme really doesn't do much to indicate this either, unlike in the Apex theme that MonoBook uses).