nicht angemeldet
Gunnar Bittersmann
Matthias Apsel
Gunnar Bittersmann
molily
Gunnar Bittersmann
Claudius L.
Auge
Auge
Auge
Der Martin
Auge
Hallo werte Selfgemeinde!
Ich suche nach einem Ansatz, um aus meinem HTML Code eine Table of Contents zu generieren.
Rein die Überschriften zu extrahieren und den benötigten HTML Code für die TOC zu erstellen, ist nicht das Problem.
Dazu lese ich den HTML Code per file_get_contents() ein und extrahiere meine Überschriften per:
preg_match_all($pattern, $html, $matches, PREG_SET_ORDER);
Wobei ich aufgrund gewisser bestehender Konventionen[1] folgenden Pattern verwende:
$pattern = '/<[article|section|header|nav|aside].*>(?=\s*<h1 class="section_heading">)\s*<h1 class="section_heading">\s*[<\w-_ ="]*>*([^<\/]*)[<\/\w]*>*\s*<\/h1>/i';
Das liefert mir (sofern Treffer vorhanden sind) ein Array, in dem jeder Treffer zum einen den HTML Teil mit der H1 Überschrift und dem öffnenden Tag des vorhergehenden Elements, und zum anderen den reinen Text der Überschrift.
Soweit so gut (hoffe ich).
Womit ich mich jetzt aber schwer tue ist, eine mögliche Verschachtelung, sprich verschiedene Ebenen zu ermitteln, um meine TOC entsprechend zu gestalten.
Jemand eine Idee, einen Vorschlag, bzw. Tipp für mich?
Besten Dank im Voraus!
Gruß Gunther
[1] Ich verwende nur <h1> Überschriften, die die Klasse "section_heading" haben. Innerhalb der H1 Überschrift können bspw. auch noch Span-Elemente vorhanden sein.
@@Gunther:
nuqneH
Jemand eine Idee, einen Vorschlag, bzw. Tipp für mich?
Nach einer Implementation des Outline-Algorithmus suchen?
[1] Ich verwende nur <h1> Überschriften, die die Klasse "section_heading" haben.
Wenn alle h1 diese Klasse haben, ist das ein sicheres Zeichen, dass die Klasse sinnlos ist.
Qapla'
@@Gunnar:
nuqneH
Jemand eine Idee, einen Vorschlag, bzw. Tipp für mich?
Nach einer Implementation des Outline-Algorithmus suchen?
Was meinst du, was ich bereits gemacht habe? ;-)
Aber ich finde nur hunderte Seiten, die den Outline-Algorithmus erklären, wie er funktioniert. Leider aber keinen einzigen "Hinweis" darauf, wie man das (effizient) mit PHP umsetzt.
[1] Ich verwende nur <h1> Überschriften, die die Klasse "section_heading" haben.
Wenn alle h1 diese Klasse haben, ist das ein sicheres Zeichen, dass die Klasse sinnlos ist.
Nein, es gibt auch noch andere H1 Elemente.
Die Klasse dient mir neben dem Rausfiltern auch noch der entsprechenden visuellen Darstellung.
Und ob sinnlos oder nicht, ich bin ein Freund davon, Elemente, die von der "standardmäßigen Darstellung" abweichen, auch entsprechend zu "kennzeichnen".
Ich wäre aber froh, wenn wir uns in diesem Thread auf das PHP Problem beschränken könnten - danke! :-)
Gruß Gunther
Hi,
Womit ich mich jetzt aber schwer tue ist, eine mögliche Verschachtelung, sprich verschiedene Ebenen zu ermitteln, um meine TOC entsprechend zu gestalten.
Hör’ auf, reguläre Ausdrücke zum Parsen von HTML zu nutzen (was man sowieso nicht tun sollte), und nehme einen DOM Parser stattdessen.
MfG ChrisB
Hi,
Womit ich mich jetzt aber schwer tue ist, eine mögliche Verschachtelung, sprich verschiedene Ebenen zu ermitteln, um meine TOC entsprechend zu gestalten.
Hör’ auf, reguläre Ausdrücke zum Parsen von HTML zu nutzen (was man sowieso nicht tun sollte),
Aha ... OK!
Warum denn eigentlich nicht?
Imho ist das ist in gewissen Fällen nämlich wesentlich einfacher.
In meinem konkreten Fall bspw. verändere ich ja gar nicht den vorhandenen HTML Code, sondern möchte ja nur gewisse Daten daraus extrahieren.
und nehme einen DOM Parser stattdessen.
Welchen? ;-)
Mal angenommen, man würde DOMDocument nehmen, dann weiß ich aber immer noch nicht, wie ich es am geschicktesten anstelle, quasi meine HTML Outline zu generieren?
Da mir das Ganze für mein kleines Projekt jetzt zu aufwendig ist, habe ich mir aktuell anders beholfen (setzte den Level manuell).
Aber für zukünftge Projekte würde es mich dennoch interessieren ...!
Soweit ich das bis jetzt durchblickt habe, müsste ich also
Ist das vom Ansatz her so in etwa korrekt?
Gruß Gunther
Meine Herren!
Hör’ auf, reguläre Ausdrücke zum Parsen von HTML zu nutzen (was man sowieso nicht tun sollte),
Warum denn eigentlich nicht?
Weil sie nur sehr schwierig zu lesen und zu schreiben sind. Die Syntax-Regeln von HTML sind nicht so einfach mit regulären Ausdrücken zu erfassen. Was würde dein regulärer Ausdruck zum Beispiel mit folgendem Schnipsel anstellen:
<span title="<article>">? Es ist schwierig zur erkennen, dass <article> in dem Beispiel zum Attribut-Wert gehört.
Reguläre Ausdrücke stoßen außerdem schnell an ihre Grenzen. Nehmen wir ein einfaches Entscheidungsproblem: Beinhaltet das body-Element gleich viele section-Elemente wie h1-Elemente? Ein regulärer Ausdruck kann das Problem nachweislich* nicht lösen.
*) reguläre Ausrücke sind nicht turingvollständig.
In meinem konkreten Fall bspw. verändere ich ja gar nicht den vorhandenen HTML Code, sondern möchte ja nur gewisse Daten daraus extrahieren.
Mein Beispiel ist zugegebener Maßen sehr konstruiert, aber trotzdem würde dein regulärer Ausdruck daran scheitern.
Für die typischen Aufgaben Traversieren und Manipulieren bietet die DOM-API bereits fertige, erprobte Lösungen, also wieso diese nicht nutzen?
- alle Nodes durchlaufen, um meine H1 Section Heading Nodes zu finden
- bei einem Treffer, den entsprechenden ParentNode nach weiteren Sectioning ChildNodes durchsuchen, wobei sich bei jedem Treffer der Level jeweils um eins erhöht
Ist das vom Ansatz her so in etwa korrekt?
Der offizielle Algorithmus deckt wesentlich mehr Szenarien ab, als deinen spezielle Fall, zum Beispiel auch Verschachtelungs-Tiefe anhand des Rangs (h1,h2,h3,…).
Aufbauend auf dem DOM-Vokabular ist dieser sehr präzise formuliert. http://www.w3.org/TR/html51/sections.html#outlines
Aufbauend auf dem DOM-Vokabular ist dieser sehr präzise formuliert. http://www.w3.org/TR/html51/sections.html#outlines
Ich bin bis dato immer so vorgegangen[*]:
<main role="main">
<h1>Blah</h1>
<div>
<h2>Unterblah</h2>
....
</div>
<div>
<h2>Unterblah 2</h2>
....
</div>
</main>
Da ich mich immernoch recht schwer tue, mit dem Verstehen der englischen Doku vom W3C, nun meine Frage:
Hab ich das falsch gemacht? Gibt es irgendwo eine passable deutsche Beschreibung?
Was mich am allermeisten verwirrt ist, wenn man in jeder semantischen Gruppe ein neues h1-Element benutzt (siehe eines der unteren Beispiele), warum gibt es dann noch die anderen h2-h5-Elemente? Wenn jetzt das erste Beispiel der Grund ist, warum benutzt man dann nicht einfach gruppierende Elemente? Irgendwie muss es ja zusammen gehören, wenn es unter der gleichen Überschrift ist.
MfG
bubble
[*] ich hab hier das div-Element gewählt, weil ja in dem Beispiel so wie es ist nicht abzusehen ist, welches Element semantisch korrekt wäre.
Om nah hoo pez nyeetz, bubble!
warum gibt es dann noch die anderen h2-h5-Elemente?
6 *scnr*
Was mich am allermeisten verwirrt ist, wenn man in jeder semantischen Gruppe ein neues h1-Element benutzt (siehe eines der unteren Beispiele), warum gibt es dann noch die anderen h2-h5-Elemente?
Du musst ja nicht alles sektionieren. Es spricht nichts gegen
<article>
<h1>
<h2>
<p>
<p>
<h2>
Ebenso halte ich
<section>
<h1>
<article>
<h2>!
nicht für falsch.
Matthias
Om nah hoo pez nyeetz, Matthias!
Du musst ja nicht alles sektionieren. Es spricht nichts gegen
<article>
<h1>
<h2>
<p>
<p>
<h2>
>
> Ebenso halte ich
>
> ~~~html
<section>
> <h1>
> <article>
> <h2>!
nicht für falsch.
Das "Problem" hier ist, dass es zwar nicht "falsch" im Sinne von "nicht valide" ist, aber imho auch nicht "korrekt" im Sinne der von HTML5 vorgesehenen Verwendung.
Gunnar hat ja schon auf das "generische H-Element" hingewiesen, was es aber eben aus Gründen der Kompatibilität nicht gibt. Imho ist es jetzt eben nicht <h>, sondern <h1>.
Gruß Gunther
@@bubble:
nuqneH
<main role="main">
<h1>Blah</h1>
<div>
<h2>Unterblah</h2>
....
</div>
<div>
<h2>Unterblah 2</h2>
....
</div>
</main>
>
> Hab ich das falsch gemacht?
Ja. div ist kein sectionig element.
> Was mich am allermeisten verwirrt ist, wenn man in jeder semantischen Gruppe ein neues h1-Element benutzt (siehe eines der unteren Beispiele), warum gibt es dann noch die anderen h2-h5-Elemente?
Die Frage ist: Warum benutzt man h1 statt eines Hierarchieebenen-neutralen h-Elements?
Die Antwort: Weil Hixie unter dem NIH-Syndrom leidet (not invented here).
Das [h-Element](http://www.w3.org/TR/xhtml2/mod-structural.html#sec_8.5.) war in XHTML 2 vorgesehen. Hixie hatte schon nicht den Sinn von XHTML 1 verstanden.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
Hallo,
Die Frage ist: Warum benutzt man h1 statt eines Hierarchieebenen-neutralen h-Elements?
Die Antwort: Weil Hixie unter dem NIH-Syndrom leidet (not invented here).
Du solltest Ad-Hominem-Argumente nicht mit der Erklärung technischer (Fehl-)Entscheidungen verwechseln.
Die Antwort ist eher: Abwärtskompatibilität. h1 hat eine existierende Semantik als Überschrift (erster Ordnung). h hätte für Prä-HTML5-Browser keinerlei Bedeutung. Es wäre fatal, ein Element wie h einzuführen und alle hX dadurch zu ersetzen. Niemand würde es benutzen, weil es die UX für unzählige Benutzer zerstören würde. Von SEO und anderer maschineller Auswertung ganz zu schweigen. Ein h-Element wäre tatsächlich »dangerous fiction.«
Natürlich ist es aus Sicht der Abwärtskompatibilität ebenfalls schlimm, nur h1-Elemente zu haben, die in Prä-HTML5-Browsern wörtlich als Überschriften erster Ordnung genommen werden. Aber nicht so katastrophal wie gar keine vom User-Agent verstandenen Überschriften. Das ist halt ein Kompromiss.
Diesen Kompromiss kann man als faul ansehen. Aber wenn man Sections einführen will, von der expliziten Nennung der Heading-Ebene weg will, zudem die Sprache evolutionär und ohne Kompatibilitätsbrüche erweitern will, dann ist das eine der besseren denkbaren Möglichkeiten. XHTML 2 operierte unter ganz anderen Voraussetzungen, hat die genannten Einschränkungen nicht. Wollte nicht abwärtskompatibel sein, brauchte keine Kompromisse eingehen.
Daher ist es nicht hilfreich, einen solchen Vergleich anzustellen und zu sagen, Hixie habe XHTML 2 nicht verstanden. Das hat er und das haben dutzende andere HTML-WG-Mitglieder bestimmt. Da werden sie keine Antwort auf die Frage gefunden haben, wie man nachträglich und abwärtskompatibel Sectioning in HTML einführt.
Mathias
@@molily:
nuqneH
Die Antwort ist eher: Abwärtskompatibilität.
Vielleicht ist Abwärtskompatibilität die größte Fehlentscheidung von HTML5. Es wurde sowieso ein neuer Parser gebaut.
h hätte für Prä-HTML5-Browser keinerlei Bedeutung. Es wäre fatal, ein Element wie h einzuführen und alle hX dadurch zu ersetzen.
nav hat für Prä-HTML5-Browser ebenfalls keinerlei Bedeutung. Ist die Einfährung auch fatal?
Niemand würde es benutzen, weil es die UX für unzählige Benutzer zerstören würde.
Wieso würde es das? Natürlich müsste man für h explizit Styles angeben, da keine Defaults vorhanden sind. Ebenso wie man das für nav, section, article, … machen muss.
Von SEO und anderer maschineller Auswertung ganz zu schweigen.
Suchmaschinen hätten ruckzuck auch h implementiert.
Natürlich ist es aus Sicht der Abwärtskompatibilität ebenfalls schlimm, nur h1-Elemente zu haben, die in Prä-HTML5-Browsern wörtlich als Überschriften erster Ordnung genommen werden. Aber nicht so katastrophal wie gar keine vom User-Agent verstandenen Überschriften. Das ist halt ein Kompromiss.
Ich wage mal eine andere These: Der Outline-Algorithmus hätte sich eher durchgesetzt, wenn dafür ein neutrales h-Element eingeführt worden wäre. Die Hierarchie-Ebenen von h1 … h6 wären wie angegeben 1 … 6, die Hierarchie-Ebene von h-Elementen wird gemäß Outline-Algorithmus berechnet.
Qapla'
Hi!
Vielleicht ist Abwärtskompatibilität die größte Fehlentscheidung von HTML5.
Das kann man so sehen, meinetwegen. Für valide Kritik an HTML5 ist es wichtig, die Grundprinzipien zu kennen, um zu verstehen, wie Entscheidungen gefällt werden, die damit im Einklang stehen müssen. Mit Kritik am Ende anzusetzen, wenn man eigentlich am Anfang ansetzt, ist unpassend.
Es wurde sowieso ein neuer Parser gebaut.
Es wurde ein Parser spezifiziert, der mit sämtlichem bestehendem Web-Content klarkommt und sich genauso verhält, die die meisten User-Agents es schon taten. Für diejenigen, die nicht gänzlich kaputten Code geschrieben haben, hat sich wenig geändert.
nav hat für Prä-HTML5-Browser ebenfalls keinerlei Bedeutung. Ist die Einfährung auch fatal?
Nein. Aus meinen Ausführungen sollte klar geworden sein, warum nicht.
Neue Elemente wie die Sectioning-Elemente oder die neuen input-Typen einzuführen ist kein großes Problem, es ist zumeist abwärtskompatibel möglich. Ein Problem sind neue Elemente, die alte ersetzen, und gleichzeitig von zentraler Wichtigkeit sind. Daher war die Idee der Spec-Autoren, dass es besser ist, dass Prä-HTML5-UAs einen Haufen an h1 vorfinden, als keine Überschriften.
Niemand würde es benutzen, weil es die UX für unzählige Benutzer zerstören würde.
Wieso würde es das? Natürlich müsste man für h explizit Styles angeben, da keine Defaults vorhanden sind.
Styles sind nicht das Problem. Die fehlende Semantik ist das Problem. <div style="display: block; margin: 1em 0; font-size: 1.5em;"></div> macht noch kein <h1></h1>. Zumindest erzählen wir das ständig allen.
Suchmaschinen hätten ruckzuck auch h implementiert.
Dann hätten User-Agents auch Ruckzuck HTML5-Sectioning implementiert. ;)
Mathias
@@molily:
nuqneH
Neue Elemente wie die Sectioning-Elemente oder die neuen input-Typen einzuführen ist kein großes Problem, es ist zumeist abwärtskompatibel möglich. Ein Problem sind neue Elemente, die alte ersetzen, und gleichzeitig von zentraler Wichtigkeit sind.
h würde keine Elemente ersetzen, sondern h1 … h6 ergänzen. Ja, alte Parser würden in h-Elementen nichts „von zentraler Wichtigkeit“ sehen. So what?
Daher war die Idee der Spec-Autoren, dass es besser ist, dass Prä-HTML5-UAs einen Haufen an h1 vorfinden, als keine Überschriften.
Lieber Überschriften der falschen Ebene als keine Überschriften? Pest und Cholera.
Qapla'
h würde keine Elemente ersetzen, sondern h1 … h6 ergänzen.
Das war so gemeint: Entweder man verwendet h1-h6 oder h. Daher würde h die vorhandenen Elemente in der Praxis ersetzen.
h würde h1-h6 nicht in dem Sinne ergänzen, dass man aus Kompatibilität beides verwendet könnte:
<h><h1>…</h1></h>
oder so etwas. Nicht erstrebenswert. Da müsste man genauso eine dämliche Regel schaffen, die einen HTML5-UA das verschachtelte hX ignorieren lässt. Da finde ich eine Regel, die einen UA die Ebeneninformation ignorieren lässt, schon angenehmer.
Lieber Überschriften der falschen Ebene als keine Überschriften?
Ja. Ich halte das – unter den gegebenen Bedingungen – für einen annehmbaren Kompromiss.
Pest und Cholera.
Es ist beides nicht ideal, das steht außer Frage. Das würde auch niemand behaupten, am wenigsten wahrscheinlich der oft gescholtene Ian Hickson.
Mathias
Hi!
Was mich am allermeisten verwirrt ist, wenn man in jeder semantischen Gruppe ein neues h1-Element benutzt (siehe eines der unteren Beispiele), warum gibt es dann noch die anderen h2-h5-Elemente?
Du meinst h2-h6. ;-)
Imho gibt es die in erster Linie nur wegen der Abwärtskompatibilität.
HTML5 Style ist es, nur noch H1 Elemente zu verwenden.
Das leite ich jedenfalls aus der Aussage:
"h1–h6 elements must not be used to markup subheadings, subtitles, alternative titles and taglines unless intended to be the heading for a new section or subsection." (Quelle: http://www.w3.org/html/wg/drafts/html/master/sections.html#headings-and-sections)
ab.
Wenn jetzt das erste Beispiel der Grund ist, warum benutzt man dann nicht einfach gruppierende Elemente? Irgendwie muss es ja zusammen gehören, wenn es unter der gleichen Überschrift ist.
Welches erstes Beispiel meinst du?
Und ja, wenn ein neuer "Abschnitt" eingeleitet wird, sollte man also ein «Sectioning content» Element verwenden, gefolgt von einer H1 Überschrift. Oder nur eine H1 Überschrift.
Gruß Gunther
@@Gunther:
nuqneH
HTML5 Style ist es, nur noch H1 Elemente zu verwenden.
Nicht machen!! Der Outline-Algorithmus ist in keinem Browser implementiert.
Das leite ich jedenfalls aus der Aussage:
"h1–h6 elements must not be used to markup subheadings, subtitles, alternative titles and taglines unless intended to be the heading for a new section or subsection." (Quelle: http://www.w3.org/html/wg/drafts/html/master/sections.html#headings-and-sections)
ab.
Damit ist gemeint, dass man nicht
<h1>Der Outline-Algorithmus</h1>
<h2>Oder: Ein weiteres Hixie-Hirngespinst</h2>
schreiben soll, wenn „Der Outline-Algorithmus – Oder: Ein weiteres Hixie-Hirngespins“ _eine_ Überschrift ist, wobei die zweite Zeile einen alternativen Titel darstellt.
(Das hgroup-Element ist tot.)
Das wäre als
<h1>Der Outline-Algorithmus
<span class="alternate">Oder: Ein weiteres Hixie-Hirngespinst</span></h1>
auszuzeichnen und entsprechend zu stylen
.alternate
{
display: block;
font-size: 0.7em;
}
Qapla'
@@Gunnar:
nuqneH
HTML5 Style ist es, nur noch H1 Elemente zu verwenden.
Nicht machen!!
Warum nicht? ;-)
Der Outline-Algorithmus ist in keinem Browser implementiert.
Hast du das Wörtchen "noch" vergessen?
Aber davon mal abgesehen, halte ich "klassische" Webbrowser eh nicht für die "Hauptzielgruppe" für die Outline.
Jedenfalls sehe ich bspw. Screenreader da wesentlich weiter vorne.
Hier ein Artikel zum Thema: http://juicystudio.com/article/html5-outline-algorithm-jaws.php
Das leite ich jedenfalls aus der Aussage:
"h1–h6 elements must not be used to markup subheadings, subtitles, alternative titles and taglines unless intended to be the heading for a new section or subsection." (Quelle: http://www.w3.org/html/wg/drafts/html/master/sections.html#headings-and-sections)
ab.Damit ist gemeint, dass man nicht
<h1>Der Outline-Algorithmus</h1>
<h2>Oder: Ein weiteres Hixie-Hirngespinst</h2>
>
> schreiben soll, wenn „Der Outline-Algorithmus – Oder: Ein weiteres Hixie-Hirngespins“ \_eine\_ Überschrift ist, wobei die zweite Zeile einen alternativen Titel darstellt.
>
> (Das hgroup-Element ist tot.)
>
> Das wäre als
>
> ~~~html
<h1>Der Outline-Algorithmus
> <span class="alternate">Oder: Ein weiteres Hixie-Hirngespinst</span></h1>
auszuzeichnen und entsprechend zu stylen
.alternate
{
display: block;
font-size: 0.7em;
}
Schon klar!
Das "Dilemma", in welches man sich gebracht hat, ist ja das wegen der Abwärtskompatibilität jede Überschrift egal welcher Ordnung Heading content darstellt/ darstellen muss.
Somit erzeugt sie eben auch jeweils eine neue (implizite) Section in der Outline.
Der Outline-Algorithmus soll aber ja genau die Problematiken, die uns allen bestens vertraut sind und die durch die Bestimmung des Levels durch den Rang des jeweiligen Überschriftenelements entstehen, verhindern/ vermeiden.
Ich sehe auch aktuell keinerlei Nachteile durch die ausschließliche Verwendung von H1 Elementen.
Und wenn, dann glaube ich persönlich, dass zukünftige Entwicklungen wohl am ehesten den Outline-Algorithmus implementieren werden, als irgendetwas anderes.
Alte und überholte Sachen sterben irgendwann aus ..., auch wenn es manchmal seeehr lange dauert! ;-)
Ich gehe davon aus, dass die Entwicklung dahin gehen wird, dass man das H1 Element quasi als generisches H-Element verwenden wird und die alten H1-H6 Elemente noch eine halbe Ewigkeit "mitschleppen" wird.
Aber warum sollte man sich heutzutage denn noch freiwillig die Probleme mit H1-H6 ans Bein binden?
Gruß Gunther
@@Gunther:
nuqneH
Nicht machen!!
Warum nicht? ;-)
“The HTML5 Document Outline is a dangerous fiction” (Steve Faulkner)
Der Outline-Algorithmus ist in keinem Browser implementiert.
Hast du das Wörtchen "noch" vergessen?
Nein.
“It is a fiction because user agents have not implemented it and there is no indication that any will.”
Aber davon mal abgesehen, halte ich "klassische" Webbrowser eh nicht für die "Hauptzielgruppe" für die Outline.
Jedenfalls sehe ich bspw. Screenreader da wesentlich weiter vorne.
“It is dangerous because it can lead unsuspecting developers to think that using the nesting of heading elements in sectioning elements actually has some effect for users who consume heading semantics. Overwhelmingly the opposite is true.”
Steve Faulkner beschäftigt sich intensiv mit Barrierefreiheit und Screenreadern.
Der Outline-Algorithmus soll aber ja genau die Problematiken, die uns allen bestens vertraut sind und die durch die Bestimmung des Levels durch den Rang des jeweiligen Überschriftenelements entstehen, verhindern/ vermeiden.
“but is essentially a fiction in the real world.”
Ich sehe auch aktuell keinerlei Nachteile durch die ausschließliche Verwendung von H1 Elementen.
“The HTML5 Document Outline is a dangerous fiction”
Und wenn, dann glaube ich persönlich, dass zukünftige Entwicklungen wohl am ehesten den Outline-Algorithmus implementieren werden, als irgendetwas anderes.
“there is no indication that any will.”
Qapla'
Hallo,
“there is no indication that any will.”
Was ist das für eine dubiose Vorhersage?
JAWS hatte es schon implementiert, wenn auch fehlerhaft, und es dann wieder entfernt. Was spricht dagegen, dass sie es irgendwann korrekt implementieren? Technische Komplexität kann es nicht sein.
Leute werden anfangen, gemäß HTML5 Dokumente zu schreiben, es ist schließlich valides Markup mit einer definierten Semantik. Also werden User-Agents die Spezifikation auch implementieren müssen, oder sonst wie sinnvoll damit umgehen müssen. So ist der Lauf der Dinge.
Es gibt hunderte Features im Bereich HTML5, die noch nicht implementiert sind. Die sind alle erst einmal reine Fiktion. Da schreibt niemand großspurige Artikel »dangerous fiction«, obwohl sie genauso »dangerous« sein können, wenn man sie nicht mit vernünftigem Fallback, Polyfill o.ä. einsetzt.
Mathias
@@molily:
nuqneH
“there is no indication that any will.”
Was ist das für eine dubiose Vorhersage? […]
Leute werden anfangen, gemäß HTML5 Dokumente zu schreiben,
Werden die Leute nicht, wenn die Dokumente nicht entsprechend verarbeitet/dargestellt werden, was bei aktuellen Browsern der Fall ist. Henne und Ei.
Also werden User-Agents die Spezifikation auch implementieren müssen
Wer sollte sie dazu zwingen? Massenhaft bereits existierende Dokumente, die auf den Outline-Algorithmus setzen, wohl kaum, s.o.
Und die Implementierung ist auch nicht ganz trivial. Schon die Darstellung wirft Fragen auf.
Die Styles für eine Überschrift 3. Ebene müssten im Browserstylesheet nicht nur für h3 definiert werden, sondern auch für sämtliche Permutationen von <sectioning-element> <sectioning-element> <h-element> gelten (mit <sectioning-element> ∈ {section, article, aside, nav, …} und <h-element> ∈ {h1, …, h6}). Je tiefer die Ebene, umso aufwendiger wird das.
Vermutlich wird man dazu eine Pseudoklasse wie :heading-level(n) benötigen, wobei das n für jedes Element gemäß dem Outline-Algorithmus berechnet wird.
Qapla'
@@Gunnar Bittersmann:
nuqneH
<sectioning-element> <sectioning-element> <h-element>
Nee, nicht mit Nachfahren-, sondern mit Kindkombinator:
<sectioning-element> > <sectioning-element> > <h-element>
Error 907.
Qapla'
Die Styles für eine Überschrift 3. Ebene müssten im Browserstylesheet nicht nur für h3 definiert werden, sondern auch für sämtliche Permutationen von
<sectioning-element> <sectioning-element> <h-element>gelten
Hatten wir das nicht schon? Siehe.
Das Problem scheint schon längst gelöst zu sein.
Mathias
@@molily:
nuqneH
Die Styles für eine Überschrift 3. Ebene müssten im Browserstylesheet nicht nur für h3 definiert werden, sondern auch für sämtliche Permutationen von
<sectioning-element> <sectioning-element> <h-element>geltenHatten wir das nicht schon? Siehe.
Gerade erst gelesen.
Das Problem scheint schon längst gelöst zu sein.
Ja, [link:http://dev.w3.org/csswg/selectors4/#matches@title=:matches()] (:-moz-any()) vereinfacht die Sache.
Qapla'
PS: Rot beim Syntax-Highlighting steht für cool feature? ;-)
Hallo Gunther,
HTML5 Style ist es, nur noch H1 Elemente zu verwenden.
was ich mich hierbei frage, wird es dadurch nicht unter Umständen recht schwierig, passende Selektoren für’s Styling zu finden?
Um ein Beispiel von webdesign.tutsplus.com zu verwenden: Es ist doch sehr wahrscheinlich, dass das erste h1-Element einen anderen Style bekommen soll als das zweite. In diesem einfachen Beispiel ist das noch relativ einfach: h1 vs. article h1 (Beispel auf dabblet).
Aber was tun, wenn es komplizierter wird, beispielsweise geschachtelte sectioning elements? Wenn man dann in jedem sectioning element wieder mit h1 anfängt, wie lassen sich dann Selektoren definieren, die alle Elemente auf einer bestimmten Ebene der Outline treffen?
Übersehe ich hier etwas Wichtiges, oder wäre das doch ein Grund, nicht nur h1 zu verwenden?
Viele Grüße
Claudius
Hallo Claudius,
HTML5 Style ist es, nur noch H1 Elemente zu verwenden.
was ich mich hierbei frage, wird es dadurch nicht unter Umständen recht schwierig, passende Selektoren für’s Styling zu finden?
Aber was tun, wenn es komplizierter wird, beispielsweise geschachtelte sectioning elements? Wenn man dann in jedem sectioning element wieder mit
h1anfängt, wie lassen sich dann Selektoren definieren, die alle Elemente auf einer bestimmten Ebene der Outline treffen?
Die Antwort darauf findest du in jedem Default Stylesheet der Browser.
Beispiel Firefox:
h2, *:-moz-any(article, aside, nav, section) h1 {...}
h3, *:-moz-any(article, aside, nav, section) *:-moz-any(article, aside, nav, section) h1 {...}
Übersehe ich hier etwas Wichtiges, oder wäre das doch ein Grund, nicht nur
h1zu verwenden?
Wie gesagt, aus meiner Sicht spricht nichts dagegen, ausschließlich H1 Elemente zu verwenden.
Wichtig dabei ist nur, dass man dann auch konsequent bei dem Schema bleibt.
Denn was man auf gar keinen Fall tun sollte, ist ein Mischmasch aus beiden Varianten zu verwenden!
Gruß Gunther
Hallo Gunther,
Die Antwort darauf findest du in jedem Default Stylesheet der Browser.
Beispiel Firefox:
h2, *:-moz-any(article, aside, nav, section) h1 {...}
h3, *:-moz-any(article, aside, nav, section) *:-moz-any(article, aside, nav, section) h1 {...}
danke für diesen Hinweis. `any`{:.language-css} kannte ich bisher nicht. [Auf MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/:any#Notes) wird sogar explizit auf die Verwendung in Verbindung mit Überschriften hingewiesen, sehr interessant.
Viele Grüße
Claudius
Hallo
HTML5 Style ist es, nur noch H1 Elemente zu verwenden.
Vielleicht ist mein Englisch ja eingerostet, aber ich lese da etwas ganz anderes.
Das leite ich jedenfalls aus der Aussage:
"h1–h6 elements must not be used to markup subheadings, subtitles, alternative titles and taglines unless intended to be the heading for a new section or subsection." (Quelle: http://www.w3.org/html/wg/drafts/html/master/sections.html#headings-and-sections)
ab.
Ich lese da, man darf eine Überschriftenkaskade nicht dazu verwenden, Untertitel o.Ä. zu realisieren, es sei denn es handelt sich um die Überschriften zu Teilen des Textes („unless intended to be the heading for a new section or subsection“). Wenn ich nicht völlig falsch liege, ist's also nichts mit „nur h1“. Wenn solch Mumpitz eingeführt würde, wärs _mir_ um die Validität egal.
Tschö, Auge
Hallo!
HTML5 Style ist es, nur noch H1 Elemente zu verwenden.
Vielleicht ist mein Englisch ja eingerostet, aber ich lese da etwas ganz anderes.
Ja, das war vielleicht etwas "optimistisch", diese Passage zur Argumentation heranzuziehen.
Und tatsächlich kann man auch das genaue Gegenteil (also die Verwendung von Überschriften entsprechenden Ranges) in der Spec finden.
Das leite ich jedenfalls aus der Aussage:
"h1–h6 elements must not be used to markup subheadings, subtitles, alternative titles and taglines unless intended to be the heading for a new section or subsection." (Quelle: http://www.w3.org/html/wg/drafts/html/master/sections.html#headings-and-sections)
ab.Ich lese da, man darf eine Überschriftenkaskade nicht dazu verwenden, Untertitel o.Ä. zu realisieren, es sei denn es handelt sich um die Überschriften zu Teilen des Textes („unless intended to be the heading for a new section or subsection“).
Ja, das liegt daran, dass Hx Elemente eben "Heading content" sind, also implizit eine neue Section einleiten.
Wenn ich nicht völlig falsch liege, ist's also nichts mit „nur h1“. Wenn solch Mumpitz eingeführt würde, wärs _mir_ um die Validität egal.
Das ist kein Mumpitz, ist schon lange eingeführt und 100%ig valide!
Die Gründe und die Für & Wider sind in diesem Thread ja mittlerweile hinreichend erläutert worden.
Leider ist die Spec oftmals nicht eindeutig genug, bzw. bezieht nicht klar genug Stellung. Und die Codebeispiele sind meistens eher "verwirrend/ irreführend", denn hilfreich.
Gruß Gunther
Hallo
Ich lese da, man darf eine Überschriftenkaskade nicht dazu verwenden, Untertitel o.Ä. zu realisieren, es sei denn es handelt sich um die Überschriften zu Teilen des Textes („unless intended to be the heading for a new section or subsection“).
Ja, das liegt daran, dass Hx Elemente eben "Heading content" sind, also implizit eine neue Section einleiten.
Naja, soll'n se ja auch.
Wenn ich nicht völlig falsch liege, ist's also nichts mit „nur h1“. Wenn solch Mumpitz eingeführt würde, wärs _mir_ um die Validität egal.
Das ist kein Mumpitz, ist schon lange eingeführt und 100%ig valide!
Was ist schon lange eingeführt und 100%ig valide? Die ausschließliche Verwendung von h1? Der von dir zitierte Text sagt ja explizit, dass es nicht so ist und wenn es so _wäre_, wäre es für mich eben doch Mumpitz und ein Grund, auf Validität zu wursten.
Die Gründe und die Für & Wider sind in diesem Thread ja mittlerweile hinreichend erläutert worden.
Nö, immer noch nicht.
Tschö, Auge
Hallo!
Wenn ich nicht völlig falsch liege, ist's also nichts mit „nur h1“. Wenn solch Mumpitz eingeführt würde, wärs _mir_ um die Validität egal.
Das ist kein Mumpitz, ist schon lange eingeführt und 100%ig valide!
Was ist schon lange eingeführt und 100%ig valide? Die ausschließliche Verwendung von h1? Der von dir zitierte Text sagt ja explizit, dass es nicht so ist
Wo sagt der das!?
Er sagt nur (leider) nicht, dass man ausschließlich H1 verwenden sollte (und die Bewertung des Ranges dem jeweiligen verarbeitenden Programm überlassen sollte).
und wenn es so _wäre_, wäre es für mich eben doch Mumpitz und ein Grund, auf Validität zu wursten.
Ich verstehe ehrlich gesagt nicht, was du jetzt mit deiner Validität hast, und warum die ausschließliche Verwendung von H1 Elementen für dich ein Grund sein sollte, "auf Validität zu wursten"!
Die Gründe und die Für & Wider sind in diesem Thread ja mittlerweile hinreichend erläutert worden.
Nö, immer noch nicht.
Was ist denn deiner Meinung nach noch nicht (hinreichend) erläutert worden?
Gruß Gunther
Hallo
Was ist denn deiner Meinung nach noch nicht (hinreichend) erläutert worden?
Dass es angeblich sinnvoll sei, nur h1 zu verwenden und damit auf einen hierarchischen Aufbau, der sich aus der Verwendung der weiteren Überschriften (h2 bis h6) ergäbe zu verzichten. Und nein, ich halte das nicht für sinnvoll. Wenn ich also, um ein valides Dokument zu erzeugen, nur noch h1 verwenden dürfte, obwohl ich der Hierarchie wegen weitere Überschriftenebenen bräuchte, diese aber nicht mehr verwenden dürfte, weil ja nur noch h1 zu verwenden sei, dann schisse ich auf Validität.
Tschö, Auge
Hi,
Was ist denn deiner Meinung nach noch nicht (hinreichend) erläutert worden?
Dass es angeblich sinnvoll sei, nur h1 zu verwenden und damit auf einen hierarchischen Aufbau, der sich aus der Verwendung der weiteren Überschriften (h2 bis h6) ergäbe zu verzichten.
damit sitzt du aber, wenn ich es richtig verstehe, auf der gleichen Bank wie Gunnar gegen molily.
Solange der Sprachumfang keine explizit gliedernden Elemente kannt (HTML 4.01, XHTML 1.0), muss die Hierarchie durch den Rang der Überschriften h1..h6 ausgedrückt werden. Sobald die Gliederung aber durch Elemente wie z.B. section ausgedrückt wird, das auch verschachtelt auftreten kann, braucht man keine weitere Differenzierung der Überschriften mehr.
Ergo: Entweder konsequent HTML 5 mit Gliederung/Outline durch section und nur einem generischen Element für Überschriften (h1 stellvertretend für ein allgemeines h-Element), oder auf die Gliederung nach HTML 5 verzichten und stattdessen die abgestuften Überschriften h1..h6 verwenden.
Und nein, ich halte das nicht für sinnvoll. Wenn ich also, um ein valides Dokument zu erzeugen, nur noch h1 verwenden dürfte, ...
Ich verstehe den Artikel zwar auch in der Richtung, aber die im traditionellen Sinn korrekte Verwendung von h1 bis h6 ist ja eben nicht invalid. Ich sehe das nur als eine Empfehlung - salopp ausgedrückt: Wenn du die Gliederung durch die Dokumentstruktur ausdrückst, halt dich nicht auch noch mit verschiedenen Elementen für die Überschriften auf.
obwohl ich der Hierarchie wegen weitere Überschriftenebenen bräuchte, diese aber nicht mehr verwenden dürfte, ...
Streiche "dürfte", setze "sollte" stattdessen.
weil ja nur noch h1 zu verwenden sei, dann schisse ich auf Validität.
D'accord. Nur dass die Validität hier gar nicht beschädigt wird.
Ciao,
Martin
Hallo
damit sitzt du aber, wenn ich es richtig verstehe, auf der gleichen Bank wie Gunnar gegen molily.
Wenn ich die beiden Stränge lese, glaube ich eher, dass er mir gegenüber sitzt. Er hätte ja gern „h“ (so ganz mit ohne Zahl) gehabt. :-)
Solange der Sprachumfang keine explizit gliedernden Elemente kannt (HTML 4.01, XHTML 1.0), muss die Hierarchie durch den Rang der Überschriften h1..h6 ausgedrückt werden. Sobald die Gliederung aber durch Elemente wie z.B. section ausgedrückt wird, das auch verschachtelt auftreten kann, braucht man keine weitere Differenzierung der Überschriften mehr.
Ergo: Entweder konsequent HTML 5 mit Gliederung/Outline durch section und nur einem generischen Element für Überschriften (h1 stellvertretend für ein allgemeines h-Element), oder auf die Gliederung nach HTML 5 verzichten und stattdessen die abgestuften Überschriften h1..h6 verwenden.
Was spricht gegen die gleichzeitige Verwendung beider Systeme?
obwohl ich der Hierarchie wegen weitere Überschriftenebenen bräuchte, diese aber nicht mehr verwenden dürfte, ...
Streiche "dürfte", setze "sollte" stattdessen.
Der von Gunther zitierte Text sagt ja nichts von beidem, kein „darf nicht“, kein „sollte nicht“, außer für die falsche Verwendung. Gunther macht daraus aber konsequent „nur noch h1“ (auch wenn's da nicht steht). Das wiederum würde, wenn es so festgelegt wäre, implizieren, dass die anderen Ebenen invalide wären (bitte auf den Konjunktiv zu achten).
Tschö, Auge
Mein Herr!
Vorab schon mal vielen Dank für deine Antwort!
Hör’ auf, reguläre Ausdrücke zum Parsen von HTML zu nutzen (was man sowieso nicht tun sollte),
Warum denn eigentlich nicht?
Weil sie nur sehr schwierig zu lesen und zu schreiben sind. Die Syntax-Regeln von HTML sind nicht so einfach mit regulären Ausdrücken zu erfassen. Was würde dein regulärer Ausdruck zum Beispiel mit folgendem Schnipsel anstellen:
<span title="<article>">? Es ist schwierig zur erkennen, dass<article>in dem Beispiel zum Attribut-Wert gehört.Reguläre Ausdrücke stoßen außerdem schnell an ihre Grenzen. Nehmen wir ein einfaches Entscheidungsproblem: Beinhaltet das body-Element gleich viele section-Elemente wie h1-Elemente? Ein regulärer Ausdruck kann das Problem nachweislich* nicht lösen.
*) reguläre Ausrücke sind nicht turingvollständig.
In meinem konkreten Fall bspw. verändere ich ja gar nicht den vorhandenen HTML Code, sondern möchte ja nur gewisse Daten daraus extrahieren.
Mein Beispiel ist zugegebener Maßen sehr konstruiert, aber trotzdem würde dein regulärer Ausdruck daran scheitern.
Das ist sicherlich alles richtig, allerdings will und wollte ich ja nie eine "universell" anwendbare Funktion schreiben, sondern lediglich eine, die in meinem konkreten Fall, unter Berücksichtigung der bereits genannten Konventionen, den Job schnell & einfach erledigt.
Für die typischen Aufgaben Traversieren und Manipulieren bietet die DOM-API bereits fertige, erprobte Lösungen, also wieso diese nicht nutzen?
Weil mir diese in manchen Fällen eher als "Overkill" erscheinen, wenn ein recht simpler regulärer Ausdruck die Aufgabe auch erledigen kann.
- alle Nodes durchlaufen, um meine H1 Section Heading Nodes zu finden
- bei einem Treffer, den entsprechenden ParentNode nach weiteren Sectioning ChildNodes durchsuchen, wobei sich bei jedem Treffer der Level jeweils um eins erhöht
Ist das vom Ansatz her so in etwa korrekt?
Der offizielle Algorithmus deckt wesentlich mehr Szenarien ab, als deinen spezielle Fall, zum Beispiel auch Verschachtelungs-Tiefe anhand des Rangs (h1,h2,h3,…).
Aufbauend auf dem DOM-Vokabular ist dieser sehr präzise formuliert. http://www.w3.org/TR/html51/sections.html#outlines
Ja, schon klar.
Und außerdem ist (m)ein TOC ja nicht zu 100% identisch mit der Outline.
Anhand der Auflistung kann man aber schon sehr schön sehen, wie viele Bedingungen man der Reihe nach durchprüfen muss, um das korrekt umzusetzen. Mal gucken, wenn ich das nächste Mal Langeweile habe ...! ;-)
Solche Sachen wären doch auch mal etwas als Community Projekt für's Wiki ...!
Ich bin mir sicher, dass dabei anschließend das Optimum herauskommt.
Gruß Gunther
Hi!
Womit ich mich jetzt aber schwer tue ist, eine mögliche Verschachtelung, sprich verschiedene Ebenen zu ermitteln, um meine TOC entsprechend zu gestalten.
Hör’ auf, reguläre Ausdrücke zum Parsen von HTML zu nutzen (was man sowieso nicht tun sollte), und nehme einen DOM Parser stattdessen.
OK, überzeugt! ;-)
Ich verwende jetzt den DOMDocument Parser.
Der Einfachheit halber setze ich den Level aber manuell im Class-Attribut. Der Rest ist aber tatsächlich wesentlich einfacher, als mit Regexp.
Manchmal dauerts halt ein bisschen länger, bis ich die Vorteile/ Vorzüge von etwas erkenne ...! ;-)
Gruß Gunther