Ich habe das ursprünglich vor über zwei Jahren geschrieben. Es wurde etwas veraltet, besonders jetzt, da HTML5 gekommen ist und HTML viel schöner gemacht hat, als es selbst XHTML 1.1 war. Also habe ich es aktualisiert!
Ich kann nicht anders, als auf jeder schönen Website, die ich sehe, den Quelltext anzusehen. Es ist, als hätte man Röntgenbrillen, die es einem erlauben, jede Person, die man jemals gesehen hat, nach Belieben in Unterwäsche zu sehen. Wie könnte man das nicht? Es ist einfach so verlockend zu sehen, ob eine schöne Website auch mit schönem Code gebaut ist, oder ob ihre Schönheit nur oberflächlich ist. Code? Schön? Sicher. Schließlich ist Code Poesie. Das ist nur HTML, daher kann es nicht so kompliziert und elegant sein wie eine dynamische Sprache, aber es trägt immer noch die Pinselstriche seines Schöpfers.
Das bringt mich zum Nachdenken, was macht schönen Code aus? In HTML läuft es auf Handwerkskunst hinaus. Werfen wir einen Blick auf einige Markup-Sprachen, die so geschrieben sind, wie Markup geschrieben werden sollte, und sehen wir, wie schön es sein kann.
Es ist groß genug, um es auszudrucken und in Ihrem Spind aufzuhängen, um Ihre Freunde zu beeindrucken. Nun, es könnte etwas unhandlich sein. Ich werde die PSD zur Verfügung stellen, falls Sie sie ändern möchten.
- HTML5 – HTML5 und seine neuen Elemente sorgen für das bisher schönste HTML.
- DOCTYPE – HTML5 hat den besten DOCTYPE überhaupt
- Einrückung – Code ist eingerückt, um Eltern-/Kind-Beziehungen zu zeigen und die Hierarchie zu betonen.
- Zeichensatz – Als Erstes im Head deklariert, vor jeglichem Inhalt.
- Titel – Der Titel der Website ist einfach und sauber. Zweck der Seite steht zuerst, ein Trennzeichen wird verwendet und endet mit dem Titel der Website.
- CSS – Es wird nur ein einziges Stylesheet verwendet (Medientypen werden innerhalb des Stylesheets deklariert) und nur guten Browsern bereitgestellt. IE 6 und darunter erhalten ein universelles Stylesheet.
- Body – ID auf Body angewendet, um einzigartiges Seitenstyling ohne zusätzliches Markup zu ermöglichen.
- JavaScript – jQuery (die schönste JavaScript-Bibliothek) wird von Google bereitgestellt. Nur eine einzige JavaScript-Datei wird geladen. Beide Skripte werden am Ende der Seite referenziert.
- Dateipfade – Website-Ressourcen verwenden relative Dateipfade für Effizienz. Inhaltliche Dateipfade sind absolut, vorausgesetzt, der Inhalt wird syndiziert.
- Bildattribute – Bilder enthalten Alternativtext, hauptsächlich für sehbehinderte Benutzer, aber auch zur Validierung. Höhe und Breite werden für die Rendering-Effizienz angewendet.
- Hauptinhalt zuerst – Der Hauptinhalt der Seite kommt nach grundlegender Identität und Navigation, aber vor jeglichem ergänzenden Inhalt wie Seitenleistenmaterial.
- Passende beschreibende Block-Level-Elemente – Header, Nav, Section, Article, Aside… all dies beschreibt den Inhalt, den sie enthalten, besser als die alten Divs.
- Hierarchie – Titel-Tags sind für echten Inhalt reserviert und folgen einer klaren Hierarchie.
- Passende beschreibende Tags – Listen werden als Listen markiert, abhängig von den Anforderungen der Liste: ungeordnet, geordnet und die wenig genutzte Definitionsliste.
- Häufiger Inhalt enthalten – Inhalte, die auf mehreren Seiten vorkommen, werden über serverseitige Includes eingefügt (über jede Methode, Sprache oder jedes CMS, das für Sie funktioniert)
- Semantische Klassen – Über passende Elementnamen hinaus sind Klassen und IDs semantisch: Sie beschreiben, ohne zu spezifizieren. (z. B. "col" ist viel besser als "left")
- Klassen – Werden immer dann verwendet, wenn ähnliche Stile auf mehrere Elemente angewendet werden müssen.
- IDs – Werden immer dann verwendet, wenn ein Element nur einmal auf der Seite erscheint und auf keine andere Weise sinnvoll angesprochen werden kann.
- Dynamische Elemente – Dinge, die dynamisch sein müssen, sind dynamisch.
- Zeichen codiert – Wenn es ein Sonderzeichen ist, ist es codiert.
- Frei von Styling – Nichts auf der Seite wendet Styling an oder impliziert gar, wie das Styling aussehen könnte. Alles auf der Seite ist entweder eine erforderliche Website-Ressource, Inhalt oder beschreibt Inhalt.
- Kommentare – Kommentare sind für Dinge enthalten, die beim Überprüfen des Codes möglicherweise nicht sofort offensichtlich sind.
- Gültig – Der Code sollte den W3C-Richtlinien entsprechen. Tags sind geschlossen, erforderliche Attribute verwendet, nichts veraltet, etc.
Sehr guter Artikel. Mir gefällt die Idee, dem Body eine ID zu geben, daran hatte ich vorher nicht gedacht.
Ich erstelle gerade eine Website, die eine andere Fußzeile hat, das hätte also praktisch sein können :D
Gute Arbeit, Chris. Hier ist ein weiterer nützlicher Link für Ihre Leser . . . http://www.456bereastreet.com/archive/200711/posh_plain_old_semantic_html/
Ich liebe sauberen Code, egal welche Sprache ich verwende – das einzige Problem ist, wenn eine Frist droht und man sich dabei ertappt, wie man seinen Code verschönert, anstatt diese wichtige Anforderung zu erfüllen !!!
Muss man das wirklich tun? Macht es aus SEO-Sicht überhaupt einen Unterschied?
„Wichtiger Inhalt zuerst“
„Es ist am besten, wenn Ihre wichtigsten Inhalte, wie Nachrichten und Veranstaltungen, zuerst im HTML aufgeführt werden können. Wenn Ihre Seitenleiste nur Navigation oder weniger wichtige Inhalte enthält, ist es am besten, wenn sie zuletzt im HTML kommt.“
Ich bin mir nicht sicher, ob es einen Unterschied für SEO macht (und persönlich denke ich, dass SEO nur ein weiterer trendiger Zug ist, auf den Leute aus irgendeinem Grund aufspringen – schreibe guten, gültigen Code und guten Inhalt, und der Rest folgt), aber...
Es macht einen RIESENunterschied für die Barrierefreiheit.
Haben Sie schon einmal versucht, eine Website blind mit einem Screenreader zu besuchen? Müssen Sie wirklich eine 50-Elemente-Liste eines Blogrolls durchpflügen, bevor Sie zum eigentlichen Artikel gelangen?
Wichtiger Inhalt zuerst ist auch einfach gesunder Menschenverstand. Ich meine, warum sollte man das nicht tun? Gibt es irgendeinen triftigen Grund, ÜBERHAUPT, es nicht auf diese Weise zu tun?
Dem schließe ich mich an, David. „SEO“ sollte „BO“ (Browseroptimierung) sein. Nur sehr wenige wissen überhaupt, wonach eine Suchmaschine sucht. Wie Sie sagten: „Schreiben Sie guten, gültigen Code und gute Inhalte, und der Rest folgt.“ Eine gute Designfirma sollte jede Webseite optimieren, die sie hochlädt. Verwenden Sie einfache Tags wie Titel, Beschreibung und ALT, und alles wird gut sein.
Die HTML 5.1 Spezifikation hat jetzt das Element 'main', um dieses Problem der Unterscheidung des Hauptinhalts Ihrer Seite von Header, Footer, Navigationspanel usw. zu lösen.
Gerne sage ich, dass ich jeden Tipp, der auf der Website, an der ich gerade arbeite, aufgeführt ist, verwende. Ich versuche immer, Projekte so zu strukturieren, dass ich die Zeit und die Ressourcen habe, sauberen, semantischen Code zu schreiben. Wenn das nicht gelingt, wenn ein Kunde einfach flexibel im Zeitplan ist, bin ich fast immer bereit, meine eigene Zeit in die Perfektionierung des Codes zu investieren. Am Ende des Tages möchte man stolz auf seine Arbeit sein und wissen, dass man sein Bestes gegeben hat. Schließlich, wer weiß, wer unter die Haube schaut und einen Blogbeitrag über Ihre Website schreibt. Das erinnert mich (:schauder:), ich muss wirklich meine eigenen Websites aktualisieren. Schuster-Kinder-Syndrom. ;)
Alles gut (und es sollte offensichtlich sein), aber die Idee von „Code ist in Abschnitte gegliedert“ ist einfach Unsinn.
Der Seitencode ist für Maschinen, nicht für Menschen. Es sollte keine Rolle spielen, ob er tabellarisch, unordentlich oder sogar alles in einer Zeile ist. Tatsächlich ist es für IE6 manchmal besser, Listen in einer Zeile zu halten, ohne Zeilenumbrüche.
Vielleicht ist das Tabulieren gut, wenn Sie den gesamten Code pro Seite von Hand schreiben, aber wenn Sie ein CMS verwenden, werden Sie höchstwahrscheinlich nicht alle hübschen Formatierungen erreichen.
Und es gibt immer Tools, um den Seitenquellcode schnell zu formatieren, um zu sehen, „wie sie es gemacht haben“, selbst wenn das ursprüngliche HTML „unordentlich“ ist.
Ich denke, es ist extrem wichtig, den Code sauber zu halten, nicht nur für sich selbst, sondern auch für jeden anderen, der in Zukunft an der Website arbeiten muss.
Mir wurden Websites übergeben, bei denen sich die Zeit einfach verdoppelte, weil sich jemand eindeutig nicht um irgendeine Art von Ordnung gekümmert hatte.
Selbst wenn Sie ein CMS verwenden, werden wahrscheinlich Vorlagen verwendet, die Sie irgendwann bearbeiten möchten.
Das ist doch wohl ein Witz. Ihre Codeformatierung ist entscheidend, um leicht verwaltbare Dateien zu pflegen. Selbst mit einem CMS müssen Sie oft Änderungen auf Vorlagenebene vornehmen, und wenn Sie sich durch unübersichtlichen Code wühlen, um das Listenelement in einem Meer des Chaos zu finden, werden Sie sich wünschen, Sie wären besser organisiert gewesen.
Die Qualität Ihrer Codeformatierung ist ein klares Indiz für die Sorgfalt und Gründlichkeit des Programmierers. So einfach ist das.
Das Problem hier ist nur „wann“. Tabulatoren sind für Menschen. Browser wollen nur sauberen, gültigen Code.
Also, Sie haben beide Recht.
Schon mal was von Code-Tidy-Tools gehört, du Noob?
Kein Inline-Styling? Ich möchte nicht für jede wilde Idee, die ich während einer temporären Urlaubs-Umgestaltung haben könnte, wie zum Beispiel ein hässliches grünes DIV innerhalb des Inhaltsbereichs mit einem Hintergrundbild, CSS erstellen. Soll ich das alles in eine eigene CSS-Datei für EINE Seite packen? Ich denke nicht.
Aber im Allgemeinen stimme ich Ihnen zu. Das gesagt, denke ich, dass die meisten Leute, die diese Seite lesen, das bereits wissen. Tun sie nicht?
Sie verwenden das ID-Attribut im Body-Tag, wie im Beitrag gezeigt, und verweisen entsprechend auf dieses Div.
@smickworks: Ich sagte, dass Sie durch das Erstellen eines separaten Stylesheets für nur eine Seite den Vorteil verlieren, CSS im Cache zu haben, aber dennoch – Inhalt sollte von der Präsentation getrennt sein, egal ob er nur auf einer einzigen Seite erscheint oder gemeinsam ist.
Sie können alle CSS-Seiten in eine Datei legen. Es ist nur eine sehr lange CSS-Datei (je nach Website).
Unterstützen diese neuen beschreibenden Blöcke Nicht-HTML5-Browser?
Schön geschrieben ;)
Der Titel sollte NACH dem Meta-Tag mit der Codierung stehen, denn wenn der Titel Nicht-ASCII-Zeichen enthält, kann es ernsthafte Probleme geben – IE kann eine leere Seite anzeigen.
Guter Punkt!
Erfordert gültiges HTML5 nicht sowieso, dass der Zeichensatz an erster Stelle im Head steht?
Nein. Es muss nicht das erste sein. Es muss nur innerhalb der ersten x Zeichen oder Zeilen oder so sein (ich erinnere mich nicht genau). Aber es gibt wirklich keinen Grund, es meiner Meinung nach nicht zuerst zu setzen.
Sehr nützlicher Artikel, danke besonders für die Body-ID. Ich werde dies als Checkliste für meine zukünftigen Websites verwenden.
Hallo zusammen,
Guter Artikel, gute Kommentare.
Ich habe mich auch gefragt, wie man saubereren Code schreibt, bin aber auf einige Hindernisse gestoßen, für die ich immer noch keine gute Lösung gefunden habe.
1: Wie sollten wir PHP, HTML und Javascript in einer Datei kombinieren? Wenn ich PHP code, versuche ich das MVC-Modell zu verwenden und nur einige Schleifen und Echo-Statements in den „View“-Seiten zu verwenden. Aber wenn ich dann auch noch JS dazumische, wird es schnell chaotisch.
2: Wenn Ihr PHP sauberes, gut eingerücktes HTML erzeugen soll, müssen Sie in Ihrem PHP manuell /t und /n codieren. Das macht Ihr PHP weniger sauber und lesbar. Da der PHP-Code eher komplexe Probleme verursacht, für die ich den saubersten Code haben möchte, ziehe ich es vor, weniger sauberes HTML zu haben.
3: Ein Problem, auf das ich kürzlich gestoßen bin. Wenn Sie eine Website haben, auf der Benutzer Inhalte hinzufügen können und bestimmte Tags verwenden dürfen, wie kontrollieren Sie, dass die verwendeten Tags auch sauber sind?
Was sind Ihre Gedanken zu diesen Fragen?
1: Das sollten wir nicht. Verwenden Sie stattdessen ein Vorlagensystem, persönlich mag ich PHPTAL
1: Warum eine Datei? Verschiedene Anwendungsebenen haben unterschiedliche MVC-Verwendungen, man kann Views auf einer Datenbankebene haben, aber diese Views bilden das Modell für die darüber liegende Ebene. Dasselbe gilt für die Client-Ebene, der Server liefert seine View (das HTML) und das ist das Modell der Browserseite. Die Präsentation sollte, wenn MVC angewendet wird, durch CSS gesteuert werden.
2: Sie können die Heredoc-Syntax in PHP verwenden, und Ihr PHP wird viel sauberer und sehr lesbar sein.
3: Das ist Anwendungslogik, man kann immer versuchen, sie zu formatieren und zu validieren, das sollte Spaß machen.
Keine PHP Includes, jsp:includes oder sonstiger Quatsch. Wenn Sie sich entscheiden, den Inhalt an dieser bestimmten Stelle oder überhaupt nicht einzubinden, dann raten Sie mal – Sie müssen alle 150 Seiten Ihrer Website ändern.
Nein, stattdessen verwenden Sie einen Decorator/Kompositor wie sitemesh oder ein MVC-Framework wie RoR, das View-Templating kostenlos bereitstellt.
Fügen Sie keine Header und Footer in Ihre Seite ein – fügen Sie Ihre Seite in Ihre Header und Footer ein!
Wie Sie sehe ich mir den Quellcode von Websites an, die ich besuche, nur um zu sehen, ob Konkurrenten so sauberen Code erstellen, wie ich es kann.
Zur Klarstellung bezüglich IE und XHTML. IE wechselt standardmäßig in den Quirks-Modus mit einem XHTML 1.1 Doctype, nicht jedoch mit XHTML 1.0 Strict.
Zweitens, es ist semantisch, wenn es gelesen werden kann. Ein zusätzliches Div um ein ul herum wird niemanden umbringen. Obwohl ich persönlich die zusätzlichen Divs nicht verwenden würde.
Zuletzt, das Tabulieren des Codes hilft anderen Programmierern – HTML ist nicht nur für Maschinen – jemand muss möglicherweise später damit arbeiten, sei es in einem CMS oder außerhalb, es hilft immens.
Ich fühle mit Ihnen, Chris, ich habe die gleiche Sucht nach gut gemachtem Code.
Ich mache das auch oft. Besonders wenn ich eine hübsche Seite sehe, frage ich mich gerne: „Wie hübsch ist sie unter der Haube?“.
Ich finde es eine Herausforderung, bei dynamischen Seiten ein HTML-Dokument zu generieren, das mit der richtigen Einrückungsstruktur und Zeilenumbrüchen schön aussieht. Es ist so weit gekommen, dass ich einfach den Tatsachen ins Auge sehen muss, dass ich zu viel Zeit damit verbringe und es wirklich einfach in Ruhe lassen sollte.
Schöner Artikel. Schade ist jedoch, dass die Seite, auf der der Artikel steht, nicht validiert wird. H1-Element innerhalb eines A-Elements, fehlendes Alt-Attribut, nicht geschlossene P-Elemente.
Schöne Liste!
Ich frage mich, ob es ein Tool gibt, das meine Website überprüfen und mir Tipps zur Verbesserung geben kann. Oder gibt es sogar ein Tool, das hilft, ein Tabellen-basiertes Design in ein sauberes Div-Design umzuwandeln?
Jeder Hinweis wäre sehr dankbar!
@Inwit,
Ja, es gibt ein solches Werkzeug, das menschliche Gehirn und seine Motivation für Standards und sauberen Code ;-)
Im Ernst: Ich denke, es ist viel besser, Code von Hand neu zu gestalten/zu refaktorisieren, als Software es tun zu lassen.
Ich vertraue selten maschinengeneriertem Code.
Beispiel: Schreckliche Dreamweaver- und Frontpage-Sites… *schüttelt sich*
Ich habe die gleiche Art von Sucht, obwohl ich öfter ein CTRL+SHIFT+S in Firebug mache.
Man könnte argumentieren, dass ein semantisch sauberes Menü keine Umhüllung benötigt.
Der Artikel hat mir gefallen.
Dies ist ein sehr schöner Artikel, ein paar neue Tipps für mich und ein paar gute Ideen, die ich manchmal vergesse. Eine Sache, die mir jemand gesagt hat und die ich jetzt LIEBE, ist, am Ende meiner Divs einen Kommentar einzufügen, der klar macht, zu welchem Div er gehört.
Hallo,
Gute Ratschläge, aber ich würde lieber (und tue es auch) eine Klasse auf den Body legen, anstatt eine ID.
Der Body-Tag ist bereits eindeutig, also wird body.yourclass eindeutig sein, keine ID nötig.
Außerdem könnte die ID, die Sie für Ihren Body wählen, mit einer ID kollidieren, die auf der gesamten Seite verwendet wird.
Zusammenfassend könnte man auch sagen, dass in *einer* Website die Bodies der verschiedenen Seiten dasselbe "Objekt" sind. Ihnen eine ID zu geben würde bedeuten "jeder Body ist eine andere Entität", was nicht stimmt: dieselbe Entität, aber mit kleinen (oder großen) Unterschieden, daher ist die Klasse meiner Meinung nach semantisch besser.
Meine 2 Cents…
In diesem Fall ist die Verwendung einer ID am Body-Element sinnvoll. Sie wird verwendet, um die spezifische geladene Seite anzuzeigen. Dies kann nützlich sein, wenn Sie das Standard-CSS für eine einzelne Seite überschreiben müssen, jetzt haben Sie eine ID, die Sie in Ihrer Selektoranweisung verwenden können.
Ich bin anderer Meinung.
Ein Body erscheint nur einmal, also gibt es keinen Grund, warum Sie keine ID anstelle einer Klasse verwenden könnten.
Warum Sie eine ID anstelle einer Klasse verwenden sollten, ist im Artikel/Bild angegeben. Es dient dazu, einer bestimmten einzigartigen Seite ein bestimmtes einzigartiges Styling zuzuweisen.
Wenn man nun eine Untergruppe mehrerer Seiten hätte, die auf diese Weise gestylt sind, wäre eine Klasse angebracht.
Angenommen, Sie möchten für Ihren Online-Katalog ein bestimmtes anderes Aussehen als für Ihren Blog. Alle Seiten des Katalogs könnten eine Body-Klasse "catalog" haben und einen grünen Hintergrund erhalten.
Aber dann haben Sie eine Seite im Katalog mit Sonderangeboten, geben Sie diesem Body eine ID von "red_hot" und stylen Sie den Hintergrund rot, da er einzigartig ist.
Einiges davon ist unnötig, wenn man ein CMS verwendet, aber wenn man das Laden zusätzlicher Stylesheets vermeiden möchte oder eine spezielle Behandlung über JavaScript wünscht, kann eine ID und/oder Klasse am Body einen sehr nützlichen Hook in Ihr Markup bieten.
Es gibt nur ein Body-Element im Dokument und innerhalb des HTML-Elements, daher kann man es mit einer ID identifizieren. Es spielt keine Rolle, wie viele Dokumente auf Ihrer Website existieren.
@John Lascurettes
Obwohl Sie technisch gesehen Recht haben, dass kein umschließendes Div benötigt wird, ist es aus mehreren Gründen immer noch gut, es zu tun.
Nur ein Beispiel: Zukunftsplanung. Die Schönheit von CSS besteht darin, dass Sie ein Dokument semantisch markieren können und die Präsentationsschicht getrennt bleibt. In einer idealen Welt bedeutet das, dass Sie eine Seite einmal markieren und nach Herzenslust gestalten und neu gestalten können. Sie benötigen JETZT vielleicht kein umschließendes Div, aber es schadet nicht, es bietet mehr Kontrolle, und Sie könnten Ihre Meinung ändern.
Hey, ich liebe den Artikel.. Ich fragte mich, ob Sie mir ein HTML einer Textbox zeigen könnten. Ich brauche es für etwas, aber natürlich weiß ich nicht, wie es aussieht.. Danke!
-Ashley
„Sauberer und schöner Code kann Ihnen auf lange Sicht tatsächlich Zeit sparen, weil er so viel einfacher zu lesen und Dinge zu finden ist.
Das ist SO WAHR! Ich lerne gerade Webdesign, aber das habe ich sehr schnell gelernt. Außerdem konnte ich mich köstlich über das Kauderwelsch amüsieren, das ich beim Bereinigen meiner Vorlagen gefunden habe. :):)
Der HTML-Code ist zwar sauber, aber nichts Besonderes. Wenn Sie eine typische Website wie diese mit dem typischen Header, der Menüleiste, dem Suchfeld, den Sidebars, dem Inhaltsbereich und der Fußzeile gestalten. Es könnte funktionieren. Aber wenn Sie eine Business-Site mit vielen Inhaltsbereichen gestalten, bezweifle ich, dass Ihr sauberer HTML-Code funktionieren würde.
Die 1. Regel, die alle Programmierer befolgen sollten, ist KOMMENTIEREN!!!
1) Sie haben keine Gründe genannt, warum diese Art von Markup nicht funktionieren sollte. Es hätte einfach mehr Elemente und wahrscheinlich mehr dynamischen Inhalt.
2) Kommentare werden sowohl im Bild als auch im Artikel erwähnt und hervorgehoben.
Ehrlich gesagt sind HTML-Kommentare viel weniger wichtig als Code-Kommentare. Und mit Code meine ich echten Code (PHP, JavaScript usw.), nicht Markup (HTML).
Der einzige Grund für die Verwendung eines HTML-Kommentars (wie im Artikel veranschaulicht) ist, wenn nicht völlig offensichtlich ist, was der Code tut. Wie die PHP-Includes.
Beispiel: Sie können die Website sehen und das Markup sehen… braucht man wirklich einen Kommentar, der sagt „Dies ist das Hauptnavigationsmenü“ für ein UL-Element mit der Klasse „main_nav_menu“?
Sie haben eindeutig noch kein großes Projekt gemacht, also wissen Sie es nicht. Gehen Sie zu bbc.co.uk, nytimes.com, msn.com oder einer anderen großen und bekannten Website und erzählen Sie mir dann von schönem semantischem Markup.
re „wow“: Erlauben Sie mir, Ihnen den ought/is-Fehlschluss vorzustellen. Was ist, muss nicht unbedingt sein. Und umgekehrt. Hören Sie auf zu trollen.
Kommentieren… ist das dieses Klammer-Ausrufezeichen-Ding, das ich mache, um mir Notizen zu hinterlassen, damit ich weiß, wo zum Teufel ich mich inmitten all meines Kauderwelschs befinde??
Ich lebe von denen.
@sV : HTML kommentieren? ROFL! Wenn Sie wertvolle Bandbreite verlieren und Ihre Clients verlangsamen wollen, ja, dann ist das definitiv der richtige Weg!
Kommentare sind OK für serverseitige Skripts oder Quellcode, der kompiliert werden soll, während es SCHLECHT ist, sie in Ihren HTML- oder CSS-Code zu setzen.
Wenn Sie Informationen teilen möchten, erstellen Sie eine *Dokumentation*, keine Kommentare.
Und es ist möglich, eine riesige Website sauber zu halten. Tatsächlich müssen Sie es tun, wenn Sie nicht wollen, dass sie nach 6 Monaten Patchen zusammenbricht.
„Sauber“ bedeutet nicht „einfach“, Sie können sauberen komplexen Code produzieren.
Übrigens, Sie müssen nicht kommentieren, wenn es sauber ist ;-)
Ich glaube, ich kann Ihnen nicht mehr zustimmen!
Auch: „HTML/CSS schreiben“ != „Programmieren“
Es ist nur Markup.
Wenn Sie Ihren Namespace intelligent nutzen und aussagekräftige IDs und Klassennamen verwenden, besteht meiner Meinung nach selten ein Bedarf an HTML-Kommentaren.
Das ist ein wunderschönes Bild davon, wie schöner HTML-Code aussieht!
Danke.
Gutes Beispiel, wie man in HTML codiert. Danke. Ich möchte nur hinzufügen, dass Titel-Tags sehr wichtig sind und ich stimme Chris Coyier zu, dass Titel-Tags nach Meta-Tags stehen sollten.
Die Body-ID kann automatisch mit PHP erstellt werden
<body id="<?= basename($_SERVER['PHP_SELF'], ".php")?>">Besonders nützlich, wenn Sie eine Vorlage verwenden.
Ich stimme nicht mit all dem überein. Viele dieser Funktionen werden verwendet, um Ihr HTML/CSS zu überfordern (z. B. das Umhüllen einer Seite in einem DIV dient überhaupt keinem semantischen Zweck – es hilft Designern lediglich, grafische/typografische Effekte zu erzielen). Ähnlich verhält es sich mit dem Sinn, ein Menü in eine Liste zu packen: Es ist eben eine Liste; nicht damit Sie abgerundete Ecken zu Ihren Tabs hinzufügen können.
Ist es außerdem nicht eine bessere Idee, Ihre Überschriften logisch zu organisieren und konsistent zu gestalten? Warum sollten Sie Ihre Überschriften der Ebene 2 von Seite zu Seite ändern – das verwirrt den Benutzer nur.
Schöner Code sollte gut strukturiert und semantisch ausgezeichnet sein. Das macht ihn leicht lesbar.
„Warum die Überschriften der Ebene 2 von Seite zu Seite ändern – das verwirrt den Benutzer nur.“
Der Grund ist, dass Überschriften der Ebene 2 auf Ihrer gesamten Website alle dasselbe bedeuten können, aber das diktiert nicht, dass sie alle gleich aussehen sollten.
Wie genau verwirrt das Ändern des H2-Tags von Seite zu Seite den Benutzer? Die sehen die Tags nicht, also wen kümmert es, ob es H2, H4 oder .sometext ist? Und wenn der einzige Weg, eine gewünschte Seitenpräsentation zu erstellen, darin besteht, sie in einem DIV zu verpacken, was schadet das?
Überschriftenebenen werden von Screenreadern angekündigt, sie können auch damit navigieren. Wenn Sie also einer Seite zuhören, beginnt sie damit, den ganzen Unsinn im Header zu lesen. Sie können einfach die Taste für H1 oder H2 drücken, um den Kauderwelsch zu überspringen und den Inhalt zu hören, der tatsächlich für die Seite relevant ist. Eine konsistente Verwendung von Überschriftenebenen auf Ihrer Website wird für einen blinden Benutzer ein Segen sein.
Sie haben in der Tat ein schönes, sauberes HTML und einige großartige Empfehlungen. Ich würde argumentieren, dass Sie noch etwas vergessen haben. Das HTML sollte auch minimiert werden.
Ich würde fast allem in diesem Artikel widersprechen. Er verfehlt den Punkt völlig. Der Sinn von HTML, CSS und anderen verwandten Technologien ist es, die Website zu erstellen und sie dann in der Regel auf dem neuesten Stand zu halten. Der Sinn von HTML, CSS usw. ist nicht der Selbstzweck. Die Leute bezahlen Sie nicht, um Code zu schreiben, sie bezahlen Sie, um ein Problem zu lösen. Sie wollen also, dass das Problem gelöst wird, ohne neue Probleme zu erzeugen. Die meisten Leute wollen den saubersten, einfachsten Code, der genau die erforderliche Arbeit leistet. Beim Lesen des obigen Artikels würde ich also die wissenschaftlichen Fragen nach dem Warum stellen und es für jeden Punkt beweisen.
# DOCTYPE korrekt deklariert
Warum? Die meisten Webseiten funktionieren auch ohne ihn völlig einwandfrei, wodurch er unnötige Unordnung schafft. Außerdem sind die Leute vom W3 wirklich genervt, dass alle auf ihre Seite verweisen. Sie sagen, wenn Sie dies verwenden müssen, dann legen Sie die .dtd-Datei auf Ihren eigenen Server und verwenden Sie Ihre eigene verdammte Bandbreite.
# Ordentlicher Kopfbereich
Ich stimme zu. Halten Sie die Dinge ordentlich, wie es hier steht.
# Body mit ID
Warum? Was bewirkt das im Vergleich zur Nichtverwendung? Persönlich kann ich mir spezifische Gründe vorstellen, dem Body eine ID zu geben, z. B. wenn man ihn dynamisch ändern will. Andernfalls erhält man Code, der möglicherweise nichts bewirkt.
# Semantisch sauberes Menü
Warum? Wenn sich das Menü wahrscheinlich ändern wird, könnte dies eine gute Regel sein. Aber abhängig von der Menüstruktur und dem Seitenlayout ist dies möglicherweise keine gute Idee.
# Haupt-DIV für alle Seiteninhalte
Warum? Das könnte Code um des Codes willen sein. Welches Problem löst das?
# Wichtiger Inhalt zuerst
Warum? SEO vielleicht? Westliche Menschen lesen von links nach rechts und von oben nach unten. In einem einigermaßen standardmäßigen 3-Spalten-Layout würde ich daher erwarten, dass Header, links, Mitte, rechts, Footer die Reihenfolge des Codes sind, alles andere und ich muss herumjagen.
# Gemeinsamer Inhalt ENTHALTEN
Dem stimme ich einigermaßen zu. Im Allgemeinen eine gute Idee, aber manchmal funktioniert es und manchmal nicht. Es ist ein Architekturproblem.
# Code ist in Abschnitte gegliedert
Oh, ich liebe sauber eingerückten Code. Einrückungen sind mein Freund. Am Rande: Python verwendet Einrückungen als Strukturierungsmethode. So ist eingerückter Code dasselbe wie in den meisten anderen Sprachen, die geschweifte Klammern verwenden, in geschweiften Klammern stehender Code.
# Richtige End-Tags
Ja, aber ich hasse wirklich Leute, die dieses kleine /> am Image-Tag und anderen anbringen. Es funktioniert auch ohne und kein großer Browser hat das geringste Problem damit.
# Hierarchie der Header-Tags
SEO hat seine eigenen Regeln, die Header-Tags für alle ruinieren. Aber auch hier bezahlen Kunden nicht für schönen Code, sie betreiben ein Geschäft, und SEO ist im Allgemeinen sehr wichtig für ihr Ergebnis, daher übertrifft es alle guten Designregeln.
# Inhalt, Inhalt, Inhalt
P vs. BR ist eher eine Stilwahl. Wenn Sie P in Ihrem CSS verfeinern möchten, kann es besser sein, aber wenn nicht, warum nicht bei einem Tag bleiben, das besser mit der Denkweise von Computern übereinstimmt?
# Kein Styling!
Falsch falsch falsch. CSS ist ein Werkzeug wie alle anderen. Tabellen, Schriftarten und andere Tags sind nur Werkzeuge. Eine Tabelle kann eine Million Meilen zurücklegen, mit wenigen Überraschungen, mit denen CSS Sie umbringen wird. Aber auch hier ist es ein Architekturproblem. Wenn Sie Hunderte von handcodierten HTML-Seiten haben, wird CSS Sie bei Ihrer nächsten Website-Überarbeitung retten, aber wenn Sie nur wenige Vorlagen in einer datenbankgesteuerten Website haben, wird zu viel Formatierung in CSS nur im Weg stehen und die Codekomplexität erhöhen.
Meine Regel ist, das richtige Werkzeug für die Aufgabe zu verwenden, nicht mein Lieblingswerkzeug für die Aufgabe. Das richtige Werkzeug sollte zu den wenigsten und kleinsten Dateien führen. Ein gutes Beispiel, wo ich schlechte Verwendung von Dingen wie CSS gesehen habe, ist, wo Sie sagen wir 30 grundverschiedene Seiten auf einer Website haben und all ihr CSS in einer Datei zusammengefasst ist. Genauso schlimm wäre es, das CSS in 30 separate Dateien aufzuteilen.
CSS in einer separaten Datei dient drei Zwecken. Ein gemeinsames Repository für gemeinsamen Code, potenziell ein einziger Ort zur Neuformatierung der gesamten Website und zur Beschleunigung des Ladens der Website, da die CSS-Datei mit 304 beantwortet wird. Wenn das CSS also nicht auf der gesamten Website wiederholt wird, bleibt nur die Beschleunigung der Seitenladezeiten. Wenn Sie also mit der üblichen Situation konfrontiert sind, CSS in eine CSS-Datei zu kopieren, die nur an einer Stelle auf einer selten geladenen Seite verwendet wird, warum ist es dann in der CSS-Datei? Warum nicht so weit gehen, das CSS direkt in ein Style-Attribut zu packen, wo es verwendet wird? CSS-Puristen werden sich darüber aufregen, aber für mich riecht das nach Religion, nicht nach Fakten. Beim guten Programmieren sollte man bedenken, dass echte Menschen diesen Code lesen werden. Wenn eine Person Änderungen an einer Seite vornimmt und zwischen einer CSS-Datei hin- und herspringen und nach bestimmten Tags-Modifikatoren suchen muss, haben Sie dann den Zwecken Ihres Kunden gedient oder den Zwecken einiger Regeln, die jemand in seinem Kopf erfunden hat? Wenn die Style-Modifikatoren genau dort sind, wo Sie Ihre Änderungen vornehmen müssen, haben Sie alles einfacher, unkomplizierter und damit billiger gemacht.
Ich persönlich würde jeden Programmierer entlassen, der mein Geld für „korrekte“ Formatierung verschwendet, die den Code nur verkompliziert und verschleiert und somit den eigentlichen Grund verfehlt, warum er überhaupt eingestellt wurde: Probleme lösen.
Viel wichtigere Coderegeln, die ich auferlege, sind zum Beispiel: Verwenden Sie Englisch im Code. ftr_l.png ist schlecht, während footer_left.png besser ist.
Erstens, ich stimme absolut jedem einzelnen Punkt, den Sie gerade gesagt haben, überhaupt nicht zu.
# DOCTYPE korrekt deklariert
A) Doctypes existieren aus einem Grund. Wenn Sie es nicht verstehen, sollten Sie vielleicht googeln.
# Body mit ID
A) Erklärt in einem meiner obigen Kommentare. Es geht um Kontrolle über und Hooks in Ihr Markup.
# Semantisch sauberes Menü
A) Alles sollte semantisch sauber sein. Hier geht es nicht nur darum, dass Ihre "für IE 6 gemachte" Website in Ordnung aussieht oder Ihr Frontpage-/Dreamweaver-Code funktioniert... es geht um Langlebigkeit, Stabilität und Kompatibilität des Markups.
# Haupt-DIV für alle Seiteninhalte
A) Dies ist derzeit die einzige Möglichkeit, bestimmte Designprobleme wie zentrierte Websites mit fester Breite zu lösen.
# Wichtiger Inhalt zuerst
A) Wieder, früherer Kommentar. Barrierefreiheit. Screenreader-Benutzer sollten nicht Ihre gesamte Blogroll oder Liste wahrscheinlich nicht zusammenhängender Unternehmensdienstleistungen anhören müssen, nur um zu einem Artikel zu gelangen.
Und warum nicht den wichtigen Inhalt zuerst platzieren? Ich habe noch keinen triftigen Grund gehört, warum man dies absichtlich nicht tun sollte, außer aus Entwicklerfaulheit.
# Richtige End-Tags
A) Ein Image-Tag ist per Definition ein selbstschließendes Tag. Wie Link-Tag und Meta-Tags. Ich bin mir nicht sicher, warum Sie mit den Regeln streiten. Es ist, als würde man sagen: Ja, aber ich hasse es, if/else-Code in der Programmierung zu verwenden… ich würde lieber Schildkröte/Shell o_0 verwenden
# Hierarchie der Header-Tags
A) Leute, die SEO-Mist blind lesen und befolgen, sind ihre eigenen schlimmsten Feinde. Gültiger, semantischer Code und nützlicher, relevanter Inhalt sind die einzigen zwei Dinge, um die Sie sich jemals kümmern müssen. Der Rest bringt nur abnehmende Erträge, besonders wenn Sie einen "SEO-Experten" bezahlen, um Ihre Website zu verschmutzen.
# P vs BR ist eher eine Stilwahl.
A) Nein, eigentlich nicht. Es ist eine semantische und strukturelle Wahl. Wenn etwas ein Absatz ist, verwenden Sie den P-Tag, wenn Sie nur einen Zeilenumbruch wollen, verwenden Sie den br-Tag. Ziemlich einfach, wirklich.
# zu viel Formatierung in CSS wird Ihnen nur im Weg stehen und die Codekomplexität erhöhen
A) Nein, einfach falsch. Eine Tabelle für etwas zu verwenden, das keine tabellarischen Daten sind, ist einfach ignorant. CSS zu verwenden, kompliziert die Dinge überhaupt nicht – es vereinfacht die Dinge erheblich.
Schon mal von DRY gehört? Wiederverwendbarer Code? Modularität? Wartungsfreundlichkeit?
A) Das ist möglicherweise das dümmste, was ich je von einer angeblich intelligenten Person gehört habe.
# das CSS direkt in ein Style-Attribut packen, wo es verwendet wird… riecht nach Religion, nicht nach Fakten
Zweitens, ich habe alle Hoffnung auf eine sinnvolle Debatte mit Ihnen zu diesem Thema verloren, als ich dies sah
„Mein Geld für ‚richtige‘ Formatierung zu verschwenden, die nur dazu diente, den Code zu verkomplizieren und zu verschleiern“
Richtige Formatierung verschleiert den Code? Wirklich?
Es würde mich nicht stören, aus diesem Grund von Ihnen gefeuert zu werden, aber es macht mich auch wirklich, WIRKLICH dankbar, dass ich nicht für jemanden wie Sie arbeite.
@Robert Sie scherzen doch, oder?! Wow.
Ich kann nicht glauben, dass du dir die Zeit genommen hast, das zu schreiben. Was für eine Energieverschwendung. Du könntest nicht falscher liegen.
Ich glaube, Robert hat nur gescherzt, oder? Ich meine, alles, was er gesagt hat, war eindeutig weit, weit daneben.
Dann habe ich mir seine Website angesehen. Ich lache mich immer noch kaputt. HAHAHA
@Robert
DOCTYPE: Das Weglassen führt zum Quirks-Modus mit vielen seltsamen Verhaltensweisen, was die Erstellung von Cross-Browser-Implementierungen erschwert, da der Schnelle-Modus in anderen Browsern versuchte, die vielen Eigenheiten von IE zu implementieren. Und das macht alles zu einem Ratespiel.
Und wo haben Sie gehört, dass W3C nicht möchte, dass Leute einen Doctype mit DTD verwenden, der sich auf die W3C-Website bezieht? Es gibt keinen Browser, der die DTD von HTML-Dateien lädt, daher hat diese Aussage keine Grundlage.
Semantisch sauberes Menü
Nicht nur ein semantisch sauberes Menü ist wichtig, sondern das gesamte Dokument. Und der Grund dafür ist, dass Maschinen den Inhalt verstehen und interpretieren können. Assistive Technologien, Suchmaschinen sind die größten Gruppen, die von semantischen Dokumenten profitieren.
Wichtiger Inhalt zuerst
Weil eine Website auf so viele Arten dargestellt werden kann. Ein Mobiltelefon zum Beispiel kann kein dreispaltiges Layout anzeigen. Es muss alles linearisiert werden. Websites werden von so viel mehr als nur einem Browser auf einem Computer aufgerufen. Deshalb sollte das Layout nicht die Reihenfolge Ihres Inhalts bestimmen.
Richtige End-Tags
Das /> ist da, weil es im XHTML-Format ist. HTML im XML-Format. Wenn Ihnen das nicht gefällt, verwenden Sie HTML.
Der Vorteil von XHTML gegenüber HTML ist, dass Sie einen einfachen XML-Parser verwenden können, um das DOM zu lesen und zu iterieren. Wenn Sie HTML haben, benötigen Sie einen SMGL-Parser, der nicht so einfach ist.
Hierarchie der Header-Tags
„SEO hat seine eigenen Regeln, die Header-Tags für alle ruinieren.“ – Und was wäre das?
# Inhalt, Inhalt, Inhalt
P vs BR ist KEINE Stilwahl. Ein P-Element definiert einen Absatz, ein BR ist einfach ein erzwungener Zeilenumbruch. Wie ist BR mehr im Einklang mit der Denkweise von Computern?
# Kein Styling!
Tabellen für das Layout und Schriftarten-Tags sind die falschen Werkzeuge, Punkt. Es geht darum, das Layout vom Inhalt zu trennen.
Insgesamt scheint es, dass Sie Websites als eine rein visuelle Angelegenheit betrachten. Ihre Argumente berücksichtigen nicht, wie das Dokument für verschiedene Medien, wie Screenreader, Handheld-Geräte und Druck, dargestellt werden soll. Das Auslagern des gesamten Layouts in separate CSS-Dateien ermöglicht es Ihnen, diesen verschiedenen Medien ein anderes CSS zu servieren.
Wenn eine Website 30 Seiten hat, die 30 verschiedene Stylesheets benötigen, dann ist die eigentliche Frage, warum sie 30 verschiedene Stylesheets benötigt? Warum gibt es keine Konsistenz?
„Ich würde jeden Programmierer feuern, den ich dabei erwische, wie er mein Geld für ‚richtige‘ Formatierungen verschwendet, die nur dazu dienten, den Code zu verkomplizieren und zu verschleiern und somit den eigentlichen Grund zu verfehlen, warum er überhaupt eingestellt wurde; Probleme zu lösen.“
CSS verkompliziert oder verschleiert nicht. Das läge allein an der Person, die den Code schreibt.
Einige Ihrer Fragen sind gültig, wenn Sie die Artikel als spezifisches Beispiel betrachten. Mehrere der DIVs und IDs sind möglicherweise nicht erforderlich. Es hängt alles von jeder Website ab, und das Markup sollte an jeden Fall angepasst werden.
Viele Ihrer Fragen bezüglich Semantik und der Trennung von Layout und Inhalt halten jedoch nicht stand. Haben Sie sich über die Vorteile von Web-Semantik informiert? Den Wert der Trennung von Inhalt, Layout und Verhalten?
Thomas, verlieren Sie Ihre Energie nicht mit Robert, wir leben offensichtlich nicht in derselben Welt ;-)
Im besten Fall ist es ein Troll, im schlimmsten Fall glaubt er wirklich, was er sagt…
Er ist genau die Art von Kunde, die jeder Freiberufler fürchten sollte…
Er glaubt, er sei klug genug, um nicht nur Ihre Arbeit zu erledigen, sondern Ihre Arbeit auch besser zu erledigen.
Kurz gesagt: Gefährlich.
„Im Allgemeinen finde ich, dass die Darstellung Ihrer Seite mit den wenigsten (und nicht weniger) Elementen die bevorzugteste ist.“
Ja – mit einer Einschränkung. Manchmal ist es nützlich, an Stellen, an denen es später als Styling-Hook nützlich sein könnte, ein zusätzliches Div hinzuzufügen. Ein paar Mal habe ich mich verflucht, weil ich keine Ersatz-Styling-Hooks eingefügt hatte, als ich etwas ändern wollte, und musste entweder darauf verzichten oder jede Seite durchgehen, um sie hinzuzufügen. Ein paar zusätzliche Divs um wichtige Abschnitte der Seite schaden nicht und könnten Ihnen auf lange Sicht viel Zeit sparen.
„Nein, nein, nein. Warum sollten Sie sich überhaupt die Mühe machen, den Zeichensatz festzulegen, wenn Sie die darin enthaltenen Zeichen nicht verwenden? Setzen Sie einfach das ©-Symbol direkt in Ihren Code, eine Praxis, die es richtig anzeigt, solange Sie den richtigen Zeichensatz festgelegt haben.“
Nein, nein, nein. Wissen Sie, welchen Zeichensatz Ihr Texteditor verwendet? Ich nicht – es könnte Windows-1252 sein, soweit ich weiß. UTF-8 in die dritte Zeile eines Klartextdokuments einzutippen, speichert das Dokument nicht auf magische Weise in UTF-8! Ich bleibe lieber auf der sicheren Seite und verwende die Zeichenkodierung, und garantiere, dass sie in jedem Browser richtig angezeigt wird.
Wenn Sie Ihre Dateien nicht in UTF-8 speichern können, sollten Sie kein Webentwickler sein (oder härter lernen).
Wenn Sie wissen, was Ihr Editor tut (und Ihr Webserver), dann gibt es keinen Grund, kodierte Entitäten zu schreiben.
Amen dazu. Warum sollte man diese schrecklichen Codierungsstrings verwenden, anstatt seine Dateien UTF-8 (ohne BOM) kodiert zu speichern.
Das erspart Ihnen eine Menge Ärger.
Großartiger Artikel, aber können Sie mir bitte sagen, wie ich vorgehen soll, um den „wichtigen Inhalt“ zuerst zu erhalten. Ich verwende PHP-Includes, um meine Navigation und den Footer zu verwalten, und im HTML-Quelltext ist der Navigationsteil zuerst. Wie bekomme ich den „Inhalt“ zuerst gelesen?
Danke
Sie würden den Inhalt vor, sagen wir, Ihrer Seitenleiste einfügen, wenn Sie einen typischen Blog als Beispiel nehmen.
Der Hauptgrund ist Barrierefreiheit.
Eine Person mit einem Screenreader (der linear die Seite herunterliest) sollte nicht Ihre 50-Elemente-Liste von Kategorien und Blogroll überspringen müssen, nur um zu Ihrem Artikel zu gelangen.
Hey, wenn Sie Haml für all Ihre HTML-Bedürfnisse verwenden, sind Sie bereits auf halbem Weg!
Sehr schöner Artikel, ich würde jedoch einen weiteren Tipp zu Ihrer Liste vorschlagen: Verwenden Sie das richtige Grafikdateiformat für den richtigen Bildtyp.
Ihr "CleanCode"-Bild sollte offensichtlich PNG (oder GIF) sein, NICHT JPEG. JPEG ist für fotografische Inhalte, und Ihr CleanCode-Bild ist eindeutig kein Foto!
Ich habe einige Tests gemacht, und Sie sollten in der Lage sein, ein 8-Bit-PNG mit 32 Farben bei etwa 100-125 KiB zu erstellen, mit einem besseren Endergebnis als Ihre 896 KiB JPEG-Datei. Dasselbe könnte wahrscheinlich mit dem PDF erreicht werden, wenn Sie ein PNG anstelle eines JPEG einbetten.
Was?! Jpeg ist ein unterstütztes Web-Bild!
Danke, dass du all die Idioten rauslässt, Chris, lmao!
Sehr guter Artikel! Ich hatte auch noch nie daran gedacht, eine ID am Body zu verwenden :)
Sauberer Code ist kein Hobby, keine lästige Pflicht oder Arbeit, es ist eine Lebensweise. Ich kann es nicht ertragen, wenn ich eine schrecklich programmierte Website sehe, die gut aussieht, es zerstört einfach meine Bewunderung für den Entwickler, der sie erstellt hat.
Übrigens, ich habe auch Ihre Seite über den Quelltext angesehen, weil ich selbst Webentwickler bin und genau dasselbe mache. Ihre Seite hat ziemlich sauberen Code, mein Freund, gute Arbeit.
Wenn nur jeder angehende Webentwickler diesen Beitrag lesen würde..
Sie könnten Ihr IE-CSS viel stärker vereinfachen, indem Sie bedingte Kommentare verwenden, um Divs mit der ID der IE-Version und einer Klasse von IE zu rendern. Auf diese Weise können Sie alle Ihre Stile in einem Stylesheet zusammenhalten. Das macht die Verwaltung viel einfacher. Sehen Sie sich den Quellcode von newsweek.com an, um zu sehen, was ich meine.
Ich gehe davon aus, dass Sie ein Reset-Stylesheet in Ihrer main.css-Datei verwenden. Das ist für eine kleine Website in Ordnung, aber größere Websites benötigen Stylesheets, die flexibler aufgeteilt sind.
Mit HTML5 müssen Sie kein "type"-Attribut deklarieren.
http://diveintohtml5.org/semantics.html#rel-stylesheet
Unterstützt HTML5 jetzt php-Typ-Tags? :) Jedenfalls, gute Arbeit :)
Warum werden JS-Dateien am Ende der Seite deklariert? Sie sollten eigentlich im Head stehen.
Vielen Dank,
Dies ist gängige Praxis, damit das Laden von JS das Rendern der gesamten Website nicht potenziell verlangsamt.
Wie bereits erwähnt, um Blockierungen (Verlangsamung) zu vermeiden, können Sie auch paralleles Laden Ihrer JS-Dateien verwenden, während Sie diese weiterhin im Head Ihres Dokuments platzieren, um dasselbe Ergebnis zu erzielen.
Ich persönlich verwende paralleles Laden am Ende meines Dokuments, wodurch nicht nur ein schnelleres Laden des Inhalts, sondern auch ein schnelleres Rendering und keine Blockierung gewährleistet wird.
Tatsächlich fügen meine Skripte meine Skripte in den Head des Dokuments ein, was bedeutet, dass es in Dingen wie Firebug immer noch korrekt aussieht.
x
Das Einzige, was ich anders machen würde, ist die Position Ihres H1-Tags. Ich platziere ihn normalerweise um das Website-Logo oder den Titel, falls vorhanden. In diesem Fall würde er in der Zeile stehen, die besagt
Auf diese Weise haben Sie, wenn Ihre Seite ohne Stile angesehen oder gedruckt wird, immer noch einen schönen, großen, fetten H1-Website-Titel oben auf Ihrer Seite. Die restlichen Überschriften können dann mit H2, H3 usw. beginnen. Es mag nicht streng semantisch korrekt sein, aber ist H1 nicht das Nächstliegende, was wir haben (abgesehen von TITLE, das nicht in den Body gehört), um den Website-Titel semantisch zu beschreiben?
Ich dachte, es könnte auch für SEO-Zwecke nützlich sein, aber ich könnte mich irren, wenn der Titel-Tag denselben Inhalt hat und eine höhere Priorität für SEO einnimmt. Weiß jemand die Antwort darauf?
Ich war früher zu 100% dafür, aber jetzt bin ich anderer Meinung. Ich denke, Logos sollten einfach normale Ankerlinks sein und <h1>s sollten für die Hauptüberschrift der jeweiligen Seite reserviert sein. Nur eine persönliche Präferenz. Ich möchte das Wichtigste auf der Seite hervorheben, nämlich den Inhalt auf dieser Seite, nicht das Logo.
Ich muss Chris zustimmen, denn Inhalt ist König und das Logo ist nur zweitrangig. H1-Tags sollten definitiv für Inhaltstitel verwendet werden, nicht für Logos….
Wenn überhaupt, würde ich den Slogan eines Blogs in einen H1-Tag setzen und den Namen und das Logo in normalen 'a'- und img-Tags belassen.
Selbst dann verschwenden Sie einen H1-Tag, seien Sie also vorsichtig, wo Sie ihn zuweisen.
Ihr H1 ist aus SEO-Sicht möglicherweise das wichtigste einzigartige Inhaltselement. Der Seitentitel hilft ebenfalls, aber eher aus der Sicht eines Benutzers, der SERPs betrachtet, als aus der Sicht eines Crawlers, der Ihren Inhalt betrachtet und dessen Relevanz bestimmt. Verankern Sie das Logo, betiteln Sie es und lassen Sie es. „Stellen“ Sie Ihre Seite klar mit dem H1 vor, und Sie sind startklar.
Meiner Meinung nach sollten, um die Relevanz Ihrer Keywords zu erhöhen, Ihr Titel und Ihre Hauptüberschrift fast gleich sein.
So wird es kein Problem geben, wo wir H1 als Titel platzieren sollten, und H1 dient dem gleichen Zweck, d.h. der Beschreibung des Seiteninhalts
Viel Spaß mit dem Beispiel. Ein kleiner Tippfehler in der Titelleiste des _Bildes_ ist mir aufgefallen, da alles andere so sorgfältig präsentiert wird. "beatiful-code" spielt keine Rolle, aber nur zur Info.
Chris,
Nur eine Frage zur Einrückung. Verwenden Sie Tabs oder Leerzeichen dafür? Was das Endprodukt betrifft, so sehr ich meinen Code auch gerne ordentlich organisiert halten möchte, gibt es immer ein Stück Inhalt (z.B. CMS oder einen serverseitigen Prozess), das es durcheinanderbringt.
Beste Grüße
Ich glaube nicht, dass das Endergebnis perfekt formatiert sein muss, verglichen mit den von Ihnen verwendeten Vorlagen.
Maschinen kümmern sich nicht darum, wie es formatiert ist. Sie hingegen müssen den Code lesen und pflegen können.
Auch ich habe Formatierungsprobleme, wenn ich bestimmte Dinge einbeziehe, aber meine Ansichtsvorlagen sind absolut sauber, das ist also die perfekte Lösung für mich.
Sie verwenden UTF-8 und codieren Sonderzeichen. Warum das?
Ich wollte gerade dasselbe fragen. Sicher, wenn Sie Ihre Seiten in UTF-8 schreiben, dann ist es sinnvoll, das Rohzeichen anstelle des Zeichencodes zu schreiben? Es ist aus zwei Gründen sinnvoll: Sie blähen die Dateigröße nicht mit unnötigem Zeug auf; und Sie können lesen, was Sie geschrieben haben, ohne Zeichencodes im Kopf parsen zu müssen!
Wenn Sie alle Zeichencodes ausschreiben, dann hat es wirklich keinen Sinn, UTF-8 zu verwenden.
Ich würde gerne die erweiterbaren Tags wie `section` und `aside` verwenden, aber ich dachte, dass IE6 sie nicht erkennen würde. Kann das jemand bestätigen oder dementieren?
IE6 wird sie ohne ein JavaScript-Shiv nicht sehen -> http://ejohn.org/blog/html5-shiv/
IE 6 macht viele Dinge nicht richtig, und es unterstützt HTML5 ohne externe JS-Hilfe sicher nicht.
Fantastisch! Ich muss HTML5 lernen.
Das Tolle daran ist, dass es nicht viel zu lernen gibt, HTML5 ist recht ähnlich zu XHTML 1.0 – 1.1 :)
Hallo,
Ich mag Ihre Beschreibung von schönem HTML-Code, aber ich möchte eine Ergänzung zu HTML5 hervorheben, die dies noch schöner macht. Die Definition des Zeichensatzes in HTML5 ist so möglich
Eine Erklärung, warum dies funktioniert, findet sich in dieser öffentlichen HTML-Mailinglisten-Nachricht (via Mark Pilgrim).
Hoppla, das hat überhaupt nicht funktioniert – der Code wurde nicht angezeigt. Lassen Sie mich es noch einmal versuchen (und fügen Sie diesen Kommentar gerne mit dem vorherigen zusammen)
<meta charset="utf-8">Ah, und zweitens besteht keine Notwendigkeit, Zeichen außer < und & zu maskieren. Der Code sieht viel besser aus, wenn nur die notwendigen Zeichen codiert sind.
Danke für die Aktualisierung, Chris! Es ersetzt das alte an meiner Wand.
Großartige Sachen, Chris.
Ich habe eine Frage, die möglicherweise mein eigenes Versehen ist. Mir ist aufgefallen, dass Sie dem footer-Tag eine Klasse hinzugefügt haben, was impliziert, dass es gestylt werden sollte, anstatt eines Divs namens footer. Aber ohne ein javascript createElement shiv erkennen IE7 und IE8 den footer-Tag nicht. Sind die bedingten IE CSS-Aufrufe im Head dazu gedacht, dies zu berücksichtigen?
Ich habe hin und her überlegt, ob ich das Shiv aufnehmen soll… Ich habe mich dagegen entschieden, weil es eher eine vorübergehende Sache ist und dieser Artikel nicht wirklich darum geht…
Was die Klasse betrifft, so benötigt sie diese Klasse nicht, um eindeutig gestylt zu werden. Beachten Sie, dass dieser Klassenname mit vielen anderen Elementen auf der Seite geteilt wird („container“). Das ist der Klassenname, den ich für den Clearfix verwende.
Das ist schön für reines HTML.
Wenn jedoch Web-Scripting (z. B. PHP) involviert ist, neigt die Ausgabe dazu, nicht richtig eingerückt zu sein.
Das lässt sich immer noch durch ordentliche Einrückung innerhalb des PHP-Codes beheben. Es ist schwieriger und zeitaufwändiger, aber immer noch möglich.
:( Ich wünschte, mein HTML sähe so aus. Es wird besser, aber im Moment ist es ziemlich chaotisch. Ich habe meinen Titel nicht zuerst, und mein Javascript ist im Head. Ich werde es wahrscheinlich irgendwann in den Footer verschieben, aber wie schlimm ist es? Ich habe document.ready, also wie viel Unterschied macht das? Ich versuche nicht, streitsüchtig zu sein oder so, ich bin wirklich neugierig.
Hey Chris, noch ein Gedanke: Es ist nicht druckbar! Selbst auf 11x17-Tabloid-Papier ist der beschreibende Text etwa 4pt groß. Ich habe dein PSD gehackt und das Code-Beispiel-Fenster erheblich zugeschnitten und dann die rechte Spalte um eine volle Spaltenbreite nach links verschoben. Jetzt, auf 11x17, ist der Text lesbar. Nochmals vielen Dank, dass du dies zur Verfügung gestellt hast! Art
Ich frage mich nur, warum Sie "Sonderzeichen kodieren" würden, wenn Sie bereits utf-8 angeben? Ich kaufe das Argument "schwer zu erkennen, was Ihr Editor verwendet" nicht, weil ... nun ja ... es nicht schwer zu erkennen ist, was Ihr Editor verwendet.
Inhalte, die bereitgestellt werden, kopieren und direkt in den Code einfügen zu können, ohne etwas ersetzen zu müssen, ist ziemlich nett...
Größtenteils gefällt mir Ihr HTML-Layout. Ich würde jedoch sagen, dass die Head- und Body-Elemente innerhalb des HTML-Elements eingerückt sein sollten, um konsistent zu sein.
Sie haben wahrscheinlich Recht, es ist nur so, dass ich sie aus irgendeinem Grund über die Jahre immer hart links gelassen habe. Ich habe wirklich keine Ahnung warum, aber alles andere sieht für mich jetzt komisch aus.
Ich weiß nicht, ob das schon erwähnt wurde, aber wenn Sie HTML5 verwenden und es in IE funktionieren soll, dann müssen Sie dieses http://ejohn.org/blog/html5-shiv/ einbinden, um die Elemente zu stylen.
Das beantwortet eine Frage, die ich hatte
Auf welche Probleme werde ich bei der Browserunterstützung stoßen, wenn ich diese Tipps verwende? Ich gehe davon aus, dass die neuen Tags in älteren Browsern möglicherweise nicht unterstützt werden. Ich würde all dies gerne implementieren, wenn ich wüsste, welche Art von Browserunterstützung verfügbar ist. Möchte mich jemand aufklären?
hervorragender Tipps-Artikel! Ich kannte einige davon, aber definitiv nicht alle! Wunderschön! Danke!
Skript-Tags gehören in den Head-Bereich, nicht wild verstreut im Seitenkörper. Wenn Sie möchten, dass Code nach dem Laden der Seite oder domready ausgeführt wird, verwenden Sie die richtigen Event-Handler.
Diese Skript-Tags sind nicht „wild verstreut“, sie sind speziell am Ende der Seite platziert, damit sie andere Teile der Seite nicht vom Herunterladen abhalten, wodurch die Zeit, die die Seite zum Rendern benötigt, verkürzt wird.
Schauen Sie sich an, was Yahoo dazu zu sagen hat.
Der obige Kommentar sollte <head> section sagen, anscheinend wird HTML hier nicht escaped…. hrmmm alert('Vulnerable to script injection')
Warum verwenden Sie drei Bedingungen für das Stylesheet? Ich mache normalerweise einen normalen Include, den auch IE6 sieht, und dann einen bedingten Include nur für IE6, der defekte Elemente repariert.
Gute Arbeit, Chris.
Gut gemacht. Habe das gerade an einen Freund geschickt.
Sollten -Tags aus Gründen der Barrierefreiheit nicht ein title-Attribut haben?
Soweit ich weiß, sind Titelattribute niemals eine Anforderung, weder für die Validierung noch für die Barrierefreiheit oder sonstiges.
Alt-Attribute bei img-Tags, klar. Aber Titel-Tags sind rein optional.
Titel-Tags sind sicherlich keine Pflicht, aber sie können für die Barrierefreiheit äußerst nützlich sein, insbesondere im Umgang mit Links.
Screenreader können von Link zu Link springen. Wenn der Text Ihres Links also nicht von selbst verständlich ist, benötigen Sie einen Titel-Tag, um Kontext hinzuzufügen.
Davon abgesehen wurde mir gesagt, dass es schlimmer ist, Titel hinzuzufügen, wenn sie mit dem Linktext identisch sind. Daher ist so etwas wie
Sie können <a href="http://www.example.com/" title="Einen Artikel über sauberes HTML ansehen">den Artikel lesen</a>, wenn Sie möchten.ist gut, aber so etwas wie
Sie können <a href="http://www.example.com/" title="Einen Artikel über sauberes HTML ansehen">Einen Artikel über sauberes HTML ansehen</a>ist schlecht. Titel-Tags sollten nur verwendet werden, um Kontext hinzuzufügen, wo dieser fehlt.
Für mich ist die Verwendung von Klassen anstelle von IDs (wo ID als einzelner Aufruf gedacht war) ein Zeichen für schlampigen Code. Ich würde meinen Entwicklern nicht zustimmen, die Klasse für den Abschnitt und den Footer zu verwenden, wenn sie den Footer direkt gestalten sollten und eine ID nur dazu verwenden sollten, das Styling in einzigartigen Szenarien, verschachtelten Footern innerhalb anderer Elemente oder mithilfe fortgeschrittener CSS-Selektoren zu umgehen.
Vielleicht bin ich durch den Anblick von schrecklichem Frontend-Templating-Code (hust, Zen Cart, OS Commerce, Cube Cart, die meisten CMS-Templates) verdorben worden, aber Klassen sind für mich und meine Abteilung im Allgemeinen ein letztes Mittel.
Im zweiten Absatz hätten Sie „(the)“ statt „(they)“ sagen sollen.
Dieser Artikel ist herausragend. Ich bin nur traurig, dass ich ihn in meiner Programmierkarriere nicht früher gefunden habe. Ich bin tatsächlich fassungslos, dass jemand den Mut haben könnte, dies anzufechten. Haben Sie jemals eine „unsaubere“ Website aktualisiert, die von jemand anderem erstellt wurde??? Anscheinend nicht..
Ich weiß nicht. Ich glaube, das Footer-Element ist ungültig, wenn man Überschriften (wie h4) verwendet.
Die Verwendung von h4-Überschriften ist völlig gültig, dieser Fall eingeschlossen.
Code ist Kunst
http://camendesign.com
P.S. Ihr Formular erfordert JS. Bitte beachten Sie http://camendesign.com/website_optimisation_measures
Cool, ich liebe die Codeformatierung, es sieht wirklich toll aus!
Aber... das ist sehr nutzlos und eine Verschwendung unserer Bandbreite. HTML == Ausgabe, nicht Kunst. Wenn Sie die Einrückung weglassen, wird Ihre Seite kleiner und lädt schneller. LOL Ich glaube wirklich, dass es einige Leute gibt, die glauben, dass Suchmaschinen eine Seite höher ranken würden, wenn sie perfekt eingerückt ist. Minimiertes und komprimiertes HTML ist viel wertvoller: weniger Daten, lädt schneller. Wenn Ihre Seite also viele Besucher hat, muss sie minimiert/komprimiert geliefert werden.
Außerdem verwenden Sie UTF-8, daher müssen Sie keine HTML-Entities verwenden, oder?
Ich finde es auch sehr böse, die Skript-Tags am Ende des Body zu platzieren; sie sollten innerhalb der Head-Tags geladen werden. Ich sehe, Sie verwenden jQuery, also sollten Sie einfach das Ready-Ereignis verwenden.
Ich füge Skripte normalerweise in den Head ein, warum am Ende des Body?
<aside><h3>…</h3></aside>ist weit entfernt von schön, wenn man die HTML5-Spezifikation liest. Innerhalb von Gliederungselementen setzen Sie Ihre Überschriften zurück und beginnen Sie neu mit h1.Übrigens, der Kommentar-Escaper dieser Seite funktioniert nicht.
Warum fragen Sie nach unescaped Code, wenn Sie eigentlich escaped Code meinen?
Sie können unescaped Code (den Sie leicht lesen können) einfügen, und er wird vom Browser escaped, wenn er in einem 'code'-Tag ist.
An alle, die sich über die JavaScript-Referenzierung im Head beschweren: http://developer.yahoo.com/performance/rules.html#js_bottom
Großartige Diskussion! Hier sind meine zwei Cent wert
Skript-Aufrufe am Ende.
Ich weiß, dass YSlow darauf großen Wert legt, aber ich habe festgestellt, dass einige Skripte nicht funktionieren, wenn sie am Ende platziert werden, also neige ich dazu, sie im Head zu lassen und sicherzustellen, dass die .js-Dokumente minimiert sind.
Gibt es noch jemanden, der mir zustimmt?
Ähm.. Ich habe das gelesen und musste kommentieren… Sie scheinen zu sagen, wie sauber Ihr Code ist, aber es gibt immer noch ziemlich schlechte Angewohnheiten darin.
* Ihre CSS-Hacks im Header für IE sind NICHT W3C-Standard – obwohl sie einen W3C-Check bestehen würden, sind sie immer noch ein Hack.
* Ihre Pfade sind meist ABSOLUT statt relativ. Sie verwenden nur relative Pfade in Ihren PHP-Includes.
* Ihre Verwendung von UTF-Kodierung für Apostrophe ist nicht notwendig.
* Es sind PHP-Includes, NICHT Server Side Includes – es gibt einen großen Unterschied.
* Wenn Sie den PHP-Parser für jede HTML-Seite einschalten, wird Ihr Server langsamer, es sei denn, Sie sagen, dass Ihre Seite PHP ist… In diesem Fall ist es kein schönes HTML, es ist 'schönes' PHP.
* Google Analytics ist ein unnötiges PHP-Include – der Tracking-Code ist ziemlich Standard und jedem, der ein oder zwei Websites erstellt hat, ist ziemlich klar, was es ist.
* Sagen Sie, 'col' ist ein guter, klarer Name für eine CSS-Klasse?
„…obwohl sie einen W3C-Check bestehen würden, sind sie immer noch ein Hack.“
Bedingte Kommentare sind kein Hack. Sie sind genau das: Kommentare. IE interpretiert sie lediglich anders. Der Start-Hack … das ist ein Hack, weil er einen Fehler in der Rendering-Engine durcheinanderbringt. Bedingte Kommentare sind kein Fehler. Sie wurden so geplant. Wenn Sie sagen wollen, dass bedingte Kommentare ein Hack sind, dann müssen Sie sagen, dass die Webkit CSS-Animationen/Transitionen ein Hack sind, da sie noch nicht in der Spezifikation sind. Die Nutzung einer legitimen Browser-Funktion ist niemals ein Hack.
„Das sind PHP-Includes, KEINE Server Side Includes – es gibt einen großen Unterschied.“
Es gibt keinen GROßEN Unterschied zwischen PHP-Includes und Server Side Includes. Es sind im Grunde dieselben Dinge und ehrlich gesagt sind Sie kleinlich. Es ist eine allgemein anerkannte Sache, sie Server Side Includes zu nennen, weil sie auf dem Server und nicht auf dem Client enthalten sind.
„In diesem Fall ist es kein schönes HTML, es ist ‚schönes‘ PHP.“
Nein, es ist immer noch HTML. PHP ist nur das Zeug innerhalb der PHP-Tags. Alles andere ist immer noch HTML. Der PHP-Parser kümmert sich nicht um alles außerhalb der PHP-Tags.
Google Analytics ist ein unnötiges PHP-Include – der Tracking-Code ist ziemlich Standard und jedem, der ein oder zwei Websites erstellt hat, ist ziemlich klar, was es ist.
Nicht unbedingt. Hängt von Ihrem Grund ab, es in einen Include zu packen. Was ist, wenn Sie im Include Code haben möchten, der den Seitennamen prüft und den Tracking-Code selektiv einfügt. So könnten Sie den Code auf einigen Seiten anzeigen lassen, aber nicht auf anderen. Das ist nur ein Beispiel, ich könnte mir andere vorstellen.
„Sagen Sie, ‚col‘ ist ein guter, klarer Name für eine CSS-Klasse?“
Sicher, wenn es eine Spalte ist und Sie möchten, dass alle Ihre Spalten gleich aussehen.
Eigentlich ist "col" immer noch präsentationstechnisch. Das HTML sagt mir, dass dies eine Spalte sein sollte. Auf einem Telefon sollte es wahrscheinlich keine Spalte sein.
Andererseits bin ich mir nicht sicher, ob wir es 100%ig vermeiden können. Irgendetwas muss dem Browser sagen, dass es in einen Tab, Dialog oder eine Spalte geht.
Ich spiele mit einer Website herum, die ich zu 0 % präsentationstechnisch gestalten möchte, und was ich letztendlich getan habe, war, jedem Block (Abschnitt, da ich HTML5 verwende) eine ID zu geben und dann jQuery zu verwenden, um .addClass(“.dialog”) zu den Abschnitten hinzuzufügen, die als Dialoge gedacht sind.
Im iPhone-Javascript füge ich die Klasse nicht ein, da sie dort keine Bedeutung hat (die Stile für .dialog sind nur für Browser).
Wenn Skripte am Ende des Bodys platziert werden, wird sichergestellt, dass das HTML vor JavaScript geladen wird. Wenn JavaScript-Dateien heruntergeladen und ausgeführt werden, können sie oft dazu führen, dass andere Downloads ins Stocken geraten. Wenn Sie sie also im Head platzieren, laufen Sie Gefahr, eine leere Seite anzuzeigen, während Ihr JavaScript lädt.
Sie am Ende des Bodys zu platzieren, eliminiert dieses Problem. Dies stellt sicher, dass der Inhalt nicht auf die Präsentationsschicht wartet.
Das heißt, ich platziere JS im Head, wenn der Inhalt davon abhängt, wie das Laden einer SWF-Datei oder das Starten einer Kartenanwendung.
Wenn „Code Poesie ist“, dann ist das Neruda. Gut gemacht, Chris.
Ich frage mich jedoch, A List Apart's Beispiel hier: http://www.alistapart.com/articles/previewofhtml5
Hat <section> innerhalb von <article> und du hast das Gegenteil gemacht.
Während ich Ihrem Beispiel zustimme, einfach weil es semantisch logisch erscheint, einen Abschnitt und dann Artikel(e) zu haben. Gibt es einen Unterschied?
Hat <section> innerhalb von <article> und du hast das Gegenteil gemacht.
Sollte sein
Hat einen Abschnitt innerhalb eines Artikels und Sie haben das Gegenteil getan.
Ich würde davon ausgehen, dass das obige Beispiel nicht als harte und schnelle Regel für die semantische Platzierung von Elementen auf einer Seite gedacht ist. Vielmehr ist es ein Beispiel für ein sauberes und leicht lesbares Layout. Ich bezweifle, dass der Autor sagt, er sei auf die beste Art und Weise gestoßen, ein Layout zu erstellen. Vielmehr würde ich denken, dass er nur versuchen will zu beweisen, dass sauberer Code eine schöne Website und eine leicht lesbare macht. Wo Sie ein Sektionselement platzieren, hängt wirklich von Ihrer Website ab. Wenn Sie es in Artikelelemente einfügen, können Sie sich CSS-technisch selbst ins Bein schießen. Jede Website muss daraufhin bewertet werden, was Sie mit der Website erreichen wollen, aber wir müssen uns einigermaßen im Bereich der akzeptierten Praxis bewegen. Aber es gibt etwas Spielraum. Zum Beispiel lege ich nie eine Wrapper-Klasse um alles innerhalb des Body-Tags. Aber ich sehe Websites, die das ständig tun. Ich werde nicht aufschreien. Ich halte es für unnötig, da Sie bereits einen Wrapper haben … es heißt Body-Element. Aber viele Leute tun es … Spielraum.
Guter Artikel. Aber wann kann ich ihn verwenden? In 10 Jahren, wenn alle alten Browser tot sind? Webentwickler müssen versuchen, alle Browser zu unterstützen.
Sie können es jetzt sofort verwenden… das ist der Sinn dieses Artikels.
Bieten Sie etwas an, das für ältere Browser funktioniert, aber geben Sie Nutzern moderner Browser ein verbessertes Erlebnis.
Hallo,
Ich genieße Ihre Seite sehr. Ihre Erkenntnisse sind immer eine großartige Lernerfahrung.
Ich habe nach einer Antwort gesucht und konnte keine finden.
Wenn ich HTML5 und CSS3 verwende, wie stelle ich sicher, dass ältere Browser verstehen, was ich tue?
Vielen Dank,
Jack
Ich genieße Ihre Seite sehr. Ihre Erkenntnisse sind immer eine großartige Lernerfahrung.
Ich habe nach einer Antwort gesucht und konnte keine finden.
Wenn ich HTML5 und CSS3 verwende, wie stelle ich sicher, dass ältere Browser verstehen, was ich tue?
Das ist eine gute Frage, die ich gerne beantwortet sehen würde.
Ich denke, das war eine großartige Darstellung, wie HTML aussehen sollte. Es wurde Zeit, dass jemand bemerkte, dass man nur ein Stylesheet haben sollte. Ich würde noch einen Schritt weiter gehen und sagen, dass man heutzutage keine bedingten Stylesheets mehr braucht. Wenn man lange genug mit einer Website experimentiert, kann man die meisten Dinge heutzutage umgehen, sogar für IE6. Man sollte IE7 meiner Erfahrung nach nicht hacken müssen.
Semantische Klassen waren auch eine weitere großartige Sache, die Sie hervorgehoben haben, die Leute denken manchmal nicht an den nächsten, der versucht, ihren Code zu bearbeiten!
Das wäre mein einziger weiterer Kritikpunkt – mehrere Klassen auf einem Element. Das kann eine echte Qual sein, wenn man versucht, am Code eines anderen zu arbeiten, und man in 10 verschiedenen Orten nachsehen muss, um herauszufinden, was all die Klassen tun.
Großartiger Artikel, vielen Dank fürs Posten.
Es ist erwähnenswert, dass, wenn Code tatsächlich Poesie ist, dies als die spezifische Vision einer Person verstanden werden sollte und nicht unbedingt eine, an die sich jeder halten sollte.
Ich bestreite nicht, dass die Vorschläge ungültig sind, aber Schönheit liegt im Auge des Betrachters!
***
Ich arbeite intensiv mit einer anderen Sprache und kann bezeugen, dass es sehr wichtig ist, Sonderzeichen zu kodieren.
Es spielt keine Rolle, wie Sie Ihr Dokument deklarieren oder wie Sie es in Ihrem Editor speichern; jemand wird einen Weg finden, die Seite in einer unbeabsichtigten Kodierung anzuzeigen. Das Kodieren von Sonderzeichen umgeht das ganze Chaos, das daraus entstehen kann (seltsame Zeichen im besten Fall und kaputte Seiten im schlimmsten).
Die eine Herausforderung für mich ist manchmal, den Code schön aussehen zu lassen. Sicher, es ist einfach, wenn man von Grund auf neu codiert oder die volle Kontrolle über die Ausgabefunktionen hat. Einige bestehende Funktionen, wie z.B. wplistpages, geben die Liste "leider" in einer einzigen Zeile aus.
Ich bin auch absolut für sauberen Code und werde wahnsinnig, wenn mein PHP unerwünschte Leerzeichen hinzufügt…
Aber ich habe eine Therapiegruppe besucht, um darüber hinwegzukommen :p jetzt, solange mein Code in meinem Editor sauber ist und im gerenderten Output fast so sauber ist, bin ich glücklich und verliere nicht so viel Zeit damit, es nur für Sauber-Code-Freaks wie mich gut aussehen zu lassen :)
Eine Sache, die Sie vergessen haben, ist international freundlich zu sein, wie z. B. keine Daten wie "11/9/2009" zu verwenden, die Ihre nicht-amerikanischen Leser verwirren.
Die USA sind nicht das einzige Land, das mm/dd/yyyy verwendet. Nach dieser Definition ist es also international. Ich glaube nicht, dass wir im Webdesign so kleinlich sein müssen. Wenn wir diesen Weg einschlagen, sollten wir vielleicht auch amerikanisches oder britisches Englisch standardisieren. Ich denke, die Regel ist, die Formatierung und Regeln zu verwenden, die für Ihre Wähler gelten. Wenn Sie internationale Wähler haben, müssen Sie möglicherweise eine mehrsprachige Website bereitstellen, die auch das Datumsformat dieses bestimmten Landes verwendet.
Sehr viele (die meisten europäischen?) Länder verwenden TT/MM/JJJJ oder eine Variation mit TT vor MM, daher hat Peter einen sehr guten Punkt, obwohl Amerikaner nicht die einzigen sind, die MM zuerst verwenden.
Obwohl ich Amerikaner bin (lebe in Europa), muss ich seinem Punkt zustimmen. ES SEI DENN, Ihre Website ist für eine bestimmte Region bestimmt, in der Sie wissen, dass Ihre Besucher das Datumsformat verstehen werden, sollte ein standardmäßigeres und leicht verständlicheres Format verwendet werden, d.h. 12. November 2009 oder 12. Nov 2009.
Vermeidet jegliche Verwirrung, auch wenn es etwas mehr Platz beansprucht.
@Davin Studer – Tatsächlich ist Belize das einzige andere Land außer den USA, das mm/dd/yyyy verwendet. Siehe Datumsformat nach Land.
Die einfachste Lösung für das Datumsproblem ist die Verwendung des internationalen Standards ISO 8601, der überall unmissverständlich erkennbar ist: JJJJ-MM-TT
Beispiel: 2013-10-29
Ist HTML5 browserübergreifend?
Ich fordere, nein, verlange, dass ein großes Wandplakat davon zum Kauf angeboten wird. Es würde hervorragend neben meinen Sins of a Solar Empire Tech-Tree-Postern aussehen. :D
Interessant, obwohl ich keinen Vorteil darin sehe, absolute Pfade für Ihre Bilder zu verwenden – Können Sie bitte klarstellen, was Sie mit "angenommen, Inhalt wird syndiziert" meinen?
Meinen Sie, wenn Ihre Bilder auf einer separaten Domain liegen? Das wäre der einzige Grund, warum ich absolute Pfade verwenden könnte, aber das versteht sich von selbst.
Oder befürworten Sie, Ihre Medieninhalte auf einem separaten Server zu speichern, um die Download-Geschwindigkeit zu erhöhen (indem Sie die Beschränkung von zwei HTTP-Verbindungen pro Domain umgehen)?
Grüße
Pete
Interessant, obwohl der Kommentar „jquery best js librairy ever“ ziemlich nutzlos ist (aber das ist wirklich ein winziges Detail).
Eine Idee wäre, einen kleinen „zurück nach oben“-Button am unteren Ende der Seiten einzubauen, Chris, da der Scrollbalken manchmal riesig ist (wie hier).
Großartiger Artikel, sauberer Code ist immer leichter zu betrachten und zu aktualisieren!
Frage an die Experten – sollten Ihre PHP-Includes absolute URLs sein, um die Verwendung in verschiedenen Ordnern zu ermöglichen? Und wenn ja, ist die empfohlene Praxis, einfach die Variable $_SERVER['DOCUMENT_ROOT'] davor zu verwenden?
Interessanter Beitrag – ich bin nicht so sehr in CSS involviert, aber irgendwie würde ich ein paar Meta-Tags als Beschreibung und Keywords hinzufügen. Ich denke, Bewertungsseiten schlagen immer noch vor, diese hinzuzufügen.
Auch aus der Sicht einer Suchmaschine weiß ich nicht, wie die Navigation als PHP im fertigen HTML auf der Website aussehen wird – werden die Links dann sichtbar sein… die fertige HTML-Seite hier wäre großartig, um das Ergebnis zu sehen.
Prost
Damals, als ich all meine Websites und die Websites der Unternehmen, für die ich gearbeitet habe, von Hand codiert habe, war ich immer sehr streng in Bezug auf HTML-Standards. Aber jetzt, da ich WordPress benutze, ist das irgendwie über Bord gegangen, nicht weil ich nicht denke, dass qualitativ hochwertiger Code entscheidend ist, sondern weil WordPress meinen Code immer wieder neu zu schreiben scheint, wann immer es möchte. Ich mag den Vorteil, WordPress zu benutzen, mehr als ich es hasse, dass es meinen Code neu schreibt.
Toller Artikel, ich bin ein Suchti nach sauberem Code!
Code wird von Maschinen ausgeführt, aber Maschinen erstellen keinen Code, Menschen tun es. Hässlicher Code macht es für andere schwerer, mit Ihrem Code zu arbeiten, eine wahrscheinliche Situation, wenn Sie jemals in ein professionelles Entwicklungsteam eintreten.
Ich liebe Ihr Posterbeispiel für sauberen Code. Sehr schön! :)
Ein paar Fragen
Ich habe H1 als eine Art Platzhalter für den Seitennamen verwendet und den Text per CSS ausgeblendet, um ihn durch ein Logo zu ersetzen. Ich habe gelesen, dass dies SEO-freundlich ist. Ist es besser, sie für tatsächlichen Inhalt zu reservieren? (Ich habe mit H2 als Hauptinhaltsüberschrift begonnen und von dort aus weitergemacht.)
Wie praktikabel ist es, Sonderzeichen auf einer großen Website zu kodieren, wo Inhalte dynamisch über ein CMS von technisch nicht versierten Personen – oft Journalisten – eingefügt werden? Sollte die CMS-Software & in & und < in < Ø in Ø usw. übersetzen? Oder ist das nur für statische Seiten?
Wie bald erwarten Sie, HTML5 verwenden zu können? Ich liebe es auch und habe es in von mir erstellten iPhone-Web-Apps verwendet, aber für echte Seiten?
Danke! :)
Reich
Verdammt, ich habe meine Liste mit OL und LI geschrieben, anstatt sie selbst zu nummerieren (1. 2. 3.), aber das hat nicht funktioniert. Ich habe auch PRE für mein Sonderzeichenkodierungsbeispiel verwendet, aber das scheint ignoriert zu werden. :-/
Jedenfalls hoffe ich, Sie verstehen die Idee. :)
Übrigens Chris: Was bedeutet "a little long in the tooth"? Klingt cool, aber ich habe es noch nie gehört. Vampir? :)
Ich denke, Sie könnten es etwas kürzen, indem Sie Dan Cederholms Trick verwenden
<!--[if gte IE 7]><!--><link rel="stylesheet" type="text/css" media="screen, projection" href="screen.css" />
<!--<![endif]-->
Haben Sie überprüft, wie es auf IE6 aussieht? Nicht besonders schön. http://browsershots.org/ -> zum Testen. IE6 vermasselt die Dinge wirklich. :S
Das besteht nicht den W3C-Validator. Was ist mit der Gültigkeit passiert?
Exzellenter Tipp Chris :) Ich habe mich immer gefragt, wie "guter Code" aussieht.. das wird mir definitiv auf vielfältige Weise helfen (natürlich in Bezug auf die Codierung)
Mach weiter so. :)
Ausgezeichnet!!! Sehr guter Fortschritt!!
Grüße aus Spanien!!
Auch wenn HTML5 besser ist als 4 und XHTML, wird es doch nur von neuen Browserversionen unterstützt, oder?
Also glaube ich nicht, dass Leute, die sich mit Computern nicht auskennen, ihren Browser wie IE6-Benutzer aktualisieren werden.
Ich liebe es! Warum müssen Sie Höhe und Breite eines Bildes angeben? Das erscheint mir altmodisch. Weiß das hier niemand?
Das hängt davon ab, wie der Browser die Seite rendert. Das Hinzufügen von Breite und Höhe ermöglicht es dem Browser, den richtigen Platz für das Bild zu reservieren. Andernfalls ermittelt er die Dimensionen aus den Bildmetadaten, während es vom Server zum Client übertragen wird.
Unterm Strich führt dies zu weniger Ruckeln beim Laden der Seite.
Cool! Vielen Dank, Russell.
Ich bin ganz für saubere Codierung. Toller Artikel. Ich werde mir die Skripte am Ende ansehen, obwohl sie manchmal oben sein müssen, aber eine interessante Idee.
Großartiges Beispiel Chris, danke für das Teilen des PSDs. Kann es kaum erwarten, HTML5 tatsächlich zu verwenden!
wirklich nützlicher Artikel Chris, meine eigene Website ist in XHTML codiert, aber ich mache ein Redesign und könnte dies in HTML5 codieren :) danke
okay, also mache ich es richtig, denn mein HTML sieht diesem hier sehr ähnlich
Ich denke, Sie können Ihren Code noch schöner machen, indem Sie die Klasse .col weglassen. Sie können die ul's doch über "footer ul" ansprechen, oder?
Die Fußlisten könnten innerhalb von Tags liegen
Hallo Chris
Um ehrlich zu sein, der Code ist nur so lala, besonders da Sie ein so triviales Beispiel zu Demonstrationszwecken verwendet haben =)
Ich weiß, dass viele Leute Komplimente machen, aber wir sollten in der Lage sein, unsere Meinung gleichermaßen auszudrücken.
Hoffentlich wird mein Kommentar nicht gelöscht.
Viele Grüße,
Ich bin sehr inspiriert von den Programmierstilen. Danke für den Artikel.
Prost.
Ich habe kürzlich eine PHP-Funktion zur Bereinigung und Einrückung von XHTML erstellt, die unter snipplr.com zu finden ist und eine gute Ergänzung zu Ihren Tipps sein könnte.
Kleiner Tippfehler im zweiten Absatz
Schauen wir uns einige Markup an, das so geschrieben wurde, wie Markup geschrieben werden sollte, und sehen wir, wie schön es sein kann.
„Dateipfade – Site-Ressourcen verwenden relative Dateipfade für Effizienz“
Diese Idee bricht zusammen, wenn Sie Ihre Assets von verschiedenen Domains oder sogar Subdomains bereitstellen möchten. Zum Beispiel, wenn Sie eine Website mit hohem Traffic haben und die Last verteilen möchten. Verwenden Sie absolute Pfade, um auf die verschiedenen Inhaltsorte in Ihrem Content Delivery Network zu verweisen. z.B. static2.example.com/css/main.css
„Eine CSS-Datei verwenden“
Dies ist eine gute Idee in Bezug auf die Geschwindigkeit, da der Browser nur eine Verbindung herstellen muss, um Ihre Datei herunterzuladen. Für die Modularisierung ist es eine völlige Qual. Die beste Lösung besteht darin, modulare CSS-Dateien zu schreiben und sie zur Laufzeit mithilfe eines serverseitigen Handlers zu einer Datei zusammenzufassen. Auf diese Weise können Sie alle Ihre CSS-Teile als eine Datei bereitstellen, die auch zwischengespeichert und komprimiert werden kann (und sie zwischenspeichern, damit sie nur einmal abgerufen wird).
Lesen Sie die YSlow-Dokumentation für weitere Informationen.
„Einrücken“ – Ihr Code muss natürlich lesbar sein, besonders in der Quelltextansicht. Die Verwendung von Gzip- oder Deflate-Kompression reduziert die Notwendigkeit, Whitespace aus Ihrem Code zu entfernen.
Mein ganzes Gehirn dachte beim Überprüfen nur daran, pro MB heruntergeladener Daten auf meinem Mobiltelefon zu bezahlen und die gesamte main.css-Datei herunterladen zu müssen, um dann das Telefon herausfinden zu lassen, welche Teile des CSS verwendet werden sollen, anstatt eine kleinere, mobil-spezifische Datei zu haben.
Tolle Lektüre, danke!
Großartig, danke fürs Teilen
Toller Artikel.
Ich denke, mein Markup sieht bereits ziemlich genau wie Ihre Gliederung aus, aber ich kann wahrscheinlich einige Bereiche verbessern. Ich muss das Bild vielleicht sogar ausdrucken!
Cool. Es ist schwer, guten Code zu erklären, und es ist gut, ihn auf einem großen Bild zu sehen. Das muss gerahmt werden. Es ist ein Kunstwerk!
Hallo Chris, vielen Dank für den PSD-Download. Wo finde ich jedoch die Schriftart FunctionLH Heavy? Sie verwenden sie für Ihre Abschnittstitel und sie sieht ziemlich gut aus.
Die beste Code-Erklärung, die ich je gesehen habe. Einfach, klar, saubere Sprache, nichts Veraltetes :) wie der W3C-Validator.
Sie haben einen sehr informativen Blog, der viele großartige Ideen bietet.
Der folgende Code hat für mich funktioniert
<body id="”>
Es ruft den Dateinamen der aktuell geladenen Skriptdatei ab und entfernt die Erweiterung.
Großartiges Update, Chris, danke. Ich denke, das ist relevant für das, worauf @paul hinauswollte
Ich verwende gerne Seitenvariablen, um viele Dinge zu deklarieren, einschließlich der Body-ID. So können Sie deklarieren
$activepage = 'about-us';Dann können Sie den Wert in die Body-ID echoen und ihn auch an anderen Stellen verwenden, z. B. innerhalb von Includes usw.
Ich denke, dieses Markup sieht wie eine Blogstruktur aus
Gut, aber Inline-PHP ruiniert alles.
Ich habe gelesen, dass man bei UTF-8-Kodierung und HTML5 nicht „©“ verwendet, sondern das echte Zeichen ©. Können Sie Quellen oder einen W3C-Link angeben, der besagt, dass © in HTML5 besser ist als ©?