Ich habe mehrere Eingabemasken, welche einige Inputtext Felder
beinhaltet. Soweit funktioniert alles tadellos.
Jedoch stellt sich nun ein "Benutzerproblem" ein. Einige Leute, welche
dieses Portal nutzen (Ist nur lokal in einem Intranet) und die Masken
ausfüllen, drücken öfters nach der Eingabe eines Textfeldes die "Enter"
Taste. Somit wird dann natürlich die gesamte Form gespeichert /
geändert.
Frage: Kann ich über CSS, oder wie auch immer, die Entertaste
unterdrücken. Sodas diese kein Submit mehr auslößt wenn ich in einem
Input Feld bin?
Lieben dank für eure Hilfe. :)
<textarea name='POST-variable-name' maxlength='65535' placeholder='Grau
dargestellter Standard-Text, der verschwindet, sobald man was eingibt'
rows='3'></textarea>
textarea ist natürlich der falsche weg..
(das CSS wär schlimm damit die Felder wie inputs aussehen und sich so
verhalten..)
der mMn Richtige wäre ein form-check on submit,
also ein javascript dass bei on submit (ausgelöst durch zB die enter
taste)
das Formular aif vollständigkeit prüft, ist es nicht vollständig
passiert nix (oder man gibt eine Meldung aus) und ist es das doch (also
alle Felder ausgefüllt) wird das Formular gespeichert.
'sid
Ich hasse es, wenn Webseiten meinen, die Return-Taste blockieren zu
müssen.
Das Richtige wäre, die Leute zu erziehen! Das Verhalten ist Standard
bei allen Webbrowsern - sollen sie halt mal lernen, die Tab-Taste zu
benutzen (funktioniert ja auch bei regulären Programmen).
Ich würde mich hier @foobar anschliessen.
Eventuell könntest du bei den Formularfeldern noch required und pattern
attribute setzen, damit der Browser statt dem Absenden eine Meldung
anzeigt, wenn eins noch nicht oder falsch ausgefüllt ist.
Rene K. schrieb:> drücken öfters nach der Eingabe eines Textfeldes die "Enter"> Taste. Somit wird dann natürlich die gesamte Form gespeichert /> geändert.
Das ist meiner Meinung nach eine Schwachstelle in der
Bedienungsphilosophie, eine Eingabe mit Enter abzuschliessen ist ja
schliesslich nicht abwegig. Intuitiver wäre folgendes: Enter übernimmt
den editierten Text, erst nochmaliges Enter schliesst das ganze
Formular.
Georg
sid schrieb:> textarea ist natürlich der falsche weg..> (das CSS wär schlimm damit die Felder wie inputs aussehen und sich so> verhalten..)>> der mMn Richtige wäre ein form-check on submit,> also ein javascript dass bei on submit (ausgelöst durch zB die enter> taste)
Ich weiß nicht, warum das so schwer sein sollte, eine <textarea> wie
einen input aussehen zu lassen...
Natürlich ist es eher ein Hack und nicht wirklich die Lösung, aber damit
hält man den Nutzer davon ab, das Formular per Enter-Taste abzuschicken.
Eine Alternativoption wäre auch die Möglichkeit, auf dem Server zu
prüfen, ob das Formular vollständig ausgefüllt wurde und wenn nicht, das
Formular mit den schon eingegebenen Werten zurück zu senden.
Etwa so hier: <input type="text" name="POST-Name" value="Schon
eingegebener Text">
Wenn es sehr viele Nutzer gibt, ist die Javascript-Variante natürlich in
sofern eleganter, dass sie auf der Client Side funktioniert.
Jan D. schrieb:> Ich weiß nicht, warum das so schwer sein sollte, eine <textarea> wie> einen input aussehen zu lassen...> Natürlich ist es eher ein Hack und nicht wirklich die Lösung, aber damit> hält man den Nutzer davon ab, das Formular per Enter-Taste abzuschicken
weil man dazu
a) alle inputs in textareas umwandeln muss
b) allen inputs die sich wie inputs und nicht wie textareas verhalten
sollen einen css style zuweisen mus
und letztlich
c) die css dazu derart anpassen muss dass es sich wie ein input wirkt,
auf ALLEN clients, nichtnur Chrome ;)
wohingegen ein einzelnes javascript der deutlich geringere Aufwand ist.
schmalerer quelltext, weniger entwicklungsaufwand, bessere portabilität
ich hab übrigens oben das event.preventDefault(); vergesen ;)
und wenn man jQuery benutzt geht's noch schlanker...
1
$('input').keydown( function( event ) // oder keyup wie du magst
if(event.which == 13 || event.keyCode == 13) //which oder keyCode halt
4
{
5
event.preventDefault();
6
return false;
7
}
8
});
wenn Du das mit CSS und textarea in weniger als vier Zeilen schaffst,
und weniger als dem edit einer einzelnen Datei;
dann bin ich schwer beeindruckt.
'sid
sid schrieb:> weil man dazu> a) alle inputs in textareas umwandeln muss> b) allen inputs die sich wie inputs und nicht wie textareas verhalten> sollen einen css style zuweisen mus> und letztlich> c) die css dazu derart anpassen muss dass es sich wie ein input wirkt,> auf ALLEN clients, nichtnur Chrome ;)>> [...]>> wenn Du das mit CSS und textarea in weniger als vier Zeilen schaffst,> und weniger als dem edit einer einzelnen Datei;> dann bin ich schwer beeindruckt.>> 'sid
Funktioniert bei mir auch mit gemischten Textareas und Inputs in
Formularen. Ich persönlich verwende normalerweise nur Firefox, aber es
funktioniert auch bei meinen Mitentwicklern, die Chrome verwenden und
ich habe gerade auch getestet, dass elinks mit der Seite auch umgehen
kann.
Das heißt natürlich nicht, dass es laut Spezifikation erlaubt ist, aber
ich habe nirgendwo gesehen, dass es verboten ist...
Was das CSS an geht haben wir den Großteil einfach von dem, was wir auf
unsere Inputs anwenden kopiert. Sind sowieso mehr als vier Zeilen, aber
wenn ich wöllte könnte ich die Anweisungen alle auf eine Zeile hauen,
dann würde ich auch dieses Kriterium erfüllen....
Das ist Käse, nimm einfach das Input Type=submit raus und mach n Button,
der zündet nicht per Enter
oder disable den Submit und enable per JS nach Eingabe
sid schrieb:> sid schrieb:> ein javascript>> Nachtrag ... es geht glaube ich noch einfacher> am Ende der html (im footer) folgendes javascript<script> type="text/javascript">> function disableEnterKey(evt) {> var evt = (evt) ? evt : ((event) ? event : null);> var node = (evt.target) ? evt.target : ((evt.srcElement) ?> evt.srcElement : null);> if ((evt.keyCode == 13) && (node.type=="text")) {return> false;}> }>> document.onkeypress = disableEnterKey;>> </script>>> müsste den EnterKey innerhalb aller bestehenden Textfelder nutzlos> rendern.>> 'sid
Super, danke dir sid. Da ich sowieso Header und Footer in jede Datei
includiere, brauche ich damit auch nur jene eine Datei zu ändern für
alle Formulare.
Textarea Felder kommt hier nicht in Frage. Da ich sonst sämtliche
Formulare umarbeiten muss, dieser Aufwand steht in keinerlei Verhältnis.
Auch das "umlernen" der Benutzer funktioniert nicht, da es sich um
verschiedene Nutzer handelt, ich nicht weiß wer es ist und ich froh bin
das sie überhaupt den Rechner anbekommen. ?
Das das prüfen der Formularfelder eigentlich der sauberere Weg ist, ist
mir auch durchaus bewusst, dies wird wohl auch langfristig ins HowTo
aufgenommen.
Weinbauer schrieb:> Das ist Käse, nimm einfach das Input Type=submit raus und mach n> Button, der zündet nicht per Enter> oder disable den Submit und enable per JS nach Eingabe
Dies ist natürlich auch eine Option, danke für den Gedankenanstoß.
sid schrieb:> müsste den EnterKey innerhalb aller bestehenden Textfelder nutzlos> rendern.
Hatte nun mal die Zeit gefunden es zu integrieren. Funktioniert
tadellos, genauso wie ich das möchte :-)
Danke sid.
Meine Güte, was man hier so lesen muss...
<input> zu <textarea> und umstylen, oder fett Javascript wo man es nicht
braucht. Übrigens, die 2000er haben angerufen und wollen ihr jquery
zurück.
HTML Standard ist es, daß Enter den ersten submit Button auslöst. Also
schaltet man den ab.
weia schrieb:> Geht in jedem HTML-konformen Browser. Ohne Javascript. Ohne externes
CSS.
Ist durchaus bewusst, aber...
Rene K. schrieb:> Ich habe mehrere Eingabemasken
... und ...
Rene K. schrieb:> Da ich sonst sämtliche> Formulare umarbeiten muss, dieser Aufwand steht in keinerlei Verhältnis.
... sowie ...
Rene K. schrieb:> Da ich sowieso Header und Footer in jede Datei> includiere, brauche ich damit auch nur jene eine Datei zu ändern für> alle Formulare.
Dein Vorschlag bedarf auch das jedes einzelne Formular umgearbeitet
werden muss (zumindest der disabled Submit Button eingefügt werden).
Aber recht hast du natürlich, das ist die saubere Version ganz ohne JS
o. JQ.
weia schrieb:> Leute sollten mal wieder die Grundlagen lernen.
Allerdings, um dir mal ein wenig deine Arroganz herauszunehmen: zähle
ich dies nicht als HTML-Grundlage, sondern ebenfalls zu Workaround/Hack
- genauso wie die Sache mit der Textarea.
Rene K. schrieb:> Allerdings, um dir mal ein wenig deine Arroganz herauszunehmen: zähle> ich dies nicht als HTML-Grundlage, sondern ebenfalls zu Workaround/Hack> - genauso wie die Sache mit der Textarea.
Wenigstens der minimalinvasive Workaround ohne Overhead. Arrogant sollte
das nicht rüberkommen, aber mich nervt es wenn ohne Grund JS auf eine
Seite geklatscht wird. Bei manchen geht dann nicht mal mehr die
Navigation.
Von wievielen Formularen reden wir denn hier eigentlich? Eine handvoll
geht manuell, und eine größere Menge würde ich per Regex versuchen zu
ändern.
weia schrieb:> Wenigstens der minimalinvasive Workaround ohne Overhead. Arrogant sollte> das nicht rüberkommen, aber mich nervt es wenn ohne Grund JS auf eine> Seite geklatscht wird.
Das kann ich unterschreiben. Für mich speziell wäre sowas nervig, weil
ich auch öfter mal Browser wie Dillo oder elinks verwende, die kein
JavaScript unterstützen. Da würde ich lieber ein Skript schreiben, das
mir alle Seiten umarbeitet, wenn das tatsächlich weniger Aufwand wäre,
als es manuell zu machen.
weia schrieb:> Übrigens, die 2000er haben angerufen und wollen ihr jquery> zurück.
ich sagte falls.. es geht auch ohne, bedarf dann nur mehr getipptem
Text.
1
document.querySelectorAll("input")
statt
1
$('input')
ist halt zu lang zum tippen ;)
jquery hat übrigens noch immer sensationellen Zuspruch..
(~73% aller webseiten weltweit nutzen jquery; ~97.5% aller webseiten mit
bekanntem js-library benutzen jquary als library)
schau einfach mal spasseshalber in die Quelltexte der Seiten die Du
aufrufst.
hier (mc.net) zB:
ah da isset ja.
Und weil es noch "überall" ist und ich tippfaul bin hab ich die variante
getippt
das sollte so übrigens mootools kompatibel sein, was nochmal 2.2% der
websites mit bekanntem library abdeckt..
und 99.7% find ich nicht schlecht ;)
Dass der "xyz hat angerufen"-Witz schon im letzten Jahrtausend dümmlich
war spielt mal keine Rolle (wär mir aber gewöhnlich ein Fest)
weia schrieb:>
ääähm
weia schrieb:> Leute sollten mal wieder die Grundlagen lernen.
Ja LEUTE sollten das...
submit ist ein input type, 'button' ist hier ein workaround
ist dasselbe auch im vorigen Jahrtausend standartisiert und mit weniger
Tippaufwand... also zu bevorzugen!
Rene K. schrieb:> Hatte nun mal die Zeit gefunden es zu integrieren. Funktioniert> tadellos, genauso wie ich das möchte :-)>> Danke sid.
gern geschehen ;)
'sid
Jo weia, das' der Unterschied.. "Du DIR"
"ich (mach) mir" auch Sachen die andere nicht machen und Sachen die ich
für andere nicht machen wollte/würde
Wenn man aber Bestand verarbeitet, macht man das was sinnvoll ist;
und Kosteneffizienz ist immer sinnvoll für den Kunden.
Wartbarkeit ist immer sinnvoll für alle Beteiligten;
Und Javascripte lassen sich nicht wegdiskutieren,
auch wenn ich Venenschwellung bei bootstrap und Co bekomme.
(oder vielmehr deren sinnloser verwendung)
jquery ist überall, da kannste Dich auf den Kopf stellen;
und ehrlich gesagt ist jquery in passend kompiliert auch ne feine Sache
und verursacht nur minimalen overhead (sauber kompiliert kommt man je
nach Projekt auf unter 5kB selten mehr als 100kB wenn man n passendes
precompiled min nimmt)
Und wenn ich Schwachköpfe sehe die 56MB startseiten aus WYSIWYG
WIX-kagge generieren, oder Wordpress für content-freie single page
layouts nutzen, dann sind mir 100kB echt schon egal :D
Besonders wenn das total overhead bei 5-10MB liegt
das hatten die Monster-Seiten von derBauer in den neunzigern nicht.
Aber Hobbyisten gucken halt ungern über ihren Tellerrand..
naja..
hast Du die Links auch mal gelesen die du da schicktest übrigens?
wenn ich das element verstecken will, dann erklär mir mal weswegen der
button der richtige typ sein soll
isser nämlich immernoch nicht!
Nur weil etwas älter ist, bedeutet das nicht, dass es schlechter ist!
(XP war um LÄNGEN besser als vista ;))
wenn etwas seit 1995 funktioniert und das es auch in 2020 noch tut,
und weniger bytes braucht ist es immernoch der richtige Weg!
und wenn ich einnen input verstecken will, dann muss ich dem nicht
vorher n button typ zuordnen, das ist unfassbarer Dummfug!
Dummfug den man sonst so nur von bekloppten Millenials hört,
die meinen sie hätten die Welt erfunden als sie das letzte mal aufm
Töpfchen waren und Mama nicht abwischen kommen musste.
In diesem Sinne...Shalömmchen
'sid
sid schrieb:> jquery ist überall, da kannste Dich auf den Kopf stellen;
Deswegen muß es nicht toll sein. Corona ist gefühlt auch gerade überall.
JQuery hatte mal seine Hypezeit; viele Webdev's können es und klammern
halt daran. Flash war auch mal das Ding. Ich habe mir auch mal JQ
angeguckt, aber mich dann doch lieber gleich für Vanilla JS entschieden.
Und damit konnte ich bisher auch alles umsetzten was ich brauchte.
sid schrieb:> wenn ich das element verstecken will, dann erklär mir mal weswegen der> button der richtige typ sein soll
<button> ist halt das Element für einen, genau, Button. Legt der Name
irgendwie auch nahe. Aber ich zitiere es gerne:
"The HTML <button> element represents a clickable button, used to submit
forms or anywhere in a document for accessible, standard button
functionality."
- MDN
"Wenn Sie einen Button erzeugen möchten, verwenden Sie ein
button-Element"
- SelfHTML
"There are some problems with <button> on older, non-standard browsers
(such as Internet Explorer 6), but the vast majority of users today will
not encounter them."
- HTML
Standard ist auch, daß der erste <button> mit Typ submit bei Enter
getriggert wird. Also setzt man einen Dummybutton ein, den man
abschaltet. Du hast bei HTML alle möglichen Defaults, die je nach Bedarf
geändert werden. Der Standard sieht das Attribut disabled explizit auch
für Buttons vor, also würde ich es nicht wirklich als Workaround oder
gar falsch bezeichnen wenn man das, wie eben definiert, benutzt.
sid schrieb:> und wenn ich einnen input verstecken will, dann muss ich dem nicht> vorher n button typ zuordnen, das ist unfassbarer Dummfug!
Man versteckt ja kein input Element (außerdem gibt's sogar
type="hidden"). Inputs sind für Eingaben da; daher war type="submit"
(meiner Meinung nach) schon immer ein Fehlkonstrukt. Das Absenden der
Eingaben ist eine Aktion, dafür ist button da.
sid schrieb:> Dummfug den man sonst so nur von bekloppten Millenials hört,> die meinen sie hätten die Welt erfunden als sie das letzte mal aufm> Töpfchen waren und Mama nicht abwischen kommen musste.
Ich befürchte, ich bin leider älter als Du mich machst.
der button ist ein "grafik" element das erzeugt damit man was
anclikbares hat
Du willst doch garnix anklickbares! (deswegen versteckt man es doch)
dann braucht man auch kein button zu erzeugen, der "gewöhnliche" input
reicht dazu (und ist schlanker in den funktionen, hat keine child
elemente etc...)
und ja Du kannst einen hidden input erzeugen, aber leider keinen hidden
input submit sonst wär das natürlich noch besser <input type="submit
hidden"/> geht aber leider nicht.
Und inputs sind omnipresent, das hat NULL mit IE6 zu tun..
das' ne blöde Ausrede, eine die ich sonst so bisher nur von besagten
Millenials kenne.
was weder bedeutet, dass alle Millenials pauschal bekloppt sind,
noch dass jeder der sich bescheuert anstellt ein Millenial sein muss.
Das sollte nur heissen, dass ich derartige Aussagen
"es ist älter als <4> Jahre also muss es schlecht sein"
sonst in solcher Art nur von Bekloppten gehört habe deren Pubertät
in eben jenem Zeitraum messbar stattgefunden hat
(und das wären dann heutzutage eben vorwiegend sogenannte Millenials)
ich hab sowas auch schon im letzten Jahrtausend gehört, nur hiessen
solche dann schlicht Twens manchmal noch Teens... Du weisst schon ;)
"bekloppte Teens/Twens" um genau zu sein, denn auch da gab es
-wie in jeder Generation- welche mit und welche ohne Verstand.
Deine buttonAussage insbesondere mit dem Hinweis auf den IE6 (den schon
damals niemand benutzt hat) ist schlicht bescheuert,
und nur weil Du jQuery nicht magst heisst das nicht dass es schlecht
ist, ich mag mootools nicht und find angular blöd..
schliesse aber nciht aus, dass es an mir liegt und persönlicher
Präferenz.
Ich benutze selten selber jQuery, halt in Kundenprojekten, weil es
bequemer ist es weiter zu nutzen als den Kunden zu verärgern ;)
Ich störe mich an jQuery nicht (eher an Bootstrap und dem ganzen anderen
google krempel)
Aber auch hier.. fast ausschliesslcih wegen persönlicher Präferenz.
In beiden Fällen wären wir einer Meinung,
wenn DU nur gesagt hättest:
"ich mag jQuery nicht, es geht ohne und zwar so...."
oder
"ich benutze statt input-submit lieber button-submit weil..."
Du es also als persönliche Präferenz ausgedrückt hättest.
etwas als falsch zu benennen was defacto korrekt ist ist ... hmm naja
falsch halt (fast dumm gar)
falls in 2030 der input-submit deprecated (in html8 oder so), kann sich
das ändern;
in 2020 mit html5 ist es aber vollendeter unsinn was Du da anführst.
Und DAS war was ich zu bemängeln versuchte.
adesso amico mio, ci vediamo dopo
'sid
Da muss ich mich gerade mal einmischen...
Besagte sogenannte Millenials würden nicht mal auf die Idee kommen,
einen Button vom Typ „submit“ zu erstellen, weil sie ihre
HTML-Kenntnisse aus der Schule haben. Und wie wir wissen, sind Schulen
ja immer top aktuell auf dem neusten Stand der Technik... Wir haben
ernsthaft Lehrer, die Informatik-Unterrichtsmaterialien aus den
Neunzigern verwenden (Ich meine nicht für Theorie, sondern wenn es darum
geht, irgendwas zu implementieren und dafür die Sprachen zu lernen. Für
die Konzepte dahinter haben wir dann wieder neue Bücher, wahrscheinlcih
weil sich da weniger geändert hat...).
sid schrieb:> Du willst doch garnix anklickbares! (deswegen versteckt man es doch)> dann braucht man auch kein button zu erzeugen, der "gewöhnliche" input> reicht dazu
Das input erzeugt eigentlich auch was Sichtbares, was Du aber auch
versteckst; wie beim Button. Oder ist das Verstecken per se ganz böse
und deswegen husten wir JS über alle Formulare um die Enter-Taste
abzufangen? Damit hast Du auch gleich inkonsistenes Verhalten, je
nachdem, wer zB NoScript benutzt.
sid schrieb:> Und inputs sind omnipresent, das hat NULL mit IE6 zu tun..
Ich redete nicht von inputs im allgemeinen, sondern vom input
type="submit" im speziellen. Natürlich braucht man inputs. Bitte bei den
Tatsachen bleiben.
sid schrieb:> Deine buttonAussage insbesondere mit dem Hinweis auf den IE6 (den schon> damals niemand benutzt hat) ist schlicht bescheuert,
Das beruhte auf einem Zitat von html.com
sid schrieb:> etwas als falsch zu benennen was defacto korrekt ist ist
Und trotzdem bleibe ich dabei daß es "unvorteilhaft" ist, ein input
Element als Button zu verwenden, wenn es explizit ein button Element
gibt. Dieses Element ist genau dafür da und von der Nutzbarkeit her
überlegen. Also warum soll man für etwas, was man eh nicht sieht, auf
ein komplett anderes Element zurückfallen?
Du kannst auch mit einem Schlitzschraubendreher eine
Kreuzschlitzschraube rein- und rausdrehen. Manchmal auch Torx oder
Inbus. Ging, geht, und wird gehen. Fühlt es sich richtig an? Nein. Man
macht's nur im Notfall, oder eben wenn man es nicht besser weis.
Mein Missionierungseifer hält sich allerdings in Grenzen. Wenn Du es
nicht verstehst, oder verstehen willst, dann ist das Dein Ding. Man kann
das Pferd ja auch nur bis zum Wasser führen...
weia schrieb:> Und trotzdem bleibe ich dabei daß es "unvorteilhaft" ist, ein input> Element als Button zu verwenden, wenn es explizit ein button Element> gibt. Dieses Element ist genau dafür da und von der Nutzbarkeit her> überlegen. Also warum soll man für etwas, was man eh nicht sieht, auf> ein komplett anderes Element zurückfallen?
Wo ist jetzt konkret das Problem mit <input type="submit">? Es ist doch
nicht falsch, soweit ich weiß. Wenn’s Dir nicht gefällt, musst Du es
doch nicht benutzen.
weia schrieb:> Das input erzeugt eigentlich auch was Sichtbares, was Du aber auch> versteckst; wie beim Button. Oder ist das Verstecken per se ganz böse> und deswegen husten wir JS über alle Formulare um die Enter-Taste> abzufangen? Damit hast Du auch gleich inkonsistenes Verhalten, je> nachdem, wer zB NoScript benutzt.
Da stimme ich wiederum zu, aber da es sich angeblich um eine größere
Menge Formulare handelt, ist das einfach die Lösung mit dem geringsten
Aufwand. Ich persönlich würde mir ein Skript schreiben, das es mir
ermöglicht, alle Formulare auf einmal zu lösen, aber das ist, glaube
ich, eher keine Lösung, die normalerweise in Betracht gezogen wird.
Jan D. schrieb:> Wo ist jetzt konkret das Problem mit <input type="submit">? Es ist doch> nicht falsch, soweit ich weiß. Wenn’s Dir nicht gefällt, musst Du es> doch nicht benutzen.
Irgendwann soll man einfach mal auf das logisch dazu passende Element
wechseln. Deprecated ist das andere (noch) nicht, aber stell' Dir doch
mal den Unterricht vor:
"Hier machen wir nun einen Absendeknopf mit input type='submit'"
"Herr Lehrer, wofür ist dann button da?"
"Für Knöpfe"
"Warum nehmen wir dann input?"
"Weil ich das schon immer so mache"
Personalreferent schrieb:> Mein Gott ist das ein Kindergarten hier.
Aber noch nicht kindisch genug damit Du Dir den Kommentar gespart
hättest :)
So, und nun is aber gut.
Thread beobachten
Seitenaufteilung abschalten