Farbcode als "Insert-Tag" in CSS-Verwaltung

Hi,

ich arbeite mit der "internen CSS-Verwaltung" und finde es recht komfortabel, nach Selektoren zu filtern oder alternative Einträge schnell mal ein/aus-zuschalten...

Was mir dabei in den Sinn gekommen ist: wie wäre es, die Farbverwaltung in dieses System einzubeziehen bzw. separat zu behandeln. Ansätze zu dem Them gibt es schon einige unter dem Begriff "OO-CSS" z.B. http://www.internet-magazin.de/ratge...ts-204709.html oder http://www.stubbornella.org/content/...-video-on-ydn/

Wo sehe ich ein "Problem":
im CSS werden diverse Farbangaben "hardverdrahtet" eingegeben, so dass bei einer Änderung des Farbschmema "zu Fuß" durch das CSS muss, um die Sache anzupassen...

Wie sehe ich die "Lösung":
Man könnte sich ein Farbschema zusammenstellen mit Farbkennzeichnung (mein_blau_hell) und Farbwert (#A4ACF7) - könnte man sicher nett aufbohren mit Kästchen (50x50px) der Farbe oder Tool like Adobe-Kuler...

In den CSS Angaben könnten dann die Farben entweder als Auswahl zur Verfügung stehen oder auch im "CSS-Freitext" als Insert-Tag wie {{color::mein_blau_hell}}

Da die CSS-Dateien dann sowieso "dynamisch" generiert werden, wäre eine Ersetzung eigentlich kein Problem

Weiterhin könnte man an eine "Zuweisung" der Farben an den TinyMCE auch denken oder die Erstellung verschiedener Schemata, auf die man im BE wechseln kann.

Per Suche habe ich nichts zu so einer Idee gefunden... vielleicht gabs das ja auch schon.

Gruss zonky

Zitat:

---

Zitat von zonky

Per Suche habe ich nichts zu so einer Idee gefunden... vielleicht gabs das ja auch schon.

---

Ansatzweise ähnliche Ansätze:

http://www.contao-community.de/showt...628-Farbpicker
http://dev.contao.org/issues/1868

@xchs

die zwei Links sind ja eher was für das "pimp-my-extension" und wären im Vergleich zur eigentlichen Umsetzung "Kindergeburtstag"

Kern der Geschichte ist eine zentrale Definition von Farben als Name, die im CSS eingefügt wird also aus
DEF: my_blue = "#091BFD"
p {
color: {{color::my_blue}};
}
wird
p {
color: #091BFD;
}

...

zonky

leider kann CSS noch keine Variablen verarbeiten:mad:, damit bin ich selber schon oft an Grenzen geraten. Der einzige Umweg ist es über PHP generieren zu lassen, daher braucht man eine zusätzliche Extention, oder eine Klasse/ID nur für die Farbwerte zu führen, dann braucht man auch nur an einer Stelle die Werte zu verändern. :p

z.B.

/* schriftcolor */
a, p {color:#ff00ee;}

/* backgroundcolor */
h1,a:hover,a:focus,a:active {background-color:#ee00dd;}

h1 {font-size:140%;}
a {display:block, text-decoration:none;}
p{margin: 0 0 5px;}

Wenn du die beiden Color-Definitionen noch ans Ende schreibst, dann könntest du auch damit ggf. Farbdefinitionen in den Klassen/IDs überschreiben ;-)

LG Kirsten

Zitat:

---

Zitat von zonky

http://www.stubbornella.org/content/...-video-on-ydn/

---

Ja, das habe ich auch mit Interesse gelesen - allerdings fand ich das eigentlich nichts neues. Das 'Problem' dabei ist, dass man sich auch dran halten muss, CSS objektorientiert einzusetzen. Und das klappt eigentlich immer nur dann, wenn man sich vorher den Kopf macht, mögliche Strukturen anschaut, eine Farbwelt baut und die dann konsequent in einer CSS umsetzt.

Das machen aber die wenigsten - da bekomme ich viel zu oft kein semantisches CSS zu sehen, sondern abenteuerliche und schwer zu wartende Konstrukte, bei denen die Farben (und auch andere Sachen) großzügig über dutzende von Dateien verteilt sind.

Man muss halt strikt durchorganisiert mit .class arbeiten ... dann macht das 'cascading' in CSS auch erst richtig Sinn.

Zitat:

---

Zitat von zonky

Wo sehe ich ein "Problem":
im CSS werden diverse Farbangaben "hardverdrahtet" eingegeben, so dass bei einer Änderung des Farbschmema "zu Fuß" durch das CSS muss, um die Sache anzupassen...

---

Das Problem sehe ich eher - siehe oben - dabei, sowas halt nicht zu machen. Also von der Struktur her so zu arbeiten, dass man

Code:

---

.myred{
color:#AC000C}
.myblu{
color:#6288DD}

---

einmal festlegt, und dann diese .Classes nur zuweist. Dann hält sich das alles doch sehr in Grenzen, statt für jedes einzelne Element die Farbzuweisung jeweils individuell zu handhaben. Bedeutet im Vorfeld ein wenig mehr Arbeit, in der Anwendung dann aber sehr viel weniger.

Der Punkt ist, dass solch ein Vorgehen prinzipiell unabhängig von Contao ist - so arbeiten zu wollen ist etwas, dass im Kopf passiert. Man muss das einfach nur verstehen und tun, dann hat man das von Dir angeführte Problem gar nicht.

Zitat:

---

Zitat von zonky

Man könnte sich ein Farbschema zusammenstellen mit Farbkennzeichnung (mein_blau_hell) und Farbwert (#A4ACF7) - könnte man sicher nett aufbohren mit Kästchen (50x50px) der Farbe oder Tool like Adobe-Kuler...

In den CSS Angaben könnten dann die Farben entweder als Auswahl zur Verfügung stehen oder auch im "CSS-Freitext" als Insert-Tag wie {{color::mein_blau_hell}}

---

Das nett aufzubohren könnte man machen - für mich wäre das allerdings mehr ein 'Goodie'. Wenn ich mal setze, dass eine Webseite maximal 20 Farbdefinitionen besitzt, dann fände ich es nett, in meiner colors.css das auch visualisiert zu bekommen. Notwendig finde ich es nicht.

Deinen InsertTag finde ich hingegen problematisch, weil es den objektorientierten Ansatz wieder auflöst, indem es die Funktionalität im CSS verschachtelt. Da möchte ich dann eben nicht im Code suchen, an welchen Stellen ich eine Farbe über einen InsertTag inkludiert habe. Die Anwendung einer Farbklasse gehört für mich eindeutig in den HTML-Teil (wo ich das Objekt 'Farbe', repräsentiert durch die Klasse .mycolor, auf einen semantischen HTML-Block anwende).

Zitat:

---

Zitat von zonky

Weiterhin könnte man an eine "Zuweisung" der Farben an den TinyMCE auch denken oder die Erstellung verschiedener Schemata, auf die man im BE wechseln kann.

---

Das finde ich den allerproblematischsten Teil - eigentlich bin ich der Meinung, dass der MCE komplett rausgeworfen gehört, weil eine Formatierung dort einfach auf dieser Ebene nicht hingehört, die Übersicht erschwert und auch - bei größeren Projekten - die Wartung komplett unmöglich macht.

Ich bekomme manchmal sowas vorgesetzt, und ich finde es unendlich unübersichtich.

Wenn Du schon oben einen objektorientierten Ansatz ins Feld führst, dann solltest Du das auch stringent durchhalten. Nicht dem Text im Textelement eines Artikels noch die CSS-Attribute zuweisen sondern dem Artikel selbst (oder, über erweiterte Selektoren eben auch den Elementen innerhalb eines Artikels). Eigentlich bräuchte es dann nämlich nur die beiden Felder #id und .class.

Schön wäre es in diesem Zusammenhang, es komplett über Module regeln zu können. Bei den meisten Sachen klappt das (#id, .class). Bei einigen anderen Sachen klappt das leider zur Zeit nicht (da fällt mir ein, das sich gerne den Inhaltscontainern #wrapper,, #header, #container und so weiter gerne .Klassen zuweisen können möchte).

Und dabei fällt mir ein, dass ich mir das auch für das Inhaltslelement #Artikel tun können möchte und das Contao zur Zeit (noch) recht unzugänglich handhabt. Dann könnte ich nämlich - was ja der eigentliche Booster in HTML5 ist - vollständig frei sämtlichen Elementen Rollen zuweisen. Für mich der ultimative Turbo ... ;-)

Auf diese Art und Weise könnte man das 'Farbwahl-Problem' (und etliche andere auch) komplett erschlagen. Finde ich zielführender als an der von Dir vorgeschlagenenen noch eine Krücke dranzubasteln.

Ich hoffe, dass mein Geschreibsel einigermaßen verständlich ist ...

Carolina.

Zitat:

---

Zitat von lucina

Das Problem sehe ich eher - siehe oben - dabei, sowas halt nicht zu machen. Also von der Struktur her so zu arbeiten, dass man

Code:

---

.myred{
color:#AC000C}
.myblu{
color:#6288DD}

---

einmal festlegt, und dann diese .Classes nur zuweist. Dann hält sich das alles doch sehr in Grenzen, statt für jedes einzelne Element die Farbzuweisung jeweils individuell zu handhaben. Bedeutet im Vorfeld ein wenig mehr Arbeit, in der Anwendung dann aber sehr viel weniger.

---

Hmmm, gerade das würde ich nicht empfehlen. Also wenn ich dich richtig verstanden habe gibst du den einzelnen Elementen im HTML-Code die Klassen myred, myblu usw. mit. Das macht doch alles noch komplizierter und hebt die Vorteile von CSS auf. Denn wenn man mal die rote Schrift grün haben möchte, dann muss man sich durchs HTML hangeln und dort myred durch mygreen an unzähligen Stellen ersetzen; ändert man das im CSS dann hat myred einen grünen Farbwert und man blick gar nichts mehr.
Im HTML sollte wirklich nur der Inhalt sein, alles was mit Formatierung/Gestaltung zu tun hat gehört ins CSS, das gilt auch für die Benennung der Klassen und IDs.
Oder hast du das anders gemeint?

Hi,

vielleicht sollte ich nochmal etwas ausführen, wie ich mir die Umsetzung vorstellen könnte:

In Theme > CSS gibt es einen Extra "Bereich" für ein Farbschema in dem zu "Farbwörtern" die entsprechenden Angaben abgelegt werden. Die Sachen kommen in eine extra "Tabelle".

Im CSS können die Schema-Angaben verwendet werden - müssen es aber nicht.

Bei der Erstellung der eigentlichen CSS-Datei werden beide Sachen "gemergt".

Für die Umsetzung wäre ein erster Schritt, wenn es einen Hook bei der Erstellung der CSS-Dateien gäbe, in den man sich einklinken kann.

Letztlich wäre das Prinzip auch auf andere Angaben wie z.B. Breitenangaben oder was auch immer anwendbar {{style:my_border_thin}} mit my_border_thin = '1px'...
border: solid {{style:my_border_thin}} {{color:my_border_dark}};

Die ganze Sache ist sicher nichts "Essentielles" - z.Z. eher ein "Gedankenkonstrukt", ob man sich mit der Sache mal beschäftigen könnte... aber ohne den Hook würde es eh schwierig werden.

zonky

Einen solchen Hook habe ich bereis angefragt, weil ich genau eine solche Extension schon mal bauen wollte.
Das steht seit knapp einem halben Jahr bei mir auf der ToDo-Liste, leider hab ich bisher noch keine Zeit gefunden das zu machen :(