XH: alternatives Seitensplitten unabhängig von <hx> - Tags

[frase]

Na ja, bei der von mir angedachten "Nope"-Variante eben nicht. Da müsste man schon Content-Beabeiten bemühen.

Na denn, rein damit
Da müsst ihr Zwei klarkommen.
(Warum eigentlich nur 2? Gottseidank?)

[Holger]

Na ja, bei der von mir angedachten "Nope"-Variante eben nicht. Da müsste man schon Content-Beabeiten bemühen.

Na denn, rein damit
Da müsst ihr Zwei klarkommen.
(Warum eigentlich nur 2? Gottseidank?)

Ja was denn nun? Ich dachte, der Weg für Power-User soll offen bleiben

[cmb]

Na ja, bei der von mir angedachten "Nope"-Variante eben nicht. Da müsste man schon Content-Beabeiten bemühen.

Na denn, rein damit
Da müsst ihr Zwei klarkommen.
(Warum eigentlich nur 2? Gottseidank?)

Ja was denn nun? Ich dachte, der Weg für Power-User soll offen bleiben

Ja, soll er auch – entweder per Konfiguration, oder von mir aus auch per Konvertierungsfunktionalität. Jedenfalls kann ich mir gut vorstellen, dass es eben eine Möglichkeit gibt, den Content zu bearbeiten wie bisher, und eine die eine "Nope" Variante gleich integriert. Und beides eben mit den von Dir vorgeschlagenen Split-Kommentaren.

[Holger]

Ja, soll er auch – entweder per Konfiguration, oder von mir aus auch per Konvertierungsfunktionalität.

Bin ich zu doof für, sorry. Verstanden hab ich es, kapiert aber nicht
Beim lesen den HTML-Kommentar also herausfiltern, beim Schreiben wieder dazu kopieren?

Anderer Vorschlag: dem DAU den Source-Button aus der Toolbar entfernen und gut ist. Ich fände es gerade gut, wenn man im HTML-Modus noch annähernd das machen kann, was jetzt auch möglich ist (zusammenfassen, umbenennen, verschieben etc.).

[meltemi]

Für mich sollte der Content einer Seite immer mit <h1> beginnen.

Dann hätten diejenigen, die schon eine Template-h1 haben (was in vielen Fällen, abhängig vom Website-Thema, durchaus sinnvoll sein kann) zwangsweise zwei h1, was nicht nur semantisch falsch ist, sondern Google verwirrt. Ich weiß nicht, welches Vorkommen von h1 Google in einem solchen Fall verwendet, und möchte es auch nicht testen.

Als Notlösung bliebe denjenigen dann nur, die Template-h1 zu entfernen und auf allen Seiten als h1 den gleichen Text zu verwenden. Das darf nicht wahr sein.

[cmb]

Anderer Vorschlag: dem DAU den Source-Button aus der Toolbar entfernen und gut ist. Ich fände es gerade gut, wenn man im HTML-Modus noch annähernd das machen kann, was jetzt auch möglich ist (zusammenfassen, umbenennen, verschieben etc.).

Vielleicht sollten wir den "Nope" Aspekt (zumindest zunächst) mal ganz ausblenden. Eigentlich ging es in diesem Thread ja "nur" um die Möglichkeit, dass ein User auf jeder Seite h1-h6 nach eigenen Wünschen verwenden kann. Und dies sollten wir dann mal umsetzen, so dass sich jeder, der möchte, das anschauen kann.

Mir wäre es halt wirklich sehr lieb, wenn die Entwicklung des Codes in einem öffentlichen zugänglichen Repo stattfinden würde. Ich hatte Github vorgeschlagen (v.a. wegen der Möglichkeit von PRs), aber eigentlich könnten wir das auch in einem Featurebranch im XH-Repo auf SourceForge machen. Was meinst Du?

[Holger]

So, ich hab' das jetzt mal lokal durchgespielt:
die Überschriften sind im WYSIWYG-Mode nicht mehr sichtbar und werden über dem Editor, bzw. dem Seiteninhalt angezeigt. Die Einstellung der Menülevels wird ignoriert. Während der Entwicklungsphase wird der höchste Menülevel im Content automatisch der Konfigurationsvariable zugeordnet. Das muss dann später bereinigt werden. Das Format der Split-Marker ist jetzt

Code: Select all

<!--XH_mlX:Seitenüberschrift-->

Ich würde gerne beim HTML-Kommentar bleiben, damit es für erfahrene User keine Probleme mit den Editoren gibt. Dazu unten mehr.

Momentan läuft technisch alles, wie bisher. In den Core - Funktionen ist lediglich die jeweilige RegExp angepasst. Beim jetzt geänderten Format sind sie auch total simpel.
Im Prinzip funktioniert auch alles wunderbar.

Aber

Anderer Vorschlag: dem DAU den Source-Button aus der Toolbar entfernen und gut ist.

ist leider Quatsch: wenn man nur lange genug die Löschen-Taste drückt, entfernen die Editoren auch die unsichtbaren Kommentare . Also ist nochmal nachbessern angesagt. Zum Beispiel mittels Christophs Vorschlag:

Ja, soll er auch – entweder per Konfiguration, oder von mir aus auch per Konvertierungsfunktionalität.

Bin ich zu doof für, sorry. Verstanden hab ich es, kapiert aber nicht
Beim lesen den HTML-Kommentar also herausfiltern, beim Schreiben wieder dazu kopieren?

Versuch macht klug . Jetzt verstehe ich, wie du es meinst.
@Christoph: kann man nicht einfach dem Editor nur den Inhalt aus $c[$s] [Edit] mit herausgefilterten Split-Markern [/Edit] geben? Dann könnte man sich auch das ganze RegExpen sparen. Da ja $s, $h und $l bekannt sind und per Editor keine Seiten gelöscht, angelegt oder verschoben werden sollen, kann man die Split-Marker ja leicht beim Speichervorgang voranstellen.
Ist der Poweruser-Switch gedrückt, kann alternativ der Kommentar im Editor einfach mitgeführt werden und -ohne irgendwelche Prüfungen, wie vorhanden bisher auch, abgespeichert werden.
Habe ich da jetzt einen Denkfehler? Ich werde es Morgen mal so erweitern...

Für mich sollte der Content einer Seite immer mit <h1> beginnen.

Dann hätten diejenigen, die schon eine Template-h1 haben (was in vielen Fällen, abhängig vom Website-Thema, durchaus sinnvoll sein kann) zwangsweise zwei h1, was nicht nur semantisch falsch ist, sondern Google verwirrt. Ich weiß nicht, welches Vorkommen von h1 Google in einem solchen Fall verwendet, und möchte es auch nicht testen.

Als Notlösung bliebe denjenigen dann nur, die Template-h1 zu entfernen und auf allen Seiten als h1 den gleichen Text zu verwenden. Das darf nicht wahr sein.

Solch eine starre Lösung gefällt mir auch nicht, wie ich ja oben schon mehrfach erwähnt habe. Aber ich habe schon eine Idee, wie man das mit allen Optionen lösen könnte, zum Beispiel:
man könnte global den Level der ersten Content-Überschrift per Konfiguration beliebig festlegen. Auf einzelnen Seiten könnte man das dann sogar per PageParams ändern. Oder, mein Favorit , man schaltet per Konfig die Überschriften für die Ausgabe komplett ab, und nimmt sie nur noch für die Navigation. Dann hat man die volle Kontrolle in einem anfangs ganz leeren Editorfenster zurück. So könnte man es wohl ziemlich allen recht machen.

[frase]

@meltemi && @Holger
Die <h1>-Seitenüberschriften in den gängigen Templates befinden sich im Header - einem abgeschlossenen Bereich (meist <div>) der ähnlich wie <article> oder <section> behandelt wird.
Der Seiten-Content ebenso.
In Holgers Demo gibt es z.B. auf "Seite 1" drei (3!) mal <h1>, was völlig okay ist. (die html5-Outlines werden nicht bemängelt.)*
Ich möchte kein Buch lesen, das mit Kapitel 2 oder 3 anfängt.
Ob man es dem User vorschreibt, oder nur vorschlägt (also nicht starr), darüber kann man reden.
Ziel war es ja gerade die oft "kaputte" Seitenstruktur von CMSimple zu "verbessern".
Schade, dass das wieder ein Nebenschauplatz ist, der das Wichtige stört, aber doch dazugehört.
Wohin denn sonst? Prokrastinieren?
*
Seite 1 = OK
https://validator.w3.org/nu/?doc=http%3 ... utline=yes
Seite 3 = Fehler
https://validator.w3.org/nu/?showoutlin ... 526gt%253B

[cmb]

@Christoph: kann man nicht einfach dem Editor nur den Inhalt aus $c[$s] [Edit] mit herausgefilterten Split-Markern [/Edit] geben? Dann könnte man sich auch das ganze RegExpen sparen. Da ja $s, $h und $l bekannt sind und per Editor keine Seiten gelöscht, angelegt oder verschoben werden sollen, kann man die Split-Marker ja leicht beim Speichervorgang voranstellen.
Ist der Poweruser-Switch gedrückt, kann alternativ der Kommentar im Editor einfach mitgeführt werden und -ohne irgendwelche Prüfungen, wie vorhanden bisher auch, abgespeichert werden.
Habe ich da jetzt einen Denkfehler? Ich werde es Morgen mal so erweitern...

Ja, so hatte ich mir das gedacht. Zusätzlich müssen noch beim Speichern eventuell vom User eingefügte Split-Marker gelöscht werden.

Ich möchte kein Buch lesen, das mit Kapitel 2 oder 3 anfängt.

Na ja, man kann ja auch die gesamte CMSimple_XH Site mit einem Buch vergleichen. Dann ist sogar die derzeitige Heading-Struktur recht passend.

Die <h1>-Seitenüberschriften in den gängigen Templates befinden sich im Header - einem abgeschlossenen Bereich (meist <div>) der ähnlich wie <article> oder <section> behandelt wird.
Der Seiten-Content ebenso.
In Holgers Demo gibt es z.B. auf "Seite 1" drei (3!) mal <h1>, was völlig okay ist. (die html5-Outlines werden nicht bemängelt.)*

Siehe auch was Matt Cuts zu mehreren <h1> auf einer Seite zu sagen hatte.

[frase]

Dann ist sogar die derzeitige Heading-Struktur recht passend.

Siehe den letzten Link in meinem letzten Post.

Nachtrag:

Siehe auch was Matt Cuts zu mehreren <h1> auf einer Seite zu sagen hatte.

Das sag' ich doch. Wenn sinnvoll, dann erlaubt.