kleine Tiny-Meckerei

[cmb]

Das ist ja auch noch so ein offener Punkt: alle Stylesheets kombinieren / Template als letzte Datei einbinden.
Darüber müsste auch noch genauer diskutiert werden.
Ich bin sehr dafür, dass alle Styles vom Core zusammengefasst werden. Das Template als letzte Datei wäre natürlich gut, um Styles zu überschreiben.

Auch wenn die Änderung der Reihenfolge (also Template-Stylesheet am Ende) ein potentieller BC Break ist, bin ich auf jeden Fall dafür, und denke, das hätte schon immer so sein sollen, war es aber vermutlich nur nicht, weil der Pluginloader eben eine externe Komponente war.

Nur, wie ich auf GitHub auch geschrieben hatte, werden dann @import Anweisungen im Template nicht mehr funktionieren, weil sie ganz oben im Stylesheet definiert werden müssen. In den Plugin-Stylesheets kam das wohl bisher noch nicht vor. Richtigerweise müssten bei der Kombination der Stylesheets auch heute schon die @imports an den Anfang der Datei verschoben werden.

Hatte ich auch schon überlegt, aber auch das könnte einen Unterschied machen. Ich denke, das beste wäre es, wenn wir festlegen, dass Plugin-Stylesheets kein @import verwenden sollten, und die Template-Stylesheets erst mal separat lassen. Das bedeutet dann zwar einen Request mehr, aber es gibt keine Probleme bezüglich @import, und ist einfacher zu realisieren bzw. effizienter, wenn mehrere Templates verwendet werden.

[frase]

Ich denke, das beste wäre es, wenn wir festlegen, dass Plugin-Stylesheets kein @import verwenden sollten, und die Template-Stylesheets erst mal separat lassen.

Wenn das eine, ist das andere nicht nötig ...

In einigen meiner Templates ist @import zwingend nötig. Wäre sehr schade, wenn diese Möglichkeit "verboten" würde.
Edit: Habe gerade gesehen, dass ich da was verwechselte. Sorry.

Geht es nicht, Core-, Plugin- und Templatestyles in dieser Reihenfolge zusammenzufassen und alle @import-Vorkommen in der Reihenfolge ihres Auftretens an den Anfang zu verschieben?

[Holger]

Ich denke, das beste wäre es, wenn wir festlegen, dass Plugin-Stylesheets kein @import verwenden sollten, und die Template-Stylesheets erst mal separat lassen. Das bedeutet dann zwar einen Request mehr, aber es gibt keine Probleme bezüglich @import, und ist einfacher zu realisieren bzw. effizienter, wenn mehrere Templates verwendet werden.

Ok, plugins.css + core.css kombinieren. Template danach als separaten Request.

Damit hat sich das hier

Aber da könnten wir auch bei der Iframe-Variante nachbessern, indem eben core.css und plugins.css auch verwendet werden.

aber sofort wieder erledigt.

[cmb]

Geht es nicht, Core-, Plugin- und Templatestyles in dieser Reihenfolge zusammenzufassen und alle @import-Vorkommen in der Reihenfolge ihres Auftretens an den Anfang zu verschieben?

Das geht schon, aber zum einen bedeutet das Verschieben der @imports auch wieder eine potentielle Änderung des Aussehens, und andererseits: was machen wir im Fall, dass mehrere Templates auf einer Site im Spiel sind (Sprach sezifisch oder gar Seiten spezifisch)? Gibt's dann für jedes Template eine eigenes kombiniertes Stylesheet? Wäre das, gerade bei vielleicht häufigen Template-Wechseln überhaupt noch effizient?

Damit hat sich das hier

Aber da könnten wir auch bei der Iframe-Variante nachbessern, indem eben core.css und plugins.css auch verwendet werden.

aber sofort wieder erledigt.

Beim TinyMCE können mehrere Stylesheets angegeben werden. Bei Fa_XH nutze ich diese Möglichkeit übrigens. Das scheint auch beim CKEditor möglich.

[manu]

aber zumindest bei mini1 zerschießt das das Layout

Und nicht nur bei mini1.
Ich denke, das ist nur ein Style-Problem (z-Index) und die Art, an welcher Stelle die Toolbar angezeigt wird.

Ich meinte gar nicht mal die Toolbar, sondern folgendes:
inline-editing.jpg
Sieht eher nach einem Overflow-Problem aus....

Nehmt in der Einstellung die Editor Höhe/Editor Height raus. Dann sieht es schon besser aus.

[frase]

Danke, Manu!
So einfach ist das manchmal

[manu]

...Ach ihr wollt direkt im Core von der Textarea zum DIV wechseln . Dann wäre der Inline-Editor ja simpel machbar. Ich dachte ich müsste per JS vor der Editor-Initialisierung die Textarea gegen das DIV tauschen...

??? Der tinymce4 läuft seit Anfangs mit einem (ursprünglichen) div. Spielt das eine Rolle?
EDIT: ach ja, den div, den ich meine, ist ja nur der Selector. Der Wechsel von textarea zu div passiert ja im XH_contentEditor()..

[Holger]

Beim TinyMCE können mehrere Stylesheets angegeben werden. Bei Fa_XH nutze ich diese Möglichkeit übrigens. Das scheint auch beim CKEditor möglich.

Super . Dann wäre das ja gelöst.

[cmb]

Der Wechsel von textarea zu div passiert ja im XH_contentEditor()..

Weiter oben hatte ich erwähnt, dass das nur wegen der TinyMCE Initialisierung war. Stimmt aber leider nicht. Eine recht wesentliche Sache ist das Escaping (XH_hsc()): bei einer <textarea> muss escape't werden, bei einem <div> darf das aber nicht sein. Wollte man die <textarea> per JS zu einem <div> machen, dann müsste per JS unescape't werden, und das geht, glaube ich, nur per Regex – etwas unschön.

[Holger]

Der Wechsel von textarea zu div passiert ja im XH_contentEditor()..

Weiter oben hatte ich erwähnt, dass das nur wegen der TinyMCE Initialisierung war. Stimmt aber leider nicht. Eine recht wesentliche Sache ist das Escaping (XH_hsc()): bei einer <textarea> muss escape't werden, bei einem <div> darf das aber nicht sein. Wollte man die <textarea> per JS zu einem <div> machen, dann müsste per JS unescape't werden, und das geht, glaube ich, nur per Regex – etwas unschön.

Ja, das wäre nicht schön.
Aber, ich frage nochmal, wäre denn eine Konfigurationsoption, möglichst abhängig vom Mode des aktiven Editors, nicht auch sinnvoll?