So, hier der komplette Hack für den CSS-Editor!

Die andauernden Probleme die es immer wieder gab, das der Upload nicht klappt, das Regeln die wohlüberlegt eingefügt wurden angemeckert wurden, das es nicht möglich war Hacks einzubauen weil es die Fehlerprüfung unmöglich machte abzuspeichern, alles passe, Ende, vorbei. 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!!! Wenn jemand mag, es darf sich gerne noch darüm gekümmert werden, bkm und ich sind daran gescheitert. Es ist eine kleine Vorbereitung in der Datei versteckt, näheres aber dann von mir, ihr wisst ja wo ihr mich findet.

Die Fehlerberichte und der Entwicklungsprozess ist hier nachzulesen, wenn nötig dann auch dort weiterdiskutieren, Fehler zu melden.

Ich empfehle abgebildete Einstellungen im Projekt vorzunehmen:
Klicken um den Anhang anzusehen

ZIP entpacken, ins Backendverzeichnis kippen, hochladen. Die enthaltene css_edit.tpl sollte auch mit hochgeladen werden! Es ist nur eine Änderung von einem Textfeld zu Textarea gemacht, dies ist notwendig da es auch die Möglichkeit gibt das mehrzeilige Selektoren vorkommen.

Klicken um den Anhang anzusehen

Ich persönlich würde mich freuen wenn sich die Maintainer mal dazu äußern würden ob sie das übernehmen. Ich bin der Meinung, dass damit der Editor so bleiben kann wie er ist. 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, wozu das sich dort öffnende Feature da ist erschließt sich mir nicht.
Vielleicht wär das auch was für ne Thickbox

Mitgewirkt haben, bkm, summerbrother und braendle, Danke.

Wenn die Erweiterung hält, was sie verspricht, kommt Sie in den Kern.

Thema physische Dateien:
Die gibt es nicht. Die Datei wird aus Datenbankinhalten generiert. Somit ist die Datei praktisch nur ein "Cache". Das ist ja gerade das Hauptproblem des Editors.

Damit dieser die CSS Datei wie gewünscht abbilden kann, muss die interne Logik so umgebaut werden, das die Datei als Ganzes betrachtet wird und bei Gelegenheit in Ihre Einzelteile zerlegt wird.

Momentan läuft es so, dass es nur die Einzelteile gibt, die bei Bedarf zu einem großen Ganzen zusammengesetzt werden. Dummerweise entsprechen die verfügbaeren Einzelteile aber nicht der Summe der möglichen Einzelteilen. Womit ich sagen will, letzteres ist größer, und noch schlimmer: es ist eine dynamische Größe, die alleine durch die Entwicklung von CSS Standards wächst.

Ach so, du gehst da anders ran. Die Datei existiert sehr wohl, die wird auf den Server geschrieben und wird bei jedem edit gändert und vom Besucher-Browser geladen. Ich dachte jetzt man holt die Datei in eine Textarea, schreibrechte hat sie automatisch, editiert die dort und stößt dann über die inc.css.php sowas wie einen upload an. In dessen Folge wird die DB und die Datei aktualisiert.
Wenn das so nicht geht, dann wirds schwieriger.

Zu der unbekannten Größe "Standards", das kann ja erst mal so bleiben, automatisiert geht nur CSS1, alles weitere muss per Hand gemacht werden. Oder was willst du damit sagen!?

Damit will ich sagen, dass Du als Programmierer dann ewig dem "gerade aktuellen Standard" hinterherprogrammierst, weil sich dauernd etwas ändert. Wenn Du Supportverträge verkaufen willst, ist das die ideale Lösung. Willst Du aber etwas allgemeingültiges schaffen, was möglichst robust ist und lange Besatand hat, ist dies der falsche Weg.

Daher will ich ja umbedingt, das die Grundlage des CSS Editors eine Datei ist und über eine simple textarea bearbeitbar ist. Der WYSIWYG CSS Editor kann ja gerne darauf aufbauen, überhaupt kein Problem. Aber wenn es kracht (also wie jetzt), nicht das gewünschte abgebildet werden kann, dann muß es die Möglichkeit geben, auf die unterste Ebene zu kommen und dort arbeiten zu können.

Solange dies nicht möglich ist, ist der CSS Editor keine dauerhafte Option für das System.

Mit diesem Hack erreichst du doch die unterste Ebene, in der kleinen Textarea ganz links
Da kannst du jetzt reinschreiben was du willst, es wird einfach alles übernommen! So wie ich von Anfang an wollte, schon beim anderem Projekt (leider nicht mehr nachzulesen). Wenn ich in meine CSS "Blödsinn" reinschreibe, dann steht das jetzt auch drin. Es Kracht nicht mehr!
Nebenbei, CSS1 ist allgemeingültig, wird Bestand haben.

IMHO ist von der Programmlogik unser Ziel schon erreicht. Alles andere, die automatisierte Eingabe und das Edit "direkt an der Datei" sind nun nur noch Zusatzfeatures.

Klar wäre es schön die Automatismen mal anzupassen, aber das wäre ein anderes Thema.

Wahrscheinlich denkst du viel weiter als ich

Nachtrag Wie sieht denn die Alternative aus, Editor rausschmeißen, Textarea rein? Wie soll denn derjenige der von CSS nur marginal gehört hat seine Schriftart ändern, der dreht doch durch

@Olaf
Super Arbeit.

@björn
Wie sieht den das mit den im FCK+Tiny auswählbaren CSS-Einstellungen aus, hat das keinen einfluss? Wird das alles im ContentFlex aus dieser spezielen CSS-Datei angezeigt und Auswählbar?

Gruss

hallo olaf

klingt alles sehr gut. aber irgendwie bin ich zu blöd, die von dir vorgeschlagenen einstellungen für das projekt zu tätigen. ich finde unter der ganzen administration nirgends diese optionen zum einstellen der css-parameter.


gruss andi

Admin -> Projekte -> Schraubenschlüssel (2. Symbol von rechts in der rechten Spalte des zu bearbeitenden Projektes) -> ganz runterscrollen

argh, das icon (kommt mir eher vor wie eine bombe) habe ich doch glatt übersehen, weil es so abgesoftet war :-) sorry und danke!

Ja, erst einmal eine Textarea, die eine Datei schreibt. Das ist die unterste Ebene, die einfach da sein muss. Darauf können grafische Tools aufgesetzt werden. Wer möchte, kann so etwas ja programmieren. Sicherlich erst einmal ein Komforteinbusse.


Ich weiß jetzt nicht genau, was Du meinst, und wenn ich es wüsste, bin ich mir relativ sicher, das das Thema dieses Threads ein anderes ist.

Na dann proggt mal. Frage mich nur wie dann die ganzen Styleauswahlen in den Modulen gehen soll, das geht doch alles über die DB. Wie gesagt ich seh das nicht so. Solange kein neuer Editor da ist würd ich den alten nicht rausschmeißen. Die Textarea kann ja trotzdem kommen, ich schlug ja da auch was vor.

Wir können das beenden, mein Standpunkt ist vertreten, vielen Dank

wie wäre es mit einer Trennung?

1. Eine CSS für das Layout, per Textarea zu bearbeiten.
2. Eine CSS für den Content, mit dem jetzigen Editor zu bearbeiten.

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.

Hätte den Vorteil, dass die Angaben die nur fürs Layout notwendig sind gar nicht in der Datenbank auftauchen. Und die damit Auswahl, der für die Redakteuer erforderlichen Regeln nicht so umfangreich ist.

Wenn du diese Unterscheidung für dich machst o.k., aber wozu sollte Sefrengo sich darum kümmern, siehe mein Vorschlag weiter oben. Dann kannst du entscheiden wie du bearbeitest


Das wiederum ist ein guter Gedanke, entweder beim Upload ein Schalter der bewirkt ob die Daten für Module bereitgestellt werden oder nicht. Oder/und im Editor dafür ein Schalter bei den entsprechenden Selektoren. Nur ob das jemand reinprogrammiert.... müsste bestimmt die DB angepasst werden

Da ist mein Gedankengang ganz einfach, die eine CSS gehört zum Layout (hat sich keine Redakteuer drum zu kümmern) die andere gehört zum Content und damit von Fall zu Fall in den Bereich des Redakteuers.

Eine etwas andere, bzw. meine besondere Sichtweise des Begriffes "Trennung von Layout und Inhalt"

PS: darum soll sich auch nicht Sefrengo kümmern, sondern der Webseiten Entwickler.

So, nun auch mein Senf mal wieder dazu. Die absolute Trennung ist ein schöner Gedanke aber doch in der Praxis nicht durchzusetzen. Haben wir doch schon alles durchprobiert. Olaf, weisst Du noch bei der XHTML-Version ? Da haben wir doch genau das praktiziert. War aber nicht wirklich praktikabel.

Den Editor komplett zu entfernen und gegen eine Textarea auszutauschen halte ich für Quark. Wo ist dann der Unterschied zur Bearbeitung per FTP ?

Olafs Ansatz ist schon ganz ok und praktikabel. Nu stell man sich noch vor, das in der Übersicht der Regeln mittel Ajax die jewelis zu bearbeitende Regel sich *zisch* öffnet und beim schliessen speichert...
Wahlweise kann man in select-Feldern klicken oder einfach, wie jetzt auch, in der kleinen Textarea direkt schreiben....

@eknem
FULLACK, und damit ist das dann eine Frage des Rechtemanagments, die vom Layout bekommt kein Redakteur zu Gesicht und fertig.

@summer
XHTML-Edition, du meinst das Musterlayout, da zeigte sich das es nicht allgemeingültig zu händeln war. Weil du nie weist was der User genau braucht, und damit sind wir wieder bei eknem, das muss der Admin machen

Wir werden ja sehen wie Björn letztlich entscheidet, ich seh es so, dass sich erst mal niemand finden wird der einen anderen Editor da einbaut.

Vielleicht sollte man jemanden fragen, der sich damit auskennt

Ja mei, ich geh immer davon aus das niemand Zeit hat

Mich persönlich wird's natürlich freuen wenn du meine Vorstellungen umsetzt

Nu Spass beiseite, du hast dich ja sehr rar gemacht. Wenn ich gar nicht mehr weitergekommen wäre hätte ich dich bestimmt auch gefragt. So denke ich aber immer, geh damit keinen auf die Ketten, die haben alle so viel zu tun. Und im Forum hab ich ja gefragt, fällt mir gerade ein. Das ist denk ich die beste Adresse, oder!?
Und dann heißts, Freiwillige vor...

Oder vielleicht mal ganz einfach einen Plan erstellt was wirklich gebraucht wird und nicht einfach zur nächsten Version wieder raus fliegt.
Eine Kombi Version DB=> cssfile && CSSEditor=>Textarea finde ich schon nicht schlecht, wenn man davon ausgeht das nicht jeder CSS
aus dem "Kopf" erstellt und Module auch auf CSS zugreifen.
IMHO

Damit wir uns nicht falsch verstehen, ich habe nichts dagegen, wenn wir ein möglichst komfortables Tool haben.

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

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.

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.

Wenn jemand natürlich die Zeit hat, eine Lösung zu finden, die weniger schmerzhaft ist, würde ich das natürlich sehr begrüssen.

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.


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


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!

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 ist der springende Punkt.

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

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



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.

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

@alle

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

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.

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


gruss 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!?

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

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..

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

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

@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.

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

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)

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

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...

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

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

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

hallo mika

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


und die antwort von meister olaf:


ist also gewollt.

@mika, noch ein Zitat:

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.

nebenbei bemerkt: IE MAC? was ist bzw. war das eigentlich?!

wie meinst' des jetzt? soweit ich weiss, war das ne superduperspezial-mac-ie-5.2-Version (zumindest bei OSX). Aber ich hab keinen. Trotzdem hätt ich gerne ein barrierearmes, browserübergreifend funktionierendes CSS. Und da stellt Yaml halt schon eine gute Plattform zum weiterarbeiten dar.

Aber zum Thema: Der Editor schmeisst das CSS derart um, dass ich Zeile für Zeile per Hand lesen muss. (sind halt auch eine große Menge Kommentare im Yaml-CSS drin. Ich experimentiere gerade mit der Datei /css/main/iehacks.css aus dem aktuellen YAML-Pack yaml_252_06110101)

Mit Dateivergleich meckert mein Programm, dass aufgrund zu umfangreicher Unterschiede hier kein Vergleich mehr möglich ist. dauert also.

@olaf: wie kommst du drauf, dass der Editor den mac-Hack rausschmeisst. Wird der als Kommentar deklariert?

michel

nunja. ich würde sagen in der grafischen branche (leider) ein noch nicht ausgestorbener browser. bei seiten mit zielpublikum «macintosh user» sicherlich noch immer empfehlenswert zu unterstützen. immerhin tauglicher als ie 5 win.


soweit mir bekannt schliesst das yaml-framework ie mac und netscape 4.5 vom css standardmässig aus. bietet aber eine möglichkeit, die «ie-mac-unterstützung» wieder zu integrieren.


klar /* no IE5 \*/

Echt jetzt!? Eigentlich dürfte es nur die Kommentare entfernen.

Das lässt sich IMHO dann ganz gut vergleichen. 2 Fenster nebeneinander und dann in dem einen die Kommentare überspringen. Du kannst dir ja dazu auch die angelegten Dateien vom Server holen, dann brauchst du nicht im Browser rumwurschteln.

@ADMINS
könnte man bitte diesen Thread ab hier: http://forum.sefrengo.org/index.php?showto...#post-main-5255 splitten?

Dabei fällt mir auf, die Beitragslinks funktionieren nicht! Ich hab mir die ID aus'm DomInspector rausgesucht. Die sollten da eigenlich automatisch erscheinen, aber alles ab # fehlt dort, wäre jedenfalls gut

Hallo Olaf,

Du musst nicht die rechte, sondern die linke Maustaste benutzen, klicken und dann den Link ausschneiden

Ich hab jetzt a bisserl experimentiert: Das Problem liegt vor allem im Download bereits hochgeladener CSS-Skripte. Ich habe die Kommentare aus der Grund-Datei entfernt, damit ich ein vergleichbares Ergebnis bekomme, hab anschließend die Datei hochgeladen, manche Selektoren als fehlerhaft markiert bekommen und dann wieder aus Sefrengo downgeloaded. Die erste Datei ist diejenige, die ich hochgeladen habe, die zweite diejenige, die ich downgeloaded hab:

hochgeladene:

downgeloadede Datei!!!:



Was auffällt: Die @...-deklarationen werden vollständig durch @import(url...) ersetzt!?

Mir kommts ja fast so vor, als ob ich den hack gar nicht eingespielt hätte, aber ich habs gemacht und auch die Einstellungen im Projekt - ich verstehs nicht.

Was auch total komisch ist, ist die Tatsache, dass beim Hochladen in Design > Css was ganz anderes angzeigt wird, als dass dann als CSS eingebunden wird:

Klicken um den Anhang anzusehen

in der Seite hab ich dann das CSS über die FF-Web-Developer-Bar ausgelesen und das CSS stimmt mit dem überein, was dann downgeloaded wird (siehe oben).

Ich hab jetzt grade keinen ftp-Zugang, aber heute abend kontrolliere ich noch mal die dateien aus deinem Hack Olaf.

Ansonsten hab ich dann keine Ahnung mehr, was da passiert ??? ratlos

Ich weiss es, ich weiss es

CSS1 kennt keine Media-Typen in CSS-Dateien. Der Parser kennt nur CSS1. Die einzige Form der @-Einträge sind dort @import-Einträge und der CSS-Parser zerschiesst dir diese @media-Angaben in der Datei.
Sorry, die YAML-Erweiterung ist nicht mit dem CSS-Editor zu nutzen. Keine Chance - im Moment.

Diese Art der Dateien - da hatte ich es die Tage mit Björn drüber - werden in der nächsten Version des CSS-Bereiches unterstützt. Da hilft auch der Hack von Olaf zur Zeit nicht.

alles klar. danke dir. dann werd ich ausschließlich mit dem dateimanager arbeiten und in den Projekteinstellungen die CSS-Dateien erlauben. Diese können dann auch ins Layout eingebunden werden. Ich kann zwar nicht direkt im SF editieren, aber brauche kein FTP. Hilft auch schon a bisserl weiter.

Merci und lg Michel

Jo, danke, warum einfach wenns auch umständlich geht Hautsache ich merk mir das....

Ich seh auch keine Möglichkeit das noch irgendwie reinzuhacken, weil es nie mit dieser Schachtelung der {} zurechtkommen würde.
Ansonsten hört sich ja so an als wenn schon dran gearbeitet würde, toll.

Dazu benötigt man eine Art "zweite Ebene" in den CSS-Regeln, die es so noch nicht gibt.


Jo, am Konzept feile ich noch ein bissel, da hier noch einiges zu bedenken ist