Vielleicht verwenden Sie XHTML nicht (mehr), aber wenn Sie HTML schreiben, sind Sie möglicherweise stärker von XHTML beeinflusst, als Sie denken. Es ist sehr wahrscheinlich, dass Sie HTML auf die XHTML-Art schreiben.
Was ist die XHTML-Art, HTML zu schreiben, und was ist die HTML-Art, HTML zu schreiben? Schauen wir uns das mal an.
HTML, XHTML, HTML
In den 1990er Jahren gab es HTML. In den 2000er Jahren gab es XHTML. Dann, in den 2010er Jahren, wechselten wir zurück zu HTML. Das ist die einfache Geschichte.
Das kann man auch an den groben Daten der Spezifikationen erkennen: HTML „1“ 1992, HTML 2.0 1995, HTML 3.2 1997, HTML 4.01 1999; XHTML 1.0 2000, XHTML 1.1 2001; „HTML5“ 2007.
XHTML wurde populär, als jeder glaubte, XML und XML-Derivate seien die Zukunft. „XML all the things.“ Für HTML hatte dies tiefgreifende Auswirkungen: Die Auswirkung, dass wir lernten, es auf die XHTML-Art zu schreiben.
Die XHTML-Art, HTML zu schreiben
Die XHTML-Art ist gut dokumentiert, da XHTML 1.0 in seinem Abschnitt über „Unterschiede zu HTML 4“ detailliert beschrieben wird.
- Dokumente müssen wohlgeformt sein.
- Element- und Attributnamen müssen in Kleinbuchstaben geschrieben werden.
- Bei nicht-leeren Elementen sind End-Tags erforderlich.
- Attributwerte müssen immer in Anführungszeichen gesetzt werden.
- Attributminimierung wird nicht unterstützt.
- Leere Elemente müssen geschlossen werden.
- Die Handhabung von Leerzeichen in Attributwerten erfolgt gemäß XML.
- Skript- und Style-Elemente benötigen CDATA-Abschnitte.
- SGML-Ausschlüsse sind nicht möglich.
- Die Elemente mit den Attributen
idundname, wie z. B.a,applet,form,frame,iframe,imgundmap, sollten nuridverwenden. - Attribute mit vordefinierten Wertebereichen sind case-sensitiv.
- Hexadezimale Entitätsreferenzen müssen in Kleinbuchstaben angegeben werden.
Klingt das vertraut? Mit Ausnahme der Kennzeichnung von CDATA-Inhalten und der Behandlung von SGML-Ausschlüssen befolgen Sie wahrscheinlich alle diese Regeln. Alle.
Obwohl XHTML tot ist, wurden viele dieser Regeln nie wieder in Frage gestellt. Einige wurden sogar zu „Best Practices“ für HTML erhoben.
Das ist die XHTML-Art, HTML zu schreiben, und ihr bleibender Einfluss auf das Feld.
Die HTML-Art, HTML zu schreiben
Eine Möglichkeit, uns zurückzuführen, ist die Ablehnung der von XHTML auferlegten Regeln. Lassen Sie uns das tatsächlich tun (ohne den SGML-Teil, da HTML nicht mehr auf SGML basiert)
- Dokumente müssen nicht wohlgeformt sein.
- Element- und Attributnamen dürfen nicht in Kleinbuchstaben geschrieben werden.
- Bei nicht-leeren Elementen sind End-Tags nicht immer erforderlich.
- Attributwerte müssen nicht immer in Anführungszeichen gesetzt werden.
- Attributminimierung wird unterstützt.
- Leere Elemente müssen nicht geschlossen werden.
- Die Handhabung von Leerzeichen in Attributwerten erfolgt nicht gemäß XML.
- Skript- und Style-Elemente benötigen keine CDATA-Abschnitte.
- Die Elemente mit den Attributen
idundnamedürfen nicht nuridverwenden. - Attribute mit vordefinierten Wertebereichen sind nicht case-sensitiv.
- Hexadezimale Entitätsreferenzen dürfen nicht nur in Kleinbuchstaben angegeben werden.
Lassen Sie uns die esoterischen Dinge entfernen; die Dinge, die nicht relevant erscheinen. Dazu gehören XML-Leerzeichenbehandlung, CDATA-Abschnitte, Verdopplung von name-Attributwerten, die Groß-/Kleinschreibung vordefinierter Wertebereiche und hexadezimale Entitätsreferenzen
- Dokumente müssen nicht wohlgeformt sein.
- Element- und Attributnamen dürfen nicht in Kleinbuchstaben geschrieben werden.
- Bei nicht-leeren Elementen sind End-Tags nicht immer erforderlich.
- Attributwerte müssen nicht immer in Anführungszeichen gesetzt werden.
- Attributminimierung wird unterstützt.
- Leere Elemente müssen nicht geschlossen werden.
Wenn man sich von diesen Regeln löst, sieht das viel weniger nach der Arbeit mit XML und mehr nach der Arbeit mit HTML aus. Aber wir sind noch nicht fertig.
„Dokumente müssen nicht wohlgeformt sein“ deutet an, dass es in Ordnung war, wenn HTML-Code ungültig war. Es war in Ordnung, dass XHTML auf Wohlgeformtheit verwies, wegen der strengen Fehlerbehandlung von XML. Aber während HTML-Dokumente auch dann funktionieren, wenn sie schwere Syntax- und Wohlgeformtheitsprobleme enthalten, ist es weder für den Profi – noch für unser Feld – nützlich, diese Widerstandsfähigkeit zu nutzen und auszunutzen. (Ich habe diesen Fall bereits in meinem Artikel „In Critical Defense of Frontend Development.“ dargelegt.)
Die HTML-Art würde daher nicht vorschlagen: „Dokumente müssen nicht wohlgeformt sein.“ Es wäre auch klar, dass nicht nur End-, sondern auch Start-Tags nicht immer erforderlich sind. Wenn man dies umformuliert und neu anordnet, ist dies die Essenz
- Start- und End-Tags sind nicht immer erforderlich.
- Leere Elemente müssen nicht geschlossen werden.
- Element- und Attributnamen können klein oder groß geschrieben werden.
- Attributwerte müssen nicht immer in Anführungszeichen gesetzt werden.
- Attributminimierung wird unterstützt.
Beispiele
Wie sieht das in der Praxis aus? Bei Start- und End-Tags beachten Sie, dass viele Tags optional sind. Ein Absatz und eine Liste zum Beispiel werden in XHTML so geschrieben
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>
<ul>
<li>Praesent augue nisl</li>
<li>Lobortis nec bibendum ut</li>
<li>Dictum ac quam</li>
</ul>In HTML können Sie sie jedoch nur mit diesem Code schreiben (der gültig ist)
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.
<ul>
<li>Praesent augue nisl
<li>Lobortis nec bibendum ut
<li>Dictum ac quam
</ul>Entwickler haben auch gelernt, leere Elemente so zu schreiben
<br />Das ist etwas, das XHTML in HTML gebracht hat, aber da der Schrägstrich bei leeren Elementen keine Wirkung hat, benötigen Sie nur dies
<br>In HTML können Sie auch alles in Großbuchstaben schreiben
<A HREF="https://css-tricks.de/">CSS-Tricks</A>Es sieht so aus, als würden Sie schreien, und das gefällt Ihnen vielleicht nicht, aber es ist in Ordnung, es so zu schreiben.
Wenn Sie diesen Link kondensieren möchten, bietet HTML Ihnen die Möglichkeit, bestimmte Anführungszeichen wegzulassen.
<A HREF=https://css-tricks.de/>CSS-Tricks</A>Als Faustregel gilt: Wenn der Attributwert kein Leerzeichen oder Gleichheitszeichen enthält, ist es normalerweise in Ordnung, die Anführungszeichen wegzulassen.
Schließlich erlaubt HTML – HTML, nicht XHTML – auch die Minimierung von Attributen. Das heißt, anstatt ein input-Element als erforderlich und schreibgeschützt zu markieren, so
<input type="text" required="required" readonly="readonly">Sie können die Attribute minimieren
<input type="text" required readonly>Wenn Sie nicht nur die Tatsache nutzen, dass keine Anführungszeichen benötigt werden, sondern dass text der Standard für das type-Attribut ist (es gibt noch mehr solche unnötigen Attribut-Wert-Kombinationen), erhalten Sie ein Beispiel, das HTML in all seiner minimalen Schönheit zeigt.
<input required readonly>HTML schreiben, auf die HTML-Art
Das Obige ist keine Darstellung dessen, wo HTML in den 90ern stand. HTML war damals voller <table>-Elemente für das Layout, voller präsentationsbasierendem Code, weitgehend ungültig (wie es heute noch ist), mit stark variierender Unterstützung durch die Browser. Dennoch ist es die *Essenz* dessen, was wir hätten beibehalten wollen, wenn XML und XHTML nicht gekommen wären.
Wenn Sie offen für einen Vorschlag sind, wie eine umfassendere, zeitgemäßere Art, HTML zu schreiben, aussehen könnte, habe ich einen. (HTML ist mein Hauptfokus, daher ergänze ich dies durch Links zu einigen meiner Artikel.)
- Syntax und Semantik respektieren.
- Validieren Sie Ihr HTML und liefern Sie nur gültiges HTML aus.
- Nutzen Sie die Optionen, die Ihnen HTML bietet, solange Sie dies konsequent tun.
- Denken Sie daran, dass Element- und Attributnamen klein- oder großgeschrieben sein können.
- Halten Sie die Verwendung von HTML auf das absolute Minimum beschränkt
- Denken Sie daran, dass präsentationsbasierte und verhaltensbezogene Markups stattdessen von CSS und JavaScript gehandhabt werden sollten.
- Denken Sie daran, dass Start- und End-Tags nicht immer erforderlich sind.
- Denken Sie daran, dass leere Elemente nicht geschlossen werden müssen.
- Denken Sie daran, dass einige Attribute Standardwerte haben, die es erlauben, diese Attribut-Wert-Paare wegzulassen.
- Denken Sie daran, dass Attributwerte nicht immer in Anführungszeichen gesetzt werden müssen.
- Denken Sie daran, dass Attributminimierung unterstützt wird.
Es ist kein Zufall, dass dies den drei Grundregeln für HTML ähnelt, dass es mit der Prämisse eines kleineren Payloads, der auch zu schnelleren Websites führt, funktioniert und dass dies der Schule der minimalen Webentwicklung folgt. Nichts davon ist neu – unser Feld könnte es lediglich beschließen, es wiederzuentdecken. Werkzeuge sind ebenfalls verfügbar: html-minifier ist wahrscheinlich das etablierteste und fähigste, alle HTML-Optimierungen zu handhaben.
Sie haben HTML auf die XHTML-Art gelernt. HTML ist nicht XHTML. Entdecken Sie HTML neu und helfen Sie mit, eine neue, moderne Art des Schreibens von HTML zu gestalten – die XML anerkennt, aber nicht unbedingt darauf basiert.
Nachdem ich meine Reise während der „dunklen“ Zeiten von
<marquee>und<table>als Methode zur Gestaltung einer Website begann, schätze ich die Nostalgie, HTML wie HTML zu schreiben.Dennoch würde ich nicht empfehlen, all diese Vorschläge zu übernehmen.
Das Nichtverwenden von End-Tags (oder leeren Elementen) kann zu Fehlern führen, es sei denn, Sie haben Ihren Linter ausdrücklich angewiesen, sie zu ignorieren.
Ich würde auch zögern, das Weglassen von Anführungszeichen zu empfehlen, denn nun ja… es bietet keine Vorteile.
Die Dateigröße wird nicht nennenswert reduziert.
Sie führen mögliche Fehlerquellen in Ihr HTML ein, was die Wartbarkeit zu einem potenziellen Problem macht.
Sie umgehen einen Standard, der von Editoren/Code-Prozessoren verwendet werden kann, um Attribute/Werte leichter zu unterscheiden, was potenziell Probleme bei der Code-Analyse verursacht.
Und ich widerspreche vehement dem Weglassen von Standardwerten, da dies erneut ein Wartbarkeitsproblem (und vielleicht Edge-Case-Probleme bei einigen Browsern?) verursacht.
<input>ist nicht so klar wie<input type="text">, und als Entwickler müssen Sie bedenken, dass Sie möglicherweise nicht die einzige Person sind, die an einem Projekt arbeitet. Das Einsparen einiger Bytes durch Weglassen von 12 Zeichen ist nicht nützlich, wenn es zu Verwirrung beim Verständnis dessen führt, was Ihr HTML tatsächlich rendern soll.…
Früher schien HTML in Großbuchstaben der Standard zu sein, und soweit ich mich erinnere, war das Argument, dass es besser lesbar / leichter zwischen HTML und Inhalt zu unterscheiden war.
Ich würde argumentieren, dass die Code-Farbgebungsfunktionen, die in praktisch jedem modernen Editor implementiert sind, dieses Argument überflüssig machen, wodurch Großbuchstaben wirklich eine Frage der persönlichen Präferenz sind.
…
Wo ich zu 100 % zustimme, ist die Vermeidung von Redundanzen wie bei
disabled="disabled". Für mich fühlt sich diese Art der Attributdeklaration weniger lesbar an… wahrscheinlich, weil ich gebeten werde, sie als „Disabled ist Disabled“ zu interpretieren, was mein Auge nur zucken lässt.Obwohl ich diese Funktionen gerne für die Minifizierung verwenden würde, erfordert das tatsächliche Schreiben von Code, dass sie lesbar und vorhersehbar sind. Daher wird aus allen „Sie können X überspringen“ ein „Auch wenn die Syntax es erlaubt, können Sie X nicht überspringen“. Schließende Tokens und konsistente Attribute machen es für einen Menschen einfacher zu handhaben, auch wenn Maschinen es nicht kümmert.
Etwas ausführlicher im Quellcode zu sein, erleichtert Ihr Leben in Zukunft erheblich.
Sie sagen immer HTML, wo Sie SGML sagen sollten. Es gibt zwei Arten, HTML zu schreiben: als SGML oder als XML. Und beide sind mit HTML5 gültig.
XHTML ist nicht „nicht die HTML-Art“, es ist nur nicht die SGML-Art.
Und im Übrigen ist XML im Wesentlichen eine strengere Teilmenge von SGML.
Was Sie als Linux bezeichnen, ist eigentlich GNU + Linux etc etc
Entschuldigung, aber ich widerspreche entschieden dem Punkt, dass End-Tags nicht erforderlich sind. Betrachten Sie diesen Fall
Es ist nicht intuitiv, was das Ergebnis sein sollte.
<div>ist ein Blockelement, also wird die<ul>vorher beendet, richtig? Falsch.<div>ist unter dem letzten verschachtelt. Okay, nun muss das<strong>-Tag vorher beendet werden, richtig? Falsch! Der gesamte Inhalt danach ist fett gedruckt. Das Weglassen der End-Tags verursacht Verwirrung und Probleme. Konzeptionell ist es möglich, aber praktisch sollte es niemals getan werden.Okay, aber warum sollten wir das tun? Was sind die Vorteile?
HTML trägt nur sehr wenig zum Gesamtseitenvolumen bei, und diese „moderne“ Art des Schreibens macht Seiten schwerer zu verarbeiten.
Ich bin alt genug, um HTML auf die HTML-Art gelernt zu haben, bin zur XHTML-Art gewechselt, weil ich sie besser fand, aber ich bin offen dafür, überzeugt zu werden.
Gute Überlegung.
Das Nichtschließen von
</li>-Tags im Besonderen führt jedoch dazu, dass zusätzliche Leerzeichen als Teil desfirstChild-Textknotens des Elements hinzugefügt werden. Dies ist dasselbe Problem, das Sie haben, wenn Sie Zeilenumbrüche an Stellen mit<li>einfügen, die von CSS gestylt werden, und Sie visuelle Abstände zwischen Elementen erhalten, die Sie nicht wollten. Zum Beispiel hat eine Ikone am Ende eines Labels auf einem Button etwas mehr Abstand zwischen dem Text und der Ikone als sonst.Aber in diesem Fall ist es völlig vermeidbar – da das Weglassen des schließenden Tags zusätzliche Leerzeichen und Zeilenumbrüche als Teil dieses Elements interpretiert.
Ich stimme einigen Teilen zu (wie der Minimierung von Attributen), widerspreche aber stark anderen.
Das Weglassen von Anführungszeichen für Attribute, insbesondere für URLs, ist eine schreckliche Idee. Nur weil man es kann, heißt das nicht, dass man es tun sollte. Und Konsistenz ist oft besser als totale Minimalismus.
Ich meine, man muss in JavaScript keine Zeilenumbrüche verwenden, aber es ist schrecklich zu lesen, wenn man keine verwendet. Dasselbe gilt für Semikolons, ich ziehe es vor, sie immer zu verwenden; Konsistenz über maximalen Minimalismus.
Ebenso machen selbstschließende Tags für leere Elemente sie lesbarer (meiner Meinung nach); auch wenn es dem Computer egal ist und sie nur für uns dumme Menschen da sind.
Sagen Sie, was Sie wollen, ich werde immer selbstschließende Tags für Elemente ohne schließenden Tag verwenden. Meine OCD erlaubt es mir nicht, mit einem öffnenden Tag und keiner Angabe des schließenden Tags zufrieden zu sein.
Autsch. Ich will nicht zurück zu HTML, wo Tags manchmal geschlossen und manchmal nicht, manchmal Großbuchstaben und manchmal nicht. Diese HTML-Dateien sahen schrecklich aus und verdienten es zu sterben. Genauso wie JS langsam von TypeScript übernommen wird, hoffe ich aufrichtig, dass das W3C ähnliche Codequalitätsmechanismen auf HTML anwendet.
Bitte ermutigen Sie die Leute nicht, schlechten Code zu schreiben, nur weil er möglich ist. Mit Build-Ketten und HTML-Optimierern ist dies nicht notwendig und schult nur neue Webentwickler darin, sich nicht darum zu kümmern und Code zu schreiben, als wäre es wieder 1990. Bitte nicht.
Dies sind persönliche Syntaxpräferenzen, die als „Best Practices“ präsentiert werden, und dieses Thema zieht sich durch die unterstützenden Artikel.
Ich stimme einigen Ihrer Vorlieben zu, und es ist gut, sich daran zu erinnern, dass wir mehrere gültige Optionen haben. Aber die Realität ist, dass sie *einfach keine Rolle spielen*.
Niemand hat jemals eine langsame Website zu einer schnellen gemacht, indem er schließende Tags weggelassen hat. Das Minifizieren von HTML steht so weit unten auf der Liste der Performance-Optimierungen, dass es genauso gut nicht existieren könnte, abgesehen von extrem optimierten Dingen wie der Google-Suchseite.
Es ist absolut gültig, diese Dinge zu tun, um Ihr Vergnügen an Minimalismus oder Optimierung zu befriedigen. Vielleicht macht es Ihren Code lesbarer.
Ich denke nur, dass das Performance-Argument irreführend ist. Sie haben etwas Subjektives mit einem Anschein von Objektivität getarnt.
Es gibt auch Nachteile bei einigen dieser Praktiken. Einer ist der mentale Aufwand, sich Dinge zu merken, die man wirklich nicht merken muss. Ich würde lieber mein Gehirn mit Poesie füllen, als Regeln auswendig zu lernen, wann ich Anführungszeichen bei HTML-Attributen weglassen kann. Ehrlich gesagt, wen kümmert's? Zitieren Sie sie einfach immer und machen Sie mit Ihrem Leben weiter.
Nochmal, es ist nichts Falsches daran, sich dafür zu interessieren, weil man es interessant findet. Wir sind alle auf unterschiedliche Weise Geeks und lasst uns das feiern! Aber das ist etwas anderes, als den arbeitenden Entwickler zu überzeugen, sich dafür zu interessieren. Genießen Sie es, Ihr Steckenpferd zu reiten, aber präsentieren Sie es vorzugsweise nicht als praktisches Transportmittel für diejenigen, die einfach nur zur Arbeit kommen wollen.
Und natürlich können Sie Werkzeuge verwenden, um dies für Sie zu tun. Ich mag nicht die Denkweise, dass man alle Regeln kennen muss, bevor man die Werkzeuge benutzt. Werkzeuge automatisieren nicht nur repetitive Aufgaben, sondern befreien uns auch von der mühsamen Arbeit, irrelevante Geheimnisse zu lernen. Sie erlauben uns, uns auf die Expertise anderer zu verlassen – wie Ihre!
Andererseits ist es für viele Websites fraglich, ob es sich lohnt, das Werkzeug hinzuzufügen, angesichts des nahezu Null-Performance-Vorteils des Minifizierens von HTML. Es könnte davon abhängen, wie einfach es ist, es in Ihr bestehendes Setup zu integrieren.
Einfachheit ist selten so einfach, wie Minimalisten es gerne darstellen. Vereinfacht man eine Dimension, kompliziert man oft eine andere; Perfektionismus neigt dazu, die Gesamtkomplexität zu erhöhen.
Ich glaube nicht, dass ich mich jemals damit abfinden werde, in meinen Listen keine schließenden Tags zu verwenden!
Tolle Lektüre, aber ich würde es
Pugüberlassen, alles für mich zu formatieren.Mein wichtigstes Fazit nach dem Lesen dieses anarchischen Manifests: Nur weil man etwas kann, heißt das nicht, dass man es tun sollte. XHTML ist insgesamt eine Verbesserung, und das Einsparen von ein paar Bytes ist es nicht wert, die Lesbarkeit beim Verfassen von HTML zu verlieren.
Ich denke, XHTML war zu streng und bot einen hohen Preis für einen geringen Gewinn, aber es hatte einen Sinn. Lesbarkeit zählt (viel) in jeder Sprachsyntax. Erzwingung wird nicht die Antwort sein, aber ich denke, die Förderung von Dingen wie dem immerwährenden Schließen von Tags und dem Nichtunterdrücken von Standardargumenten hilft (wiederum viel) bei der Lesbarkeit des Codes.
Auch hier denke ich nicht, dass das Erzwingen von Codestilen die Antwort ist, aber die Förderung von lesbarerem Code ist immer eine gute Sache.
Die meisten davon befolge ich, ja. Außer bei ein paar
Schließen von leeren Tags. Habe das früher viel getan, so um 2012, wegen Kompatibilitätsproblemen.
Und ein paar Dinge, die ich tue, sind auf die XHTML-Art, weil es einfacher ist.
Alle hexadezimalen Entitätsreferenzen müssen klein geschrieben werden, sei es bei Farbcodes oder IDs, es ist viel einfacher, alles klein zu halten.
Entschuldigung, aber dem kann ich größtenteils nicht zustimmen. Mit XHTML-Syntax kann ich den Quellcode visuell prüfen und eine angemessene Struktur erkennen. Ich habe nicht immer Zugriff auf Tools, die das HTML validieren.
Für mich ist XHTML natürlicher, da es für die meisten Elemente Anfang und Ende erfordert. Bei leeren Elementen signalisiert der / sein Ende. Es bringt auch etwas Vernunft für diejenigen, die von Backend-Sprachen oder sogar JavaScript kommen, da die Syntax in diesen Sprachen Anfangs- und End-Tokens erfordert.
Ich werde gelegentlich immer noch Namensattribute verwenden, da dies eine Spezifikation ist und sich nicht um das Anfangen und Beenden eines Elements kümmert. CSS-Selektoren und Teile der JavaScript-API verwenden jedoch ID-Attribute, daher ist dies wahrscheinlich der Grund, warum das Namensattribut zugunsten von ID-Attributen in den Hintergrund getreten ist, mit Ausnahme von Formularen.
Ich würde argumentieren, dass Artikel wie dieser, obwohl sie harmlos die tatsächliche Spezifikation für HTML5 beschreiben, schlechte Praktiken normalisieren.
Zum Beispiel wird das Weglassen von Attributanführungszeichen, um ein paar Bytes zu sparen, mehr Probleme verursachen als das einfache Weiterbefolgen der XHTML-Spezifikation, insbesondere da Attribute heutzutage oft dynamisch eingefügt werden.
Ähnlich verursacht das Weglassen von schließenden Tags unzählige Probleme, wenn das HTML mehr als ein paar Zeilen umfasst oder von mehreren Entwicklern bearbeitet wird, und Sie nicht sicher sind, ob es verschachtelt sein soll oder einfach nur ein Fehler.
Es gab Gründe, warum XHTML in den frühen 2000er Jahren bevorzugt wurde. Das sollten wir nicht vergessen.
Leider erwarten viele Nicht-Browser-Parser optionale und schließende Tags. Bing erwartet beispielsweise optionale Head- und Body-Tags, sonst kann es Metadaten nicht lesen. Einige Link-Vorschau-Tools schlagen ebenfalls fehl.
Optionale schließende Schrägstriche, Anführungszeichen usw. sind völlig unnötig und sollten von typischen HTML-Minifizierern erfasst werden.
Viele der XHTML-Punkte ergaben tatsächlich Sinn. Sie müssen ein Element in HTML nicht schliessen, aber es hilft zu wissen, wo es endet (aber die Leute verstehen das Konzept von „Elementen“ in HTML nicht wirklich).
Eine von XHTML beeinflusste Sache, die nie verschwunden ist und tief, tief im Webentwicklungsbereich verwurzelt ist, ist die Schreibweise von HTML-Elementselektoren in Kleinbuchstaben innerhalb des CSS. Dies rührt daher, dass XHTML besagte, dass innerhalb des HTML die HTML-Elementnamen wahrscheinlich in Kleinbuchstaben geschrieben werden sollten, aber geschrieben werden müssten, wenn man sein Dokument als XML validieren wollte, und dann müsste man auch die Referenzen darauf im Stylesheet in Kleinbuchstaben schreiben, sonst würde die Übereinstimmung von Elementen im HTML mit ihren entsprechenden Elementen im CSS nicht funktionieren. Deshalb begannen ALLE in der Webentwicklungsbranche, Referenzen auf HTML-Elemente in Kleinbuchstaben in ihrem CSS zu schreiben, obwohl es nicht nötig ist, obwohl es Stylesheets weniger lesbar macht, obwohl kaum jemand weiß, warum sie es tun, und niemand davon abweichen will.
Wenn Sie sehen
#header UL LI A:link
ist es viel einfacher, schnell zu erkennen, dass UL LI A sich auf HTML-Elemente bezieht, als das Folgende:
#header ul li a:link
Besonders wenn man Tonnen von CSS-Code durchsiebt. Und wenn diese Verwirrung auftritt, ist es für Entwickler schwieriger, den Unterschied zwischen IDs, Elementen, Klassen usw. zu verstehen. Und dann macht diese Verwirrung es einfacher für Entwickler, mit DIV-Suppe einverstanden zu sein.
Kontroverse Sachen! Das OCD in mir lehnt das ab.
Ich würde gerne das VS Code-Plugin sehen, das von der XHTML-Art des Schreibens zur HTML-Art des Schreibens konvertiert.
Ja. Die automatische Korrektur von HTML-Code in VSCode treibt mich in den Wahnsinn, wenn ich instinktiv spüre, dass sie sinnlos ist.
Ich möchte HTML auf die HTML-Art schreiben, aber mein IDE schreit mich ständig an. ;) Die Standard-Code-Stil-Einstellungen scheinen immer XHTML-HTML zu sein.
Ich bin vielleicht altmodisch (ich habe HTML in den 90ern gelernt und meinen ersten Auftrag damit in den frühen 2000ern gemacht), aber ich finde, dass das Lernen und Respektieren des XHTML-Mantras Ihnen hilft, ein besserer Frontend-Entwickler zu sein, weil es weniger schlampig und vorhersehbarer ist. Nur weil HTML permissiver ist, heißt das nicht, dass wir unsere Standards darauf senken sollten. So sehe ich das jedenfalls.
Ich habe das Gefühl, dass minifizierte Attribute bereits zum Standard geworden sind. Aber optionale schließende Tags und für mich sind wie ein Semikolon in JavaScript. Ja, manche Leute schreiben ohne, und achten immer auf die Umstände, aber für mich schadet das der Lesbarkeit des Codes.
Ich erinnere mich, dass ich einen seltsamen Randfall gefunden habe, bei dem eine Bibliothek keine
</li>-Tags generierte und das Hinzufügen von<!doctype html>dazu führte, dass das Layout der Website, an der ich arbeitete, kaputt ging. Ich habe nur die Bibliothek repariert, um</li>-Tags zu generieren, und das hat das Problem gelöst.Ich vermeide gerne Tags wie
<head>, weil ich weiß, dass Browser sie intelligent hinzufügen, und ich baue keine Websites für Bots, die meine Kommentarformulare spammen, aber im Allgemeinen schließe ich meine Tags. Wenn ein Bot deswegen kaputt geht, dann ist dieser Bot schlecht implementiert und bald wird sein Entwickler das bemerken, wenn er eine Website findet, die einen HTML-Minifier verwendet (der im Beitrag genannte hat 3,9 Millionen Downloads pro Woche). Ich benutze immer noch<html>wegen deslang-Attributs.Seltsamerweise habe ich mehr Leute gesehen, die selbstschließende Tags (wie
</link>und</br>) schließen, weil Firefox diese als Fehler in `view-source:` hervorhebt, als umgekehrt. Nun, viele Leute vergessen auch, nicht-selbstschließende Tags zu schließen: Firefox hebt auch diese Fehler hervor und ich habe diese oft gesehen.Ich glaube nicht, dass "HTML auf die HTML-Art" es in irgendeiner Weise besser macht, andererseits glaube ich wirklich, dass es weniger sicher ist. Die Verwendung von XHTML-ähnlichen Regeln erleichtert die Arbeit mit dem Code für Nicht-Browser-Parser, Linters, HTML-Formatierer und viele andere Werkzeuge.
Es fühlt sich an, als gäbe es zwei Optionen: mehr deklarativen und lesbaren Code schreiben, der funktioniert, oder kleineren und flexibleren Code schreiben, der (vielleicht) auch funktioniert, und ich sehe darin keinen wirklichen Vorteil.
Ich habe diesen ganzen Weg hinter mir und erinnere mich sogar, schockiert gewesen zu sein, als ich sah, dass
<option>geschlossen werden konnte!Und ich stimme zu, XHTML war ein bisschen zu viele Einschränkungen, aber es hat meiner Meinung nach viel Gutes für HTML getan. Es brachte saubereren Code, weniger Interpretationsspielraum und mehr Konsistenz.
Browser sind extrem tolerant, aber das bedeutet nicht, dass wir diese Grenzen ausreizen müssen. Sie bringen so gut wie nichts außer einem leichteren Code (was immer noch wichtig ist, aber bedenken Sie, dass Sie daneben auch JS-Bibliotheken ausliefern...).
Konsistenz ist definitiv der Schlüssel. Machen Sie, was Sie wollen, aber bleiben Sie zumindest konsistent!
Guter Artikel. Ich habe mir darüber nicht wirklich viele Gedanken gemacht. Das ist Ihr Punkt. :-)
Eine Anmerkung zur englischen Syntax: „Documents may not be well-formed“ ist eine mehrdeutige Konstruktion. Es klingt, als sei es illegal, wenn Dokumente wohlgeformt sind. Vielleicht „Documents need not be well-formed“ oder „Documents may be not-well-formed“.
Tolle Lektüre! Der Teil über das Nicht-Schließen von Tags erinnert mich stark an Leute, die ihr JavaScript ohne Semikolons schreiben. Ja, es funktioniert, aber ich halte es für barbarisch ;-)
Minimalismus ist nicht immer die beste Idee. Ich gebe gerne die zusätzlichen Bytes für die Lesbarkeit (und damit die Wartbarkeit) des Codes eines Projekts aus. Das gilt für HTML ebenso wie für CSS und JS.
Es ist möglich, einen Minifier während des Builds einzurichten, sodass Sie Ihren XHTML-HTML im Repository behalten und nur sauberen HTML-HTML ausliefern können – das habe ich getan und bin glücklich ;)
Es gibt jedoch eine wichtige Überlegung, die Sie beachten sollten.
Ist nicht semantisch dasselbe wie
Im zweiten Fall ist das Bild technisch gesehen Teil eines Absatzes. Es kann auch Ihre Darstellung beeinträchtigen, wenn Sie nicht vorsichtig sind.
Super! Persönlich gilt: Je weniger Sie schreiben, desto besser!
Respektvoll muss ich sagen, dass „strikte“ Konventionen zu besser lesbarem Code führen. Den Code so weit zu minimieren, dass unklar ist, was er tut, mag ein paar Bits einsparen, aber nur auf Kosten der Lesbarkeit.
Für mich ergibt XHTML viel mehr Sinn; nicht weil es XML-kompatibel ist (obwohl das ein riesiger Vorteil ist!), sondern weil es bedeutet, dass es eine Handvoll Regeln gibt, die man konsequent befolgen kann, um gültigen Code zu haben. Wenn man anfängt zu sagen: „Eigentlich braucht HR kein (Selbst-)Schließungs-Tag“, dann muss man sich eine Liste merken: „Die Regeln gelten für diese Dinge, aber nicht für diese Dinge, es sei denn, Sie sind in diesem Kontext, in dem Fall müssen Sie vielleicht auch dies tun…“; d. h. unnötige Verwirrung und Komplexität statt einfacher Konsistenz.
Es gibt einige Dinge am XHTML-Ansatz, die schlecht sind; z. B. ist
'readonly="readonly"'eine Tautologie; warum nicht'readonly="true"'… Nur'readonly'hinzuzufügen ist irgendwie in Ordnung (es ist weniger wortreich, und wenn der Standard immer falsch ist, ist es klar), aber auch das ist inkonsistent, daher würde ich lieber den Aufwand betreiben, dass es etwas gleich ist, als nur den Attributnamen dort zu haben.Ich frage mich auch, wie viele Stunden weltweit in HTML-Design-Diskussionen für jedes Element/Attribut investiert werden, die eingespart werden könnten, indem man sagt: „Folgen wir einfach der allgemeinen Regel“, was Zeit für produktivere Diskussionen über die Schaffung neuer Funktionalität / Wertschöpfung ermöglicht.
Schöne Übersicht über XHTML und HTML,
ein fehlendes Element, das erwähnt werden sollte, ist die „harte Hierarchie“ einer XHTML-Seite durch die Code-Struktur.
Tags können sich in XHTML nicht überschneiden
Text A
Text B
[ Aufgrund von Regeln kann ich das Überschneiden von Tags nicht mit dem fettgedruckten Tag in HTML und XHTML demonstrieren ].
Text A und Text B könnten in HTML „fett“ angezeigt werden, in XHTML jedoch nicht. Es ist ein geringer Verlust für ein effektives Stilwerkzeug.
Eine erforderliche Einschränkung in Ihren Seiten: die Doctyp-Deklaration. Da Sie sie nicht schreiben, geht Ihre Seite in den „quirk mode“, ein großartiges Werkzeug für alle Codes in Ihrem Browser.
Im „quirk mode“ kann niemand XHTML oder HTML bevorzugen, wegen der verbleibenden Anzeige Ihrer Seiten.
Es ist eine große offene Tür für alle arbeitenden Coder, Anfänger oder Experten. Es ist flexibler Code, geschrieben und gelesen.
Sie können mit HTML/XHTML spielen, indem Sie Tags in der Mitte löschen und sehen, wie die Anzeige und das Rendering so gut wie möglich funktionieren. (Es ist permissiv, nicht wohlgeformt, aber quirk mode).
XHTML hat den SGML-Stil weitgehend entfernt und verwendet offene und schließende Tags vorne, sodass die Lesbarkeit einfach ist (auch wegen des Anfangs und Endes von „Codebereichen“).
Einzelne Tags dann erforderlich /: “” wie ein Abschluss.
XHTML ist im Grunde die Basis für die Integration von „XML-Daten“, es ist ein Layout für XML-Unterstützung von Anfang an und alle XML-Derivate.
Browser heute verarbeiten viele Arten zu codieren!
Großbuchstaben sind ruhig! WIRKLICH!
Danke für Ihre Arbeit.
Ich bleibe bei der XHTML-Art, danke. Die ursprüngliche Idee, Schludrigkeit zur Sprache des Webs zu machen, unterstütze ich nicht. Als Fan von Pipelines und Maschinenlesbarkeit bevorzuge ich die Konsistenz und Kompatibilität von XHTML. Das Einzige, was ich von der HTML-Art vermisse, ist die Attributminimierung.
Eines habe ich in 30 Jahren Programmierung gelernt: Code sollte immer so einheitlich wie möglich sein.
Konsistenz ist viel einfacher als Sonderregeln. Ich möchte mir nicht merken müssen, welche Tags geschlossen werden müssen. Ich möchte nicht nach potenziell falscher Syntax Ausschau halten. Warum sollte jemand Großbuchstaben-Tags schreiben wollen? Lesbarkeit? Dafür ist Syntaxhervorhebung da.
Allgemeine Regeln bedeuten weniger Belastung für Ihr Gedächtnis. Weniger Entscheidungen zu treffen. Weniger Fehler.
Jedes Mal, wenn Sie Sonderregeln haben, müssen Sie diese neuen Teammitgliedern erklären, und sie werden sie falsch machen. Jedes einzelne Mal.
Obwohl im Prinzip reines HTML schlanker und sauberer ist, macht es in der Realität viele Annahmen. Um es richtig zu validieren, muss man alle möglichen Elemente und ihre optionalen Regeln kennen, einschließlich browserspezifischer Erweiterungen. Andernfalls bleiben wir mit dem Chaos von früher zurück, als die meisten Browser sehr nachsichtig mit dem damals weit verbreiteten, furchtbar fehlerhaften HTML sein mussten. Browser versuchten, alle Probleme zu beheben, indem sie raten, was der Autor meinte, was nicht immer korrekt war. Zumindest mit einer korrekten XML-Formatierung kann jedes Dokument strukturell validiert/interpretiert werden, ohne spezielle Regeln kennen zu müssen (im Guten wie im Schlechten). Und obwohl die Verwendung von Erweiterungselementen nicht mehr so schlimm ist wie vor den Standards HTML4/5, muss sie immer noch berücksichtigt werden.
Obwohl ich persönlich das Vertrauen verloren habe, sobald sie nur noch „html“ als Sammel-DOCTYPE für den Standard verwendet haben (und nicht zumindest „html5“).
Weniger ist mehr – weniger Code = schneller für Front- und Backend.
Es ergab für mich nie Sinn, schließende Tags bei Listen hinzuzufügen – also habe ich es nicht getan. Auch habe ich den Backslash für br- oder hr-Tags nicht hinzugefügt.
Es macht immer noch keinen Sinn, strong gegenüber b für fett oder em gegenüber i für kursiv zu verwenden.
Es gibt noch mehr wie diese meiner Meinung nach. Oder ist es MEINER Meinung nach. LOL
Mein Gott, ich habe so viel Zunder in einem Discord-Kanal bekommen, weil ich mich hinauswagte und meine Tags nicht mehr schloss. Mein Code war immer noch perfekt validiert. Der Missbrauch – von einer hysterischen Menge, also bin ich einfach gegangen. Danke für den Artikel. Ich liebe semantisches HTML. Und aus den alten Zeiten von XHTML… (war 5 Jahre vom Webdesign weg) habe ich bewusst beschlossen, jetzt keine Tags mehr zu schließen, wenn sie nicht benötigt werden – um mehr darauf zu achten. Ich wusste nichts von den Anführungszeichen, die werde ich auch entfernen. Ich validiere mein HTML immer, immer.