XH: alternatives Seitensplitten unabhängig von <hx> - Tags
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Ta
Variable ist umbenannt und Franks Template ist jetzt ebenfalls auf GitHub verfügbar.
Fehlt noch ein halbwegs funktionaler Demo-Content. Und, nicht zu vergessen, was machen wir jetzt mit dem DropDown für das Format der Seitenüberschrift? Ich tendiere inzwischen doch zur "DAU" - Lösung...
Fehlt noch ein halbwegs funktionaler Demo-Content. Und, nicht zu vergessen, was machen wir jetzt mit dem DropDown für das Format der Seitenüberschrift? Ich tendiere inzwischen doch zur "DAU" - Lösung...
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Ta
Sorry, kannst du nochmal einen Denkanstoß geben? Irgendwie ist mir da was entgangen oder entfallen.Holger wrote: Und, nicht zu vergessen, was machen wir jetzt mit dem DropDown für das Format der Seitenüberschrift? Ich tendiere inzwischen doch zur "DAU" - Lösung...
Edit:
Ah, du meinst <h1>%s</h1> in der CMS-Konfiguration?
Da hatte ich mal gefragt, ob dort theoretisch auch was anderes eintragbar wäre?
Falls nicht, plädierte ich stark zu einem DropDown. Was sonst?
Alles andere ist fehlerträchtig.
Nochmal zu den Editoren:
Das Problem mit ".foo" und "p.foo" habe ich verstanden. Ich weiß auch, dass es vor sehr langer Zeit schonmal im Gespräch war.
Nur die endgültige Lösung weiß ich nicht.
Die kontextabhängige Definition scheint mir keine Lösung.
Beispiel: Ich definiere ".red", das ich mal für ein einzelnes Wort in einem Absatz, in einer Tabelle, oder in einer Überschrift verwenden will. Und es gibt noch andere Einsatzmöglichkeiten.
Wenn ich nun für jeden Fall eine Regel definieren muss, wird das Stylesheet mehrere MB groß.
Privat für mich habe ich im Tiny4 die Filterregel auskommentiert: importcss_selector_filter: ...
Da weiß ich aber nicht, was das für Folgen haben könnte.
Und für Normaluser ist das sowieso keine Lösung.
Und was sagen Template-Gestalter dazu?
Für den CKEditor habe ich noch gar keinen Lösungsansatz.
Die Folge: Ich benutze den Tiny3.
Ich weiß, das nervt irgenwie alles, aber mir scheint es wirklich wichtig und zu "simple" zugehörig.
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Ta
Da könnte man z.B. eine Klasse mit angeben: <h1 class="page-heading">%s</h1>. Ob diese Möglichkeit wirklich relevant ist – weiß nicht. Es wäre aber denkbar, dass man das Dropdown so gestaltet, dass nicht etwa h1,h2, etc. verfügbar sind, sondern eben <h1>%s</h1>,<h2>%s</h2>, etc. Das könnte dann in metaconfig.php von einem fortgeschrittenen Anwender geändert werden (andere Einträge oder Deaktivierung des Dropdown→freie Texteingabe). Und es sollte sogar möglich sein diese Einstellung (also $mcf[headings][format]) dynamisch zu setzen, je nachdem ob der Advanced-Mode aktiv ist oder nicht.frase wrote:Ah, du meinst <h1>%s</h1> in der CMS-Konfiguration?
Da hatte ich mal gefragt, ob dort theoretisch auch was anderes eintragbar wäre?
<INS>Ich habe mal einen entsprechenden Pull-Request eingereicht.</INS>
Das sollte kein Problem sein. Die Default-Regel filtert lediglich alles was nicht element.klasse ist raus – ich denke, damit sich der TinyMCE 4 hier mehr wie der TinyMCE 3 verhält. Die Dokumentation zu importcss_selector legt auch noch andere Möglichkeiten nahe, z.B. könnte ein Template die anzubietenden Styles auch mit einem Präfix kennzeichnen, z.B. .user_*. Ob und wie das beim CKEditor entsprechend möglich ist, weiß ich nicht.frase wrote:Privat für mich habe ich im Tiny4 die Filterregel auskommentiert: importcss_selector_filter: ...
Da weiß ich aber nicht, was das für Folgen haben könnte.
Auf jeden Fall muss klar sein, dass es schwierig bis unmöglich sein dürfte hier Konventionen zu haben, die von allen Editoren auch entsprechend erkannt werden. Schließlich wissen wir ja noch nicht mal, welche weiteren Editor-Integrationen noch folgen werden, und welche es vielleicht sogar schon auf individuellen Sites gibt. Im Zweifel bietet es sich vielleicht an, Templates einfach für den Standardeditor vorzubereiten – wer einen alternativen Editor verwenden will, muss dann eben ggf. nachbessern. Welcher Editor nun der Standardeditor für XH 1.7 wird, ist aber ein anderes Thema.
Last edited by cmb on Sun Dec 04, 2016 11:52 am, edited 1 time in total.
Reason: PR ergänzt
Reason: PR ergänzt
Christoph M. Becker – Plugins for CMSimple_XH
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Ta
Sehr gut erklärt. Ich bilde mir ein, dass ich es jetzt verstanden habe.cmb wrote:Da könnte man z.B. eine Klasse mit angeben: <h1 class="page-heading">%s</h1> ...
Darum schwenke ich um und bin mehr für die "offene" Variante. Entscheiden sollten nun die Programmierer. Und so gesehen, könnte erstmal alles bleiben, wie es ist.
Nun denn, die Antwort hat auch weitergeholfen.cmb wrote:Auf jeden Fall muss klar sein, dass es schwierig bis unmöglich sein dürfte hier Konventionen zu haben, die von allen Editoren auch entsprechend erkannt werden.
Also kann/muss jeder seinen Editor selbst konfigurieren.
Fragt sich nur, was als "Standard"-Einstellung das Beste wäre.
(Leerzeichen in Tags? Nur kontextbezogene Styles oder alle? ...)
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Ta
Siehst du eine Möglichkeit, auch bestimmte Styles/Klassen auszuschließen? (usage with RegExp filter)cmb wrote:Die Dokumentation zu importcss_selector legt auch noch andere Möglichkeiten nahe, z.B. könnte ein Template die anzubietenden Styles auch mit einem Präfix kennzeichnen, z.B. .user_*.
Grund:
FontAwesome (oder andere Icon-Fonts) müssen im Editor verfügbar sein.
Deshalb importiere ich sie per @import url(css/font-awesome.min.css);
Der Import muss am Anfang des Stylesheets stehen.
Das bewirkt, dass im Format-Dropdown erstmal alle möglich "fa"-Formate oben stehen.
Ärgerlich.
Ein Ausschluss für alle, die mit "fa*" beginnen, wäre gut.
Genial wäre, sie drinzuhaben, aber ganz am Ende.
Klingt ziemlich verrückt, kommt aber aus der Praxis.
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Ta
Das ginge beim TinyMCE 4 wohl so:frase wrote:Ein Ausschluss für alle, die mit "fa*" beginnen, wäre gut.
Code: Select all
importcss_selector_filter: /^(?!\.fa)/i,
Ich glaube, das geht beim TinyMCE 4 nicht. Allerdings bietet dieser ein paar andere diesbezüglich vielleicht interessante Konfigurationsoption. Suche mal in der Liste der verfügbaren Optionen nach "Importcss plugin". importcss_groups könnte möglicherweise die beste Option sein (also eben zum Gruppieren aller fa Styles).frase wrote:Genial wäre, sie drinzuhaben, aber ganz am Ende.
Christoph M. Becker – Plugins for CMSimple_XH
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Ta
Ach Christoph, du bist genial.
Folgendes habe ich gemacht (Tiny4 init_full.js):
fa-Styles sind komlpett weg.
Neues Untermenü unter Formate: "Template-Styles"
Warum das klappt, weiß ich nicht. Dort stehen nun alle Styles aus stylesheet.css
Das ist schon mal sehr gut.
Kann man jetzt nicht noch die fa in ein extra-Untermenü "FontAwesome" packen?
Folgendes habe ich gemacht (Tiny4 init_full.js):
Code: Select all
...
entity_encoding: "raw", // alter Code, Komma angefügt
extended_valid_elements : 'i[class],em[class]', // leere <i>Tags
importcss_selector_filter: /^(?!\.fa)/i,
importcss_groups: [
{title: 'Template-Styles', filter: /^(?!\.fa)/i }
]
}
Neues Untermenü unter Formate: "Template-Styles"
Warum das klappt, weiß ich nicht. Dort stehen nun alle Styles aus stylesheet.css
Das ist schon mal sehr gut.
Kann man jetzt nicht noch die fa in ein extra-Untermenü "FontAwesome" packen?
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Ta
Das sollte wie folgt möglich sein:frase wrote:Kann man jetzt nicht noch die fa in ein extra-Untermenü "FontAwesome" packen?
Code: Select all
// importcss_selector_filter: /^(?!\.fa)/i,
importcss_groups: [
{title: 'Template-Styles', filter: /^(?!\.fa)/i },
{title: 'FontAwesome', filter: /^(?=\.fa)/i}
],
Christoph M. Becker – Plugins for CMSimple_XH
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Ta
Das isses!
Danke ... usw.
Ich weiß, dass ich nerve.
Denke aber, das könnte wichtig werden.
Mir hilft es auf jeden Fall.
Danke ... usw.
Ich weiß, dass ich nerve.
Denke aber, das könnte wichtig werden.
Mir hilft es auf jeden Fall.
Re: XH: alternatives Seitensplitten unabhängig von <hx> - Ta
Puh, wo fange ich an ...
Zu den Editor-Styles: auch CKEditor kann mann leicht so konfigurieren, dass der Stylesheetparser alle Klassen des Templates übernimmt. Dann werden allerdings, wie beim TinyMCE3, natürlich auch die Layout-Klassen angeboten. Das halte ich aber für mehr als problematisch, denn der User kann dann leicht das komplette Layout zerstören. Außerdem kann die Select-Box nur noch raten, was sie als Eintrag anzeigen soll - im Zweifelsfall wird das dann nur die CSS - Klasse als Text sein.
Richtig komfortabel für den User wird es nur dann, wenn das Template die Styles passend für die Blockelemente definiert. Ob ein Stylesheet dann wirklich mehrere MB groß wird, kann ich mir nicht vorstellen. Aber natürlich ist es ein Mehraufwand für den Templateautor.
Trotzdem, alle anderen Varianten sind nur Workarounds.
Zu Fontawesome: das kann man doch nicht per CSS-Klasse im Editor machen. Da hat doch jedes Icon eine eigene Klasse . Für solche Fälle gibt es entsprechende Editor-Plugins. Hier zum Beispiel für den CKEditor: https://www.michaeljanea.com/ckeditor/font-awesome . Etwas in der Art gibt es sicher auch für TinyMCE. Und auch andere Tools, wie Bootstrap Glyphicons oder andere Bootstrap Widgets, gibt es sicher auch für beide Editoren. Eine Liste für den CKEditor gibt es hier: http://ckeditor.com/addons/plugins/all
Die Installation solcher Plugins ist für den User sicher eine Hürde. Beim neuen CK habe ich versucht das zu vereinfachen. In der Regel kann man Zusatzplugins einfach in den Ordner "plugins_external" kopieren. Sie werden dann selbständig inkludiert (bei Toolbar "auto"). Aber es ist auch leicht, sich mit ein paar Klicks einen erweiterten Editor zu laden. Ich werde das genau beschreiben, wenn das Plugin irgendwann mal fertig wird.
Zu den Editor-Styles: auch CKEditor kann mann leicht so konfigurieren, dass der Stylesheetparser alle Klassen des Templates übernimmt. Dann werden allerdings, wie beim TinyMCE3, natürlich auch die Layout-Klassen angeboten. Das halte ich aber für mehr als problematisch, denn der User kann dann leicht das komplette Layout zerstören. Außerdem kann die Select-Box nur noch raten, was sie als Eintrag anzeigen soll - im Zweifelsfall wird das dann nur die CSS - Klasse als Text sein.
Richtig komfortabel für den User wird es nur dann, wenn das Template die Styles passend für die Blockelemente definiert. Ob ein Stylesheet dann wirklich mehrere MB groß wird, kann ich mir nicht vorstellen. Aber natürlich ist es ein Mehraufwand für den Templateautor.
Trotzdem, alle anderen Varianten sind nur Workarounds.
Zu Fontawesome: das kann man doch nicht per CSS-Klasse im Editor machen. Da hat doch jedes Icon eine eigene Klasse . Für solche Fälle gibt es entsprechende Editor-Plugins. Hier zum Beispiel für den CKEditor: https://www.michaeljanea.com/ckeditor/font-awesome . Etwas in der Art gibt es sicher auch für TinyMCE. Und auch andere Tools, wie Bootstrap Glyphicons oder andere Bootstrap Widgets, gibt es sicher auch für beide Editoren. Eine Liste für den CKEditor gibt es hier: http://ckeditor.com/addons/plugins/all
Die Installation solcher Plugins ist für den User sicher eine Hürde. Beim neuen CK habe ich versucht das zu vereinfachen. In der Regel kann man Zusatzplugins einfach in den Ordner "plugins_external" kopieren. Sie werden dann selbständig inkludiert (bei Toolbar "auto"). Aber es ist auch leicht, sich mit ein paar Klicks einen erweiterten Editor zu laden. Ich werde das genau beschreiben, wenn das Plugin irgendwann mal fertig wird.
Das halte ich für eine wirklich smarte Idee!cmb wrote:Da könnte man z.B. eine Klasse mit angeben: <h1 class="page-heading">%s</h1>. Ob diese Möglichkeit wirklich relevant ist – weiß nicht. Es wäre aber denkbar, dass man das Dropdown so gestaltet, dass nicht etwa h1,h2, etc. verfügbar sind, sondern eben <h1>%s</h1>,<h2>%s</h2>, etc. Das könnte dann in metaconfig.php von einem fortgeschrittenen Anwender geändert werden (andere Einträge oder Deaktivierung des Dropdown→freie Texteingabe). Und es sollte sogar möglich sein diese Einstellung (also $mcf[headings][format]) dynamisch zu setzen, je nachdem ob der Advanced-Mode aktiv ist oder nicht.
<INS>Ich habe mal einen entsprechenden Pull-Request eingereicht.</INS>