Neuer Inhaltstyp (Umschlag Anfang/Ende) für semantische HTML5-Elemente

[NinaG]

Ich fände ein Inhaltselement sinnvoll, das technisch ähnlich wie Accordion-Umschlag und Accordion-Ende funktioniert.

Nur dass man damit semantische HTML5-Elemente um Inhaltselemente (gerne auch mehrere) setzen kann.

Ich würde folgende Elemente vorschlagen:

``` <article>, <section>, eventuell auch weitere HTML5-Elemente wie <header>, <footer>, <hgroup>

So bleibt das eine tolle HTML5-Unterstützung für geschulte Redakteure, während die anderen Nutzer die Elemente ignorieren können.

[andreasisaak]

Wäre das nicht eventuell besser in einer Extension aufgehoben? Ich will Leo keine Arbeit wegnehmen aber sowas hat imho nichts im Core zu suchen.

Für mich gehört das in die selbe Kategorie wie die subcolumns Extension :)

[NinaG]

Sehe ich nicht so - schließlich wirbt Contao damit, dass es HTML5-Support hat. Entsprechend müssen diese Basiselemente auch im Core supportet sein.

[andreasisaak]

Das ist jetzt wohl Auslegungssache. Schließlich werden diese Elemente ja auch supportet, über das Modul "Eigener HTML-Code". Aber letztendlich entscheidet ja eh Leo.

Als Extension wären wir flexibler und das Feature wäre schneller vorhanden - so musst du bist bis zur nächsten Version warten.

[tristanlins]

@andreasisaak baue ne Extension und geb sie @leofeyer als Pull Request rein ;-)

[NinaG]

Das wäre sicher die tollste Lösung. Dann haben die 2.11er Nutzer jetzt schon eine Lösung und Leo idealerweise wenig Arbeit weil er für die 3 nur übernehmen muss :)

[andreasisaak]

Ich hab das Projekt bereits angelegt und heute Abend landet dann der erste Stand in Github:

https://github.com/menatwork/semantic_html5

[NinaG]

Die Extension von Andreas Isaak funktioniert 1A. Ich habe sie gerade getestet (unter 2.11) und bin sehr zufrieden damit.

@leofeyer Es wäre schön, wenn du diese Funktionalität so in C3 übernimmst. :)

[andreasisaak]

Die Extension ist jetzt im ER zu finden:

http://www.contao.org/de/extension-list/view/semantic_html5.html

[Babelfisch]

Ein Vorschlag zur einfachen technischen Umsetzung der gebräuchlichsten Elemente <article> und <section>, welche ohne Umschlag auskommt. Im Template fe_page.html5 wird $this->main in <article>…</article> eingeschlossen und in mod_article.html5 der Inhalt in <section>…</section>. Das ist semantisch erst mal nicht falsch und stört nicht. Im Artikel gibt es eine neue Option: „Neuen Artikel beginnen“, die standardmäßig nicht angewählt ist. Ist diese Option gewählt, wird im Template modarticle.html5 am Anfang folgendes gesetzt: </section></article><article><section>. Bei jedem Inhaltselement gibt es eine äquivalente Option: „Neue Sektion beginnen“, die im ce…html5 ein </section><section> an den Anfang setzt.

Das hat den Vorteil, dass man keine Umschläge benötigt und der erfahrene Redakteur die Inhalte trotzdem sinnvoll strukturieren kann. Einfachen Editoren gibt man einfach keine Rechte auf die Optionen und so können sie nix kaputt machen.

Optimal wäre noch, wenn programmtechnisch vermieden wird, dass diese Option beim ersten Artikel und beim ersten Inhaltselement nicht greift.

[andreasisaak]

@Babelfisch

Die Extension macht ja in erster Linie auch etwas mehr als nur </section><section> einzufügen ;)

[Babelfisch]

Andreas, das ist mir schon klar :) Wie Nina schon sagt, sollte aber eine Grundfunktionalität im Core enthalten sein und da sehe ich bei meinem Vorschlag den Vorteil, dass man ohne zusätzliches Element und Wrapper auskommt. Das ist dann aber auf <article> und <section> beschränkt, sodass deine Extension bei Bedarf ja zusätzlich eingesetzt werden kann.

[tristanlins]

@Babelfisch dann haben wir aber wieder eine automatische Semantisierung des Inhalts, die aber nicht zwangsläufig stimmen muss, wie wir zu Beginn des Tickets bereits festgestellt haben. Und wenn @leofeyer die Extension von @andreasisaak übernimmt, dann haben wir die Grundfunktion im Core. Das was du vorgeschlagen hast ist wieder so ne halbgare Lösung, die auch nicht schneller in den Core kommt, als @andreasisaak Implementierung.

[Babelfisch]

Automatisch wäre ja nur ein <article> pro Seite und ein <section> pro Artikel. Das ist doch semantisch absolut korrekt oder übersehe ich hier was? Alle zusätzlichen Elemente lassen sich optional setzen.

Egal, war nur ein Vorschlag. Ich bin halt kein Freund von zusätzlichen Umschlagelementen, zumal sie dann ja in jedem Artikel gesetzt werden müssen und einen Haufen Nacharbeit von bestehenden Seiten verlangen.

[tristanlins]

Aber wie kannst du garantieren, dass $this->main überhaupt aus einem Artikel besteht? Wenn ich den ganzen Kram richtig verstanden habe, wäre bspw. ein Registrierungsformular gar kein Artikel (wobei einige Quellen wieder das Gegenteil behaupten). Aber wenn ich <article> gleich setze mit Inhaltlicher Information, dann ist das Registrierungsformular kein Artikel, lediglich (falls auf der gleichen Seite vorhanden) die Registrierungsbedingungen.

Das das ganze einfach nicht automatisiert funktioniert, hatte Nina imo in Ihrem Beitrag sehr deutlich beschrieben. Kein Automatismus bedeutet -> Handarbeit, egal ob bei bestehenden oder neuen Seiten. Das versuchen zu automatisieren ist imo einfach schlichtweg der falsche Ansatz, dann lieber keine HTML5-Semantik, damit kann man weniger falsch machen, als mit einer falschen automatischen Semantik.

[Babelfisch]

Hmm, wenn ich beim W3C nachlese, dann passt <article> so ziemlich auf alle Inhalte:

The article element represents a self-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.

Meine Variante muss ja aber lange nicht der Weisheit letzter Schluss sein. Wenn es in den Core übernommen wird, hat man ja noch mehr Möglichkeiten als eine Extension und könnte das ganze auch ohne Automatik realisieren. Bspw. könnte man es so machen, dass erst durch die Option „Neuen Artikel beginnen“ im Artikel das <article> Element gesetzt wird. Es muss dann nur durch ein Flag sichergestellt werden, dass der Artikel wieder geschlossen wird.

Mir geht es eigentlich nur darum, ohne Umschlag auszukommen. Da sich tl_article AFAIK nicht per Extension erweitern lässt, habe ich aber keine Lösung, die ohne Core-Unterstützung auskommt.

[Babelfisch]

Ok, ich habe mal ein Proof-of-Concept gemacht:

https://github.com/4t2/html5semantic

Die Erweiterung fügt dem Artikel unter den Experteneinstellungen die Option Article-Element beginnen hinzu. Ist das angewählt, wird der Artikel (und alle nachfolgenden) in <article>…</article> eingeschlossen. Weitere Artikel innerhalb der Seite können natürlich auch angewählt werden, sodass diese Artikel dann jeweils in eigene <article> gepackt werden.

Notwendig ist nur die Erweiterung und eine kleine Anpassung am Template _modarticle.html (liegt bei).

Die Erweiterung soll so nicht veröffentlich werden und nur eine weitere Möglichkeit der Implementierung zeigen, die zusätzliche Elemente vermeidet. Grundsätzlich ließe sich diese Variante dann natürlich auch auf Inhaltselemente und <section>, <hgroup> und Co. erweitern.

[timgatzky]

Hallo, ich hatte heute Nacht mit großem Interesse den Ausgangs-post zu dieser Problematik von Nina gelesen und würde gern einen Denkanstoß liefern, wie die gesamte Artikelverwaltung vielleicht mehr im Sinne von HTML5 aufgebaut sein könnte.

Ich setze mal meinen post von heute Nacht hier ein:

Hallo an alle,
 ich habe mit viel Interesse diese Diskussion gerade gelesen und möchte einen Denkanstoß geben, ob anstelle eines neuen Inhaltselementes der grundsätzliche Aufbau der Artikelstruktur näher an das von Nina vorgestellte HTML5 Modell angepasst werden könnte. Ein Inhaltselement lehne ich ab, weil viele Kunden bzw. die Redakteure von Kunden bereits mit dem Wrapping-Prinzip überfordert sind. Bei Erweiterungen wie [subcolumns] steigenen viele völlig aus.

Zum Aufbau:
 Die Seitenstruktur gibt es eigentlich vor. So würden laut HTML5 auch Contao-Artikel < section > hierachisch aufgebaut werden.
 Aus Sicht des Contao-Artikel-Moduls wäre auch eine Verschachtelung möglich. So wäre ein Artikel auf 1. Ebene einer Seite eine < section >, ein verschachtelter Artikel in diesem ein < article > - in diesem die Inhaltselemente

SEITE 
|- Contao-Artikel#1 < section > 
|-- Contao-Artikel#1.1 < article > 
|--- Inhaltselement#1
 |--- Inhaltselement#2 
|--- ... 
|- Contao-Artikel#2 < section >

Um die möglichst automatisierte Abgrenzung von < section > und < article > zu gewährleisten, wäre ein unverschachtelter Contao-Artikel in einer Seite eine < section > . Ein Artikel in einem Artikel wäre dann automatisch ein < article >.

Um Verwirrung wegen der Namensgebung zu vermeiden, würde die Namensänderung von dem Artikel-Moul in etwas wie Inhaltsstruktur - in Anlehnung an Seitenstruktur, weil jetzt auch hierachich und verschachtelt, sehr gut funktionieren.
 Anlegen tut man weiterhin Artikel bzw. nennt diese in Inhaltsbereich um - macht wahrscheinlich semantisch hier mehr Sinn.

Wäre das denkbar? Eine verschachtelte Struktur würde viel Übersichtleichkeit in der Artikelübersicht schaffen.

Viele Grüße,
Tim 
ps .
Ich würde, wenn ich kann, auch Unterstützung leisten. Ich bin mit Sicherheit nicht der php Goru, aber ich kann sehr gut benutzerfreundlich und in Strukturen denken und Interaktionen konstrurieren, aber auch Templates und Module entwickeln. 
Vielleicht kann ich damit meinen Beitrag leisten.

[andreasisaak]

Die Extension (das Inhaltselement) dient auch in erster Linie nicht dazu die Semantik in Contao wieder herzustellen. Ich bitte das zu beachten - es ist nur eine Möglichkeit HTML5-Elemente (und weitere gewünschte) in einfacher Form anzulegen. Bisher musste man den Inhaltstyp "Eigener HTML-Code" verwenden, da steigen die Kunden doch erst recht aus!!!

Ich würde mir wünschen die grundsätzliche Struktur des Codes in einem anderen Ticket zu besprechen. Hier geht es in erster Linie doch um die gewünschte Extension, die Nina gerne im Core enthalten sieht und die solange als freie Extension verfügbar ist.

[timgatzky]

Hi Andreas, hast voll recht - sehe ich auch so. Generell ist die HTML5 "Problematik" auch besser im Forum aufgehoben.

Die neue vorgebene Struktur für das Inet durch HTML5 fordert neue Ansätze für die Erstellung dieser Strukturen. Contao hat anscheinend diese Anforderungen seitens der Bedienung noch nicht ganz erfüllt. Eine clevere Lösung zur Erstellung der neuen Struktur ist nicht nur ein Alleinstellungsmerkmal, sondern auch für sämtliche besprochene Punkte von Nina etc. wichtig. Wenn wir wissen wie es aussehen soll, können wir es auch umsetzen.

Ich bin gespannt wo die Reise hingeht...

[stefansl]

Meiner Meinung nach, gehört das nich in den Core, da 95% aller Redakteure dieses Feature nicht nutzen werden und eher als irritierend empfinden. Ein Großteil der Redakteure (zum Beispiel Kleinunternehmer bis mittelgroße Firmen) arbeiten nicht oft genug an Ihren Seiten, um mit purem HTML klar zukommen. Bei "eigenem HTML" sehe ich das anders. Hier werden z.B. vorgefertigte Scriptschnipsel (z.B. YouTube) einkopiert.

[andreasisaak]

@leofeyer

Dann frage hier halt nochmal wenn es unbedingt sein muss. Übernimmst du die Extension in den Contao Core?

[leofeyer]

Wir müssen sie erst noch testen bzw. überhaupt mal schauen, wie sie funktioniert :)

[leofeyer]

Also momentan (getestet mit Version 1.1.7) eignet sich die Erweiterung noch nicht für die Übernahme in den Core. Das liegt nicht nur am Coding-Style und dem "alten" Aufbau des Wrapper-Elements, sondern auch daran, dass momentan ausschließlich Inhaltselemente damit gruppiert werden können, oder?

Ich möchte aber beispielsweise auch bei einem Artikel sagen können, dass er mit <article> anstatt <div> ausgegeben wird. Und macht es wirklich Sinn, eine Gruppe von Inhaltselementen als <header> oder <footer> zu taggen?

Ich bin kein Spezialist für semantisches HTML5, daher müssen wir uns das gemeinschaftlich erarbeiten.

[leofeyer]

Kommt hier noch eine Antwort oder kann ich das Ticket schließen?

[frontendschlampe]

ich fände eine Integration super, vielleicht sollte man darüber mal in einem Call diskutieren, wie wo was sinnvoll ist?!

[aschempp]

Ein Inhaltselement als <header> zu taggen habe ich gerade letzte Woche benutzt. Ich hab dazu ein eigenes ce_text_header Template zugewiesen (dank Contao 3.3). Im Template habe ich allerdings einfach das <div> durch <header> getauscht (also keine Start-Stop-Elemente).

Vielleicht liesse sich das kombinieren? Also eine Art "Gruppierungs"-Elemente schaffen, und generell in Inhaltselementen die Auswahl zwischen <div> und den anderen Tags erlauben? Das würde noch viel mehr ermöglichen, beispielsweise die Gruppierung für Grid zu verwenden.

[leofeyer]

Es geht hier nicht darum, das Feature an sich zu diskutieren. Das haben wir bereits auf Mumble gemacht. Es geht um den Pull-Request bzw. die bestehende Extension, die sich doch nicht so einfach übernehmen lässt, wie gedacht (siehe oben).