CSS-Editor-Bereinigung Version 1.0, Damit die CSS so bleibt wie erstellt Einstellungen

[Olaf]

Es muss technisch aber so gestaltet sein, dass sich die CSS Datei ohne Kompromisse bearbeiten lässt.

Das ist doch nun gegeben, was stört denn noch, dann raus damit. Das einzige Gegenargument kam bisher von andi, wegen dem Meckern beim Upload, ich dachte es wäre besser so, kann aber deaktiviert werden.

Das diejenigen, die wirklich mit CSS arbeiten wollen, dies, aufgrund der Einschränkungen des Editors, per FTP und damit am System vorbei machen, kann es ja nicht sein.

Ebend, gibt es dir nicht zu denken wenn sogar ich sage, "ist o.k. so, kann so bleiben"

Die Textarealösung ist für mich die einzige Möglichkeit, die ich ressourcenmässig bewältigen kann. Das dies nicht nur ein Gewinn ist, ist mir klar. Unter dem Strich wiegt für mich in diesem Fall der Gewinn an Flexibilität aber mehr als der Erhalt vom Komfort.

Dann sag mir doch das es so nicht geht wie ich vorschlug, dann geb ich Ruhe. Mir fehlen oft eure Argumente
Wenn du es schaffst eine Textarea zu proggen, dann kann es doch nicht mehr so ein großer Schritt sein, die in ein neues Template zu packen und zusätzlich anzubieten. Wird die Datei gespeichert schreibst du sie gleichzeitig in die DB und fertig.
Es kann IMHO beides geben!

[luxli]

Der CSS-Editor ist doch für Newby und schnelles Ändern oder Erstellen einzelner CSS ideal und die Auswirkung kann sofort kontrolliert werden. Darum begrüsse ich diese Bereinigung.

Andererseits

Das diejenigen, die wirklich mit CSS arbeiten wollen, dies, aufgrund der Einschränkungen des Editors, per FTP und damit am System vorbei machen, kann es ja nicht sein.

Das ist der springende Punkt.

Wäre es nicht möglich, dies ähnlich dem was Alexander hier im Nachsatz erwähnt zu lösen.

[andi]

Das einzige Gegenargument kam bisher von andi, wegen dem Meckern beim Upload, ich dachte es wäre besser so, kann aber deaktiviert werden.

stimmt so nicht ganz, da gabs noch einen zweiten punkt, welcher björn nochmals «aufgabelt»:

Das diejenigen, die wirklich mit CSS arbeiten wollen, dies, aufgrund der Einschränkungen des Editors, per FTP und damit am System vorbei machen, kann es ja nicht sein.

genau hier störe ich mich am aktuellen system. da mir der editor wirklich zu umständlich ist muss ich immer den umweg über den ftp machen. will ich das ganze auch noch im system für die module bereit halten muss ich zusätzlich jedes mal das veränderte css-file in sefrengo neu importieren. eine «einfache» textarena wäre für mich ein segen.

[Olaf]

genau hier störe ich mich am aktuellen system. da mir der editor wirklich zu umständlich ist muss ich immer den umweg über den ftp machen. will ich das ganze auch noch im system für die module bereit halten muss ich zusätzlich jedes mal das veränderte css-file in sefrengo neu importieren. eine «einfache» textarena wäre für mich ein segen.

Sach, liest jemand was ich schreibe???? Das ist kein Problem des Editors! Der Editor öffnet sich wenn du auf einen Selektor klickst. Das ist ein Problem des Core! Stichwort, Vorhaltung der CSS, Einbindung ins System.
Somit gebe ich die Frage zurück, was stört am jetzigem Verfahren mit Upload und Editor, was hindert dich daran mit diesem Hack ohne FTP zu arbeiten? Bitte nicht wieder Textarea, das gehört hier nicht hin.
EDIT Ach so, im übrigen fehlen mir wieder deine Argumente
Du sagst es hindert dich, aber was hindert dich daran, das lässt du offen.

Für die Zukunft würde ich noch anregen, eine Möglichkeit zu schaffen direkt in der physischen CSS arbeiten zu können, sprich, die Datei selbst in eine Textarea zu laden und dort zu editieren. Zu beachten wäre dabei, dass nicht nur die Datei editiert wird sondern auch die Einträge in der DB zu aktualiesieren sind. Dies könnte sich hinter dem Bleistifftsymbol in der Rechten Spalte der Übersicht verbergen.

Es kann doch nicht sein, das ihr das nicht kapiert.

[feniweb]

@alle

Ich mache es jetzt auch schon so. Die CSS fürs Layout ist hardgecodet, die andere wird importiert. Nachteil ich kann die CSS fürs Layout nur per FTP ändern. Hier wäre eine Textarea für mich sehr nützlich.

Also ich mache das auch so Layout immer extern und nur Formatierungen die für das ganze Modu-System ist im CSS-Editor. Über Dreamweaver kann man recht schnell Layoutänderung durchführen und neu laden.

Aber über ein Textarea hätte ich auch nichts.

Müssen die CSS-Regeln in der DB stehen um allen Modulen zugänglich zu machen?


Gruss

[andi]

Somit gebe ich die Frage zurück, was stört am jetzigem Verfahren mit Upload und Editor

ganz einfach...es ist umständlich (da bin ich mit einem geeignetem texteditor schneller)

was hindert dich daran mit diesem Hack ohne FTP zu arbeiten? Bitte nicht wieder Textarea, das gehört hier nicht hin.

auch mit hack muss ich mit einem ftp arbeiten...ausser ich will den (umständlichen) editor nutzen, um neue klassen, selektoren usw. anzulegen.

ich schalt mich hier jetzt mal aus, verfolge das geschehen aber gerne weiter...


gruss andi

[Olaf]

Wäre es nicht möglich, dies ähnlich dem was Alexander hier im Nachsatz erwähnt zu lösen.

Das ist doch aber ein Programm für PC oder MAC, nich fürn Server

ganz einfach...es ist umständlich (da bin ich mit einem geeignetem texteditor schneller)
auch mit hack muss ich mit einem ftp arbeiten...ausser ich will den (umständlichen) editor nutzen, um neue klassen, selektoren usw. anzulegen.

Nein, ebend nicht, du sparst jetzt den Schritt FTP. Du nutzt einfach den Editor nicht! Du editierst deine Dateien local, lädtst sie hoch und fertig. Das ist der einzige Gewinn den dieser Hack bringt. Und natürlich das es wenigstens möglich ist im Editor eigene Angaben zu machen und er Alles annimmt. Wenn du das verstehst und dann meinen FeatureRequest richtig einordnest, dann sind wir doch einer Meinung, oder!?

EDIT
Wieso ist es eigentlich umständlich mit dem Editor neue IDs anzulegen? Oben Selector auswählen, NAME eingeben, in Textarea die Regeln reingeschrieben. Ich könnt mir sogar vorstellen zukünftig bei kleineren Sachen so zu arbeiten. Ich glaub nicht das ein anderer Editor viel schneller zu bedienen ist. Am Rande bemerkt

[Guest_summerbrother_*]

Ich bin der festen Überzeugung, dass mit dem Editor in seiner jetzigen Form noch keiner gearbeitet hat. Sonst würde er erkennen, dass die Arbeit um ein vielfaches erleichtert ist, für alle Beteiligten.

Ich hätte auch nie gedacht, dass Olaf sich irgendwann mal für den Editor ausspricht, aber ich habs ja schon immer gesagt ..

So, ich fahr ne Woche zum Skifoahn und Ihr diskutiert das hier schön weiter..

[braendle]

Ich nu wieder ...

Danke Olaf, für den Einsatz ... ich hatte wenig Zeit, sehr wenig, einfach zu wenig um mich um größere Umbauten zu kümmern.
Die Problematik des Editors ist mir schon länger bewußt, aber für mich ist das Hobby und mit Beruf und Familie war das nicht in Einklang zu bringen.

Konzeptionell muss man sich eines klar machen:
Stilklassen müssen in den Modulen bereitgestellt werden könnn.
Ob das aus der DB geschieht oder nur durch Parsen der Stildateien ist eigentlich wurscht. Sinn und Zweck des Editors war, die Stile in der DB vorzuhalten um ein ständiges Parsen der CSS-Dateien (und damit Performance-Probleme) zu verhindern.

Also sollten die CSS-Infos - auch beim Bearbeiten einer CSS-Datei als ganzes - wieder in der DB laden. Das kann man sicherlich machen, was wohl am meisten stört ist der unzureichende Support von CSS2/CSS3-Selektoren und -Regeln beim Validieren und Schreiben ins File. Die Unantastbarkeit des CSS-Files sollte für die Zukunft wohl festgeschrieben werden.
Wobei - wenn ich Tools wie Dreamweaver sehe ... ach lassen wir das ... ich mag diese Vergleiche nicht.

Nun, es gibt für alles Lösungen:

1. Das CSS-File wird zukünftig nicht automatisch generiert, kann aber über einen entsprechenden Button generiert werden. Hierbei gehen aber Informationen, die nicht in der DB stehen verloren - eine entsprechende Warnung wird vorher ausgegeben.

2. CSS-Regeln, die über den Editor bearbeitet werden, werden im CSS-File auf Anforderng ersetzt. Nur die Regel selbst - nicht die ganze Datei. Jede Regel kann ene Kommentierung bekommen, die bei Generierung eines CSS-Files vor der Regel im CSS-File ausgegeben wird.

3. Das CSS-File wird als Textarea bearbeitbar und wird nach Bearbeitung in die DB importiert. Kommentare ausserhalb der Regeln werden beim Import der folgenden Regel des CSS-File zugeordnet.

4. Eine spezielle Kommentierung in der CSS-Datei ermöglicht Bereiche, die vom System als "benutzerdefinierte Regeln" interpretiert und in die DB ohne Änderungen übernommen werden.
Dies sollte die spezielle Hacks etc. die man so als Hardcore CSSler benötigt ermöglichen. Schlimmstenfalls kann eine komlette CSS-Datei als benutzerdefinierte Regel angelegt werden.
Die Kommentierung könnte so aussehen: /** UDCSS ..... UDCSS **/
"Benutzerdefinierte Regeln" werden immer in einem einfachem Textarea bearbeitet - komfortfreie Zone.

5. Es gibt in der DB eine Kopie der Regeln für die Auswahl in den Module und zum Generieren der Datei - für alle Notfälle

6. Validierungen werden am File durchgeführt und nutzen den CSS-Validator vom W3C o.ä. Tools im Netz.

7. Validierungen einzelner Regel werden ebenfalls über das W3C durchgeführt - dazu müssen ggf. temporäre File geschrieben werden können -> Schreib-Lösch-Rechte im Filesystem notwendig.

8. Die Vorschau bei Änderungen wird - wenn möglich - mit Seiten durchgeführt, die die Regel enthalten

9. Beim Upload einer CSS-Datei wird die nur importiert. Eine Prüfung nach W3C wird nur nach Aufforderung durchgeführt.

10. Einige der Ideen könnten man per Projekt-Einstellung zwischen Option und Pflicht umschaltbar machen, z.B. automatische Prüfung mit W3C-Validator, Auswahl des Validators aus einer Liste unterstützter Validatoren, Automatische Generierung des CSS-Files bei Neuanlage etc.
Die Liste der Option kann lang werden

11. Der Regel-Editor kann sicherlich optimiert werden und CSS-Regeln aus den Standards CSS2 und CSS3 unterstützen. Das Bedienkonzept kann optimiert werden.

12. Der Regel-Editor sollte als Unterstützungstool beim Bearbeiten von CSS-Files fungieren und sich dort nur im Bereich der aktiv bearbeiteten Regel auswirken.

Weitere Wünsche sind gerne gesehen.

So ... jetzt trink' ich mal meinen Wein weiter ... und warte auf die Reaktionen

[Olaf]

Ich hätte auch nie gedacht, dass Olaf sich irgendwann mal für den Editor ausspricht, aber ich habs ja schon immer gesagt ..

Das ist ganz einfach, lieber den Spatz in der Hand als den Adler auf dem Dach.

So, ich fahr ne Woche zum Skifoahn und Ihr diskutiert das hier schön weiter..

Schöne Woche Gibts denn schon Schnee in Europa!?

Ich nu wieder ...

einverstanden

[Guest_bkm_*]

... und warte auf die Reaktionen

@braendle

Wäre dazu nicht ein Ansatz ein weiteres Feld in der DB (xxx_css) zuschaffen wo beim ersten auslesen des Files
die komplette Regel von /* bis } oder selector bis } gespeichert wird.
Dieses könnte dann zum zerteilen (für die DB bzw. den Editor ) oder neu schreiben des Files genutzt werden.

[MaZderMind]

Hi
Ich hab den Thread lange verfolgt und mir die Erweiterung auch angeguckt. Ich kann bjoerns Problem nachvollziehen und stimme ihm auch zu, verstehe abe nicht wo genau das Problem besteht.
Olafs bearbeitung ist doch gut und seine Idee hinter dem bearbeiten-Symbol der Stylesheet-Datei eine Textarea unterzubringen ist noch besser.
Für den Moment müsste es so aussehen, dass aus den DB-Inhalten eine CSS-Datei gemacht, der Inhalt in der Textarea ausgegeben und das ganze angezrigt wird. Beim speichern wird dieser Weg zurückverfolgt und die Datei wieder in die DB geschrieben.
Was ich aus Björns aussagen nun rausgelsen hab, ist dass dieser Weg idealerweise anderstum laufen sollte. Das heißt alles wird in der Datei gespeichert, der Editor liest die Datei ein, stellt die Regeln dar und speichert änderungen direkt in der Datei ab.
Problem stellt in diesem Fall die auswahl der Klassen z.B. im Editor dar. Die könnte über einen einzelnen Regex passieren, der die Klassennamen aus der Datei ausliest und in der DB ablegt. Bei jedem Backendseitenaufruf wird über das Dateialter die konsistenz dieser Werte getestet und ggf. erneueret.

Schritt eins ist nicht so schwehr einzubauen -- einfcher vermutlich als der Hack. die inc.css_edit_file (+zugehöriges Template) muss umgebaut werden, sodass die selben Prozesse wie beim Uploaden einer Datei ablaufen.
Schritt zwei ist eine tiefgreifende Änderung im core an die selbst ich mich nicht so ohne weiteres rantrauen würde. Vorerst sollte der erste Schritt allerdings genügen.

Gruß, Peter

[andi]

Das ist doch aber ein Programm für PC oder MAC, nich fürn Server
Nein, ebend nicht, du sparst jetzt den Schritt FTP. Du nutzt einfach den Editor nicht! Du editierst deine Dateien local, lädtst sie hoch und fertig. Das ist der einzige Gewinn den dieser Hack bringt. Und natürlich das es wenigstens möglich ist im Editor eigene Angaben zu machen und er Alles annimmt. Wenn du das verstehst und dann meinen FeatureRequest richtig einordnest, dann sind wir doch einer Meinung, oder!?

dein feature-request ist schon korrekt . trotzdem wäre ein bearbeiten der css in einer textarea direkt im backend erfüllender als erst das css runterzuladen, im editor anzupassen und wieder zu importieren. habe mir gerade nochmals alles durchgelesen: grundsätzlich sind wir doch einer meinung

update:
was mich beim jetztigen editor mit hack noch stört

• löschung der kommentare (diese sind bei grossen css-dateien für die strukturierung unumgänglich)
• sortierung der neuen einträge (ein neuer eintrag soll nicht immer am schluss der css eingesetzt werden - wiederum thema strukturierung)
• fehlende textarea für direkte bearbeitung (jaaaa, steinigt mich)

[Olaf]

Jo, so viele Ideen, so viele Gedanken, sogar andi und ich = Einigkeit

Und nu? Braendle, hast du jetzt Zeit das anzugehen? Hört sich eigentlich so an, dein Post. Wollen wir das angehen? Brauchst du mich dazu?
Sonst noch jemand Zeit und Lust da mitzumachen? Geben uns die Maintainer ihren Segen, helfen sie vielleicht sogar mit?

[braendle]

Jo, so viele Ideen, so viele Gedanken, sogar andi und ich = Einigkeit

Und nu? Braendle, hast du jetzt Zeit das anzugehen? Hört sich eigentlich so an, dein Post. Wollen wir das angehen? Brauchst du mich dazu?
Sonst noch jemand Zeit und Lust da mitzumachen? Geben uns die Maintainer ihren Segen, helfen sie vielleicht sogar mit?

Jepp, mein Post hört sich so an ...
Nein, für den Anfang brauch ich keine Unterstützung für die Umsetzung ... aber zum Testen allemal. Verbesserungsvorschläge nehme ich aber weiterhin gerne und dankend an

[Olaf]

Ahh gute Neuigkeiten. Verbesserungsvorscläge, hm, eigentlich fällt mir nich so viel ein. Wie Andy schon schrieb, die Sortierung!
zu 6. vielleicht noch einstellbar welcher Level/Profil, in der URL zu erreichen per profile=css1 , 2 , 21 oder 3
zu 8. vielleicht eine Seite aus dem Frontend, einfach die CSS nach den vorhandenen einbinden

Das trau ich mir aber nur zu schreiben weil deine Ausarbeitung schon sehr komplex sind. Eigentlich braucht es nicht alles auf einmal was du alles aufzählst. Spatz <-> Adler
Nicht das wir ewig vom Adler träumen müssen

EDIT ach so, wenn Bedarf besteht kann ich dir eine CSS erstellen, wo alles an Zeugs drinnen vorkommt was der Editor unterstützen sollte. Geb bescheid...

[Guest_summerbrother_*]

Das ist ganz einfach, lieber den Spatz in der Hand als den Adler auf dem Dach.

Schöne Woche Gibts denn schon Schnee in Europa!?
einverstanden

Zum ersten Rumrutschen hat es gereicht. Die Italiener sind da Meister im Präparieren.

Wenn Ihr noch wen zum Testen braucht, bin ich dabei...

[mika]

jetzt muss ich noch ne blöde frage stellen: ich hab die dateien von olafs hack hoch geladen und die einstellungen im projekt vorgenommen.

nun lade ich die betreffenden css-dateien über Design > CSS hoch und nach wie kennzeichnet das System bei diversen CSS-Formulierungen (z. B. * html .clearfix od. #main a[href^="http:"], #main a[href^="https:"]) den Selektor als fehlerhaft.

Bedeutet das nun, dass zwar die "fehlerhaften CSS-Dateien" ins System aufgenommen werden (Administration > Projekte > Fehlerhafte CSS-Regeln in CSS-Dateien aufnehmen 2=ja/0=nein = 2) aber trotzdem als fehlerhaft gekennzeichnet werden und das völlig normal ist, oder hab ich was vergessen?

lg Michel

Der Beitrag wurde von mika bearbeitet: Mon. 18. December 2006, 18:59

[andi]

hallo mika

ich zitiere mich gleich selber mit der gleichen frage, welche ich in einem anderen beitrag bestellt hatte:

es werden alle regeln aufgenommen, jedoch erscheint weiterhin die meldung «Es wurden fehlerhafte CSS-Regeln in der Datei gefunden! Bitte überprüfen Sie die hervorgehobenen CSS-Regeln, da sie nicht in der Stildatei verfügbar sind!». habe ich etwas vergessen?

und die antwort von meister olaf:

Ganz klar ein Feature
Du wirst beim Upload zwar drauf hingewiesen aber es wird übernommen. Es kann ja mal sein du hast wirklich was vergessen oder falsch gemacht, nu kannst du die Regeln checken, wenn du nun diese Regeln speicherst werden sie auch als gültig übernommen.

ist also gewollt.

[Olaf]

@mika, noch ein Zitat:

Der Editor gibt jetzt in der Datei das aus was hochgeladen wird, ganau in der Reihenfolge, mit Zeilenumbrüchen, Leerzeichen und allem was ihr sonst angebt.

Aber Achtung!!! Alle Kommentare werden gnadenlos entfernt!!!

Ich weiß jetzt nicht ob Yaml den Hack für IE5 MAC verwendet, das ist der /* no IE5 \*/ kontrollier mal. Denn der wird entfernt.

Ansonsten würde mich sehr freuen wenn du sonstige Erfahrungen mitteilst.