Donald

Hallo,

wir haben eine PHP-Anwendung, welche die Oberfläche zu einem großen Teil natürlich mit CSS gestaltet. Wir liefern diese Anwendung an Kunden, welche in der Regel durch eine Veränderung der CSS-Dateien auch einen eigenen Look and Feel erreichen wollen. Soweit ok, aber wenn wir für eine neue Version zB eine neue CSS-Klasse definieren (oder eine bestehende verändern müssen), dann wird der Abgleich der CSS-Dateien beim Update immer etwas schwierig.

Jetzt ist die Frage, mit welcher Struktur ich das in Zukunft für alle Parteien vereinfachen kann.

Meine Idee'n bisher:

Idee 1) Eine Grund-CSS mit dem Zwangs-Grundgerüst und eine zweite mit den CSS-Werten die man verändern darf?

Idee 2) Eine Grund-CSS mit allem (unsere Vorgaben, nicht veränderbar). Wir laden aber noch eine zweite CSS Datei, mit welcher der Kunde theoretisch alles überschreiben kann und darf.

Was für Ideen gibt es noch und wie haben das andere gelöst?

Freue mich über Anregungen

Donald

Mister Ad

tr0y

presetting und style limits erreicht man durch die Scope-Referenz des HTML Dokuments die besagt:

- HTML-style-Propeties, diese überschreiben...
- Style-Tags, diese überschreiben...
- Link-tags

Wenn ihr also gewisse Styles hardcoden wollt, dann stellt das mit dieser Hirarchie an. Will der User das dann allerdings in seiner CSS-Datei trotzdem ändern kann er ein style-property overtake vornehmen durch Verwendung des "!important" Instructor, der es zulässt das auch style-tags übergangen werden.

Wie wärs denn wenn ihr den Style allgemein dem User überlasst und die Templates in Zonen einteilt die ihr mit standard CSS-Dateien vorformatiert ?

Alternativ dazu ethabliert das CSS doch per XML + XSLT, gebt in der XML vor was zu einer CSS gerendert werden soll, XML ist weitaus besser als CSS in sachen parsing / manipulation, euer Wartungsaufwand bei der Updatepflege also gering und einfach. Will der Kunde seine CSS-Styles verändern erstellt er eine Kopie von eurer XML und definiert sie um.

Hier jetzt an ein CSS-Framework anzuknüpfen wäre sicher bei "non-highflexible applications", also Anwendungen die so modular aufgebaut werden das absolut nichts in den Anwendungstemplates statisch ist, fehl am Platze.

__________________
Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

Donald

Hallo tr0y,

danke für deine Tipps. Das überschreiben mit "!important" etc. wäre ja in etwa meine Idee 2. Das mit dem XML hab ich mir inzwischen überlegt. Die Probleme bleiben aber im Prinzip die selben. Beim Update muss dann an einer XML-Datei rumgebastelt werden (statt wie bisher an einer CSS Datei). Da bin ich nicht wirklich viel weiter.

Ich werde wohl in die Richtung der Idee 2 gehen. Da kann der Kunde dann alle CSS styles in einer eigenen (später geladenen) CSS-Datei überschreiben, wenn er das möchte. Eigene Elemente sind dann auch noch einfügbar.

Danke trotzdem!

Donald

tr0y

Ich würd das "Styling" ganz beim kunden lassen, das derjenige oder diejenige quasi den kompletten Style überschreibt ohne das da eine CSS im hintergrund rumliegt und mitausgeführt wird.

__________________
Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

mermshaus

Ich würde die Entscheidung davon abhängig machen, ob Nutzer üblicherweise alles verändern oder eher kleine kosmetische Anpassungen durchführen (eigene Logografik oder ähnliches).

Im ersten Fall würde ich nur das user.css laden, da es eine ärgerliche Arbeit wäre, alle Default-Styles zurückzusetzen oder zu überschreiben.

Im zweiten Fall wäre es glaube ich wesentlich angenehmer, wenn der Nutzer seine persönlichen Änderungen auf einen Blick sehen könnte und sich bei einem Update nur mit denjenigen Regeln befassen müsste, die er auch tatsächlich angerührt hat. Das spräche für ein zusätzliches Laden eines user.css nach einem default.css.

In der Regel dürfte wohl Fall 2 zutreffen.

Ein Verändern der default.css halte ich in jedem Fall auch für schlecht.

__________________
Blog | Buch | Kaloa