Virtuele keyboard onderdrukken/sluiten/voorkomen bij <input>

[Xthemes.us]

Hallo,

Weet iemand hoe je (eventueel met jQuery) voorkomt dat het virtuele toetsenbord wordt geopend op een mobiele telefoon bij het 'klikken'van een <input />? Ik heb het volgende al geprobeerd.

JavaScript:

            $inp.click(function(e){
                e.preventDefault();
                e.stopPropagation();
                $inp.blur();
            });
            $inp.focus(function(e){
                e.preventDefault();
                e.stopPropagation();
                $inp.blur();
            });

Op desktop browsers werkt het zoals verwacht, je krijgt de focus niet op het tekstveld. Op zowel de standaard browser van Android 2.1 en MicroB op de N900 is het tekstveld nog gewoon te selecteren en komt het virtuele toetsenbord naar voren.
Hoe kan dit voorkomen worden? Het input veld is namelijk bedoeld om een tijdstip in te voeren via een dialoog venster dat wordt getoond. Het virtuele toetsenbord overlapt het dialoog venster.

[MueR]

Zoals in je vorige topic aan je duidelijk is gemaakt (dat is nochtans goed geprobeerd), nee, dat gaat niet. Jij mag geen controle uitoefenen op dat niveau.

[OkkE]

Nog afgezien van kunnen - dit moet je niet willen. Blijf aub van de standaard af, die is niet voor niets zo. Gebruik bijv <input type=time> zodat je op nieuwe browsers een tijd-specifiek keyboard krijgt.

[Bosmonster]

Als je blijkbaar geen input-veld wilt, gebruik dan geen input-veld.

Ik kan me voorstellen dat je dit bijvoorbeeld wilt doordat je een eigen date-picker hebt. In dat geval zorg dat iets als een date-picker altijd additioneel is op bestaande invoermogelijkheden, ipv vervangend.

[ Voor 60% gewijzigd door Bosmonster op 02-11-2011 17:32 ]

[Ulster Seedling]

Of gebruik <input readonly="readonly" /> om een - je raad het al - read-only veld te maken, waar de gebruiker dus niet op kan klikken om wijzigingen te doen.

[Xthemes.us]

Hé bah, niet weer meteen die afkeur

Dit is juist een verbetering, het is namelijk al een <input type='time'>. Omdat nog niet alle browsers dit ondersteunen heb ik dus juist een javascript aanvulling nodig voor de browsers die dit nog niet goed aanpakken zoals (oudere versies van?) de Android browser, Firefox (zelfs de laatste versie niet).
Google Chrome ondersteunt nog net genoeg van wat ik nodig heb (een <date input='time'> met het step attribuut) en Opera ondersteunt als enige alles (datetime/date/time) wat ik nodig heb.

Afijn, dit is precies waar javascript voor bedoeld is, het verbeteren van de gebruikservaring. Als dat ook nog eens prima accessible wordt opgesteld is daar niks op tegen. Jammer genoeg schiet jQuery mobile hier op het moment nog in tekort anders had ik me graag de moeite bespaard en het wiel niet opnieuw uitgevonden. Wat ik in principe heb gedaan is vergelijkbaar met deze timepicker. Maar dan in een mobile SimpleDialog en op basis van een <input type='time'> waarbij de min/max/step attributen in acht worden genomen (en dan moet ik nog een stukje extra gaan schrijven zodat het alleen wordt gebruikt voor browsers die het niet native doen - dacht modernizr dit kon detecteren).

Readonly had ik nog niet aan gedacht en ik voorzie een probleem met events die simpelweg compleet niet aankomen en dat het element niet in de tab-volgorde wordt opgenomen. Maar goed, een poging waard - thanks.

[Bosmonster]

Daarom zeg ik, zorg dat het additioneel is. Dat is het hele idee achter progressive enhancement. Zorg dat er ook gewoon een tijd ingevuld kan worden op tekstuele wijze voor browsers die het niet ondersteunen.

Dan hoef je ook niet bij een volgende iOS-release bijvoorbeeld weer alles na te lopen of je trukerij nog werkt.

[Xthemes.us]

Was ook gericht op MueR die het gevoel heeft dat hij tegen een uhmmm MuuR praat .

Ik ben het volledig met je eens en zo maak ik ook altijd gebruik van progressive enhancement. Als er iets 100% op js leunt dan ben je fout bezig (uitzonderingen daargelaten zoals tekenprogramma's en dergelijke aangezien dat gewoon compleet niet wil zonder js).

Het idee is om een <input type="time"> te gebruiken welke in niet ondersteunde browsers gelijk staat aan een type="text" (of om precies te zijn de input waarde is niet bekend/wordt genegeerd en zonder attribuut is het standaard al een type="text"). Daar waar mogelijk wordt via JS een (touch friendly) tijdpickertje voor je neus gezet en als js gedisabled/niet ondersteunt is dan is het pech gehad.. moet je er zelf voor zorgen dat het in het juist formaat is anders hapt de server het niet.

[ Voor 41% gewijzigd door Xthemes.us op 03-11-2011 13:15 ]

[Xthemes.us]

Readonly wordt hem ook niet, lijkt er op dat ze bij Android niet bepaald de w3c regeltjes volgen.

quote: http://www.w3.org/TR/html4/interact/forms.html#h-17.12.2

When set, the readonly attribute has the following effects on an element:

• Read-only elements receive focus but cannot be modified by the user.
• Read-only elements are included in tabbing navigation.
• Read-only elements may be successful.

Gedrag onder Android 2.1 is vreemd maar niet per definitie fout. Het toetsenbord wordt getoond, maar je kunt er niks mee uitvoeren (nog al onlogisch in mijn ogen).
Gedrag onder Android 3.1 is gewoon keihard fout, ik kreeg het toetsenbord niet te zien dus ik dacht dat gaat goed. Plak een javascript onfocus listener aan het het veld met een alert() en test het even in Firefox om te kijken of ik geen typo heb gemaakt. Alles werkt zoals verwacht, terug naar Android klik op het veld.. en er gebeurd helemaal niks.

Tijd om de bugtracker van Android op te zoeken, betekend wel dat mijn plan het water invalt want voorlopig is mijn idee dus niet uit te voeren. Heb ook gekeken naar andere 'input enchancers' zoals mobiscroll en of die er iets op hadden gevonden maar blijkbaar niet. Wat nog het dichtst in de buurt komt van iets bruikbaars is de masked input jQuery plugin welke in ieder geval voorkomt dat er foutieve gegevens worden ingevuld. Veel gebruiksvriendelijker wordt het er niet op want je krijgt alsnog eerst een normaal i.p.v. numeriek toetsenbord voor je neus.

edit:
Ik kan me de moeite van een bugreport opstellen besparen, onder Android 4.0 werkt het wel naar behoren. Werkt zelfs te goed, raak in een infinite loop omdat de focus van het input element naar het alert venster zelf verschuift. Dan als het alert venster wordt gesloten komt de focus weer op de input en komt het volgende venster tevoorschijn enzovoorts

[ Voor 9% gewijzigd door Xthemes.us op 07-11-2011 16:15 ]

[martin149]

is het niet mogelijk door een simpel stukje als dit:
onfocus="this.blur()
het is dan wel niet zo mooi, maar het zou kunnen helpen, hoewel ik het nog niet beb getest

EDIT:
Hee wat leuk, het lijkt ook nog te werken hier, er gebeurt niks. Er komt geen toetsenbord hiet op 2.3.6 op mn Nexus S
TS niet goed gelezen

[ Voor 32% gewijzigd door martin149 op 07-11-2011 14:30 ]