Browser fügen ständig neue HTML-, JavaScript- und CSS-Funktionen hinzu. Hier sind einige nützliche Ergänzungen zur Arbeit mit Formularen, die Sie vielleicht übersehen haben...
requestSubmit()
Safari 16 wird der letzte Browser sein, der die Unterstützung für requestSubmit hinzufügt.
Bevor wir uns ansehen, wie .requestSubmit() funktioniert, erinnern wir uns daran, wie ein Formular programmatisch mit JavaScript über die .submit() Methode übermittelt wird. Das Übermitteln eines Formulars mit submit() löst kein Submit-Ereignis aus. Daher wird in folgendem Code das Formular übermittelt, preventDefault() hat keine Wirkung und nichts wird in die Konsole protokolliert.
const form = document.forms[0];
form.addEventListener('submit', function(event) {
// code to submit the form goes here
event.preventDefault();
console.log('form submitted!');
});
document.querySelector('.btn').addEventListener('click', function() {
form.submit();
})
.submit() ignoriert auch jede HTML-Formularvalidierung. Angesichts des folgenden Markup wird das Formular übermittelt, wenn die Eingabe leer ist, obwohl die Eingabe ein required-Attribut hat.
<form>
<label for="name">Name</label>
<input required name="name" id="name" type="text">
</form>
.requestSubmit() ist eine alternative Möglichkeit, ein Formular mit JavaScript zu übermitteln, aber im Gegensatz zu .submit() verhindert die HTML-Formularvalidierung die Übermittlung des Formulars. Wenn alle im Formular eingegebenen Daten die Validierung bestehen, wird das submit-Ereignis ausgelöst, was bedeutet, dass „form submitted!“ im folgenden Beispiel in die Konsole protokolliert wird.
form.addEventListener('submit', function(event) {
event.preventDefault();
console.log('form submitted!');
});
document.querySelector('.btn').addEventListener('click', function() {
form.requestSubmit();
})
Dies konnte man bereits erreichen, indem man programmatisch auf den Submit-Button des Formulars klickte, aber requestSubmit ist vielleicht eine elegantere Lösung.
submitter-Eigenschaft des submit-Ereignisses
Die SubmitEvent.submitter-Eigenschaft erhielt mit der Veröffentlichung von Safari 15.4 vollständige plattformübergreifende Unterstützung. Diese schreibgeschützte Eigenschaft gibt das <button>- oder <input type="submit">-Element an, das die Übermittlung eines Formulars verursacht hat.
<form>
<button name="foo" value="bar" type="submit">Bar</button>
<button name="foo" value="baz" type="submit">Baz</button>
</form>
Wenn Sie mehrere Submit-Buttons oder -Eingaben mit jeweils unterschiedlichen Werten haben, wird nur der Wert des Buttons oder der Eingabe, der zum Übermitteln des Formulars geklickt wurde, an den Server gesendet, anstatt beider Werte. Das ist nichts Neues. Neu ist, dass der Event-Listener für das submit-Ereignis nun Zugriff auf die event.submitter-Eigenschaft hat. Sie können dies beispielsweise verwenden, um dem Button oder der Eingabe, die die Formularübermittlung ausgelöst hat, eine Klasse hinzuzufügen oder deren value oder andere HTML-Attribute abzurufen.
document.forms[0].addEventListener('submit', function(event) {
event.preventDefault();
console.log(event.submitter.value);
console.log(event.submitter.formaction);
event.submitter.classList.add('spinner-animation');
})
formdata-Ereignis
Das ist nicht besonders neu, hat aber erst mit Safari 15 plattformübergreifende Unterstützung erreicht. Der Hauptanwendungsfall für das formdata-Ereignis ist die Ermöglichung der Teilnahme von benutzerdefinierten Elementen an Formularübermittlungen. Außerhalb von Webkomponenten kann es jedoch weiterhin nützlich sein.
Sie fügen dem Formular, mit dem Sie interagieren möchten, einen formdata-Ereignis-Listener hinzu.
document.querySelector('form').addEventListener('formdata', handleFormdata);
Das Ereignis wird sowohl durch eine reguläre HTML-Formularübermittlung als auch durch eine Instanz von new FormData() ausgelöst. event.formData enthält alle zu übermittelnden Daten.
function handleFormdata(event) {
for (const entry of event.formData.values()) {
console.log(entry);
}
}
Die Callback-Funktion für den formdata-Ereignis-Listener wird ausgeführt, bevor die Daten an den Server gesendet werden, was Ihnen die Möglichkeit gibt, die zu sendenden Daten hinzuzufügen oder zu ändern.
function handleFormdata(event) {
event.formData.append('name', 'John');
}
Sie hätten die FormData auch im Submit-Event-Handler ändern oder anhängen können, aber formdata ermöglicht es Ihnen, die Logik zu trennen. Es ist auch eine Alternative zur Verwendung von versteckten Eingaben im Markup Ihres Formulars, wenn Sie das Formular „auf die altmodische Art“ übermitteln – d.h. indem Sie sich auf die eingebaute Funktionalität von HTML zum Übermitteln des Formulars verlassen, anstatt dies mit fetch zu tun.
showPicker() für Eingabeelemente
showPicker() wird seit Chrome 99, Firefox 101 und im kommenden Safari 16 unterstützt. Für ein Eingabeelement, dessen type-Attribut auf Date, Month, Week, Time, datetime-local, color oder file gesetzt ist, bietet showPicker() eine programmatische Möglichkeit, die Auswahl-UI anzuzeigen. Bei Farbwahl- und Dateieingaben war es schon immer möglich, den Picker durch Aufrufen von .click auf der Eingabe programmatisch anzuzeigen.
document.querySelector('input[type="color"]').click();
Dieser Ansatz funktioniert nicht bei Datumsangaben, weshalb diese neue API hinzugefügt wurde. .showPicker() funktioniert auch mit Farb- und Dateieingaben, aber es gibt keinen wirklichen Vorteil gegenüber .click().

Inert-Attribut
Es war schon immer möglich, mehrere Eingaben auf einmal zu deaktivieren, indem man sie in ein HTML-fieldset einbindet und das fieldset deaktiviert.
Inert ist ein neues HTML-Attribut. Es ist nicht nur für Formulare, aber Formulare sind sicherlich ein wichtiger Anwendungsfall. Im Gegensatz zum disabled-Attribut kann inert auf ein form-Element selbst angewendet werden. Alles innerhalb des Formulars wird nicht fokussierbar und nicht anklickbar sein. In Bezug auf assistierende Technologien ist inert ähnlich wie das Setzen von aria-hidden="true". Im Gegensatz zum disabled-Attribut wendet inert standardmäßig keine Stile an, aber es ist einfach, eigene hinzuzufügen.
form[inert] {
opacity: .2;
}
Es kommt noch mehr...
Das Wichtigste ist das Styling von <select>-Elementen, etwas, das Entwickler seit Jahrzehnten wollen. Es scheint bald Realität zu werden, mit der Einführung von selectmenu.
Aber das ist es erstmal! Die jüngsten Updates bringen die volle Browserunterstützung für Formularfunktionen, auf die wir gewartet haben, und machen sie für den Produktionseinsatz bereit.
Warum kann der Kalender von input[type=“date“] nicht gestylt werden? Man kann ihn nicht einmal mit dem Browser-Inspektor untersuchen.
Die Kalender-HTML ist im Shadow DOM, sodass Sie sie in DevTools nicht sehen können.
Apple hat also die Weiterentwicklung der Webplattform auf verschiedene Weise und für eine beträchtliche Zeit zurückgehalten ... schon wieder.
Vielleicht werden sie eines Tages müde, hinterherzuhinken und sprichwörtlich mit gesenktem Anker davonzuschleppen?
Ich weiß, es ist nicht sehr korrekt, so etwas in Kommentaren zu „nennen“ ... aber für mich ist ein „twit“ im Englischen ein Idiot. Nicht etwas, das jemand online tut.
Wenn Apple
selectmenuverzögert, werde ich die Mistgabel auspacken und nach Cupertino aufbrechen!Ich stimme vollkommen zu. Apple hätte niemals in das Browsergeschäft einsteigen sollen, oder zumindest zu einer anderen Engine wechseln sollen. Es ist ein echter Pain in the Ass (PITA).
Als Amateur-Frontend-Entwickler war praktisch alles in diesem Artikel neu für mich, was fantastisch ist! Ich freue mich darauf, meine wackeligen Formulare, die ich für die Arbeit entwickelt habe, anzugehen und zu aktualisieren! Danke für den Artikel!
Ich warte sehnsüchtig auf die integrierten Cursor-Styles. Aber bis heute ist der benutzerdefinierte Cursor die einzige Option.
Wenn ich mich richtig erinnere, werden deaktivierte Elemente nicht in den Formular-POST aufgenommen. Das macht es schwierig, wenn man trotzdem den Wert dieser deaktivierten Elemente erfahren möchte.
Werden Elemente mit inert bei der Formular-POST-Anfrage gesendet?
Das Ersetzen von deaktivierten Attributen durch inert=„true“ führt zu Informationsverlust für Screenreader-Benutzer. Wie Sie sagen, ist es das Äquivalent zum Hinzufügen von aria-hidden=„true“. Das Formularbeispiel ist nicht typisch, das typische Beispiel ist für Inhalte außerhalb von Modal-Dialogen.
Mir ist gerade aufgefallen, dass es nicht inert=true ist, sondern nur inert.