Na denn, rein damitcmb wrote:Na ja, bei der von mir angedachten "Nope"-Variante eben nicht. Da müsste man schon Content-Beabeiten bemühen.
Da müsst ihr Zwei klarkommen.
(Warum eigentlich nur 2? Gottseidank?)
Na denn, rein damitcmb wrote:Na ja, bei der von mir angedachten "Nope"-Variante eben nicht. Da müsste man schon Content-Beabeiten bemühen.
Ja was denn nun? Ich dachte, der Weg für Power-User soll offen bleibenfrase wrote:Na denn, rein damitcmb wrote:Na ja, bei der von mir angedachten "Nope"-Variante eben nicht. Da müsste man schon Content-Beabeiten bemühen.
Da müsst ihr Zwei klarkommen.
(Warum eigentlich nur 2? Gottseidank?)
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 wrote:Ja was denn nun? Ich dachte, der Weg für Power-User soll offen bleibenfrase wrote:Na denn, rein damitcmb wrote:Na ja, bei der von mir angedachten "Nope"-Variante eben nicht. Da müsste man schon Content-Beabeiten bemühen.
Da müsst ihr Zwei klarkommen.
(Warum eigentlich nur 2? Gottseidank?)
Bin ich zu doof für, sorry. Verstanden hab ich es, kapiert aber nichtcmb wrote:Ja, soll er auch – entweder per Konfiguration, oder von mir aus auch per Konvertierungsfunktionalität.
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.frase wrote:Für mich sollte der Content einer Seite immer mit <h1> beginnen.
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.Holger wrote: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.).
Code: Select all
<!--XH_mlX:Seitenüberschrift-->
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:Holger wrote:Anderer Vorschlag: dem DAU den Source-Button aus der Toolbar entfernen und gut ist.
Versuch macht klug . Jetzt verstehe ich, wie du es meinst.Holger wrote:Bin ich zu doof für, sorry. Verstanden hab ich es, kapiert aber nichtcmb wrote:Ja, soll er auch – entweder per Konfiguration, oder von mir aus auch per Konvertierungsfunktionalität.
Beim lesen den HTML-Kommentar also herausfiltern, beim Schreiben wieder dazu kopieren?
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:meltemi wrote: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.frase wrote:Für mich sollte der Content einer Seite immer mit <h1> beginnen.
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.
Ja, so hatte ich mir das gedacht. Zusätzlich müssen noch beim Speichern eventuell vom User eingefügte Split-Marker gelöscht werden.Holger wrote:@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...
Na ja, man kann ja auch die gesamte CMSimple_XH Site mit einem Buch vergleichen. Dann ist sogar die derzeitige Heading-Struktur recht passend.frase wrote:Ich möchte kein Buch lesen, das mit Kapitel 2 oder 3 anfängt.
Siehe auch was Matt Cuts zu mehreren <h1> auf einer Seite zu sagen hatte.frase wrote: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 den letzten Link in meinem letzten Post.cmb wrote:Dann ist sogar die derzeitige Heading-Struktur recht passend.
Das sag' ich doch. Wenn sinnvoll, dann erlaubt.cmb wrote:Siehe auch was Matt Cuts zu mehreren <h1> auf einer Seite zu sagen hatte.