Jump to content

How to Discipline a Misbehaved iPhone Keyboard


iwato

Recommended Posts

ALERT:  This question can be answered by both new and old users who do not like pop-ups, because it is an iPhone -- an environment in which the now infamous/famous Grammar Captive splash panel is forever suppressed.

BACKGROUND:  After many excruciating hours the responsive design of Grammar Captive is nearly complete.  One of the several known outstanding problems that remains occurs when one uses Grammar Captive's custom search engines with an iPhone.  In order to enter one's search word or phrase the iPhone keyboard appears.  It works like a bad wine that starts with an attractive bouquet and flavor, but ends with a strong, even foul, after taste.  An alternative analogy is a misbehaved (innocent or malevolent) child that leaves his parents or older siblings to clean up after his after he has played.  In effect, the keyboard takes up the entire width of the viewport, but does not return the webpage that hosts the form input control that evokes it.

Although I was able to find a possible solution on StackOverflow it has proven difficult to implement.

PROPOSED SOLUTION:  Add an id attribute to the page's meta tag that hosts the viewport control and reference that tag when the search is submitted.

Before Search:

<meta  id="viewport" name="viewport" content="width=device-width, initial-scale=1">

After Search:

$('#viewport').attr('content', 'width=device-width, initial-scale=0.5');

I believe the reason that this works for others, but not for me is that Javascript cannot find #viewport.  This is because of the sequencing of the Javascript that produces the dynamically loaded center panel.  In brief,

overview.js is loaded with overview.html (the Grammar Captive mainpage)
search_letter.js is loaded by overview.js after the search panel has loaded, but before a search is made.  If the After Search modification is to be implement, then it must be implemented after the search has been completed.

QUESTION ONE:  Am I likely correct in my assessment?

QUESTION TWO:  If so, how might I resolve the problem?

Roddy

Link to comment
Share on other sites

It turns out that the poorly behaved iPhone keyboard is not the only source of misbehavior.  A similar phenomenon occurs with the use of <select> elements.  When the visitor goes to select a menu option, the iPhone fills the viewport with a selection panel native to the iPhone. After the selection has been made and the select panel has been closed, however, it is left up to the visitor to readjust the width of his viewing screen so that it fits properly into the viewport.

I thought Apple was smart.  Alas, it turns out to be lazy.

Please advise.

Roddy

Link to comment
Share on other sites

That's a feature that only kicks in when the font in your dropdowns is smaller than the standard for accessibility, it was designed to help people with poor vision. You can prevent that by making sure that your dropdowns have a font size of 16 pixels or greater.

I advise against changing the value of any meta tag, these are read once when the page loads and are never expected to change.

I can't answer your question about the iPhone keyboard since I don't have the means to reproduce it right now and I don't fully understand the issue. I would expect the keyboard to span the full width of the phone's screen, there's not much space on it and there are a lot of letters to cram into there. Given that you mention that the issue is similar to the dropdown one and that it occurs when focusing the search field, I would suggest making your search field larger as well.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...