Wir können Ballmer für diesen halb verrückten Nervenzusammenbruch verspotten, aber seine Botschaft traf ins Schwarze. Wenn Sie Entwicklern nicht die Tools und Kenntnisse vermitteln, die sie für die Arbeit mit Ihrem System benötigen, treten nicht nur Schwierigkeiten auf, sondern sie können auch nicht entwickeln, woran Sie arbeiten!



Leider sehen wir in der Praxis, dass in dieser Hinsicht die Entwickler selbst ihre schlimmsten Feinde sein können. Sie wählen schreckliche "Frameworks", die sie härter arbeiten lassen als klüger, oder sie stellen absichtlich ihre Unkenntnis der Grundlagen zur Schau und kopieren den Code eines anderen in der Hoffnung, dass er die erforderliche Aufgabe erfüllt.



In keinem anderen Bereich ist dies offensichtlicher als in einer arroganten, gleichgültigen, wenn nicht geradezu verächtlichen Haltung gegenüber HTML. Es gibt keine Grenze für endlosen Unsinn und falsche Aussagen von denen, die nicht in der Lage sind, eine einzige Zeile in dieser Sprache zu schreiben.



Kurz gesagt, Entwickler nehmen HTML nicht ernst genug, aber was passiert, wenn Sie sie auf ihre Schwäche hinweisen? Als Antwort werden wir nur auf einen endlosen Strom bedeutungsloser Ausreden warten, warum sie nicht durch die korrekte Umsetzung abgelenkt werden sollten!

Liste der schwachen Ausreden

"HTML ist keine echte Programmiersprache"

Es ist eine Folge von Befehlen, denen Computer folgen, um eine Aufgabe auszuführen. Wenn es eine andere Definition einer Programmiersprache gibt, dann habe ich sie in vier Jahrzehnten des Schreibens von Software nicht gehört. Ist von Turing komplett? Nein ... aber es sagt dem Computer trotzdem, wie er die grammatikalische und strukturelle Bedeutung des Inhalts maschinenunabhängig vermitteln kann. Es gibt Regeln für die Verwendung der Tags, der Reihenfolge und der Syntax.

"Niemand kümmert sich um den Code, wenn er für den Benutzer richtig aussieht."

Genau bis zu dem Moment, in dem Sie auf blinde Benutzer stoßen. HTML ist nicht nur das, wie die Seite aussieht ... Nein! Ich werde es beheben - Bei HTML geht es nicht darum, wie etwas überhaupt aussieht. HTML wird benötigt, um zu kommunizieren, was die Elemente in Bezug auf Grammatik und Struktur sein sollten, damit der Benutzeragent dem Benutzer diesen Wert vermitteln kann. Wir haben also CSS, um zu beschreiben, wie die Elemente aussehen sollen . Wenn eines Ihrer Tags, IDs oder Klassen angibt, wie die Elemente aussehen sollen, haben Sie den falschen Code basierend auf den falschen Annahmen ausgewählt.



Screenreader (Software zum Vorlesen einer Seite), Braille-E-Books, TTYs… all dies sind nicht visuelle Ziele. und vergessen Sie nicht, dass Suchmaschinen auch keine Augen haben. Es ist ihnen sogar egal, wie Ihre Seite "aussieht".



Darüber hinaus ist es für Personen wichtig, dass das Hosten Ihrer Seite langsamer oder teurer ist, oder dass sie gegen die Richtlinien zur Barrierefreiheit für Menschen mit Behinderungen verstößt oder den gesamten verfügbaren Kanal verstopft. Nicht-semantisches Markup , endlose und bedeutungslose DIVs, die nichts tun, Präsentationsklassen - sie alle summieren sich und beeinflussen das Ergebnis!



Sie werden die gleichen Ausreden für viele andere Aspekte der Webentwicklung hören, und es ist fast immer eine Lüge. Ob es sich um eine schlechte / fehlerhafte Semantik handelt, um Zugänglichkeitsprobleme für Menschen mit Behinderungen, aufgeblähtes optionales JS, Verwendung von "Webanwendungstechnologien" für Dinge, die keine Anwendung sein sollten usw. usw.



Sehr oft merkt der Benutzer bei alledem, dass etwas nicht stimmt, kann es aber nicht erklären. Benutzer sind keine Programmierer, sie wissen nicht, was der Fehler ist und wer dafür verantwortlich ist, aber sie haben das Gefühl, dass etwas nicht stimmt, alles ist zufällig.



Was ist mit dem nächsten unglücklichen Verlierer, der das Ergebnis Ihrer Arbeit unterstützen muss, das alle Fehler aus der Liste enthält, wie man HTML NICHT verwendet? Die Leute unterhalten sich immer darüber, wie ihr schrecklich kaputtes "Framework" "uns helfen soll, zusammenzuarbeiten". Wie kann die zwei- oder zehnfache Menge an Code, die nicht den Grundregeln von HTML entspricht und den eigentlichen Zweck der Sprache verletzt, die Zusammenarbeit verbessern?

"Aber Beispiele in Frameworks funktionieren genau so und wurden von Experten geschrieben."

Sie sind keine Webentwicklungsspezialisten. Sie sind vielmehr Spezialisten für Marketing, Propaganda und Täuschung. Markups in Beispielen für Systeme wie Bootstrap und Tailwind sind Alptraum-HTML-Praktiken. Sie stinken nach einer schrecklichen Mischung aus „Ich möchte kein HTML und CSS lernen“ und „Ich vermisse das Markup der neunziger Jahre“ und geben über zwanzig Jahre Fortschritt auf. Nur weil sie von Millionen von Websites verwendet werden ("die Mehrheit kann sich nicht irren") und selbsternannte Experten sie loben (Appell an die Autorität), sind sie oder ähnliche Praktiken nicht gut.

"Es ist schwieriger, mit Vanille-Code zu arbeiten."

Du machst es schwierig. Hier ist das Problem: Indem Sie die semantischen Regeln der Strukturierung und den Sinn des HTML-Zwecks ignorieren, erschweren Sie die Arbeit. Dazu trägt die Tatsache bei, dass Noob-Köder wie W3Schools (auch bekannt als W3fools) mit ungenauen Informationen, vulgären Vereinfachungen und dem völligen Fehlen der meisten Grundkonzepte von HTML überfüllt sind .



Inhalt sollte das Markup definieren, Inhalt + Markup + Zielumgebung / Benutzeragentenfunktionen sollten die Struktur definieren. Wenn Sie der grundlegenden Semantik folgen und die korrekte Trennung der Funktionen schrittweise verbessern und verwenden, erhalten Sie eine Reihe von Anweisungen, mit denen Sie einfach zu wartende Seiten erstellen können. Wenn Sie Probleme damit haben und der Meinung sind, dass diese "HTML / CSS-Frameworks" Ihnen das Leben erleichtern, kennen Sie nicht genug HTML oder CSS, um eine der Aufgaben zu erledigen.



Im Allgemeinen ist Rückenwind einfacher als Vanille-HTML / CSS. Sie müssen lediglich über 500 Klassen lernen, von denen 90% bereits als CSS-Eigenschaften vorhanden sind, und dann fast alle Regeln für die Verwendung von HTML ignorieren!



Falls Sie es nicht verstanden haben, war es Sarkasmus.

"Sie legen zu viel Wert auf HTML"

Ich höre diesen Unsinn die ganze Zeit und ärgere mich über seine Kurzsichtigkeit!



Es ist, als würde ich sagen, dass ich dem Boden unter der Baustelle oder den Materialien, aus denen das Fundament besteht, zu viel Aufmerksamkeit schenke. Wenn Sie solche Details vernachlässigen, wundern Sie sich nicht, dass dann alles auf "unverständliche Weise" zusammenbricht oder in ein Karstloch gesaugt wird!



HTML ist das Fundament und der Eckpfeiler. Wenn Sie es vernachlässigen, wundern Sie sich nicht, dass das Ergebnis eine völlige Katastrophe sein wird.



In der Tat unterscheiden sich viele der Missverständnisse, mit denen sich Webentwickler davon überzeugen, sich keine Sorgen um die Zukunft zu machen, nicht von denen, die zu allen technischen Katastrophen führen. Qualitätsersparnis, Ignorieren von Spezifikationen oder des Endbenutzers, Tanken Ihres eigenen Ego; Außerdem machen viele einen fatalen Fehler - sie verwechseln Kunst mit Design.



Der letztere Fehler führt zu Gebäuden, die Menschen mit dem von ihren Fenstern reflektierten Sonnenlicht blenden: Jemand, der sich als Künstler vorstellt, überzeugt Menschen in Kostümen, Milliarden für ein Projekt auszugeben, bei dem Form wichtiger ist als Funktion.

"Aber HTML bietet uns nicht die Tools, die wir für die Bereitstellung von UX benötigen."

Es gibt viele verschiedene Versionen dieser Ausrede, aber im Allgemeinen implizieren sie das Obige. Diejenigen, die dies sagen, beziehen sich fast immer auf Fans von "Webanwendungen" oder "Einzelseitenanwendungen", sie versuchen, JavaScript überall zu verwenden, sie kümmern sich nicht um die Zugänglichkeit für Menschen mit Behinderungen und bestehen darauf, dass "Benutzer" irgendwie "alle" "brauchen" ihre ausgefallenen Sachen, um die "Benutzererfahrung" zu verbessern.



Aber um ganz ehrlich zu sein, wissen diese Clowns so viel über UX wie Künstler, die in die Illusion geraten sind, "Webdesigner" zu sein, über Design Bescheid wissen.



Und Sie können die Ergebnisse ihrer Arbeit JETZT in unserer gesamten Branche sehen: fragile, geschwollene, langsame Lösungen, die "die Skripterstellung verbessern können", verlangsamen die Warenkorbsysteme von Online-Shops so sehr, dass viele von ihnen nicht einmal in der Lage sind, die Verfügbarkeit aufrechtzuerhalten (Hallo Zotac) ; Gleichzeitig drücken die Benutzer heftig auf F5, in der Hoffnung, dass sie weiterhin eine Grafikkarte kaufen können. Durch das Neuladen der gesamten Seite und das erneute Ausführen des Skripts führen alle Funktionen der "Anwendung" nur zu einer REDUZIERUNG der Seitenladegeschwindigkeit. Und dies ist noch ausgeprägter, wenn Sie mit den Präsentationsklassen auf das Markup spucken.



Da Skripte deaktiviert werden können und von Skripten generierte Inhalte für Bildschirmleser, Braille-E-Books usw. schwieriger sind, verstoßen Single-Page-Anwendungen (SPA) gegen die Richtlinien zur Barrierefreiheit für Menschen mit Behinderungen.



Ich sage nicht, dass SPA und dergleichen keine sinnvollen Verwendungszwecke haben, aber wenn Sie keinen einfachen Warenkorb oder ein schnell ladendes Bankportal erstellen können, das durch das Deaktivieren von Skripten nur wenig verliert, sollten Sie wahrscheinlich keine Arbeit leisten Es ist ein Geschäft. Web-Apps sollten NICHT für etwas lächerlich Einfaches wie einen Einkaufswagen auf einer Website verwendet werden!



Und wenn Sie der Meinung sind, dass die Verwendung von Skripten die Benutzererfahrung wirklich verbessert, haben Sie das System offensichtlich nicht mit echten Benutzern und echtem Datenverkehr getestet! Zumindest haben sie keinen echten Vergleich der Aufgabenteilung unter Verwendung des Caches bei normalen Seitenladevorgängen und auf Seiten mit neuen Skripten durchgeführt.

Also ist der Webentwickler für alles verantwortlich?

Auf keinen Fall . Kehren wir zum Anfang des Artikels und zu Ballmers Schreien von "Entwicklern, Entwicklern, Entwicklern" zurück.



Als er seine kleine Skizze ausspielte, sollte sie das Problem lösen, dass Windows in den späten 90er Jahren keineswegs an erster Stelle stand, da Entwickler die von Microsoft bereitgestellten Tools häufig nicht verwendeten. Borland hat die beste Dokumentation für die Windows-API veröffentlicht. Die Leute verwendeten Tools, die nicht von Microsoft stammen, weil "visuelle" Sprachen als Spielzeug angesehen wurden. Sie waren so weit hinter den Webentwicklungstechnologien zurück, dass wir sagen können, dass sie immer noch versuchen, sie einzuholen!



Das W3C und das WhatWG haben ähnliche Probleme mit dem sogenannten"Spezifikationen" sind einfach nicht für die Leute geschrieben, die Websites schreiben. Lassen Sie mich wiederholen: Die Spezifikation der Sprache, die zum Schreiben von Websites verwendet wird, gilt nicht für Personen, die tatsächlich Websites schreiben . Es ist für Leute geschrieben, die User-Agents schreiben! Der Browser ist der Benutzeragent, aber die UA ist nicht immer der Browser.



Tatsächlich ist es so absurd, dass sich die idiotische Version von WhatWGs "dynamischem Dokument" auf MDN bezieht, um "bloße Sterbliche" zu verstehen.



: , « » (living document), HTML- . HTML 5, , HTML 5, HTML 5 ? !



Einfache Tatsache: Um Beschreibungen der Tag-Bedeutungen im Klartext zu erhalten, müssen Sie sich an Quellen von Drittanbietern wenden, von denen viele nicht einmal miteinander übereinstimmen. Darüber hinaus ist das W3C völlig zahnlos geworden und stimmt blind mit allem überein, was WhatWG sagt, obwohl WhatWG immer wieder bewiesen hat, dass es nicht qualifiziert ist, einen Nachkommen von HTML 4 Strict zu erstellen. Die Akzeptanz von EMBED als gültiges Tag, das Erstellen und / oder Verwalten von Tags, die im Vergleich zu OBJECT redundant sind, unterstützte (glücklicherweise) das HGROUP-Tag nicht mehr, was zeigte, dass sie nicht einmal verstanden, wofür nummerierte Header waren und wie sie verwendet werden. .. wer daran gearbeitet hat, die Herausforderung für HTML 5 bestand nie wirklich darin, eine Spezifikation oder einen Standard zu erstellen, der uns sagt, wie man nützliche Websites erstellt!Es ging darum zu dokumentieren, ob Menschen heute richtig oder falsch handeln und welche Browser kann unterstützen, aber nicht was sie unterstützen sollen ! Angesichts der Tatsache, dass die meisten Entwickler während der Entwicklung von HTML 5 immer noch HTML 3.2 einhämmerten und den perversen HTML 4-Doctype darüber kritzelten, warum sollte man sich wundern, dass sich herausstellte, dass alles eine solche Sammlung von schlechten, veralteten und altmodischen Praktiken war?



Wenn Entwickler HTML nicht ernst genug nehmen, sind diejenigen schuld, die es als "Spezifikation" entwickelt haben. Selbst HTML 5 zu nennen war ein so schweres Verbrechen gegen die Webentwicklung ... Genau wie ein Verbrechen gegen Musik Billie Eilish für ihre mittelmäßigen Kreationen einen Grammy verlieh.



W3C und WhatWG werden von anderen Normungsorganisationen aus gutem Grund nicht einmal ernst genommen.

Was sollte die Lösung sein?

Es wäre eine gute Idee, Entwickler dazu zu bringen, HTML nicht als unterentwickeltes Kind aus der Welt der Programmiersprachen wahrzunehmen. Insbesondere, um sie dazu zu bringen, semantisches Markup zu üben und Präsentation von Inhalt zu trennen, was die Benutzerfreundlichkeit, Zugänglichkeit und Effizienz erheblich verbessert.



Darüber hinaus haben wir selbst als Entwickler das Wort und verblüffen das W3C für das katastrophale Scheitern seiner Arbeit als Zertifizierungsstelle . Wir müssen von der offiziellen Quelle eine einfachere und sauberere Sprachdokumentation verlangen. Es kann nicht gerechtfertigt werden, dass ein Dokument, das etwas so Einfaches wie HTML beschreibt, fünf- bis zehnmal länger ist als die Verfassungen der meisten Industrieländer.Die Tatsache, dass die Spezifikation der Sprache, die zum Erstellen von Websites verwendet wird, nicht für Personen geschrieben wurde, die die Sprache zum Erstellen von Websites verwenden, ist ein Misstrauensvotum.



Wir brauchen jedoch mehr als nur eine verbesserte offizielle Dokumentation. Wir müssen die Sprache reduzieren und aufgabenorientierter gestalten. Beleben Sie viele der Ideen wieder, die in HTML 5 enthalten waren, bevor das W3C sie in den Papierkorb warf und die WhatWG-Version übernahm. Die Tatsache, dass Microsoft jahrzehntelang dafür gesorgt hat, dass der IE uns daran hindert, OBJECT zu verwenden, ist nicht nur ein Grund, das IMG-Tag beizubehalten, sondern auch unnötig viele neue Tags hinzuzufügen (VIDEO, AUDIO). Nur weil "Künstler" und Marketing-Gauner dem Benutzer gerne neue Fenster öffnen, ob er es mag oder nicht, ist dies noch kein Grund für die Aufnahme der Spezifikation TARGET="_BLANK"



...



Darüber hinaus sollten die EXPLICIT-Verwendung und die Bedeutung von Tags in den Mittelpunkt der Spezifikation gestellt werden , und möglicherweise sogar in einem separaten Verwendungsleitfaden für diejenigen, die noch im Jahr 1997 leben.



Es ist keine große Sache, eine einfachere, sauberere und nützlichere Version von HTML zu erstellen, die uns alle anleitet.



Darüber hinaus ist es für uns hilfreich, wenn die Browserentwickler beim Erstellen weniger Gewicht haben. Microsoft, Mozilla, Apple und Google haben einen enormen Einfluss auf W3C und WhatWG, und dies ist völlig unethisch. Ihr Gewicht bei der Entscheidungsfindung widerspricht dem Konzept eines freien und offenen Webs.

---

Werbung

Epic Server sind VDS für das Hosting von Websites von einem kleinen Online-Shop auf Opencart bis hin zu ernsthaften Projekten mit einem großen Publikum. Erstellen Sie mit wenigen Klicks Ihre eigenen Serverkonfigurationen!



Nehmen Sie an unserem Telegramm-Chat teil .