« 1 2 3 »
Autor Zpráva
Plaváček
Profil
quatzael:

Uživatele to zároveň ujistí, že aplikace opravdu vyžaduje PSČ s mezerou...

PROČ vyžaduje aplikace PSČ s mezerou jako vstup od uživatele? Proč si to neošetří až při zpracování?
anonymníí
Profil *
quatzael:
Protože klient OPRAVDU NETUŠÍ jak se daný formulář zachová, při odeslání
Lidé tohle neřeší. Napíší nějak PSČ a co se děje dál, je jim vcelku jedno. Problémy mají špatně napsané aplikace, ne uživatelé. Moc user-friendly mi to nepřijde.

A ten formulář je poměrně dlouhý, takže každý signál, který ujistí klienta, že zadává data ve správném formátu a nedává mu na k dispozici více variant, z nichž může být správná třeba jen jedna, zpříjemní práci s formulářem.
Ano, to se dá i lépe. Po zadání validního formátu (s nebo bez mezery) políčko zezelenat nebo dát jinou, podobnou zpětnou vazbu. Doplňování mezery k tomu není třeba.
Str4wberry
Profil
Reakce na Chamurappiho:
Pokud tam tu mezeru uvidím a nemůžu ji samostatně smazat, je zjevné, že se děje něco nenormálního. Část lidí — i když malou — to může zmást, troufám si odhadnout, že větší část, než které to pomůže.
No, jak jsem psal, v nějakém formuláři na Googlu u telefonního čísla mě to trochu zmátlo. Je otázka, jestli to tamní tvůrci nějak testovali nebo ne. Také je možné, že se víc vyplatí 10 lidí trochu zmást, než zmást hodně jednoho, který zadá omylem špatné číslo, kvůli slepenému formátu si toho nevšimne, a bude nadávat, že to nefunguje.

Doplnění mezery do PSČ je spíš teoretická debata, tam jde použít krásně validace přes Google Maps API. Nebo rovnou celou adresu nechat zadávat do jedné <textarea> a mapovým API si adresu přežvýkat do potřebné podoby.
_es
Profil
quatzael:
naopak jim ulehčí práci, tím, že jim to nedovolí překlepy jako např. čárka místo tečky apod.
Prácu im to neuľahčí, ale naopak sťaží. Prečo by nemohol byť oddeľovačom hocijaký nečíselný znak, napríklad na numerickej klávesnici dostupné lomítko či pomlčka? Prečo práve a len bodka, ktorá nie je v slovenskej a českej klávesnici v numerickej časti dostupná?
quatzael
Profil
Plaváček, anonymníí:
Ja to tady píšu pořád dokola:
1. Vizuální kontrola - když uživatel dopíše PSČ, tak ihned snadno zkontroluje, jestli to zadal správně. Ve slepené variantě se chyba hůře hledá.
2. Uživatel se ujistí, že položku vyplnil správně a nebude to po odeslání muset opravovat (v mým případě až u tří inputů). Btw. psal jsem, že tam všude mám check-off obrázky, který se zobrazí, když je daný input vyplněn správně. A na straně serveru to mám taky perfektně ošetřený.
3. Ve formuláři se nachází i číselný inputy, u kterých může být hodnota i pětimístná. Když bude uživatel zpětně ve formuláři hledat nějakou položku, bude scrollovat nahoru a náhodou narazí zrovna na to PSČ, tak se ihned zorientuje, že se jedná o PSČ a ne například hledaný číselný input..
Str4wberry
Profil
Reakce na _es:
Jak chceš bez kilometru vysvětlujícího popisu u data zajistit, aby uživatel ručně nacvakal přípustný formát a serverová část aplikace ho správně vyhodnotila?
quatzael
Profil
_es:
Asi aby v tom byl aspoň trochu pořádek a ne že si v každým inputu napíšeš datum jak se Ti zlíbí. To se potom v tom nevyznáš ani Ty sám..
_es
Profil
Str4wberry [#6]:
Vysvetľujúci popis ani nemusí byť iný, respektíve môže byť trebárs: Zadajte dátum v tvare dd.mm.rrrr, dd/mm/rrrr alebo dd-mm-rrrr. Rozdelenie na dátumové zložky hocijakým nečíselným oddeľovačom snáď na strane JS (trebárs overenie platného dátumu) ani na serverovej strane nie je problém.

quatzael:
a ne že si v každým inputu napíšeš datum jak se Ti zlíbí.
MS Excel, ešte obľúbenejší než ten „datepicker“, umožňuje zadať ako oddeľovač častí dátumu pomlčku, lomítko aj bodku. To je teda „chaos“. Podľa tvojej rady by to malo by „zatrhnuté“ a aby hocikto nepísal dátum „ako sa mu páči“, ale pekne neustále presúval ruku z numerickej do hlavnej časti klávesnice na napísanie bodky.
Joker
Profil
quatzael:
Už jsem to trochu doupravil, takže je to teď jinak.
Opravuji ještě sám sebe, zkouším to na kódu z [#5], ne z [#1].
Kdyby byla k dispozici nějaká novější ukázka (ideálně rovnou hotová), klidně zkusím tu.

To tam normálně funguje. Pokud se nepletu tak to fungovalo i v tom původním kódu. Ty jsi to zkoušel, že Ti to nefunguje?
Zkoušel, právě proto tvrdím, že to nefunguje.
Ale možná v jiných prohlížečích než v Opeře to funguje.

Já nechápu co pořád máte s tím, že bude uživatel zmatenej a nebude vědět co se děje. Ten script, který se tady snažím doladit má prostě jednoduše přidat mezeru do PSČ tam kde má správně být, i přesto že jí uživatel zapomene nebo se nerozhodne napsat.
Moje představa o ideálním zadávání dat do aplikace není, že mi aplikace bude vstupy pod rukama měnit podle toho, co považuje za správné.
Za ideální považuji, když já to zadám tak jak jsem zvyklý a aplikace to správně pochopí.

Samozřejmě aplikace nemůže být připravená na všechno, ale zrovna umět zpracovat PSČ s mezerou i bez mezery je triviální.

začne psát 123, nenapíše mezeru ale rovnou napíše čtvrtou číslici a automaticky mu tam skočí mezera
Právě tohle je myslím klasický problém, který trápí velké množství podobných „vylepšených políček“:
Často je navrhoval někdo, kdo měl celou dobu před očima jeden jediný scénář, jak se to má správně používat.
Přece takhle to dělám já a tak je to normální, nikdo to nepotřebuje dělat jiným způsobem.
A když to návštěvník dělá jinak než podle scénáře, je to jeho chyba, protože to nedělá správně.
Přičemž návštěvníci mají své zvyky, často podivné, a pochopit, že nějaký postup stránka prostě nepovažuje za správný, přestože všude jinde funguje, jim dělá potíže.
Ovšem celé se to samozřejmě dělá proto, aby se to návštěvníkovi pohodlně zadávalo.

Je to "user friendly"
Tak můžu zopakovat, že když jsem si odjinud zkopíroval PSČ a pak mi ho nešlo přes ctrl-V vložit, přišlo mi to hodně user-hostile.

Protože klient OPRAVDU NETUŠÍ jak se daný formulář zachová, při odeslání, když je na té stránce prvně.
Jenže poprvé si návštěvník musí zvykat i na občas podivné chování toho inputu.
Navíc zrovna v tomhle případě ohledně zpracování moc není na co si zvykat: Zadám PSČ s mezerou nebo bez a stránka si to už zpracuje. Pokud mě aplikace kvůli tomu po odeslání vrátí na formulář a nutí mě přepsat PSČ do jiného formátu, je to chyba té aplikace.

Str4wberry:
Možná by bylo férovější srovnávat nezasahování do formuláře během psaní vs. dobře napsané zasahování.
Mně by jako ještě přijatelné zasahování přišlo přeformátování PSČ na onchange. Budiž, je to pak v jednotném formátu a budiž, nechá mě to zapsat a upravovat tak jak já chci.
Chamurappi
Profil
Reaguji na quatzaela:
Oblíbený datepicker taky nedovolí zadávat do inputu nic jiného než číslice a tečky.
To je chyba. Napsal jsem si vlastní kalendáříček, který jsem postupně naučil porozumět mnoha druhům vstupu (včetně třeba dvouciferného roku a čárek místo teček). Čím víc toho umí, tím snazší je zadat datum. V mém zájmu není návštěvníka vychovávat, aby dodržoval zrovna můj oblíbený formát. Samozřejmě mu i v kalendáři ukazuji, jaké datum si myslím, že napsal. K dokonalosti tomu chybí ještě překládání slovních názvů měsíců, aby člověk mohl vložit datum zkopírované odkudkoliv :-)

každý signál, který ujistí klienta, že zadává data ve správném formátu
Ty ho nejprve ujistíš, že nesmí zadat mezeru, a pak se mu tam sama objeví. Nehledě na to, zda mezeru sám doplňuješ, proč mu nedovolíš ji napsat?

Asi aby v tom byl aspoň trochu pořádek a ne že si v každým inputu napíšeš datum jak se Ti zlíbí.
Klást uživateli při vyplňování jakýkoliv nadbytečný odpor je hloupé. Vede to k tomu, že formulář vyplní méně lidí. Zákonitě.


Reaguji na Str4wberryho:
Doplnění mezery do PSČ je spíš teoretická debata, tam jde použít krásně validace přes Google Maps API
Google mívá zastaralá data. I když u PSČ asi moc změn nehrozí…
Na seriózní ověřování adres existují jiné služby, ale ty bývají placené.

Jak chceš bez kilometru vysvětlujícího popisu u data zajistit, aby uživatel ručně nacvakal přípustný formát
Můžu mu poradit jeden konkrétní formát, a přesto zpracovávat všechny možné.


Reaguji na Jokera:
přeformátování PSČ na onchange
Asi jsi myslel spíš onblur. Událost onchange může vznikat i po každém napsaném písmenku.
Tori
Profil
quatzael:
Ok, shodněmež se, že se neshodneme.
Možná kdybyste pojmenoval vlákno obecněji, např. "Na co si dát pozor, když chci měnit text v inputu během psaní?", tak by sice taky vznikly reakce, že uživatel nebude nadšený, že se mu to hýbe pod rukama, ale odpadla by největší kontroverze způsobená zrovna volbou PSČ a mohli byste v klidu řešit věci jako e vs. window.event nebo povolení Ctrl+něco.
Joker
Profil
Doplním reakci na příspěvky, které přibyly za dobu, co jsem měl rozepsaný předchozí příspěvek:
quatzael:
Oblíbený datepicker taky nedovolí zadávat do inputu nic jiného než číslice a tečky. A uživatele to nemate, naopak jim ulehčí práci, tím, že jim to nedovolí překlepy jako např. čárka místo tečky apod.
Nejvtipnější situace nastává, když se má zadávat datum a čas, přičemž aplikace vyžaduje český formát data (dd.mm.yyyy) a naopak neuznává český formát času (hh.mm:ss)

1. Vizuální kontrola - když uživatel dopíše PSČ, tak ihned snadno zkontroluje, jestli to zadal správně.
A kvůli kontrole až to dopíšu je nutné mi to během psaní měnit?

nebude to po odeslání muset opravovat (v mým případě až u tří inputů)
Jak jsem psal, pokud si aplikace neporadí jak s PSČ s mezerou, tak i bez mezery, považuji to za chybu aplikace. Čili aplikace nebude otravovat tak jako tak.

Chamurappi:
Napsal jsem si vlastní kalendáříček, který jsem postupně naučil porozumět mnoha druhům vstupu (včetně třeba dvouciferného roku a čárek místo teček).
Předpokládám není dostupný s nějakou nezáhadnou licenční politikou? :-)

Asi jsi myslel spíš onblur. Událost onchange může vznikat i po každém napsaném písmenku.
Může? Tak v tom případě onblur.
quatzael
Profil
_es:
Počítač pořád ještě nemá inteligenci jako člověk. Takže když mu budeš cpát všelijaký formáty, který pochopí člověk, tak hodně brzo narazíš až ta aplikace tak inteligentní nebude..
To není problém toho programátora, že nemyslel na všechno, to bude Tvůj problém, protože to budeš muset zadávat znovu..

A ja teda když něco vyplňuju, tak se snažím si ověřovat jestli to vyplňuju správně, protože nemůžu tušit, že kvůli jedný nepřesnosti me to nevrátí zpatky na prazdnej formulář, abych to zase celý vyplnil znovu.
Plaváček
Profil
quatzael:

protože nemůžu tušit, že kvůli jedný nepřesnosti me to nevrátí zpatky na prazdnej formulář, abych to zase celý vyplnil znovu.

Pokud něco takového aplikace dopustí, měl by její programátor jít raději k lopatě. :)
anonymníí
Profil *
quatzael:
abych to zase celý vyplnil znovu.
To je chyba aplikace, pokud mi sežere větší formulář, vyplňovat ho znova nebudu a nakoupím/objednám jinde.

To není problém toho programátora, že nemyslel na všechno
Pleteš se. Navíc, když už se bavíme o datu, těch validních formátů je jen několik, ostatní formáty můžou javaskriptově vyvolat nějakou nápovědu, jak to tedy správně zapsat. A zablokovat odeslání formuláře.
Str4wberry
Profil
Reakce na _es:
Vysvetľujúci popis ani nemusí byť iný, respektíve môže byť trebárs: Zadajte dátum v tvare dd.mm.rrrr, dd/mm/rrrr alebo dd-mm-rrrr.
Myslíš, že tento popis bude pro neprogramátory srozumitelný?


Reakce na Chamurappiho:
Nehledě na to, zda mezeru sám doplňuješ, proč mu nedovolíš ji napsat?
Vždyť zapsat do PSČ mezeru nebude problém. V takovém případě ten JS vůbec nic neudělá. Jeho činnost spočívá pouze v tom, že čtvrté číslo za sebou odmezeruje.

Můžu mu poradit jeden konkrétní formát, a přesto zpracovávat všechny možné.
Jde o to, že není jasné, jakým způsobem skript zadaný datum pochopí. V tom je ten kalendář ideální.

Je „14-2-13“ 14. únor 2013, nebo 13. únor 2014?
Je „10/2/2014“ 10. únor 2014, nebo 2. říjen 2014? A podobně.

Tedy mi stejně nezbude nic jiného než se držet předepsaného formátu.

Událost onchange může vznikat i po každém napsaném písmenku.
V kterém běžně používaném prohlížeči se tak děje?


Reakce na Jokera:
Jak jsem psal, pokud si aplikace neporadí jak s PSČ s mezerou, tak i bez mezery, považuji to za chybu aplikace.
Myslím, že tohle quatzael chce řešit správně. Celá pointa je v tom, že presentační podoba PSČ má být 3 číslice, mezera, 2 číslice. Takže skript schroupe i PSČ bez mezer, ale bude kvůli snazší identifikaci, že to je PSČ, zobrazovat s mezerou.

Filosofická otázka tedy je, jestli po stisknutí čtvrtého čísla v řadě doplnit mezeru nebo ne. :–)
Bubák
Profil
Str4wberry:
Filosofická otázka tedy je, jestli po stisknutí čtvrtého čísla v řadě doplnit mezeru nebo ne.
Pokud už doplňovat mezeru během psaní, já osobně bych byl pro doplnění mezery po napsání pátého čísla, nemění se mi tedy text pod rukama, ale až po napsání. Přijatelná pro mne by byla změna po onblur, což by byla umělá inteligence, která se mne nesnaží přechytračit.
pcmanik
Profil
Neviem či to tu bolo niekde spomenuté, nemám moc čas to tu celé prečítavať, ale nebolo by lepšie zožrať obidva typy PSČ teda s medzerou aj bez medzeri a len overiť na strane JS/Serveru či má potrebný počet číslic? V DB by som ho tak či tak ukladal bez medzier ako číslo, a nie ako string s medzerou.
Str4wberry
Profil
Reakce na Bubáka:
Je otázka, jestli taková změna přinese kýžený efekt v podobě zpřehlednění, které sníží počet zadaných PSČ s překlepem.
Joker
Profil
quatzael:
A ja teda když něco vyplňuju, tak se snažím si ověřovat jestli to vyplňuju správně, protože nemůžu tušit, že kvůli jedný nepřesnosti me to nevrátí zpatky na prazdnej formulář, abych to zase celý vyplnil znovu.
Kdyby stránka kvůli mezeře v PSČ zahodila celý dlouhý formulář, asi bych ho už znovu nevyplňoval, kdybych nemusel.
Navíc bych v tu stránku asi neměl důvěru, protože co ještě dalšího asi jejich programátor zvoral?

Str4wberry:
Filosofická otázka tedy je, jestli po stisknutí čtvrtého čísla v řadě doplnit mezeru nebo ne.
Já bych řekl „ne“. Když PSČ přeformátovat, tak až po napsání.
Ještě k Tvému argumentu „když se to udělá dobře“, zjevně není tak snadné to udělat dobře, zato je velmi snadné to udělat špatně.

pcmanik:
On na serveru zdá se přežije oba typy, jen uživateli to přeformátuje. Kdyby tam to přeformátování nebylo, serveru by to nevadilo.

V DB by som ho tak či tak ukladal bez medzier ako číslo, a nie ako string s medzerou.
Chyba, PSČ je v drtivé většině použití řetězec.
Ukládal bych ho asi bez mezery jako CHAR(5), ale ne jako číslo.
pcmanik
Profil
Joker:
MEDIUMINT zaberá 3bajty pričom CHAR(5) zaberie 5 bajtov.
V čom bude výhoda charu? Aplikácii je predsa jedno s akými dátami pracuje.
Joker
Profil
pcmanik:
V čom bude výhoda charu? Aplikácii je predsa jedno s akými dátami pracuje.
V tom případě proč si vůbec komplikovat život přemýšlením o datových typech, když prakticky všechno jde uložit do VARCHAR?

PSČ je řetězec, proto je pro něj vhodný řetězcový typ.
quatzael
Profil
Tori, Joker, Chamurappi, _es:
uživatel nebude nadšený, že se mu to hýbe pod rukama
Já nevím, co pořád řešíte, že se mu bude hejbat. Nic se tam hejbat nebude. Nemá to být tak, že zadá čtvrtý číslo, to se mu objeví a potom teprve vyjede mezera a posune číslo. To je nesmysl.
Prostě uživatel začne psát čtvrtou číslici a ta se mu zobrazí na "pátý pozici". když místo toho stiskne mezeru tak se na tu pátou pozici dostane tak i tak. Jenom prostě když se bude snažit psát mezeru hned za první číslicí, tak mu to ten script prostě nedovolí, protože tam ani žádná mezera nemá co dělat.

Chamurappi:
Část lidí — i když malou — to může zmást, troufám si odhadnout, že větší část, než které to pomůže.
Nezlob se, ale tohle mi trochu připomíná slavný statistický výrok z filmu Vrať se do hrobu:o)
Malá část, které to nepomůže, je větší než ta, které to pomůže.
Pokud tedy bereš, že naprosté většině to bude úplně jedno, tak ok.
Ale pořád nevím, jak by to mělo někomu něco zkomplikovat.. Jedině kdyby byl zvyklej psát PSČ nějak doprostřed do stran, ale takoví lidi snad nepředstavují ani tu malou část..
Většina lidí zadává PSČ od začátku. A když se tam bude snažit cpát mezeru na první nebo druhý místo, tak ho to prostě nepustí. Ale v tom nevidím problém.
Když tam něco vloží ctrl + v, tak mu to tam samo doplní tu mezeru, pokud tam nebude.
Pokud tam bude vkládat něco dlouhýho, tak se to usekne.
A pokud bude chtít psát někde doprostřed tak se ta zbylá část PSČ bude posouvat do prava a uřezávat se na konci.

Plaváček:
Pokud něco takového aplikace dopustí, měl by její programátor jít raději k lopatě. :)
To může jít kam chce, ale mě to už nijak nepomůže, protože to budu muset zadávat znovu. Nebo jinde na jiným webu. Ten čas je tak i tak ztracenej, takže ocením, když se pokaždý můžu ujistit, že je všechno tak jak má.

anonymníí:
To je chyba aplikace, pokud mi sežere větší formulář, vyplňovat ho znova nebudu a nakoupím/objednám jinde.
Takže ho budeš vyplňovat znova, jenom prostě jinde. Ale znova..

Joker:
Navíc bych v tu stránku asi neměl důvěru, protože co ještě dalšího asi jejich programátor zvoral?
Taková stránka je například seznam.cz. Když si registruješ nový email, a zvoráš tam ten kontrolní antirobotickej kód, kterej je v mnoha případech hodně nečitelný (záměna O a 0 apod..) Tak Ti to smázne půlku formuláře. A vyplňuješ znovu..

Mimochodem všimli jste si, co tam má seznam.cz za ohodnocení bezpečnosti hesla, když tam zadáte "ukrutně" dlouhé heslo?:o)


Chamurappi:
Jo, a to onchange opravdu někde funguje po stisknutí jednotlivých kláves?
Joker
Profil
quatzael:
Ale pořád nevím, jak by to mělo někomu něco zkomplikovat
Popisoval jsem na minulé stránce, na jaké problémy jsem narazil.
Řešení některých asi nebude úplně jednoduché.

Taková stránka je například seznam.cz.
Tak tam alespoň těch „předvyplnitelných“ políček je jen pět, to není zas tolik.

Ale jinak souhlasím, že formulář pro založení mailu na Seznamu je blbě udělaný, tohle je jen jedna z věcí, které jsou tam špatně.
Chamurappi
Profil
Našel jsem zahraniční debatu na stejné téma: Automatically limiting or correcting numeric input field values.


Reaguji na Str4wberryho:
„Událost onchange může vznikat i po každém napsaném písmenku.“
V kterém běžně používaném prohlížeči se tak děje?
Zdá se, že v žádném. Zajímavé, měl jsem k té události i na textových vstupech z nějakého důvodu nedůvěru, patrně zbytečnou. Tak to je asi lepší onchange než onblur.

Vždyť zapsat do PSČ mezeru nebude problém.
Zpočátku quatzael psal, že to chce zakázat, protože jediná mezera, která tam smí být, se vloží automaticky.

Jde o to, že není jasné, jakým způsobem skript zadaný datum pochopí. V tom je ten kalendář ideální.
Vždyť píšu, že ten skript je primárně kalendář a že ukazuje, co uživatel zadal. To, že si uživatel může datum naklikat, neznamená, že mu znemožním ho i (víceméně jakkoliv) napsat.

Myslíš, že tento popis bude pro neprogramátory srozumitelný?
Když se jim dá popis „příklad: 29. 1. 2014“, tak to pochopí.


Reaguji na quatzaela:
Pokud tam bude vkládat něco dlouhýho, tak se to usekne.
Takže když tam vloží třeba odněkud zkopírovaný kus textu „PSČ: 135 79“, tak mu to okamžitě usekneš na „PSČ: 1“? Tím mu moc nepomůžeš.

pokud bude chtít psát někde doprostřed tak se ta zbylá část PSČ bude posouvat do prava a uřezávat se na konci.
Pokud tam bude mít napsané „459 78“ a rozhodne se vyměnit devítku na šestku, najede před devítku, zmáčkne šestku (ty usekneš koncovou osmičku), pak zmáčkne delete… tak ten delete už vlastně neudělá nic, protože kurzor bude na konci „456 97“. Takhle to má fungovat?


Reaguji na Jokera:
Předpokládám není dostupný s nějakou nezáhadnou licenční politikou? :-)
Není. Vlastně by šlo záhadně říct, že jeho licenční politika je teď v režii politika :-)
Ale mohl bych někdy napsat návod, jak vyrobit něco podobného…
quatzael
Profil
Chamurappi:
Našel jsem zahraniční debatu na stejné téma: Automatically limiting or correcting numeric input field values.
Tohle není žádné stejné téma. Tam neřeší žádnej ZIP code.. Jde tam o to, že se dotyčný snaží průběžně kontrolovat jestli zadaná hodnota je vyšší než například 15. A aby někdo zadal těch 15, tak nejdřív musí zmáčknout jedničku, která je menší než 15, a už to script bere jako špatně vyplněný input. To je ale opravdu úplně jiný problém.. A úplně zbytečný. Tam by stačilo opravdu jen úprava až po události onchange.

Zpočátku quatzael psal, že to chce zakázat, protože jediná mezera, která tam smí být, se vloží automaticky.
Jo, zpočátku jsem počítal, že bych mezeru neumožnil vůbec, ale je pravda, že tam kde má být, vůbec nebude vadit, když bude umožněný jí zadat. Jinde ale ne.

Takže když tam vloží třeba odněkud zkopírovaný kus textu ‚PSČ: 135 79‘, tak mu to okamžitě usekneš na ‚PSČ: 1‘? Tím mu moc nepomůžeš.
To bych mohl jedině ošetřit událostí onchange, že by se všechny nečíselné znaky byly smazány..
Ale kdo tam opravdu bude vkládat tohle?

Pokud tam bude mít napsané ‚459 78‘ a rozhodne se vyměnit devítku na šestku, najede před devítku, zmáčkne šestku (ty usekneš koncovou osmičku), pak zmáčkne delete… tak ten delete už vlastně neudělá nic, protože kurzor bude na konci ‚456 97‘. Takhle to má fungovat?
Tohle není samozřejmě úplně ideální, to přiznávám. Dalo by se udělat to, že by se nedalo psát do inputu další znaky, dokud se neuvolní místo smazáním jiných, ale to se mi nezdá moc lepší..
Str4wberry
Profil
Živá ukázka — tohle na první pohled vypadá docela zajímavě.


Reakce na Jokera:
Ještě k Tvému argumentu ‚když se to udělá dobře‘, zjevně není tak snadné to udělat dobře, zato je velmi snadné to udělat špatně.
To je pravda.

Reakce na Chamurappiho:
pak zmáčkne delete… tak ten delete už vlastně neudělá nic
To je dobrý argument proti používání maxlengthu.
quatzael
Profil
Str4wberry:
Živá ukázka — tohle na první pohled vypadá docela zajímavě.
To vypadá dobře, ale proč tam jsou ty podtržítka?
To je nějaká standardní funkce mask? Moc se nevyznám v tom ukázkovači jak funguje, takže jsem tam hledal všud, kde je nějakej kód..
Str4wberry
Profil
Podtržítka je možné vypnout. Jinak je to nějaký skript v jQuery.
quatzael
Profil
quatzael:
To je nějaká standardní funkce mask?
Aha, už to vidím.. To je nějaký jQuery..


Str4wberry:
Ty jseš totálně zlatej!!! To je přesně ono!! A takhle jednoduše.. Fakt supr!! Díky moc!!


Str4wberry:
Ach jo.. Problém.. Nefunguje to na mobilu..
« 1 2 3 »

Vaše odpověď

Mohlo by se hodit

Neumíte-li správně určit příčinu chyby, vkládejte odkazy na živé ukázky.
Užíváte-li nějakou cizí knihovnu, ukažte odpovídajícím, kde jste ji vzali.

Užitečné odkazy:

Odkud se sem odkazuje


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: