Tatsächlich sprechen einige Leute über normative Inhalte. Steve Faulkner spricht über HTML5 und Barrierefreiheit. Paul Irish wird über die verschiedenen APIs sprechen, die HTML5 bietet. Deshalb werde ich, wenn ich heute hier stehe, nicht nur über HTML5 reden und Schluss machen.
Um ehrlich zu sein, möchte ich, bevor ich offiziell anfange, klar erklären, was ich unter HTML5 verstehe. Das klingt ein bisschen komisch: Sie reden schon seit einiger Zeit über HTML5, wissen wir nicht immer noch, was HTML5 ist? Wie Sie alle wissen, gibt es eine Spezifikation mit dem Namen HTML5. Was ich mit HTML5 meine, ist diese Spezifikation. Das Problem ist jedoch, dass manche Leute, wenn sie von HTML5 sprechen, nicht nur diese Spezifikation meinen, sondern auch etwas anderes meinen. Beispielsweise ist die Verwendung von HTML5 zur Bezugnahme auf CSS3 ein gebräuchlicher Name. Das bin nicht ich. Was ich HTML5 nenne, beinhaltet kein CSS3, es ist HTML5.
Ähnliche Terminologieprobleme sind bereits aufgetreten. Ajax war ursprünglich eine Technologie mit einer klaren Bedeutung, aber nach einer Weile wurde ihre Bedeutung zu „JavaScript verwenden, um all die lustigen Dinge zu tun“. Das ist Ajax, oder? Heutzutage steht HTML5 vor dem gleichen Problem. Es bezog sich ursprünglich auf eine bestimmte Spezifikation, aber jetzt bedeutet es „alle lustigen Dinge im Web tun“. Ich spreche nicht nur von diesem HTML5, das nur die neuesten Dinge abdeckt erschien in HTML5. Ich spreche nur von der Spezifikation selbst: HTML5.
Wie ich gerade sagte, möchte ich heute nicht viel reden und ich habe nicht vor, vorzustellen, was HTML5 beinhaltet. Worüber ich heute sprechen möchte, ist ein weiterer Aspekt, das Design von HTML5. Mit anderen Worten: Worüber ich sprechen möchte, ist nicht, was in der Spezifikation enthalten ist, sondern warum es in der Spezifikation enthalten ist und wie Designer diese Dinge beim Entwurf dieser Spezifikation betrachtet haben.
Designprinzip
Das Designprinzip ist im Wesentlichen ein Glaube, eine Idee und ein Konzept, die das Rückgrat Ihres Handelns bilden. Egal, ob Sie eine Spezifikation entwickeln, ein konkretes Objekt bauen, Software schreiben oder sogar eine Programmiersprache erfinden. Dahinter können ein oder mehrere Designprinzipien stecken, und jedes Ergebnis der Zusammenarbeit mehrerer Personen ist ein Beispiel. Dies ist nicht nur in der Webentwicklung der Fall. Im Laufe der Menschheitsgeschichte gibt es auch Gestaltungsprinzipien, die großen Bauaktivitäten wie Ländern und Gesellschaften zugrunde liegen.
Nehmen Sie die Vereinigten Staaten als Beispiel. Die Gestaltungsprinzipien der Vereinigten Staaten sind alle in der Unabhängigkeitserklärung niedergeschrieben.
Wir halten diese Wahrheiten für selbstverständlich, dass alle Menschen gleich geschaffen sind und dass jeder Mensch von seinem Schöpfer mit unveräußerlichen Rechten ausgestattet ist, einschließlich Leben, Freiheit und dem Streben nach Glück.
Hier ist ein Slogan: Überleben, Freiheit und das Streben nach Glück. Dies ist der in der Verfassung verankerte Kerngedanke, der alles an uns betrifft, das Prinzip, auf dem wir unsere Gesellschaft aufbauen.
Ein weiteres Beispiel ist Karl Marx, dessen Werke als Leitfaden für den Aufbau des Sozialismus im 20. Jahrhundert galten. Die Grundidee lässt sich grob als folgendes Gestaltungsprinzip zusammenfassen:
Jeder tut, was er kann, und jeder bekommt, was er braucht.
Das ist eigentlich das Gestaltungsprinzip eines Wirtschaftssystems.
Es gibt ein weiteres Beispiel, das eine längere Geschichte hat als die beiden vorherigen, aber ähnlich ist:
Jeder für einen und einer für alle.
Dieses äußerst einfache Designprinzip wurde vor zweitausend Jahren von Jesus Christus, einem Juden aus Nazareth, vorgeschlagen. Dieses Prinzip wurde zur Kernlehre vieler nachfolgender Religionen. Prinzipien und Praxis stimmen manchmal nicht überein.
Hier ist ein Beispiel aus dem Roman. „Animal Farm“ des britischen Schriftstellers George Orwell ist eine virtuelle Gesellschaft, die auf einem Designprinzip basiert. Dieses Designprinzip lautet:
Jeder mit vier Beinen ist ein guter Kerl, und jeder mit zwei Beinen ist ein böser Kerl!
Das Interessante an „Animal Farm“ ist, dass sich mit der Veränderung und Verschlechterung der Gesellschaft auch dieses Gestaltungsprinzip ändert und zu „Jeder mit vier Beinen ist ein guter Mensch, und wer zwei Beine hat, ist ein guter Mensch.“ Das Wichtigste ist, dass auch in fiktionalen Werken die Gestaltungsprinzipien vorhanden sind.
Es gibt auch eine Reihe fiktiver Werke, die auf drei Designprinzipien basieren, nämlich die Roboterklassikerserie des berühmten amerikanischen Schriftstellers Isaac Asimov. Asimov erfand den Begriff Robotik, schlug die drei Gesetze der Robotik vor und schuf dann eine Reihe klassischer Werke – etwa 50 Bücher – basierend auf diesen drei einfachen Gestaltungsprinzipien. Unabhängig davon, wie sich die Handlung des Werks ändert, werden diese drei Gestaltungsprinzipien tatsächlich aus verschiedenen Blickwinkeln erläutert. Ich denke, jeder hier sollte mit den drei Robotergesetzen vertraut sein.
Roboter dürfen Menschen nicht schaden oder zusehen, wie Menschen zu Schaden kommen.
Roboter müssen menschlichen Befehlen gehorchen, es sei denn, der Befehl verstößt gegen das Erste Gesetz.
Roboter müssen sich verteidigen, solange sie nicht gegen das erste und zweite Gesetz verstoßen.
Dies sind wahrscheinlich die ersten Software-Designprinzipien, die in Romanen auftauchen. Obwohl die auf diesen drei Designprinzipien basierende Software im „Positronengehirn“ des fiktiven Roboters läuft, denke ich, dass dies de facto der Beginn der Softwaredesignprinzipien sein sollte. Seitdem haben wir die Designprinzipien einer Vielzahl hervorragender Software kennengelernt.
Tim Berners-Lee, der Erfinder des Web, veröffentlichte auf der W3C-Website ein Dokument, einschließlich einer URL, die seine eigenen Designprinzipien enthielt. Es gibt nicht nur viele dieser Designprinzipien, sondern er wird sie im Laufe der Zeit auch weiterhin hinzufügen, ändern und löschen. Dennoch halte ich es für eine gute Idee, die Gestaltungsprinzipien, mit denen man einverstanden ist, aufzuschreiben und irgendwo abzulegen.
Tatsächlich hat Bert Bos, einer der Erfinder von CSS, auch ein Dokument auf der W3C-Website veröffentlicht, in dem es um grundlegende Designprinzipien geht, beispielsweise darum, wie man ein Format entwirft und erstellt, sei es CSS oder nicht. Ich empfehle jedem, einen Blick darauf zu werfen.
Solange Sie beiläufig auf der W3C-Website suchen, können Sie viele solcher Designprinzipien finden, darunter auch die persönlichen von Tim Berners-Lee. Natürlich werden Sie auch einige Slogans sehen, die er von Software-Engineering-Schulen übernommen hat: Dezentralisierung, Toleranz, Einfachheit, Modularität. Das waren die Schlüsselwörter, die ihm bei der Erfindung neuer Formate ständig im Kopf herumschwirrten.
Jeder hier ist mit den Beiträgen von Tim Berners-Lee bestens vertraut, weil wir sie täglich verwenden. Er hat das Web erfunden, er hat das Web gemeinsam mit Robert Cailliau erfunden, und als er das Web erfunden hat, hat er auch die Sprachen erfunden, die wir jeden Tag im Web verwenden. Natürlich handelt es sich bei dieser Sprache um HTML: Hypertext Markup Language.
HTML
HTML begann erstmals mit Version 2.0. Es gab noch nie die Version 1.0. Wenn Ihnen jemand erzählt, dass er mit der Verwendung von HTML erstmals ab HTML 1.0 begonnen hat, lügt er Sie definitiv an. Es gab tatsächlich ein Dokument namens HTML Tags, und einige der darin enthaltenen Tags werden noch heute verwendet, aber dieses Dokument ist keine offizielle Spezifikation.
Die Verwendung von Tags, spitzen Klammern, p oder h1 usw. war keine Idee von Tim Berners-Lee. Diese Konzepte existierten zu dieser Zeit in SGML, und CERN (Conseil Europeanen pour la Recherche Nucleaire) verwendete zu dieser Zeit ebenfalls eine bestimmte Version von SGML. Mit anderen Worten: Er fing schon damals nicht bei Null an, sondern spiegelte sich auch in der späteren Entwicklung von HTML wider: die Vergangenheit fortführen und die Zukunft eröffnen, anstatt ein neues Unternehmen zu gründen und bei Null anzufangen.
Mit anderen Worten: Dieses Dokument mit dem Namen „HTML-Tags“ kann als erste Version von HTML gezählt werden, es handelt sich jedoch nicht um eine offizielle Version. Die erste offizielle Version, HTML 2.0, wurde nicht vom W3C erstellt. HTML 2.0 wurde von der IETF, Internet Engineering Task Force, entwickelt. Vor der Gründung des W3C hatte die IETF zahlreiche Standards herausgegeben. Doch ab der dritten Version übernahmen W3C und das World Wide Web Consortium die Verantwortung und waren für die Entwicklung der Folgeversionen verantwortlich.
HTML erlebte in den 1990er Jahren mehrere rasante Entwicklungen. Wie wir alle wissen, war der Aufbau einer Website zu dieser Zeit ein sehr kompliziertes Projekt. Früher bereiteten die Browserkriege Kopfschmerzen. Das Ergebnis des Marktwettbewerbs ist, dass jeder Browser mit verschiedenen proprietären Funktionen ausgestattet ist und alle versuchen, sich gegenseitig in Bezug auf proprietäre Funktionen zu übertreffen. Die Verwirrung damals war unerträglich und niemand konnte sagen, ob HTML noch wichtig war oder wie seine Zukunft als Webformat aussah.
Von 1997 bis 1999 erlebte die HTML-Version eine sehr schnelle Entwicklung von 3.2 über 4.0 bis hin zu 4.01. Das Problem ist, dass sich das Verständnis des W3C zum Zeitpunkt von 4.01 verschlechtert hatte. Sie sagten: „Okay, das ist es für diese Version und das ist es für HTML; HTML 4.01 ist die letzte Version von HTML, und wir brauchen es nicht.“ „
Das W3C hat nicht aufgehört, die Sprache weiterzuentwickeln, es ist nur nicht mehr an HTML interessiert. Nach HTML 4.01 wurde XHTML 1.0 entwickelt. Obwohl sie völlig unterschiedlich klingen, sind XHTML 1.0 und HTML 4.01 tatsächlich gleich. Ich meine, im wahrsten Sinne des Wortes ist der Inhalt beider Spezifikationen gleich, das Vokabular ist gleich, alle Elemente sind gleich, alle Attribute sind gleich. Der einzige Unterschied besteht darin, dass XHTML 1.0 die Verwendung der XML-Syntax erfordert. Mit anderen Worten: Alle Attribute müssen Kleinbuchstaben verwenden, alle Elemente müssen ebenfalls Kleinbuchstaben verwenden, alle Attributwerte müssen in Anführungszeichen gesetzt werden und Sie müssen daran denken, schließende Tags zu verwenden. Denken Sie daran, selbstschließende Tags für img und br zu verwenden.
Vom Inhalt der Spezifikation selbst her ist es eigentlich dasselbe, es gibt keinen Unterschied. Der Unterschied liegt im Codierungsstil, denn für den Browser ist das Lesen von Webseiten, die den Spezifikationen HTML 4.01, HTML 3.2 oder XHTML 1.0 entsprechen, kein Problem. Für den Browser sind diese Webseiten gleich und generieren das gleiche DOM . Baum. Es ist nur so, dass die Leute XHTML 1.0 bevorzugen, weil viele Leute mit seinem strengeren Codierungsstil einverstanden sind.
Im Jahr 2000 waren die Aktivitäten des Web Standards Project (Web Standards Project) in vollem Gange, und die Entwickler hatten genug von der Unordnung proprietärer Funktionen in Browsern. Alle waren sehr wütend und schimpften mit den Browserherstellern: „Ist es wirklich so verdammt schwierig, eine Spezifikation einzuhalten?“ CSS hatte damals große Fortschritte gemacht und war im Grunde auch eng mit XHTML 1.0 CSS und XHTML 1.0 integriert kann als „Best Practice“ angesehen werden. Obwohl sich HTML 4.01 meiner Meinung nach nicht grundlegend von XHTML 1.0 unterscheidet, wird es von allen akzeptiert. Professionelle Entwickler können alle Elemente in Kleinbuchstaben, Attribute in Kleinbuchstaben und Attributwerte in Anführungszeichen setzen: Da Profis eine Vorbildrolle spielen, beginnen immer mehr Menschen, diese Syntax zu unterstützen.
Ich bin ein Vorbild! Ich verwende den Dokumenttyp XHTML 1.0 seit 10 Jahren und der Grund dafür ist, dass mir Validatoren sehr helfen, oder? Solange ich XHTML 1.0 schreibe und es mit einem Validator teste, kann es mir sagen, ob ich vergessen habe, einen Attributwert anzugeben, ob ich ein Tag nicht geschlossen habe usw. Und wenn ich HTML 4.01 schreibe, tritt das gleiche Problem auf, und der Validator wird mich nicht unbedingt daran erinnern.
Aus diesem Grund verwende ich XHTML 1.0. Ich denke, viele Leute sind... Freunde, die XHTML 1.0 verwenden, bitte heben Sie Ihre Hand. OK Was ist mit HTML 4.01? Es sind viel weniger Menschen da. Diejenigen unter Ihnen, die Ihre Hand nicht gehoben haben, sprechen Sie bitte lauter: Was verwenden Sie? HTML5, auch gut! Was ist mit früheren Dokumententypen? es ist keiner mehr übrig?
Ich verwende XHTML 1.0 seit 10 Jahren, weil mir Validatoren wirklich helfen. Benutzt jemand XHTML 1.1? Kennen Sie jemanden, der es verwendet? Bitte heben Sie Ihre Hände und legen Sie sie nicht ab. Hat jemand Webseiten als XML-Dokumente markiert? Gibt es welche? Dann verwenden Sie nicht XHTML 1.1.
Das ist ein großes Problem. Auf XHTML 1.0 folgte XHTML 1.1, mit der Ausnahme, dass der Zahl nach dem Dezimalpunkt eine 1 hinzugefügt wurde, und aus vokabularer Sicht gab es in der Spezifikation selbst nichts Neues, die Elemente waren dieselben und auch die Attribute waren dieselben . Aber mit XHTML 1.1 besteht die einzige Änderung darin, dass Sie Ihre Dokumente als XML-Dokumente kennzeichnen müssen. Wenn Sie XHTML 1.0 verwenden, können Sie das Dokument auch als HTML markieren, und genau das haben wir getan, andernfalls könnte die Markierung des Dokuments als XML die Leute verrückt machen.
Warum sagst du das? Erstens kann Internet Explorer das Dokument nicht verarbeiten, nachdem es als XML markiert wurde. Natürlich kann IE9 damit umgehen. Ich fürchte, einige Leute werden sagen: „Es ist so süß“, aber sie haben es immer noch nicht vergessen. Das Schiff hat endlich angedockt! Aber zu diesem Zeitpunkt konnte IE als weltweit führender Browser das empfangene Dokument vom Typ XML-Dokument nicht verarbeiten, und die Spezifikation erforderte, dass Sie das Dokument als XML-Dokumenttyp senden mussten, was die Leute verrückt machen würde.
XHTML 1.1 entspricht also etwas der Realität und Sie möchten aufgrund des Fehlerbehandlungsmodells von XML keine Dokumente im XML-Format an Browser senden, die XML verstehen können. Die Syntax von XML, egal ob es sich um Kleinbuchstaben-Attribute, Kleinbuchstaben-Elemente oder immer das Hinzufügen von Anführungszeichen zu Attributwerten handelt, ist kein Problem, alles ist gut, tatsächlich mache ich das auch gerne, aber das Fehlerbehandlungsmodell von XML ist ähnlich Dies: Parsing Wenn der Server auf einen Fehler stößt, stoppt er das Parsen. So steht es in der Spezifikation. Wenn Sie XHTML 1.1 als XML-Dokumenttyp markieren, gehen Sie davon aus, dass Sie das Dokument in Firefox öffnen und es ein kaufmännisches Und (&) im Dokument gibt, das nicht korrekt codiert ist, selbst wenn dies der einzige Fehler auf der gesamten Seite ist, was Sie tun werden Wenn Sie einen gelben Bildschirm sehen, ist der Browser tot. Firefox sagt: „Es ist nicht mehr möglich. Es liegt ein Fehler auf der Seite vor. Sie können diese Webseite nicht sehen.“ Gemäß der XML-Spezifikation ist diese Verarbeitung korrekt. Bei Firefox wird die Analyse abgebrochen, wenn ein Fehler auftritt und zeigt nichts anderes an. Der Inhalt entspricht strikt den XML-Spezifikationen. Da es sich nicht um HTML handelt, verfügt HTML überhaupt über kein Fehlerbehandlungsmodell, aber gemäß der XML-Spezifikation ist es nicht falsch, dies zu tun.
Dies ist ein weiterer Grund, warum Sie Ihr Dokument nicht als XML markieren würden. Als nächstes folgt die neue Version XHTML 2. Bitte beachten Sie, dass am Ende kein Datum steht, da diese Spezifikation noch nicht abgeschlossen ist.
Lassen Sie uns jetzt über XHTML 2 sprechen. Ich möchte das Problem klarstellen. XHTML 2 ist tatsächlich eine sehr, sehr gute Spezifikation, tatsächlich sehr gut ... aus theoretischer Sicht. Ich meine, die Leute, die diese Norm geschaffen haben, sind sehr, sehr klug. Um es ganz klar auszudrücken: Der Typ, der die Entwicklung dieses Codes leitete, war Stephen Pemberton, der wahrscheinlich ein Einheimischer und ein sehr kluger Kerl war. Auch die Spezifikation selbst ist großartig und wäre ein sehr gutes Format, wenn alle damit einverstanden wären, sie zu verwenden. Allerdings ist es nicht praktisch genug.
Zuallererst verwendet XHTML 2 immer noch das XML-Fehlerbehandlungsmodell, und Sie müssen sicherstellen, dass das Dokument als XML-Dokumenttyp gesendet wird. Dies ist selbsterklärend: Niemand möchte dies tun. Zweitens ist XHTML 2 absichtlich nicht mehr abwärtskompatibel mit bestehenden HTML-Versionen. Sie sprachen sogar darüber, das img-Element abzuschaffen, was für Leute, die jeden Tag Webentwicklung betreiben, ein wenig verrückt klingt. Aber wir wissen, dass es dafür einen guten theoretischen Grund gibt – es könnte besser sein, das Objektelement zu verwenden.
So perfekt das Format XHTML 2 auch in der Theorie war, es hatte nie die Chance, in die Praxis umgesetzt zu werden. Und der Grund dafür, dass es schwierig ist, dies in die Praxis umzusetzen, liegt darin, dass Entwickler wie Sie und ich es niemals unterstützen werden und es nicht abwärtskompatibel ist. Ebenso wenig gilt dies für Browserhersteller, Browserhersteller müssen die Abwärtskompatibilität sicherstellen.
Warum wurde XHTML 1.1 nicht so weit verbreitet wie XML und warum erblickte XHTML 2 nie das Licht der Welt? Da es gegen ein Gestaltungsprinzip verstößt, ist dieses Gestaltungsprinzip das berühmte Postelsche Gesetz. Jeder weiß:
Seien Sie beim Senden konservativ; seien Sie beim Empfang offen.
Ja, Sie müssen beim Empfang offen sein, und das ist die Grundlage, auf der das Web aufgebaut ist. Leute, die Browser entwickeln, müssen bereit sein, alles zu empfangen, was ihnen gesendet wird, denn sie haben in der Vergangenheit schon minderwertige Inhalte erhalten, oder? Viele Dokumente im Web sind nicht standardisiert, aber das ist die treibende Kraft hinter der Entwicklung des Webs. Aus einer bestimmten Perspektive folgt das Web einem chaotischen Entwicklungspfad. Obwohl es chaotisch ist, ist es sehr schön und attraktiv. Im Web sind überall Dokumente mit unregelmäßigen Formaten zu sehen, aber was nun? Es wäre schön, wenn jeder korrektes XML schreiben könnte und alle Dokumente perfekt formatiert wären. Das ist jedoch nicht realistisch. Die Realität ist Burstalls Gesetz.
Als Profis versuchen wir beim Versenden von Dokumenten konservativ zu sein, bewährte Verfahren anzuwenden und sicherzustellen, dass das Dokument gut formatiert ist. Aus Sicht des Browsers müssen sie jedoch für den Empfang jedes Dokuments offen sein.
Manche mögen sagen, dass XML über ein Fehlerbehandlungsmodell verfügt, das sowohl von XHTML 1.1 als auch von XHTML 2 verwendet wird, aber dieses Fehlerbehandlungsmodell ist zu streng. Es entspricht definitiv nicht der Offenheitsregel beim Empfang. Wie kann es als offen bezeichnet werden, wenn die Analyse aufhört, wenn ein Fehler auftritt? Wir können nur sagen, dass es dem Gesetz der Robustheit (also dem Burstahl-Gesetz) widerspricht.
HTML5
Danach kommt HTML5, aber HTML5 wird nicht direkt vom W3C formuliert. Die Geschichte geht so: Am Ende des 20. Jahrhunderts gab es keine HTML-Arbeitsgruppe und einige Leute im W3C begannen zu denken: „HTML könnte eine längere Lebensdauer haben, solange wir es ein wenig verlängern.“ Solange wir einen Teil der Zeit und Energie, die wir in XHTML stecken, aufwenden, können wir die Formulare in HTML verbessern, HTML näher an eine Programmiersprache heranführen und es auf die nächste Ebene bringen.“
Also, im Jahr 2004. Bei In einem Workshop mit W3C-Mitgliedern legte Ian Hickson, damals Vertreter von Opera, einen Vorschlag zur Erweiterung und Verbesserung von HTML vor. Er schlug vor, dass die neue Task Force parallel zu XHTML 2 arbeiten könnte, aber auf der Grundlage des vorhandenen HTML arbeiten könnte, mit dem Ziel, HTML zu erweitern. Das Ergebnis der W3C-Abstimmung war „Nein“, weil HTML tot ist und XHTML 2 der Weg nach vorne ist. Dann sagten Browserhersteller wie Opera und Apple und einige andere Mitglieder: „Verlassen Sie sich nicht mehr auf sie, wir können das selbst tun, und wir lösen uns vom W3C. Sie haben die Web-Hypertext-Anwendungstechnologie etabliert.“ Gruppe (Web Hypertext Application Technology Working Group (WHATWG) – Zufälligerweise bezeichnen sie sich selbst als Arbeitsgruppe und nicht als Task Force, was das zukünftige Schicksal von HTML5 vorwegnimmt.
WHATWG hat beschlossen, sich vollständig vom W3C zu trennen und auf der Basis von HTML zu arbeiten und einige neue Dinge hinzuzufügen. In dieser Arbeitsgruppe gibt es Browser-Anbieter, die nicht nur hinzufügen können, was sie wollen, sondern sie auch einzeln implementieren können. Dadurch hatten alle immer wieder gute Ideen und setzten diese nach und nach im Browser um.
WHATWGs Arbeit ist sehr effizient und wird bald erste Früchte tragen. Während dieser Zeit gab es kaum nennenswerte Fortschritte bei XHTML 2 des W3C. Insbesondere aus der Perspektive der Umsetzung scheint es nicht übertrieben zu sein, von einem Stillstand zu sprechen.
Infolgedessen geschah etwas Interessantes. Es war 2006, und Tim Berners-Lee schrieb in einem Blog: „Weißt du was? Wir haben uns geirrt. Wir haben uns geirrt, als wir versuchten, das Web über Nacht in das XML-Zeitalter zu bringen. Das ist unrealistisch, ja, vielleicht sollten wir die HTML-Funktionsweise neu organisieren.“ Gruppe“, sagte Shanzai, und so entwickelte sich die anschließende Handlung. Das W3C gründete 2007 die HTML5-Arbeitsgruppe. Die erste Frage, mit der sich diese Arbeitsgruppe konfrontiert sieht, lautet zweifellos: „Sollten wir bei Null anfangen oder sollten wir auf der Grundlage der vorhandenen Ergebnisse der 2004 gegründeten Arbeitsgruppe namens WHATWG beginnen?“ Die Antwort liegt auf der Hand Gehen Sie von den erzielten Ergebnissen aus und beginnen Sie mit der darauf basierenden Arbeit. Also stimmten sie erneut ab und einigten sich darauf, „die Arbeit auf der Grundlage der Ergebnisse der WHATWG-Arbeit fortzusetzen“. Nun müssen sie Seite an Seite mit WHATWG kämpfen.
Die zweite Frage ist, wie das Verhältnis zwischen den beiden Arbeitsgruppen geklärt werden kann. Wer sollte Herausgeber dieser W3C-Arbeitsgruppe sein? Sollten wir auch den Herausgeber von WHATWG, der jetzt Ian Hixon von Google ist, die Rolle übernehmen lassen? Daher stimmten sie erneut dafür, „Ian Hickson als Herausgeber der W3C-HTML5-Spezifikation und gleichzeitig als Herausgeber der WHATWG fungieren zu lassen, was der Arbeit der neuen Arbeitsgruppe förderlicher sein wird“. Das Ergebnis ihrer Abstimmung: Das sehen wir heute: ein Format, zwei Versionen. Diese Spezifikation ist auf der WHATWG-Website verfügbar und es gibt auch eine Kopie auf der W3C-Website.
Wenn Sie die Insider-Geschichte nicht kennen, haben Sie möglicherweise Fragen wie: „Welche Version ist die tatsächliche Spezifikation?“ Natürlich ist der Inhalt dieser beiden Versionen derselbe ... im Grunde derselbe. Tatsächlich werden die beiden Versionen künftig getrennte Wege gehen. Jetzt gibt es Anzeichen dafür, dass sich die Wege trennen. Ich meine damit, dass das W3C irgendwann eine spezifische Spezifikation formulieren wird, die zu einem Arbeitsentwurf wird und zu einem bestimmten historischen Zeitpunkt festgelegt wird.
Was WHATWG betrifft, werden sie immer noch iteriert. Selbst wenn wir derzeit über HTML5 sprechen, kann es die Arbeit von WHATWG nicht vollständig abdecken. Das genaueste Verständnis ist, dass sie eine einfache HTML- oder Web-Technologie entwickeln, denn das ist das Kernziel ihrer Arbeit. Allerdings ist die Existenz zweier solcher Arbeitsgruppen, die gleichzeitig eine im Wesentlichen identische Spezifikation entwickeln, auf jeden Fall irreführend. Missverständnisse können Ärger verursachen.
Tatsächlich haben diese beiden Arbeitsgruppen ihre eigenen Prozesse hinter sich, denn ihre Konzepte sind völlig unterschiedlich. In WHATWG kann man von einem autoritären Arbeitsmechanismus sprechen. Wie ich bereits sagte, ist Ian Hixon der Herausgeber. Er wird sich die Meinungen aller Parteien anhören, und nachdem alle Mitglieder ihre Meinung geäußert und ihre Ansichten vollständig dargelegt haben, wird er die Meinungen billigen, die er für richtig hält.
W3C ist genau das Gegenteil. Man kann sagen, dass es ein demokratischer Arbeitsmechanismus ist. Alle Mitglieder können ihre Meinung äußern und jeder hat das Stimmrecht. Der Schlüssel zum Prozess ist die Abstimmung. Oberflächlich betrachtet ist der Arbeitsmechanismus von WHATWG nicht akzeptabel. Es ist nicht nur schwer zu akzeptieren, es ist einfach ein Rückschritt in der Geschichte. Ich glaube, jeder wird denken: „Das ist nicht die Art und Weise, ein Projekt durchzuführen!“Der Arbeitsmechanismus des W3C klingt sehr komfortabel. Zumindest zeigt es, dass alle gleich sind. Aber in der Praxis funktioniert der Arbeitsmechanismus von WHATWG sehr, sehr gut. Ich denke, das liegt hauptsächlich an Ian Hickson. Er ist in der Tat ein sehr kompetenter Redakteur. Er konnte sich stets Meinungen von allen Seiten anhören, ohne dass es zu persönlichen Emotionen kam.
Im Prinzip ist der Arbeitsmechanismus des W3C fair, tatsächlich kann es aber sehr leicht passieren, dass man in bestimmten Prozessen oder Verknüpfungen stecken bleibt und die Arbeit stagniert. Oft dauert es lange, bis man zu einer Lösung in einer Sache kommt. Welcher Arbeitsmechanismus ist also der beste? Ich denke, der beste Arbeitsmechanismus besteht darin, beides zu kombinieren. Tatsache ist, dass zwei normsetzende Einheiten gemeinsam dieselbe Norm formulieren. Dies ist meiner Meinung nach sehr förderlich dafür, dass die beiden Arbeitsmechanismen aus den Stärken und Schwächen des anderen lernen.
Der Hauptgrund, warum die beiden Arbeitsgruppen zusammenarbeiten können, ist die Designphilosophie von HTML5. Weil sie von Anfang an die Grundsätze festgelegt haben, die bei der Gestaltung von HTML5 einzuhalten sind. Infolgedessen haben wir nicht nur eine Spezifikation gesehen, nämlich das auf der W3C-Site veröffentlichte Dokument, die HTML5-Sprachspezifikation, sondern auch ein weiteres Dokument auf der W3C-Site, nämlich die HTML-Designprinzipien. Eine Herausgeberin dieses Dokuments war heute auch zu unserer Konferenz. Sie ist Anne Van Kesteren. Wenn Sie Fragen zu diesem Dokument haben, können Sie Anne fragen.
Dieses Dokument ist sehr gut, wirklich herausragend. Man kann sagen, dass dieses Dokument den Prozess dokumentiert, in dem W3C und WHATWG zusammenarbeiteten, um eine gemeinsame Entwicklung anzustreben. Glaubst du nicht, dass sie wie ein Paar glücklicher Feinde sind? Wie können sie also immer noch einer Meinung sein? Dieses Dokument dokumentiert getreulich, was sie gemeinsam getan haben und wofür sie gemeinsam eingetreten sind.
Als nächstes möchte ich über dieses Dokument sprechen. Denn da sie zu einem Konsens über dieses Dokument gelangen können, glaube ich, dass HTML5 eine großartige Spezifikation sein wird, und sie haben dies als ihr gemeinsames Aktionsprogramm erkannt. Aus diesem Grund werden Ihnen Konzepte wie Kompatibilität, Praktikabilität und Interoperabilität angezeigt. Egal, wie groß die Meinungsverschiedenheiten zwischen W3C und WHATWG sind – und tatsächlich gibt es ziemlich viele –, zumindest herrscht immer noch der in diesem Dokument festgehaltene Konsens. Das ist entscheidend. Gerade weil sie einen Konsens haben, verfügen sie über dieses Dokument, in dem die auf dem Konsens basierenden Designprinzipien beschrieben werden.
Unnötige Komplexität vermeiden
Jetzt stelle ich Ihnen einige in diesem Dokument aufgezeichnete Designprinzipien vor. Die erste ist ganz einfach: Vermeiden Sie unnötige Komplexität. Es scheint sehr einfach zu sein. Lassen Sie mich das anhand eines Beispiels veranschaulichen.
Angenommen, ich verwende die HTML 4.01-Spezifikation, öffne das Dokument und gebe doctype ein. Erinnert sich hier jemand an den HTML 4.01-Dokumenttyp? Nun ja, nein, ich denke nicht. Es sei denn... ich meine, du bist dumm. Ich fürchte, jemand hat es sich tatsächlich vor Ort gemerkt. Dies ist der Dokumenttyp von HTML 4.01:
Das ist alles. Nun, sogar ich habe ein fotografisches Gedächtnis. Ich muss diese Zeichen nicht in den Notizblock schreiben. Ich muss sagen, als ich diesen Doctype zum ersten Mal sah – natürlich dachte ich, es sei der Doctype eines HTML-Dokuments –, war ich schockiert: „Fehlt da eine Zahl 5?“ Ich dachte mir: „Was bedeutet dieser Doctype?“ Willst du dem Browser sagen, dass es sich bei diesem Dokument um die einzige HTML-Version handelt? Wird es in Zukunft nie eine neue HTML-Version geben? herrschsüchtige Haltung! Ich habe mich geirrt, weil dieser Dokumenttyp dies nicht bedeutet. Dazu müssen wir zunächst verstehen, warum Doctype am Anfang des Dokuments steht. Es ist nicht für Browser lesbar geschrieben. Doctype ist so geschrieben, dass Validatoren es sehen können. Mit anderen Worten, der Grund, warum ich diese Zeile des XHTML 1.0-Dokumenttyps am Anfang des Dokuments schreibe, besteht darin, den Validator anzuweisen, mein Dokument gemäß diesem Dokumenttyp zu überprüfen.
Der Browser spielt keine Rolle mehr. Angenommen, ich schreibe ein HTML 3.2-Dokument und der Doctype von HTML 3.2 steht am Anfang des Dokuments. Und irgendwo im Dokument habe ich ein Element verwendet, das nur in HTML 4.01 vorkam. Wie wird der Browser mit dieser Situation umgehen? Würde es das Element nicht interpretieren und rendern, nur weil es in einer späteren Spezifikation als der vom Doctype deklarierten HTML-Version erscheint? Nein, natürlich nicht! Es wird das Element weiterhin interpretieren und wiedergeben, vergessen Sie nicht das Burstahl-Gesetz, vergessen Sie nicht die Robustheit. Beim Empfang muss der Browser geöffnet sein. Daher prüft es im Gegensatz zum Validator keinen Formattyp und kümmert sich nur um den Formattyp. Dies ist der wahre Grund, warum Doctype existiert.
Nach einem anderen Designprinzip von HTML5 muss es vorwärts- und rückwärtskompatibel sein, und zukünftige HTML-Versionen – sei es HTML6, HTML7 oder etwas anderes – müssen mit der aktuellen HTML-Version, HTML5, kompatibel sein. Daher macht es selbst für Validatoren wenig Sinn, eine Versionsnummer in den Doctype einzutragen.
Gerade habe ich gesagt, dass Doctype nicht für Browser geschrieben ist, sodass es in den meisten Fällen kein Problem gibt. In einem Fall wirkt sich der von Ihnen verwendete Dokumenttyp auf den Browser aus, und ich glaube, das weiß jeder hier. In diesem Fall wird Doctype jedoch nicht wirklich für seinen Zweck verwendet, sondern nur zur Erreichung eines bestimmten Zwecks. Als Microsoft CSS einführte, waren sie die ersten, die CSS in Browsern unterstützten und auch ihr eigenes Box-Modell auf den Markt brachten. Später wurde der Standard veröffentlicht, aber im Standard wurde ein anderes Box-Modell verwendet. Was sollen sie tun? Sie möchten Standards unterstützen, aber auch abwärtskompatibel mit der Kodierung sein, die sie in der Vergangenheit eingeführt haben. Woher wissen sie, dass der Autor der Webseite Standards verwenden möchte oder wie er es früher getan hat?
Also hatten sie eine sehr clevere Idee. Das bedeutet, Doctype zu verwenden und einen gültigen Doctype zu verwenden, um den Standardmodus anstelle des Quiks-Modus auszulösen. Die Idee ist sehr clever. Wir alle tun dies heute. Wenn wir dem Dokument DocType hinzufügen, ist dies gleichbedeutend mit der Aussage „Ich möchte den Standardmodus verwenden“, aber dies ist nicht die ursprüngliche Absicht, DocType zu erfinden. Dies ist nur die Verwendung von Doctype für einen besonderen Zweck.
Ich werde Ihnen unten eine preisgekrönte Antwortfrage geben: „Wenn Sie schnell sind, beginnen Sie in einer Minute mit dem Schreiben von doctype html vor dem Dokument. Dann verwende ich den Internet Explorer zum Öffnen.“ Ihr Dokument, das den Standardmodus auslöst, oder löst es den Kompatibilitätsmodus aus? „
Die Antwort lautet: Dies ist die Mindestanzahl an Zeichen, die den Standardmodus im Internet Explorer auslöst. Ich denke, das verdeutlicht auch das Wesentliche der HTML5-Spezifikation: Sie strebt nicht nach theoretischer Perfektion. Was HTML5 verkörpert, ist nicht: „Oh, wäre es nicht gut, dem Autor einen kurzen und leicht zu merkenden Dokumenttyp zu geben?“ Ja, es ist gut, kurz und leicht zu merken zu sein, aber wenn dieser leicht zu merken ist Doctype kann sich nicht an bestehende Browser anpassen, es ist besser, dem Autor einen kurzen und leicht zu merkenden Doctype zu geben, der besser vergisst. Daher ist dieses Gleichgewicht sehr gut gelungen, und es ist nicht nur theoretisch eine gute Idee – ein kurzer und leicht zu merkender Dokumenttyp –, sondern auch in der Praxis eine gute Idee – es kann immer noch den Standardmodus auslösen. Es sollte gesagt werden, dass Doctype ein sehr typisches Beispiel ist.
Es gibt noch ein weiteres Beispiel, das ebenfalls veranschaulichen kann, wie Spezifikationen unnötige Komplexität weglassen und unnötige Komplexität vermeiden können. Wenn das vorherige Dokument HTML 4.01 verwendet, möchte ich beispielsweise die Zeichenkodierung des Dokuments angeben. Idealerweise wird die Zeichenkodierung vom Server in einem Header gesendet, sie kann aber auch auf Dokumentebene angegeben werden:
Ebenso werde ich mir diese Codezeile nicht merken. Ich möchte auch meine Gehirnzellen retten, um mich an andere wertvollere Dinge zu erinnern. Wenn ich jedoch angeben möchte, dass das Dokument in UTF-8 kodiert ist, kann ich nur diese Codezeile hinzufügen. Dies ist in HTML 4.01 erforderlich. Wenn Sie die gleiche Kodierung in XHTML 1.0 angeben, sind einige Tastendrücke mehr erforderlich, da Sie das Metaelement auch in einem öffnenden XML-Tag deklarieren müssen.
In ähnlicher Weise ist auch das Schreiben auf diese Weise gültig. Es funktioniert nicht nur mit den neuesten Browserversionen, sondern mit jedem Browser, den heute jeder verwendet. Warum? Denn wenn wir diese Metaelemente in den Browser eingeben, interpretiert der Browser sie wie folgt: „Metadaten (Meta) Punkt Punkt Punkt Punkt, Zeichensatz (Zeichensatz) utf-8.“ Dies ist, wenn der Browser diese Zeile der Zeichenfolge „Was“ interpretiert Sie sehen tatsächlich. Es muss diese Dinge sehen, basierend auf Bostals Gesetz, oder?
Ich habe das Prinzip der Robustheit schon oft erwähnt, aber manche Leute verstehen es immer nicht. Anders ausgedrückt: Der Browser wird denken: „Okay, ich denke, der Autor möchte einen Zeichensatz angeben ... Sehen Sie, ja, utf-8 ist in der Spezifikation klar angegeben.“ Jetzt kann nicht nur der Schrägstrich weggelassen werden, sondern es genügt nur noch meta charset="utf-8".Es gibt viele Beispiele dafür, unnötige Komplexität wegzulassen oder unnötige Komplexität zu vermeiden. Der Schlüssel liegt jedoch darin, unnötige Komplexität zu vermeiden, ohne die Verwendung in vorhandenen Browsern zu behindern. Wenn ich beispielsweise in HTML5 das Link-Element verwende, um auf ein Stylesheet zu verlinken, und ich rel="stylesheet" und dann type="text/css" sage, wiederhole ich mich. Was den Browser betrifft, wiederhole ich mich. Der Browser muss nicht beide Eigenschaften gleichzeitig sehen. Es reicht aus, wenn der Browser rel="stylesheet" sieht, da er erraten kann, dass es sich bei dem, was Sie verknüpfen möchten, um ein CSS-Stylesheet handelt. Daher ist es nicht erforderlich, das Typattribut anzugeben. Sie haben bereits gesagt, dass es sich um ein Stylesheet handelt; es ist nicht nötig, es noch einmal zu sagen. Natürlich können Sie mehr sagen, wenn Sie möchten; wenn Sie das Typattribut einschließen möchten, tun Sie dies bitte.
Wenn Sie ein Skriptelement verwenden und type="text/javascript" sagen, weiß der Browser ebenfalls ziemlich genau, was vor sich geht. Verwenden Sie andere Skriptsprachen für die Webentwicklung? Wenn Sie wirklich eine andere Skriptsprache verwenden möchten, wird Sie niemand daran hindern. Ich möchte Sie jedoch darauf hinweisen, dass Sie kein Browser unterstützt.
Sie können bei Bedarf ein Typattribut hinzufügen. Sie können jedoch auch nichts schreiben und der Browser geht dann natürlich davon aus, dass Sie JavaScript verwenden. Vermeiden Sie unnötige Komplexität.
Unterstützen Sie vorhandene Inhalte. Dies ist sehr wichtig, da viele Leute denken, dass HTML5 neu und glänzend ist; es sollte die Richtung der zukünftigen Entwicklung darstellen und das Web auf eine neue Entwicklungsstufe bringen. Das ist HTML5, oder? Natürlich denken wir alle darüber nach, die Zukunft des Webs besser zu machen, aber wir müssen auch an die Vergangenheit denken. Vergessen Sie nicht, dass viele Leute in der W3C-Arbeitsgruppe Browserhersteller vertreten und über die Unterstützung bestehender Inhalte nachdenken müssen. Wann immer Sie einen Browser erstellen möchten, müssen Sie sich an dieses Prinzip erinnern: Er muss vorhandene Inhalte unterstützen.
Sehen wir uns ein Beispiel für die Unterstützung bestehender Inhalte durch HTML5 an.Dieses Beispiel zeigt vier verschiedene Arten, denselben Inhalt zu schreiben. Oben ist ein img-Element und unten ist ein Absatzelement mit einem Attribut. Der einzige Unterschied zwischen den vier Schreibmethoden ist die Grammatik. Geben Sie dem Browser einen beliebigen Code, und der Browser generiert problemlos denselben DOM-Baum. Aus Sicht des Browsers gibt es keinen Unterschied zwischen diesen vier Schreibmethoden. In HTML5 können Sie also jede der folgenden Syntaxen verwenden.
Hallo Welt
Hallo Welt
Hallo Welt
🎜> < ;img src=foo alt=bar>Hallo Welt
Okay, nachdem einige Leute diese Codeteile gesehen haben, sagen sie vielleicht: „Nein, nein, nein, nein. Nur einer davon ist richtig, und die anderen drei – nein, das solltest du sagen.“ Setzen Sie die Attributwerte in Anführungszeichen! Komm schon, wir setzen Attributwerte immer in Anführungszeichen! Werden Elementnamen korrekt großgeschrieben? Wurde diese Praxis nicht nach 10 Jahren aufgegeben?
Als ich sah, dass HTML5 diese Schreibmethoden gleichzeitig ermöglicht, wurde mir schlecht. Ich schreibe seit 10 Jahren XHTML 1.0 und habe mich sehr an die strenge Syntax gewöhnt. Sie müssen jedoch verstehen, dass diese Schreibmethoden aus Sicht des Browsers tatsächlich dieselben sind. Es gibt wirklich kein Problem.
Fühlt sich sonst noch jemand unwohl? Hat jemand das gesehen und gedacht: „Oh, ist das nicht Gekritzel? Das ist falsch.“ Bin ich der Einzige, der so denkt? Gibt es sonst noch jemanden?
HTML5 muss jedoch vorhandene Inhalte unterstützen, und so sehen vorhandene Inhalte aus. Nicht wahr? Nach dem Burstahl-Gesetz hat der Browser keine Wahl.
Einige Leute sagen vielleicht: „Das wird nicht funktionieren. Ich denke, die Sprache selbst sollte einen Schalter bieten, der es dem Autor ermöglicht, anzugeben, was er tun möchte.“ Zum Beispiel, wenn Sie eine bestimmte Syntax wie XHTML verwenden möchten , anstatt eine andere Syntax zu verwenden. Ich verstehe, woher diese Leute kommen. Aber ich bin nicht damit einverstanden, Schalter in Sprachen zu setzen. Da wir nur den Codierungsstil oder den Schreibstil besprechen, hat es nichts damit zu tun, welche Grammatik korrekt ist. Für Profis wie uns denke ich, dass Sie das Lint-Tool (ein Software-Qualitätssicherungstool) oder einen strengeren Compiler verwenden können. Es kann nicht nur wie ein normaler Compiler nach allgemeinen Syntaxfehlern suchen, sondern auch die Fehler überprüfen, die, obwohl sie vollständig grammatikalisch sind, wahrscheinlich potenzielle und schwer zu findende Fehler sind), verwenden wir das Lint-Tool nicht auch für andere Technologien?
Verwenden Sie beispielsweise das Lint-Tool für JavaScript. JavaScript ist ebenfalls ein chaotisches, lockeres Beispiel, aber es ist gerade deshalb sehr mächtig, weil es chaotisch und locker ist und über viele verschiedene Codierungsmethoden verfügt. In JavaScript können Sie am Ende jeder Anweisung ein Semikolon hinzufügen, dies ist jedoch nicht erforderlich, da JavaScript automatisch ein Semikolon einfügt ... Klingt das nicht etwas unangenehm?
Aus diesem Grund gibt es Tools wie JSlint auf Douglas Crockfords Website jslint.org. Es gibt eine Seite, auf der es heißt: „JSlint könnte Ihre Gefühle verletzen.“ Aber es ist ein wirklich großartiges Tool, das Ihren JavaScript-Code fehlerfrei machen kann. Wenn Sie JavaScript über JSlint ausführen, wird Ihnen Folgendes angezeigt: „Okay, Ihr JavaScript-Code ist gültig, aber er ist falsch geschrieben. Ich mag Ihren Codierungsstil nicht. Ich bin damit nicht einverstanden. Er ist nicht gut.“ Teams ist JSlint ein sehr praktisches Tool für Teams, die einen einheitlichen Codierungsstil verwenden möchten.
Ich persönlich glaube, dass Sie sich nicht nur für das Team, sondern auch für das Schreiben von Code selbst an einen grammatikalischen Stil halten müssen. Es steht außer Frage, welche Syntax aus Sicht des Browser-Parsings besser ist als eine andere, aber ich denke, als Profis müssen wir selbstbewusst sagen können: „Das ist mein Codierungsstil.“ Allerdings denke ich nicht, dass dieser Schalter eingebaut werden sollte die Sprache. Mit dem Lint-Tool können Sie Ihren Codierungsstil vereinheitlichen. Lassen Sie uns nun über das Fusselwerkzeug sprechen. Sie können sich bei htmllint.com anmelden und dort Ihr HTML5-Dokument ausführen. Dadurch können Sie überprüfen, ob der Attributwert in Anführungszeichen steht und ob das Element in Kleinbuchstaben geschrieben ist. Sie können auch andere Prüfelemente festlegen, indem Sie das Kontrollkästchen aktivieren.
Aber das bedeutet nicht, dass Sie unvorsichtige Markierungen ablehnen sollten. Es liegt ganz bei Ihnen, ob Sie sie entfernen oder nicht. Da Browser wie gesagt vorhandene Inhalte unterstützen müssen, bildet HTML5 keine Ausnahme. Letztlich kommt es auf das Bostalsche Gesetz an. Wir können niemals ohne Burstahls Gesetz auskommen.
Lösen Sie reale Probleme
Ein weiteres Designprinzip von HTML5 besteht darin, reale Probleme zu lösen. Es ist offensichtlich, dass Formate und Spezifikationen zur Lösung verschiedener Probleme bereits überall vorhanden sind. Meiner Meinung nach besteht dieses Prinzip eher darin, theoretische Probleme als praktische Probleme zu lösen. Dieses Gestaltungsprinzip besteht darin, theoretisch häufige Probleme zwischen Menschen anzuerkennen und sensible Probleme zu beseitigen. Aber meiner Meinung nach handelt es sich bei diesen Formaten und Spezifikationen allesamt um theoretische Probleme, nicht um praktische Probleme. Dieses Designprinzip ist es, was die wirklichen Probleme und Kopfschmerzen, mit denen die Menschen heute konfrontiert sind, wirklich lösen will.
Lassen Sie mich Ihnen ein Beispiel geben. Ich glaube, viele Menschen sind diesem Beispiel begegnet. Angenommen, ich verwende HTML 4 oder XHTML 1 und es gibt bereits einen Inhalt auf der Seite. Ich möchte einen Link zum gesamten Inhalt hinzufügen. Das Problem besteht darin, dass dieser Inhalt einen Titel, einen Absatz und möglicherweise ein Bild enthält. Wenn ich sie alle anklickbar machen möchte, muss ich 3 Linkelemente verwenden. Also muss ich zuerst den Cursor in den Titel setzen (zum Beispiel das h2-Element), einen Link-Tag schreiben und dann den gesamten Text auswählen, der in den Link aufgenommen werden soll. Platzieren Sie dann den Cursor im Absatz, schreiben Sie ein Link-Tag und fügen Sie dann den Text im Absatz im Link ein ...
In HTML5 verpacke ich einfach alles in ein Link-Element.
Ja, Links enthalten Elemente auf Blockebene, aber jetzt kann ich sie alle in einem Element enthalten. Das ist großartig. Da ich auf eine ähnliche Situation gestoßen bin, in der ich denselben Link zu mehreren Elementen auf Blockebene hinzufügen musste, wäre es großartig, ihn so schreiben zu können. Aus diesem Grund begrüße ich den neuen Standard HTML5 sehr.
Es löst ein echtes Problem. Ich wage zu behaupten, dass viele meiner Freunde hier auf dieses Problem gestoßen sind.
Welches Problem wird dadurch gelöst? Der Browser muss den Code nicht neu schreiben, um diesen Ansatz zu unterstützen. Diese Art des Schreibens gibt es in Browsern tatsächlich schon seit langem, weil jemand sie schon lange so geschrieben hat. Natürlich entsprach das Schreiben auf diese Weise nicht den Standards. Wenn es darum geht, zu sagen, dass HTML5 reale Probleme löst, lautet das Wesentliche immer noch: „Sie schreiben schon seit vielen Jahren so, oder? Jetzt haben wir den Standard geändert und erlauben Ihnen, so zu schreiben.“
Die Wahrheit suchen und pragmatisch sein
Unter allen Designprinzipien ist dieses wahrscheinlich das lauteste – Wahrheit suchen und pragmatisch sein. Ich weiß nicht, ob Sie diesen Slogan jemals bei einem Treffen im Unternehmen gehört haben: „Pionierorientiert und unternehmungslustig, wahrheitssuchend und pragmatisch.“ Tatsächlich ist es nicht nur ein Unternehmensslogan, sondern auch ein sehr wichtiges Designprinzip , weil Wahrheitssuche und Pragmatismus für HTML sehr wichtig sind. Die Bedeutung ist: Bevor Sie diese problematischen Probleme lösen, schauen Sie sich zunächst an, was sich die Leute ausgedacht haben, um diese Probleme zu lösen. Die Konzentration auf das Verständnis dieser „zivilen“ Lösungen hat Priorität.Die neuen semantischen Elemente in HTML5 spiegeln das Prinzip der Wahrheitssuche und des Pragmatismus wider. Es gibt nicht viele neue Elemente und man kann nicht sagen, dass es unbegrenzt skalierbar ist, aber es ist trotzdem eine gute Sache. Obwohl ihre Zahl gering ist, ist ihre Bedeutung außergewöhnlich. Zu diesen neuen Elementen gehören Kopfzeile, Fußzeile, Abschnitt, Artikel ... Ich glaube, dass sie nicht jedem fremd vorkommen werden. Ich meine, auch wenn Sie kein HTML5 verwenden, sollten Sie mit diesen Namen vertraut sein, die Sie zuvor verwendet haben, z. B. class="header"/"head"/"heading" oder class ="Fußzeile" /"Fuß". Natürlich kann es auch ID, id="header", id="footer" sein. Ist das nicht das, woran wir uns gewöhnt haben?
Okay, geben wir Ihnen ein Beispiel. Angenommen, Sie haben heute das folgende Dokument geschrieben.
Der Code lautet wie folgt:
Natürlich können Sie das tun. Die Verwendung dieser Elemente auf Dokumentebene ist kein Problem. Wenn der Zweck des Hinzufügens dieser Elemente jedoch nur darin besteht, das ursprüngliche Div zu ersetzen, ist dies wirklich unnötig.
Obwohl wir in diesem Dokument IDs durch diese neuen Elemente ersetzen, sind sie meiner persönlichen Meinung nach als Ersatz für Klassen wertvoller. Warum sagst du das? Denn diese Elemente können nicht nur einmal, sondern mehrfach auf einer Seite verwendet werden. Ja, Sie können einem Dokument eine Kopf- und eine Fußzeile hinzufügen, aber jeder Abschnitt im Dokument kann auch eine Kopf- und eine Fußzeile haben. Und jede Partition kann in einer anderen Partition verschachtelt sein, oder?
Diese vier neuen Elemente: Abschnitt, Artikel, Seite und Navigation. Der Grund, warum sie leistungsstark sind, liegt darin, dass sie ein neues Inhaltsmodell darstellen, ein beispielloses Inhaltsmodell in HTML – die Partitionierung von Inhalten. Bisher haben wir Divs verwendet, um Inhalte auf der Seite zu organisieren, aber wie andere ähnliche Elemente haben Divs selbst keine Semantik. Aber „Abschnitt“, „Artikel“, „Beiseite“ und „Navigation“ machen Ihnen tatsächlich deutlich, dass dieser Abschnitt wie ein weiteres Dokument im Dokument ist. Jeder Inhalt, der sich in diesen Elementen befindet, kann eine eigene Zusammenfassung, einen eigenen Titel und eine eigene Fußzeile haben.
Man kann sagen, dass der häufigste Abschnitt derjenige ist, der für den Inhalt am relevantesten ist. Und Artikel ist eine besondere Art von Abschnitt. Daneben gibt es einen speziellen Abschnitt. Schließlich ist Nav auch ein spezieller Abschnitt.
Nun, auch jetzt noch können Sie Divs und Klassen verwenden, um verschiedene Teile der Seite zu beschreiben, wie folgt:
Es enthält Metadaten, die sich möglicherweise auf den Autor des Inhalts beziehen, und es gibt unten einige Links, aber das ist auch schon alles. In HTML5 kann ich vollständig sagen, dass dieser Inhalt ein Dokument ist, indem ich ihn in einen Abschnitt, einen Artikel oder eine Seite unterteile. Daher kann ich ihn natürlich verwenden Kopf- und Fußzeile.
Bitte beachten Sie, dass nicht einmal die Fußzeile unten erscheinen muss, oder? Das Wichtigste an diesen Elementen, Kopfzeile, Fußzeile, Seite und Navigation, ist ihre Semantik, sie hat nichts mit der Position zu tun. Wenn wir an das Wort „Fußzeile“ denken, denken wir immer automatisch: „Oh, es sollte unten platziert werden.“ Ebenso denken wir an „Aside“ als Seitenleiste. Wenn Sie sich jedoch die Spezifikation ansehen, werden Sie feststellen, dass es sich bei diesen Elementen nur um Inhalte handelt. Daher kann der in der Fußzeile platzierte Inhalt auch eine Signatur, der Autor des Artikels usw. sein. Es handelt sich lediglich um ein Element, das Sie verwenden. Dieses Element sagt nicht „Ich muss unter dem Dokument oder Abschnitt platziert werden.“
Bitte beachten Sie, dass das Wichtigste nicht darin besteht, dass ich die ursprüngliche Div-Klasse durch mehrere neue Elemente ersetzt habe, sondern dass ich die ursprüngliche Div-Klasse ersetzt habe Die H2 wurde durch H1 ersetzt – schockierend, ich sah einige Leute zittern. Ich habe viele professionelle Webentwickler getroffen, die jahrelang geglaubt haben, dass in der Spezifikation nur ein H1 in einem Dokument enthalten sein dürfe. Es gibt auch einige selbsternannte allmächtige SEO-Tipps, die dies ebenfalls besagen. Viele SEO-Techniken sind tatsächlich sehr dogmatisch. Mit Dogma meine ich, den Daten nicht zu vertrauen. In der Vergangenheit wurde dieses Dogma folgendermaßen ausgedrückt: „Nein, wenn die Seite mehr als zwei H1s enthält, werden Sie sterben, solange Sie in HTML5 einen neuen Inhaltsblock erstellen, unabhängig von Abschnitt, Artikel, Seite, Navigation usw.“ In anderen Elementen können Sie H1 verwenden, ohne sich Gedanken darüber machen zu müssen, auf welcher Ebene der Titel in diesem Block auf der gesamten Seite platziert werden soll. H2, H3 ist kein Problem.
Diese Veränderung ist erstaunlich. Denken Sie darüber nach, diese Änderung ist revolutionär für das Content Management. Denn jetzt können Sie sich jeden Inhaltsabschnitt als einen separaten Abschnitt vorstellen, der aus der Seite herausgenommen werden kann. An dieser Stelle kann H1 in diesem unabhängigen Abschnitt je nach Kontext die Rolle von H2 oder H3 auf der gesamten Seite spielen – je nachdem, wo es im Dokument erscheint. Angesichts dieser plötzlichen Veränderung könnten manche Menschen vorübergehend verwirrt sein. Es spielt keine Rolle, aber ich kann Ihnen sagen, dass meiner Meinung nach darin der wahre Wert dieser neuen semantischen Auszeichnungen in HTML5 liegt. Mit anderen Worten: Wir haben jetzt unabhängige Elemente, innerhalb derer die Überschriftenebenen neu definiert werden können.
Mein Dokument enthält möglicherweise eine Partition, die in einer anderen Partition oder einem Artikel verschachtelt sein kann, und dann wird der Artikel in der Partition verschachtelt, und die Partition wird im Artikel verschachtelt, in der Partition verschachtelt und dann darin verschachtelt der Artikel Artikel. Und jeder Abschnitt und Artikel kann sein eigenes H1 bis H6 haben. In diesem Sinne kann man vom H-Element tatsächlich sagen: „Die Nachkommen unserer Nachkommen sind unendlich arm.“ Wenn Sie jedoch Inhalte oder ein Content-Management-System schreiben, handelt es sich bei allen um unabhängige, völlig unabhängige Inhaltsblöcke. Hier liegt der wahre Wert.
Tatsächlich wurde diese Idee weder von der HTML5-Arbeitsgruppe erdacht, noch wurde sie kürzlich vom W3C vorgeschlagen. Die folgenden Sätze sind Auszüge aus einer E-Mail von Tim Berners-Lee an Dan Connolly aus dem Jahr 1991. In der E-Mail erläuterte er sein Verständnis von HTML. Er sagte: „Wissen Sie … Sie wissen, was ich denke. Ich denke, es ist nicht gut, wenn H1 und H2 so monoton angeordnet sind. Ich möchte, dass es zu einem Element wird.“ kann verschachtelt werden, oder sagen wir ein generisches H-Element, und wir können verschiedene Ebenen darin verschachteln. „Aber anstatt ein generisches H-Element zu sehen, haben wir weiterhin H1 und H2 verwendet – das liegt daran, dass wir weiterhin die vorhandenen unterstützen.“ Heute, 20 Jahre später, ist dieses Ideal endlich wahr geworden.
Reibungsloser Abbau
Das nächste Prinzip sollte jedem bekannt sein, und das ist der sanfte Abbau. Schließlich halten wir uns schon seit Jahren an diese Regel. Die Kehrseite der progressiven Verbesserung ist ein sanfter Abbau.
Ein Beispiel dafür, dass HTML5 diesem Prinzip folgt, ist die Verwendung des Typattributs zur Verbesserung von Formularen. Nachfolgend sind die neuen Werte aufgeführt, die für das Typattribut angegeben werden können, einschließlich Zahl, Suche, Bereich usw.
Die wichtigste Frage ist, was der Browser tun wird, wenn er diese neuen Typwerte sieht. Bestehende Browser, nicht zukünftige Browser, können diese neuen Typwerte nicht verstehen. Wenn sie jedoch einen Typwert sehen, den sie nicht verstehen, interpretieren sie den Typwert als Text.
Egal, ob Sie input type="foo" oder input type="bar" schreiben, jeder vorhandene Browser sagt: „Vielleicht meinte der Autor also Text.“ Von nun an können Sie diese neuen Werte verwenden, und das können Sie Seien Sie versichert, dass Browser, die sie nicht verstehen, die neuen Werte als type="text" behandeln. Dies ist ein gutes Beispiel dafür, dass Browser das Prinzip der eleganten Verschlechterung praktizieren.
Zum Beispiel geben Sie jetzt type="number" ein. Angenommen, Sie benötigen ein Textfeld zur Eingabe numerischer Werte. Dann können Sie das Typattribut dieser Eingabe auf „Zahl“ setzen, und dann zeigt der Browser, der es versteht, ein nettes kleines Steuerelement an, etwa ein Spinner-Steuerelement mit einem kleinen Pfeilsymbol. Rechts? Und in einem Browser, der es nicht versteht, sehen Sie ein Textfeld, ein Textfeld, mit dem Sie nur allzu vertraut sind. Warum können wir in diesem Fall nicht sagen, dass durch die Eingabe von type="number" ein Spinner mit einem kleinen Pfeilsymbol angezeigt wird?
Natürlich können Sie auch die minimalen und maximalen Eigenschaften festlegen, die sich auch reibungslos verschlechtern können. Das ist der Kern der Sache.
Schauen Sie sich noch einmal den Eingabetyp="Suche" an. Sie können diese Art von Eingabefeld auch in Betracht ziehen, da diese Art von Eingabefeld in Safari als Suchsteuerung auf Systemebene dargestellt wird und rechts ein X vorhanden ist, auf das geklickt werden kann, um die Suchschlüsselwörter zu löschen. In anderen Browsern erhalten Sie ein Textfeld, genau wie wenn Sie „input type="text" eingegeben hätten, das Textfeld, mit dem Sie bereits sehr vertraut sind. Warum also nicht input type="search" verwenden? Es wird keine Nebenwirkungen haben, keine, oder?
HTML5 fügt außerdem neue Attribute zu Eingabeelementen hinzu, z. B. Platzhalter. Kennt jemand die Verwendung dieses Attributs nicht? Das ist richtig, es wird verwendet, um Text im Textfeld vorab zu platzieren. Nein, kein Label – Platzhalter und Labels sind überhaupt nicht dasselbe. Platzhalter sind Beispielinhalte, die das Textfeld akzeptieren kann, und sind im Allgemeinen grau gefärbt. Sobald Sie auf das Textfeld klicken, verschwindet es. Wenn Sie alles, was Sie eingegeben haben, löschen und dann außerhalb des Textfelds klicken, wird es erneut angezeigt.
Natürlich können Sie diese Funktion auch erreichen, indem Sie Code in JavaScript schreiben, aber HTML5 hilft uns, das Problem mit nur einem Platzhalterattribut zu lösen.
Für Browser, die dieses Attribut nicht unterstützen, können Sie natürlich trotzdem JavaScript verwenden, um die Platzhalterfunktion zu implementieren. Es ist auch sehr einfach, über JavaScript zu testen, ob der Browser dieses Attribut unterstützt. Wenn Sie es unterstützen, treten Sie einfach einen Schritt zurück, gehen Sie aus dem Weg und genießen Sie den Erfolg. Wenn es nicht unterstützt wird, können Sie Ihr JavaScript diese Funktion simulieren lassen.
Jetzt muss ich noch ein anderes Thema erwähnen: HTML5 vs. Flash. Vielleicht haben Sie schon einmal davon gehört oder irgendwo Diskussionen darüber gesehen. Ehrlich gesagt verstehe ich es überhaupt nicht. Ich verstehe nicht, wie Menschen einen Streit beginnen können, der ausschließlich auf ihren eigenen Spekulationen basiert.
Erstens: Wenn man von HTML5 versus Flash spricht, meint man weder HTML5 noch Flash. Es bezieht sich vielmehr auf eine Teilmenge von HTML5 und eine Teilmenge von Flash. Konkret beziehen sie sich auf Videos. Wenn Sie also jemanden „HTML5 vs. Flash“ sagen hören, handelt es sich wahrscheinlich nur um HTML5-Video vs. Flash-Video.
Zweitens, wenn es um HTML5 vs. Flash geht, müssen Sie sich entscheiden: Auf welcher Seite stehen Sie? Das ist eigentlich nicht der Fall. Das Design der HTML5-Standards ermöglicht es Ihnen, das Beste aus beiden Welten zu nutzen.
Okay, werfen wir einen Blick auf dieses neue Videoelement. Es ist ein sehr durchdachtes Element und das Design ist einfach und praktisch. In der Mitte können ein Startvideoelement, ein Endvideoelement und Backup-Inhalte platziert werden. Beachten Sie, dass es sich hierbei um Fallback-Inhalte handelt, nicht um Inhalte, die die Barrierefreiheit garantieren, sondern um Fallback-Inhalte. Der folgende Code wurde für Browser geschrieben, die das Videoelement nicht unterstützen:
Was fügen Sie also in den Backup-Inhalt ein? OK, Sie können Flash-Videos abspielen. Auf diese Weise können HTML5-Videos und Flash-Videos zusammenarbeiten. Sie müssen keine Wahl treffen.
Natürlich ist Ihr Code eigentlich nicht so einfach. Da ich hier H264 verwendet habe, unterstützen einige Browser dieses Videoformat. Einige Browser unterstützen dies jedoch nicht.
Tut mir leid, bitte reden Sie nicht mit mir über das Videoformat, ich rege mich auf, wenn ich es höre. Nicht wegen der Technologie. Die Technologie spielt keine Rolle, der Schlüssel liegt darin, dass sie viele Patente, Anwälte, Rechte an geistigem Eigentum usw. beinhaltet. Dies sind die natürlichen Feinde des Webs und haben für mich beim Erstellen einer Website keinen Nutzen.
Aber was Sie eigentlich tun müssen, ist einfach den Backup-Inhalt dort abzulegen. Der Backup-Inhalt kann eine Vielzahl von Videoformaten umfassen. Wenn Sie möchten, können Sie das Quellelement anstelle des src-Attributs verwenden, um ein anderes Videoformat anzugeben.
Wie viel entspricht Snapdragon 8gen2 Apple?
So beheben Sie den Anwendungsfehler WerFault.exe
absoluteslayout
Mongodb und MySQL sind einfach zu verwenden und empfehlenswert
Verwendung des Zahlenformats
Konvertierung von RGB in Hexadezimal
So erstellen Sie Diagramme und Datenanalysediagramme in PPT
Welche sind die am häufigsten verwendeten Drittanbieter-Bibliotheken in PHP?
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
