HTML5 Struktur richtig?
3 0 0 
Matthias Apsel
0 1 
molily
0 molily
0
0 Größen für ein Handy
0 0 0 <h2>
0
1 
Gunnar Bittersmann
HTML5 Struktur richtig?
Moin,
ist diese HTML5 Struktur richtig? Oder sollte etwas verbesser werden?
<!doctype html>
<meta charset="utf-8">
<title>Firma</title>
<link href="css/screen.css" rel="stylesheet" type="text/css">
<header>
<h1>Logo</h1>
</header>
<main>
<article class="left">
<div class="service_top">Service</div>
<div class="aufzahlung">
<ul>
<li>Teil 1</li>
<li>Teil 2</li>
<li>Teil 3</li>
</ul>
</div>
<div class="service_bottom">Service</div>
</article>
<article class="middle">
<div class="competence_top">Kompetenz</div>
<div class="aufzahlung">
<ul>
<li>Teil 2</li>
<li>Teil 3</li>
<li>Teil 4</li>
</ul>
</div>
<div class="competence_bottom">Kompetents</div>
</article>
<article class="right">
<div class="contact_top">Kontakt</div>
<div>
<p>Firma</p>
<p>Tel: xxx - xxx / Fax: xxx - xxx</p>
<p>eMail: emailAdresse</p>
</div>
<div class="contact_bottom">Kontakt</div>
</article>
</main>
<footer></footer>
So sieht das später aus! Achtung ist kein fertiges Design soll nur zeigen wie die Boxen aussehen sollen bzw. wo sie platziert werden!
-
Meine Herren!
Präambel: Es ist sehr schwierig über die semantische Auszeichnung eines Dokuments zu sprechen, wenn der Inhalt fehlt, ich versuche trotzdem mal mein Bestes.
ist diese HTML5 Struktur richtig? Oder sollte etwas verbesser werden?
Du hast keine html-, head- und body-Tags annotiert. Das ist laut HTML5-Spezifikation zwar zulässig, aber ich würde es trotzdem nicht empfehlen: Durch das Weglassen der Tags schränkst du dich selber unnötig ein; dein body kann etwa als erstes Kind keinen Kommentar oder script-Element beinhalten. Lässt man die head- und body-Tags weg, werden die Elemente implizit trotzdem erstellt und das spielt zum Beispiel bei Traversieren im DOM-Baum eine Rolle: Wenn man dein HTML-Grundgerüst nimmt, könnte man auf die Idee kommen, das folgender JavaScript das erste article-Element selektiert:
document.querySelector(':root > article');Das wird allerdings nicht funktionieren, weil das article-Element eben kein Kind des Wurzel-Elements ist, sondern des body-Elements, richtig wäre:
document.querySelector('body > article');Das mag ein wenig kleinlich klingen, aber das Problem ist real, es tritt sehr häufig bei Tabellen auf. Viele Entwickler sind erstaunt darüber, wenn sie merken, dass tbody-Elemente auch implizit erstellt werden, wenn man sie nicht notiert.
Ein anderes Problem beim Weglassen von Tags ist, dass das Dokument von DOM-Parsern, die nicht HTML5 sprechen, in eine vom Standard abweichende Struktur geparst werden. Die Browser-Parser sind davon nicht betroffen, aber einige Programm-Bibliotheken könnten damit ihre Schwierigkeiten haben.
Für die Leserlichkeit ist es auch hilfreich, ich finde es nützlich, wenn die Zusammengehörigkeit von Kopfinformationen durch entsprechende Einrückung und erkennbare Tags ausgezeichnet ist.
Das wäre das Eine.
<header> <h1>Logo</h1> </header>Wenn dort später tatsächlich ein Firmenlogo erscheinen soll, sollte da wohl besser ein img-Element stehen. Oder man fasst das Logo als Teil der Präsentation auf und lädt es dann mittels CSS als Hintergrund-Bild, aber ein Logo ist keine Überschrift.
<article class="left"> <div class="service_top">Service</div> <div class="aufzahlung"> <ul> <li>Teil 1</li> <li>Teil 2</li> <li>Teil 3</li> </ul> </div> <div class="service_bottom">Service</div> </article>Das sieht für mich nicht wirklich nach einem Artikel aus, ein section-Element wäre hier möglicherweise passender als das article-Element. Das gilt auch für die übrigen article-Elemente.
Das div mit der Klasse service_top macht auf mich den Eindruck als enthalte es eine Überschrift, dass sollte sich im HTML entsprechend wiederspiegeln.
Sämtliche andere div-Element machen auf mich einen überflüssigen Eindruck. Wenn ein div-Element nur ein Kind enthält ist das häufig (nicht immer) ein gutes Indiz dafür, dass Element überflüssig ist. Das div mit der Klasse aufzahlung beinhalten beispielsweise nur ein ul-Element. Das div mit der Klasse "service_bottom" beinhaltet nur den Textknoten "Service". Dieses letzte div erscheint mir darüber hinaus gänzlich überflüssig, es trägt die selbe Information, die eigentlich (siehe oben) schon in der Überschrift steckt. Es kann natürlich sein, dass du das aus präsentationsbezogenen Gründen so brauchst, oder dass du Element präventiv schon mal eingepflanzt hast und der Inhalt sich später noch ändert. Aber das kann ich deinem Prototypen nicht entnehmen, deshalb hab ich es einfach mal angesprochen.
<p>Firma</p> <p>Tel: xxx - xxx / Fax: xxx - xxx</p> <p>eMail: emailAdresse</p>p-Elemente sollen Textabsätze in Fließtexten auszeichnen, der Fall liegt hier nicht vor. Eine passendere Alternative wäre zum Beispiel eine Definitionsliste:
<h3>Firma</h3> <dl> <dt>Tel</dt><dd>xxx - xxx</dd> <dt>Fax</dt><dd>xxx - xxx</dd> <dt>Email</dt><dd><a href="mailto:mail@example.com">mail@example.com</a></dd> </dl>Kontaktinformationen sind übrigens typischerweise Teil des Footers <footer> und nicht des Hauptinhaltes <main>. Das muss aber nicht immer so sein, deshalb hab ich ganz zu Anfang mal erwähnt, das es schwierig ist über die Semantik von Prototypen zu reden ist.
Eine letze Anmerkung: Klassennamen solltest du möglichst unabhängig von der Präsentation wählen. Man möchte in aller Regel das Dokument und damit den Inhalt möglichst stark von der Präsentation getrennt haben. Deshalb wählt man häufig nur Klassennamen, die etwas über den Inhalt ihrer Elemente aussagen, die sozusagen, die Semantik noch ein wenig anreichern. Mit CSS lassen sich solche Klassen genauso einfach selektieren, wie präsentationsbezoge Klassen ;)
--
“All right, then, I'll go to hell.” – Huck Finn-
Du hast keine html-, head- und body-Tags annotiert. Das ist laut HTML5-Spezifikation zwar zulässig
Ehrlich? Meine Güte, blos nie was einheitlich definieren sondern möglichst viele Ausnahmen zulassen?
Hab mich noch nicht bis ins letzte Detail mit HTML5 beschäftigt, aber ich dachte das sollte eine Sache mit Hand und Fuß werden. Was wurde da noch alles schwammig belassen?-
Om nah hoo pez nyeetz, Encoder!
Du hast keine html-, head- und body-Tags annotiert. Das ist laut HTML5-Spezifikation zwar zulässig
Ehrlich? Meine Güte, blos nie was einheitlich definieren sondern möglichst viele Ausnahmen zulassen?Das war aber schon immer™ so. http://wiki.selfhtml.org/wiki/Referenz:HTML#Elemente
Was wurde da noch alles schwammig belassen?
Die Frage lässt vermuten, dass dir das durchaus bewusst ist.
Matthias
-
Hello,
Hab mich noch nicht bis ins letzte Detail mit HTML5 beschäftigt, aber ich dachte das sollte eine Sache mit Hand und Fuß werden. Was wurde da noch alles schwammig belassen?
Naja, wenn man viiiel Zeoit hat, kann man sich das ja mal von vorne bis hinten durchlesen:
http://www.w3.org/html/wg/drafts/html/master/Overview.html#contentsEs wird sich aber erst durchsetzen können, wenn mindestens 95% der installierten Browser HTML5 können.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo,
Es wird sich aber erst durchsetzen können, wenn mindestens 95% der installierten Browser HTML5 können.
Die Frage, wann HTML5 »fertig« ist oder wann alle Browser HTML5 unterstützen, ist nicht sinnvoll. HTML5 hat sich schon längst durchgesetzt und es sind Mittel und Wege bekannt, wie jeweils mit älteren Browser umgegangen wird.
Die HTML5-Spezifikation ist ein riesiges Dokument, davon sind große Teile schon seit Jahrzehnten implementiert, andere Teile seit Jahren und andere Teile noch gar nicht. Das wird sich auch nicht groß ändern, höchstens verschieben. Nicht umsonst hat die WHATWG jegliche Versionsnummer aus ihrem »Living Standard« entfernt. Dort stehen breit implementierte Features neben experimentellen. Lediglich das W3C will eine feste »Recommendation« schaffen, indem sie die bereits implementierten Features in eine Spezifikation gießt. Diese hat momentan den Status »Candidate Recommendation« und ist eingefroren. Alle neuen Features fließen in HTML 5.1, das du verlinkt hat. Es ist wichtig, diesen Unterschied zu verstehen.
Mathias
-
Hello,
[...] Lediglich das W3C will eine feste »Recommendation« schaffen, indem sie die bereits implementierten Features in eine Spezifikation gießt. Diese hat momentan den Status »Candidate Recommendation« und ist eingefroren. Alle neuen Features fließen in HTML 5.1, das du verlinkt hast. Es ist wichtig, diesen Unterschied zu verstehen.
Danke für die Klarstellung.
Ich wusste das, war aber ehrlich gesagt zu faul, den Link auf den eingeforenen "Status Quo" zu suchen.Als angelernter Masochist macht es aber immer wieder Spaß, welche Features in welchem Browser nun schon wie funktionieren, und sich darüber zu ärgern, wie sie sein müssten, wenn Praktiker aus der Wirtschaftsinformatik bei der Gestaltung dabei wären... *höhöhö*
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
Hallo,
Meine Güte, blos nie was einheitlich definieren sondern möglichst viele Ausnahmen zulassen?
Ziele von HTML5 sind die Kompatibilität mit vorherigen HTML-Spezifikationen sowie die Kompatibilität mit allen bestehenden HTML-Dokumenten im Web durch die Standardisierung eines toleranten Parsers, den die Browser ohnehin schon eingebaut hatten.
In beiderlei Hinsicht sind die Tags optional und man kann sie nicht mal eben für notwendig erklären. Könnte man schon, aber dann wären valide HTML-4.01-Dokumente plötzlich invalide. Der HTML5-Parser muss ohnehin damit klarkommen, dass die Tags fehlen oder falsch gesetzt sind, schließlich war das einmal erlaubt. Ergo: Sie sind weiterhin optional.
Mathias
-
-
Hallo,
vielen Dank für deine ausführliche Erklärung
Du hast keine html-, head- und body-Tags annotiert.
Habe ich hinzugefügt.
Wenn dort später tatsächlich ein Firmenlogo erscheinen soll, sollte da wohl besser ein img-Element stehen. Oder man fasst das Logo als Teil der Präsentation auf und lädt es dann mittels CSS als Hintergrund-Bild, aber ein Logo ist keine Überschrift.
Ich hab das <h1> gelöscht und ein "img" hinzugefügt
<header> <img src="img/logo.jpg" alt="Logo" title="Logo"> </header><article class="left">
<div class="service_top">Service</div>
<div class="aufzahlung">
<ul>
<li>Teil 1</li>
<li>Teil 2</li>
<li>Teil 3</li>
</ul>
</div>
<div class="service_bottom">Service</div>
</article>> > Das sieht für mich nicht wirklich nach einem Artikel aus, ein section-Element wäre hier möglicherweise passender als das article-Element. Das gilt auch für die übrigen article-Elemente. Habe ich nun wie folgt geändert: ~~~html <section class="left"> <div class="service_top">Service</div> <div class="aufzahlung"> <span><i class="fa fa-check abstand10"></i>Herstellergarantie</span> <span><i class="fa fa-check abstand10"></i>Versandkostenfrei</span> <span><i class="fa fa-check abstand10"></i>Zahlung bequem per Rechnung</span> </div> <div class="service_bottom">Service</div> </section>Das ganze sieht derzeit wie folgt aus
-
@@Chris1996:
nuqneH
<section class="left">
Präsentationsbezogene Klassen ("left") sind keine gute Idee.
<div class="service_top">Service</div>
Sollte das eine Überschrift sein?
<div class="aufzahlung">
<span><i class="fa fa-check abstand10"></i>Herstellergarantie</span>
<span><i class="fa fa-check abstand10"></i>Versandkostenfrei</span>
<span><i class="fa fa-check abstand10"></i>Zahlung bequem per Rechnung</span>
</div>Warum ist das keine Liste (mehr)?
Präsentationsbezogene Klassen ("abstand10") sind keine gute Idee.
Missbrauch des i-Elements. i steht nicht für Icon.
Wozu überhaupt diese Elemente? Man kann auch die span-Elemente (besser: li-Elemente) so stylen, dass sie die ✔ enthalten.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
Om nah hoo pez nyeetz, Gunnar Bittersmann!
Missbrauch des i-Elements. i steht nicht für Icon.
Die großen machen es leider so vor. http://fortawesome.github.io/Font-Awesome/
Matthias
-
Hallo,
Die großen machen es leider so vor. http://fortawesome.github.io/Font-Awesome/
Solche wiederverwendbaren Bibliotheken arbeiten aus guten Gründen so. Sie zielen darauf ab, dass man nur die vorgefertige CSS-Datei und für jedes Icon ein HTML-Snippet einbinden muss. Würden sie hingegen Klassen anbieten, die die Elemente direkt bekommen (z.B. <a href="" class="icon icon-smiley icon-before">), so wären Konflikte vorprogrammiert. Styles des Elements würden die für das Icon nötigen Styles überschreiben. Oder anders herum: Icon-Styles würden :before/:after-Styles des Elements überschreiben. Das kommt in der Praxis ständig vor.
Es ist nur folgerichtig, was Font Awesome da tut. Es ist nicht die sauberste Lösung, sondern die einfachste und robusteste. Natürlich lässt sich das besser machen. Spezifische Lösungen sind immer kürzerer und sauberer, aber sie kosten. Alle Beteiligten müssen genau wissen, was sie tun, alle Beteiligten müssen vorsichtig sein und Konflikte vermeiden. Aus Sicht der Software-Entwicklung sind solche fragilen Lösungen immer problematisch.
Mathias
-
-
Hallo,
<span><i class="fa fa-check abstand10"></i>Herstellergarantie</span>
Missbrauch des i-Elements. i steht nicht für Icon.
Wozu überhaupt diese Elemente? Man kann auch die span-Elemente (besser: li-Elemente) so stylen, dass sie die ✔ enthalten.
Das ist eine Konvention, die m.W. durch Bootstrap popularisiert wurde. Ein leeres Element für Icons zu verwenden, bringt gegenüber direktem :after/:before { content: '☺' } Flexibilität mit sich. Das Icon lässt sich durch Änderung des HTML beliebig positionieren. Es ist von den Styles des Elternelements unabhängig, dadurch ist es robuster. Es kann mit CSS-Selektoren einfacher angesprochen werden (z.B. .parent .icon statt .parent:after/.parent:before). Das Icon ist somit in HTML und CSS ein eigenständiges, beliebig kombinierbares Modul.
Ich habe auf größeren Sites mit beiden Ansätzen gearbeitet. Ich bevorzuge das direkte Einfügen von Icons ohne separates Element, entweder mit Klassen im HTML (z.B.
<li class="icon icon-check icon-before">) oder mit extend eines CSS-Präprozessors.Ich kann allerdings verstehen, wieso CSS-Frameworks mit separaten Icon-Elementen arbeiten. Es passt in das Konzept, wiederverwendbare, in sich geschlossene HTML-/CSS-Module zu bauen. Dabei werden bekannterweise präsentationsbezogene Klassen verwendet. Wenn andere Teammitglieder haufenweise HTML bauen, ohne immer einen Haufen CSS schreiben zu wollen, ist der Toolkit-Ansatz von Bootstrap und Co. unschlagbar.
Die Wahl von i finde ich nicht schlecht. Natürlich steht i nicht für Icon, aber ein leeres span wäre genauso gut/schlecht wie ein leeres i. Da ist ein i wiedererkennbarer, weil man es sonst so gut wie nie verwendet.
Mathias
-
-
-
-
Guten Morgen,
hab noch nee kleine Frage, an was für Größen (Handy) sollte ich meine Seite anpassen? In diversen Tutorials sehe ich immer diese Zahlen
320-759
760-979
1280sind diese OK?
-
Mahlzeit,
320-759
760-979
1280sind diese OK?
Nicht zwingend. Damit deckst du zwar vieles ab aber es gibt z.B. Displays mit 220x176 pixel auch.
Wenn du dich auf feste Pixelbreiten verlässt, könnte das in die Hose gehen.--
42-
Nicht zwingend. Damit deckst du zwar vieles ab aber es gibt z.B. Displays mit 220x176 pixel auch.
Wenn du dich auf feste Pixelbreiten verlässt, könnte das in die Hose gehen.Nach was sollte ich mich dann richten? z.B. ich habe einen Text und ein Bild daneben. Ab wann ist der Zeitpunkt gekommen in dem ich sage, das Bild nach oben und Text darunter.
-
Noch nee kleine Frage, darf ich auf meiner Seite in einem Conten Bereich zwei <h2> Überschriften haben? Oder muss ich dann <3> nehmen und diese formatieren wie die <h2> haben beide eigentlich die gleiche Gewichtung.
-
Hello,
Noch ne kleine Frage, darf ich auf meiner Seite in einem Content Bereich zwei <h2> Überschriften haben? Oder muss ich dann <h3> nehmen und diese formatieren wie die <h2> haben beide eigentlich die gleiche Gewichtung.
Dafür ist die Abstufung H1 bis H6 da. Sie stellen eine hierarchische Ordnung dar.
Nur solltest Du immer mit dem ersten Rang <h1> beginnen. Der kann dann beliebig viele <h2> enthalten, diese wiederum beliebig viele <h3>, usw.
Du solltest auch keine Ebene auslassen. Es wäre also nicht richtig, auf <h1> gleich <h3> folgen zu lassen. Letztlich soll es den Maschinen helfen, Texte zu "verstehen". Unser Auge macht sich da eher an Fontgrößen und Einrückungstiefen fest.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
@@Tom:
nuqneH
Du solltest auch keine Ebene auslassen. Es wäre also nicht richtig, auf <h1> gleich <h3> folgen zu lassen. Letztlich soll es den Maschinen helfen, Texte zu "verstehen".
Und auch assistiven Technologien wie Screenreadern.
IIRC hat Steve Faulkner erst kürzlich darüber gebloggt.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
-
-
-
Mahlzeit,
Nach was sollte ich mich dann richten? z.B. ich habe einen Text und ein Bild daneben. Ab wann ist der Zeitpunkt gekommen in dem ich sage, das Bild nach oben und Text darunter.
Dummerweise gibt es kein Patentrezept. Aber da Smartwatches grad im kommen sind, solltest du sie auf jeden Fall berücksichtigen.
--
42
-
-
-
@@Chris1996:
nuqneH
In diversen Tutorials sehe ich immer diese Zahlen
320-759
760-979
1280sind diese OK?
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
-
