Onepage h1-Überschriften

[cmb]

Aber der springende Punkt für geänderte Überschriftstrukturen ist wohl tatsächlich

Vielleicht kann man aber auch einmal über die mit HTML5 dazu gekommenen Möglichkeiten zur semantischen Strukturierung nachdenken.

Sehe ich auch so. Allerdings finde ich es wichtig, dass auch Anwender diese im Editor nutzen können, und das wird wohl erst ab TinyMCE 4 unterstützt. Wird wohl mal Zeit für ein Update.

[Holger]

Hi,

Durch deine Aktivitäten bin ich auf einen Artikel gestoßen, der das Problem (für meine Begriffe) wirklich gut erklärt.
http://webdesign.tutsplus.com/articles/ ... sign-16824

Deswegen hab' ich ihn extra in der Demo verlinkt . Nur ob alles, was man so findet, auch wirklich immer (ganz) richtig ist?

Allerdings finde ich es wichtig, dass auch Anwender diese im Editor nutzen können

Das sehe ich aber ganz anders. Ich glaube eher, dass der größte Teil der User damit überfordert wäre. In den meisten Fällen ist es besser, einen Großteil der Buttons etc. aus der Toolbar zu entfernen, anstatt noch weiter Möglichkeiten zu integrieren.

... und das wird wohl erst ab TinyMCE 4 unterstützt. Wird wohl mal Zeit für ein Update.

Wer das ernsthaft im Editor nutzen will (und auch kann) wird auch den Weg finden den Kontent-Filter abzuschalten. Dann geht's mit jedem Editor.

Ich stelle mir eher andere Szenarien vor: z.B. passt zu einem Onepage-Template <header> <section> <aside> und <article> IMHO sehr gut. Die Ausgabe eine News-Plugins schreit geradezu nach <article>. Überhaupt steht in vielen neuen XH-Templates zwar "html" als DocType, aber nicht einmal die Möglichkeiten, die HTML5 zur Strukturierung der einzelnen Blöcke vorsieht, findet man (bei CMSimple...-Templates) irgendwo .
Konsequente Nutzung von HTML5 im Template entschärft - zumindest etwas - das Überschriften - Problem bzw. bietet weitere, valide Lösungsansätze.
Und, BTW, bei der Prüfung durch den Validator sollte man mal das Häckchen bei "Outline" setzen, oder besser noch das FF-Addon "HeadingsMap" installieren.

Schön wäre es, wenn die Templates gleich so zur Verfügung stehen würden, dass der "normale" User die Chance hat, ohne Klimmzüge eine valide Dokumentstruktur zu erzeugen. Das ist bis heute mit keiner CMSimple-Variante (out of the Box) so. Ein Ansatz kann ja meinetwegen im Template der Austausch von content() durch irgendein preg_replace - Irgendwas sein. Dann aber bitte gleich mit den richtigen Styles, damit die Überschriften im Editor auch passen usw.
Das fände ich einen großen Fortschritt. Egal, ob nun durch HTML5 oder nach der "nur eine <h1>" - Regel.

[cmb]

Allerdings finde ich es wichtig, dass auch Anwender diese im Editor nutzen können

Das sehe ich aber ganz anders. Ich glaube eher, dass der größte Teil der User damit überfordert wäre. In den meisten Fällen ist es besser, einen Großteil der Buttons etc. aus der Toolbar zu entfernen, anstatt noch weiter Möglichkeiten zu integrieren.

Okay, vielleicht sollten wir darüber nachdenken, als Default-Editor-Ini nicht "full" auszuliefern. Aber zumindest bei "full" würde ich mir schon wünschen, dass der Webmaster wenigstens <section>s verwenden kann (halte ich für viel sinnvoller als z.B. individuell Farben einstellen zu können; und wirklich schwer zu verstehen ist es ja auch nicht).

Ich stelle mir eher andere Szenarien vor: z.B. passt zu einem Onepage-Template <header> <section> <aside> und <article> IMHO sehr gut. Die Ausgabe eine News-Plugins schreit geradezu nach <article>.

ACK.

Überhaupt steht in vielen neuen XH-Templates zwar "html" als DocType, aber nicht einmal die Möglichkeiten, die HTML5 zur Strukturierung der einzelnen Blöcke vorsieht, findet man (bei CMSimple...-Templates) irgendwo .

Ich bin mir ziemlich sicher mich erinnern zu können, dass die HTML5-Strukturierungen schon verwendet wurden, aber da teilweise zurückgerudert wurde, weil die Browserunterstützung (Styling) noch nicht so verbreitet war (IE 8), siehe z.B. http://cmsimpleforum.com/viewtopic.php? ... 357#p32357.

Inzwischen sehe ich da aber keine wirklichen Probleme mehr, und wir sollten allesamt mal wirkliches HTML5 verwenden. Nicht wirklich klar ist mir, ob da eher der konservativere W3C Standard oder der WHATWG Standard umgesetzt werden sollte. Auf jeden Fall bedeutet es einige Arbeit – und vermutlich auch einige irritierte User, die dann Fehlermeldungen vom Validator erhalten.

[manu]

Allerdings finde ich es wichtig, dass auch Anwender diese im Editor nutzen können

Das sehe ich aber ganz anders. Ich glaube eher, dass der größte Teil der User damit überfordert wäre. In den meisten Fällen ist es besser, einen Großteil der Buttons etc. aus der Toolbar zu entfernen, anstatt noch weiter Möglichkeiten zu integrieren.
....

Bei Holgers Ansatz geht es doch vor allem darum, die Seitenteiler (h1-3) mit einem eigenen Tag zu ersetzen. Nummer 1 in der Anwendungsfehler-Hitparade ist, dass "die Seite verschwunden ist", weil ein Titel mit einer Überschrift h1-3 formatiert wurde. IMHO gehört das das Seiten erstellen/verschieben/löschen ins Seitenmenü und sollte im Editor schon gar nicht möglich sein, weil der DAU kapiert es eh nicht. Und wäre eine Verbesserung der Usability und wäre mit einer "internen" Vormatierung einfach und elegant gelöst. Und vor allem geschützt vor Eingriffen aus dem Editor. Klar, müssten dann wohl einige Plugins nachgebessert werden, aber das ist dann wohl der beste Zeitpunkt, dies mit einer core funktion/methode abzudecken.
..und die Überschriften 1-3 wären wieder frei für die Formatierung des Contents.
Super, dass Ihr das Thema wieder aufgreift. Das lag mir beim Lesen aus dem Hintergrund seit längerem auf der Zunge.
Gruss manu

[Holger]

Bei Holgers Ansatz geht es doch vor allem darum, die Seitenteiler (h1-3) mit einem eigenen Tag zu ersetzen.

Nein. Davon ist in dem Thread hier nicht die Rede, wenngleich ich das auch früher bereits einmal vorgeschlagen habe.

In diesem Thread geht es um OnePager und speziell darum, dass man damit eigentlich "leicht" eine semantisch richtige Seite erzeugen kann.

[cmb]

In diesem Thread geht es um OnePager und speziell darum, dass man damit eigentlich "leicht" eine semantisch richtige Seite erzeugen kann.

Upps, da ist mir der Überblick verloren gegangen (ich dachte, es geht auch um CMSimple_XH im Allgemeinen). Für Onepage_XH ist das natürlich absolut sinnvoll (wird wohl niemand einen Onepager mit HTML 4 erstellen).

[frase]

Das stimmt. Es ist komplex. Ich komme auch kaum noch mit.
Man kann gar nicht auf alles antworten. Deshalb "in Häppchen".

@Holger
Chapeau!
Gute Arbeit und viel (und offensichtlich richtig) nachgedacht.
Ich habe deine Texte noch nicht komplett durch, aber schon einen Vorschlag.
In deinem Beispiel verwendest du <article>. Im Abschnitt "Oder HTML5 like?" schlägst du eine Strukturänderung für die Ausgabe vor.
Warum nicht gleich dem Artikel die CSS-KLasse und die ID verpassen? Also so:

Code: Select all

<!-- Content -->
<?php $onepage_structure = '<article id="%s" class="onepage_page">
%s
</article>
';?>
<main role="main">
<?php echo onepage_content()?>
</main>
<!-- end -->

Damit entfällt ein zusätzlicher <div> und wir hätten ein <main>.
In deiner "jquery.onepage.js" müsste dann nur noch geändert werden:

Code: Select all

var $sections = $("div.onepage_page");

zu

Code: Select all

var $sections = $(".onepage_page");

Also statt div.classe nur .classe
Ich habe das bei mir (local) probiert und es geht.

Wenn ich vorangekommen bin, gibt's mehr Feedback.

[frase]

Ach so, falls man das tut und Ludwigs Template verwendet, muss man natürlich für die alternierenden Hintergünde im Stylesheet noch ändern

Code: Select all

article:nth-child(odd) {
	background-color: #efefef;
}
article:nth-child(even) {
	background-color: #fff;
}

Also, statt .onepage_page eben article

[Holger]

Hallo Frank,

Warum nicht gleich dem Artikel die CSS-KLasse und die ID verpassen?

Weil wir uns eigentlich darauf geeinigt hatten, als Mindestanforderung das DIV mit der Klasse zu haben.

Natürlich genügt in dem Fall nur die Klasse alleine. Aber was, wenn mal irgendein Plugin etc. sich auf die vereinbarte Mindeststruktur verlässt bzw. verlassen muss?
Zu viel Durcheinander sollten wir da nicht produzieren.

BTW: ob in meiner Demo nicht <section> vor <article> zu bevorzugen wäre, könnte man auch noch ellenlang ausdiskutieren. Es soll im Moment jedenfalls nur eine Demo sein, die vielleicht zum überlegen anregt.

LG
Holger

[frase]

...Mindestanforderung...
Natürlich genügt in dem Fall nur die Klasse alleine. Aber was, wenn mal irgendein Plugin etc. sich auf die vereinbarte Mindeststruktur verlässt bzw. verlassen muss?
Zu viel Durcheinander sollten wir da nicht produzieren.

Wie immer hast du Recht. Ich habe es bei mir dann sowieso anders glöst.
Das "wirklich Geniale" - und soweit ich das richtig sehe - das von dir Stammende, ist doch die Möglichkeit, die Struktur selbst zu bestimmen. Das is knorke!

BTW: ob in meiner Demo nicht <section> vor <article> zu bevorzugen wäre, könnte man auch noch ellenlang ausdiskutieren.

Auch da hast du schon wieder sowas von Recht!
Es hängt ziemlich vom Inhalt der Site und den Artikeln/Sectionen ab. Das muss aber der Endanwender selbst entscheiden.
Ich habe mir die Augen wund gelesen zu dem Thema. Und auch noch zu "role". Die Experten prügeln sich regelrecht und kommen zu keinem Ergebnis.