Als Chris seine Idee für ein Boilerform schrieb, dachte ich bereits darüber nach, ein neues Projekt zu starten. Ich hatte gerade beschlossen, mein Frontend-Boilerplate einzustellen und wollte etwas Neues zum Nachdenken. Chris' Idee traf mich sofort, also beteiligte ich mich enthusiastisch an den Kommentaren wie ein aufgeregter Welpe. Diese Begeisterung führte dazu, dass ich die erste Version von Boilerform baute, die du dir hier ansehen kannst.
Der Grund für meine anfängliche Begeisterung war, dass ich ein heimliches Vergnügen für Formulare habe. In verschiedenen Jobs habe ich auf einem ziemlich intensiven Niveau mit Formularen gearbeitet und viel darüber gelernt. Dies reichte vom Bau dynamischer Formulargeneratoren bis hin zum hochrangigen Spam-Schutz für eine Harley-Davidson®-Website-Plattform. Jedes verschiedene Projekt hat mir Einblicke in das Frontend und Backend des Prozesses gegeben. Jedes dieser Projekte hat auch meine Toleranz für schnelle, faule Implementierungen von Formularen aufgebraucht, da ich die drastischen Auswirkungen davon im großen Maßstab gesehen habe.
Aber hey, wir sind keine schlechten Menschen. Formulare sind ein *Albtraum* zu bearbeiten. Obwohl es jetzt besser ist: Jeder Browser behandelt sie etwas anders. Schauen Sie sich zum Beispiel diese Auswahllisten aus einer Auswahl von Browsern und Betriebssystemen an. Keiner von ihnen sieht gleich aus.
Aufgrund dieser Inkonsistenzen ist es leicht zu verstehen, warum Entwickler es vermeiden, zu tief zu graben oder einfach eine Kopie von Bootstrap hochfahren und damit fertig sein. Außerdem werden meiner Erfahrung nach die Designs kleinerer Formulare, wie z. B. eines Kontaktformulars, bis später im Projekt aufgeschoben, wenn die meiste positive Dynamik bereits verflogen ist. Ich war sogar schuldig, Kontaktformulare einen Tag vor dem Start einer Website zu erstellen. 😬
Es gibt eindeutig eine Gelegenheit, den Prozess der Arbeit mit Formularen – zumindest im Frontend – zu verbessern, und ich konnte der Versuchung, es zu tun, nicht widerstehen!
Die Planung
Ich saß und dachte darüber nach, welche Schmerzpunkte bei der Arbeit mit Formularen bestehen und was mich als Nutzer von Formularen ärgert. Ich entschied, dass ich als Entwickler es hasse, Formulare zu stylen. Als Nutzer ärgern mich schlecht implementierte *Formularfelder*.
Ein Beispiel für Letzteres sind E-Mail-Felder. Wenn Sie versuchen, ein E-Mail-Feld auf einem iOS-Gerät auszufüllen, erhalten Sie diese ärgerliche Eigenschaft, dass der erste Buchstabe vom Browser großgeschrieben wird, weil er ihn wie einen Satz behandelt. Alles, was Sie tun müssen, um dieses Verhalten zu stoppen, ist, autocapitalize="none" zu Ihrem Feld hinzuzufügen, und das stoppt. Ich weiß, dass dies nicht allgemein bekannt ist, da ich es selten sehe, aber es ist ein so schneller Gewinn, um eine positive Auswirkung auf Ihre Benutzer zu haben.
Ich wollte diese kleinen Tricks direkt in Boilerform einbauen, um Entwicklern zu helfen, das Leben ihrer Benutzer einfacher zu machen. Die Erstellung eines Frontend-Boilerplates oder -Frameworks bedeutet so viel mehr als nur Styling und Ästhetik. Es geht darum, Ihre gesammelten Erfahrungen mit anderen zu teilen, um die Landschaft insgesamt besser zu machen.
Die Spezifikation
Ich musste darüber nachdenken, was Boilerform als Minimum Viable Product bei der ersten Veröffentlichung können sollte. Ich kam zu folgenden Regeln:
- Es musste mit den meisten Frontends kompatibel sein
- Es musste gut dokumentiert sein
- Es musste leichtgewichtig sein
- Jemand sollte einen CDN-Link zu seinem
<head>einfügen können und es sollte einfach funktionieren - Jemand sollte auch die Quelle für seine eigenen Projekte erweitern können
- Es sollte nicht zu meinungsbildend sein
Um diese Punkte zu erreichen, musste ich einige technologische Entscheidungen treffen. Ich entschied mich für ein Setup mit geringer Einstiegshürde. Dies war:
- Sass-basiertes CSS
- BEM
- Plain ol' HTML
- Ein einfaches Kompilierungs-Setup
Ich konzentrierte mich auch auf Beispiele. CodePen war dafür die natürliche Wahl, da sie sich sehr gut einbetten lassen. Benutzer können sie auch forken und selbst damit experimentieren.
Die letzte Entscheidung war, eine Pattern Library herauszubringen, um Komponenten in kleine Teile zu zerlegen. Das half mir auf verschiedene Weise. Es half hauptsächlich bei der Organisation – aber es half mir auch, Boilerform in einer kleinteiligen, sporadischen Weise zu bauen, da ich abends daran arbeitete.
Ich hatte meinen Plan und meinen Stack, also machte ich mich an die Arbeit.
Einfach halten
Es ist leicht, dass ein Projekt wie dieses aus dem Ruder läuft, daher ist es nützlich, einige Punkte darüber festzulegen, was Boilerform sein wird und was nicht.
Was Boilerform sein wird
- Es wird immer ein Boilerplate sein, um Ihnen einen guten Start in Ihr Projekt zu ermöglichen
- Es wird High-Level-Hilfe bei HTML, CSS und JavaScript bieten, um das Leben von Entwicklern und Benutzern zu erleichtern
- Es wird darauf abzielen, superleichtgewichtig zu sein, damit es keine schwere Last wird
- Es wird konfigurierbare Optionen anbieten, die es flexibel und einfach machen, es in die meisten Webprojekte zu integrieren
Was Boilerform nicht sein wird
- Es wird keine Wunderwaffe für Ihre Formulare sein – es wird immer noch etwas Arbeit erfordern
- Es wird kein Framework wie Bootstrap oder Foundation sein, da es immer ein Ausgangspunkt sein wird
- Es wird mit seinem CSS und JavaScript nicht übermäßig meinungsbildend sein
- Es wird niemals auf ein bestimmtes Framework oder eine bestimmte Webtechnologie abzielen
Die Details
Ich weiß, dass ihr alle gerne in die Details eintaucht, wie Dinge funktionieren, also lasst mich euch eine Schnelltour geben!
CSS-Namespacing
Das Erste, was ich erledigt habe, war das Namespacing. Ich habe an einer Vielzahl von verschiedenen Websites und Setups gearbeitet, und sie alle haben etwas gemeinsam, wenn es um CSS geht: Konflikte. Mit diesem Gedanken im Hinterkopf habe ich einen @mixin geschrieben, der das gesamte CSS in einen .boilerform-Namespace einschloss.
// Source Sass
.c-button {
@include namespace() {
background: gray;
}
}
// This compiles to this with Sass:
.boilerform .c-button { background: gray; }Das Mixin ist im Moment einfach, aber es gibt uns Flexibilität zu skalieren. Wenn wir das Namespacing später optional machen wollten, müssen wir nur dieses Mixin aktualisieren. Ich liebe diese Art von Modularität.
Im Moment gibt es uns Sicherheit. Nichts dringt aus Boilerform heraus und hoffentlich wird alles, was hineinleckt, von den Namespaced-Resets und Regeln behandelt.
BEM mit einem Hauch von Präfixen
Ich liebe BEM. Es ist seit ein paar Jahren Kernstück meines CSS und Markup. Eine Sache, die ich an BEM liebe, ist, dass es Ihnen hilft, kleine, gekapselte Komponenten zu bauen. Das ist perfekt für ein Projekt wie Boilerform.
Ich könnte wahrscheinlich nackte Elemente sicher ansprechen, dank des Namespacings, aber BEM ist mehr als nur das Anbringen von Klassen an alles. Es gibt mir und anderen die Freiheit, jede beliebige Markup-Struktur zu schreiben. Es ist auch für jemanden wirklich einfach, den Code aufzunehmen und zu verstehen, was zu was gehört, sowohl in HTML als auch in CSS.
Eine weitere Sache, die ich diesem Setup hinzugefügt habe, war ein Komponentenpräfix. Anstelle einer .input-field-Komponente haben wir eine .c-input-field-Komponente. Ich hoffe, solche kleinen Dinge helfen einem neuen Mitwirkenden, sofort zu erkennen, was eine Komponente ist.
Horror-Eingaben erhalten ein cooles Styling
Wie oben erwähnt, sind Auswahllisten furchtbar zu stylen. Dasselbe gilt für Radiobuttons und Checkboxen.
Ein Trick, den ich seit einiger Zeit anwende, ist die Abstraktion des Stylings auf andere, freundlichere HTML-Elemente. Zum Beispiel wickle ich bei <select>-Elementen diese in eine .c-select-field-Komponente ein und verwende Geschwisterelemente, um ein konsistentes Pfeilsymbol hinzuzufügen.
Bei Checkboxen und Radiobuttons blende ich den Hauptinput visuell aus und verwende benachbarte <label>-Elemente, um Zustandsänderungen anzuzeigen. Die Verwendung dieses Ansatzes macht die Arbeit mit diesen Steuerelementen so viel einfacher. Wichtig ist, dass wir Barrierefreiheit und native Ereignisse beibehalten.
Basisattribute zur einfacheren Verwendung von Feldern
Ich habe es oben mit meinem Beispiel zur E-Mail-Kapitalisierung erwähnt, aber das war nicht die einzige Ergänzung nützlicher Attribute.
- Suchfelder haben
autocorrect="off", um zu verhindern, dass Browser Rechtschreibfehler korrigieren. Ich empfehle dringend, dies auch bei Eingaben hinzuzufügen, in die ein Benutzer seinen Namen eingibt. - Zahlenfelder haben
min,maxundstepAttribute, die bei der Validierung helfen. Das ist auch großartig für Tastaturnutzer. - Alle Felder haben leere
name- undid-Attribute, um hoffentlich den Verdrahtungsprozess zu beschleunigen
Ich bin sicherlich daran interessiert, dass dies weiter ausgebaut wird, denn kleine Anpassungen wie diese sind großartig für die Benutzererfahrung.
Weiter so. Kannst du helfen?
Boilerform ist derzeit an einem guten Punkt, hat aber echtes Potenzial, nützlich zu sein. Einige Ideen, die ich für die Weiterentwicklung hatte, sind:
- Einführung mehrerer JavaScript-Bibliotheksintegrationen, wie z. B. React, Vue und Angular
- Erstellung einiger grundlegender Formularlayouts in der Pattern Library
- Erstellung von Sass-Mixins zum Stylen lästiger Dinge wie Platzhalter
- Verbesserung der Konfigurierbarkeit
- Hinzufügen neuer Elemente wie des Range-Inputs
- Erstellung mehrsprachiger Dokumentation
Wie Sie sehen können, ist das eine Menge Arbeit, daher wäre es großartig, wenn wir ein paar Mitwirkende für das Projekt gewinnen könnten, um etwas wirklich Nützliches für unsere Community zu schaffen. Die Einbeziehung von Mitwirkenden mit unterschiedlichen Fachkenntnissen und Hintergründen wird uns helfen, es für so viele Menschen wie möglich nützlich zu machen, von Endbenutzern bis hin zu Backend-Entwicklern.
Lasst uns gemeinsam etwas Großartiges schaffen. 🙂
Schauen Sie sich die Projektseite oder das GitHub-Repository an.
Sh*t yea! Gut gemacht, Andy!
Danke!
Die Idee gefällt mir, aber ich habe Probleme mit der Implementierung der Checkbox. Sie muss ein Häkchen enthalten, oder?
Das Schöne an Boilerform ist, dass es ein Kinderspiel ist, wenn Sie ein Häkchen hinzufügen möchten. Wir normalisieren nur den Prozess der Arbeit mit Formularen :)
„Ein Beispiel für Letzteres sind E-Mail-Felder. Wenn Sie versuchen, ein E-Mail-Feld auf einem iOS-Gerät auszufüllen, erhalten Sie diese ärgerliche Eigenschaft, dass der erste Buchstabe vom Browser großgeschrieben wird, weil er ihn wie einen Satz behandelt. Alles, was Sie tun müssen, um dieses Verhalten zu stoppen, ist, autocapitalize="none" zu Ihrem Feld hinzuzufügen, und das stoppt.“
Tatsächlich ist die bessere Lösung hier die Verwendung eines
<input type="email">, das neben der Deaktivierung der automatischen Großschreibung auch die automatische Korrektur deaktiviert und auf iOS eine E-Mail-spezifische Tastatur anzeigt.Ja, das
email-Attribut ist dort impliziert. Ich glaube, die Korrektur der automatischen Großschreibung ist auch noch relativ neu. Meiner Meinung nach ist es besser, ein schnelles Attribut für eine breite Korrektur hinzuzufügen :)Grundsätzlich denke ich, dass das eine gute Idee ist: Alle Formulare erhalten gute Funktionalität, Barrierefreiheit und Fehlerverwaltung.
Aber es gibt auch https://lawsofux.com/jakobs-law – Benutzer erwarten, dass Formulare nicht browserübergreifend konsistent aussehen, sondern auf Websites in ihrem bevorzugten Browser. Wie Ben Dunkle bereits kommentiert hat, sollte eine Checkbox nicht ein Häkchen haben? Ich würde das auch erwarten – und natürlich sollte sie orange sein, wie alle Checkboxen mit meinem Ubuntu-Betriebssystem ☺
Die Vereinheitlichung einiger Formularelemente bedeutet auch, dass sie für die meisten Benutzer befremdlich werden.
Wie ich oben gesagt habe
Aber hey, wir lieben ein bisschen Beitrag, also warum nicht einen PR einreichen, der ein vererbbares farbiges Häkchen hinzufügt? Das wäre sehr dankbar! :)
Danke, das ist definitiv, was gebraucht wird, besonders bei kleinen Projekten, bei denen man nicht das volle Bootstrap-Framework einbeziehen möchte.
Erwägen Sie, so etwas für responsive Navigationsleisten zu erstellen.
Sie haben Anforderungen für das MVP identifiziert, aber ich denke, Sie haben eine kritische ausgelassen – es muss zugänglich sein. Bis dahin kann jede Organisation, die WCAG 2.0 AA anstreben muss (was die meisten tun, wenn man die aktuellen Gesetze und Rechtsentscheidungen international betrachtet), sie nicht in ihrer jetzigen Form verwenden, was bedeutet, dass sie kein guter Indikator für die Akzeptanz sein kann. Was Sie haben, ist nicht schlecht für die Barrierefreiheit, aber die Erklärung und das Ziel zu machen, ist auch ein Signal für diejenigen, für die Barrierefreiheit ein Faktor ist, bevor sie überhaupt eine Bibliothek / ein Framework / eine Plattform in Betracht ziehen.
Danke für das Feedback, Adrian.
Barrierefreiheit ist in der Tat unglaublich wichtig, und mit diesem Gedanken im Hinterkopf wäre es enorm dankbar, wenn Sie spezifische Probleme identifizieren und Issues aufwerfen und/oder PRs im Projekt einreichen würden.
Da Boilerform hauptsächlich ein Reset ist und nur geringfügige Erweiterungen der nativen Funktionalität bietet, sollte nichts gravierend falsch sein. Aber auch hier, wenn Sie etwas anderes sehen, wäre das Feedback wirklich willkommen.
Es wurde bereits gute Arbeit von der Community geleistet, um dies in dieser Hinsicht zu verbessern.
Eine Sache, die wahrscheinlich in der Dokumentation fehlt, sind Ratschläge zu bewährten Praktiken, denn meiner Meinung nach können wir Entwicklern damit wirklich helfen, zugängliche Formulare zu erstellen.
Wenn Sie doch einmal Issues protokollieren, habe ich ein spezielles Label für Barrierefreiheit im Repository erstellt.