Eigene Styles als Dropdown about redactor2

[phoebusryan]

Es gibt nun zusätzlich noch Font-Colors, Font-Sizes und Font-Familys als Plugins. Ich sehe zudem keinen Lösungsansatz, der wirklich sinnvoll ist. Ich werde sicher bei Zeiten das Properties-Plugin noch ergänzen. Ich schliesse das hier deshalb.

[phoebusryan]

Grundsätzlich gibt es dafür entweder das Styles-Plugin für Customstyles (läuft über inline-Tags) oder aber das Properties-Plugin (Vergibt IDs oder Klassen an Block-elemente).

Grundsätzlich könnte man das Properties-Plugin umbauen, sowas es das Attribut (Klasse, ID, etc.) immer an das Element gibt, wo man gerade mit dem Cursor ist, jedoch ist dies bei verschachtelten Inline-Tags sehr schwierig. Das ist auch der Grund, warum es aktuell immer auf die Block-Elemente (p, h1, blockquote etc.) geht.

[marcohanke]

Technisch habe ich da keine Ahnung von, aber ich kann mir vorstellen, dass es bei verschachtelten Elementen schwierig wird.
Ich glaube auch, dass das nicht der richtige Weg ist, weil es immer wieder zu oben genannten Fehlern kommen kann.
Da ist der Weg des Properties-Plugin besser, der ein oder andere muss zwar sein CSS und diesbezüglich sein Workflow anpassen, dafür ist es aber konsistent!
Kann man das Plugin so anpassen, dass es vorgegebenen Klassen zur Auswahl per Dropdown gibt? Dann wäre im Prinzip alles perfekt (für mich).
In meinem Fall wäre dass dann ein Dropdown mit „Button Standard, Button Highlight, Button Soft, Fußnote, Hervorhebung“
Der Kunde wählt den Text aus und das jeweilige Blockelement bekommt die Klasse.
Schön, aber nicht notwendig wären mehrere Dropdowns z.B. einmal für Buttons, einmal für Textstile und einmal für spezielle Headline-Stiele.

Am 01.07.2016 um 08:55 schrieb Thomas Kaegi [email protected]:

Grundsätzlich gibt es dafür entweder das Styles-Plugin für Customstyles (läuft über inline-Tags) oder aber das Properties-Plugin (Vergibt IDs oder Klassen an Block-elemente).

Grundsätzlich könnte man das Properties-Plugin umbauen, sowas es das Attribut (Klasse, ID, etc.) immer an das Element gibt, wo man gerade mit dem Cursor ist, jedoch ist dies bei verschachtelten Inline-Tags sehr schwierig. Das ist auch der Grund, warum es aktuell immer auf die Block-Elemente (p, h1, blockquote etc.) geht.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #36 (comment), or mute the thread https://github.com/notifications/unsubscribe/ACUEfTXO3lp0Hd4arvhbRCCN8rmJUjDeks5qRLn2gaJpZM4JC3ZD.

[skerbis]

und einmal für spezielle Headline-Stiele.

Hmmm .... Will man das wirklich? Eine Klassenzuordnung für bestimmte Tags könnte sinnvoll sein:

1. für Bilder (Ausrichtung / Gestaltung)
2. für Tabellen (z.B. Farbhinterlegung: ja / nein)

Alle anderen Stile können eigentlich mit den regulären Tags aus meiner Sicht komplett abgedeckt werden.
Für mich ist der Redactor eine kleine Textverarbeitung (nicht mehr und nicht weniger), die für den Redakteur möglichst eingeschränkt werden sollte.
Warum will man Buttons mitten im Text platzieren?

Das geht ganz sicher schief. Gibst Du dem Redakteur zu viele Funktionen zum spielen, dann wird die Seite entsprechend aussehen.

Eigentlich finde ich den Redactor ganz gut. Wenn ich ihn aber mit CKEditor vergleiche, ist er doch noch nicht so weit.

[eaCe]

Ich wäre auch dafür das Klassen zugeordnet werden können, es kann durchaus von Vorteil sein...
In dem Beispiel vergibt man gleichzeitig auch die passenden Tags..
http://imperavi.com/redactor/examples/formatting-add/

Ist denn diese Möglichkeit verfügbar?

[phoebusryan]

@skerbis Ich stimmt voll zu. Man sollte dem Kunden so wenig Möglichkeiten wie möglich geben. Grundsätzlich aber noch zum Properties-Plugin: Anscheinend (und das hätte ich auch nicht gedacht) benötigen einige User mehr Attribute als nur ID und Klasse. Sie wollen diese custom setzen könnten (z.B. data-xyz=abc). Keine Ahnung wie ich das irgendwie umsetzen sollte und wie benutzerfreundlich und fehleranfällig das dann wäre.

@eaCe Grundsätzlich KÖNNTE man sowas einbauen. Es passt aber einfach überhaupt nicht ins Konzept weil die Konfiguration davon relativ komplex sein kann. Ausserdem dachte ich, dass mit Properties und Styles alles abgedeckt ist.

[polarpixel]

Lass Dich da nicht stressen, @phoebusryan.
CSS-Klasse oder -ID z.B. für einen Absatz oder Link oder so kann schon hilfreich sein, aber ich würde nicht zu viel einbauen (Stichwort data-Attribute), um den Editor so stabil wie möglich zu machen.

[phoebusryan]

@polarpixel Ich sehe vorallem keinen stabilen und benutzerfreundlichen Weg dies zu lösen. Für den Moment bleibt es mal wie es ist. Wenn jemand einen guten Ansatz hat, kann er ihn mir gerne mitteilen.. oder einen PR senden.