Anmelden
Ich möchte für die nächsten 30 Tagen angemeldet bleiben
Deutsch
Several pages in the usergroup are available in English. Click on english to visit these pages.

Veröffentlichungen

Alle Artikel | Suche | Newsfeeds

default.css? portal.css? module.css? skin.css?
Philipp Becker, Dienstag, 18. Dezember 2007 14:52, Article Rating

CSS Dateien in DotNetNuke werden vom Portalsystem dynamisch zur Laufzeit geladen. DotNetNuke hält dabei immer eine bestimmte Reihenfolge ein, so dass Entwickler und Designer sich darauf verlassen können, an welcher Stelle sie Deklarationen im DOM ( D ocument O bject M odel ) verändern bzw. erweitern können. Die Reihenfolge im Einzelnen

  1. module.css

    diese css Datei kann vom Modulentwickler bereitgestellt werden, um eigene modulspezifische Klassen zu definieren und zu nutzen. In der Reihenfolge der auf einer Seite platzierten Module werden diese nach und nach geladen.

  2. default css

    diese css Datei dürfte so manchem Designer ein echter Dorn im Auge sein, definiert sie doch eine Reihe von Klassen, die, selbst wenn man sie nicht nutzen möchte, u.U. explizit überschrieben werden müssen. Andere wiederum mögen dies als hilfreich erkennen, müssen doch andererseits Klassen "nur" angepasst werden. Erklärtes Ziel des DNN Skinning Teams ist es dennoch, diese Datei abzuschaffen bzw. als optional schaltbar zu machen.

  3. skin.css

    in der Stylesheet Datei des Skins selbst, wird der Designer eigene Klassen erstellen über die sich das Layout seines Skins definiert, respektive wird er auch Werte aus der default.css überschreiben, um sein Skin "einzigartig" zu machen, bzw. vom DNN Standard abzuheben.

  4. container.css

    kann verwendet werden, um, ähnlich wie in der skin.css, das Layout eines Containers zu beeinflussen. Soll ein Container skinübergreifend funktionieren, muss diese css verwendet werden. Ein Container, der fest mit einem Skin verbunden ist, kann der Einfachheit halber natürlich auch über die skin.css gestylt werden

  5. portal.css

    als letzte in der Reihenfolge geladene Datei bietet sich portal.css einerseits an, um auf Portalebene css Klassen aus dem Skin oder einem Modul zu übersteuern; andererseits aber auch, um wiederum eigene Klassen zu definieren, die in Modulheadern, Textmodulen, etc... vom Administrator verwendet werden können, um z.B. bestimmte Texte zu formatieren.

Anhand eines Beispiels möchte ich kurz erläutern, wie das übersteuern einer CSS Klasse funktioniert, beispielhaft sei hier die Klasse .Skinobject dargestellt, deren Deklaration natürlich in der default.css beginnt und oft verwendet wird, um Textobjekte im Skin darzustellen:

.SkinObject {      
    font-weightbold;      
    font-size: 8.5pt;      
    color#003366;      
    font-familyTahomaArialHelvetica;      
    text-decorationnone;      
}    

Diese Klasse wird wohl kaum von einer module.css übersteuert, sehr wohl aber u.U. von einem gekauften Skin in einer skin.css

.SkinObject {      
    color:#000000;      
}     
 

Wir sehen hier, dass das Skin den Wert für die Farbe des Textes auf schwarz ändert, in dem der Wert für color einfach neu gesetzt wird, d.h. überschrieben wird. Da die skin.css nach der default.css geladen wird (siehe oben), gilt hier der zuletzt genannte Wert, in diesem Fall also schwarz. So würde die neue Klasse aussehen, wenn sie zum Client geschickt wird:

.SkinObject {         
    font-weightbold;         
    font-size: 8.5pt;         
    color#000000;         
    font-familyTahomaArialHelvetica;         
    text-decorationnone;         
}      

Aber halt, keine Regel ohne Ausnahme... Möchte beispielsweise der Skindesigner, dass nach ihm keiner mehr den Wert für die Farbe übersteuern kann, dann würde er vermutlich einen kleinen Zusatz eintragen:

.SkinObject {        
    color#000000 !important;     
}     
 

Und was passiert dann mit den anderen Werten? Ist die Schrift immer noch "bold"? Natürlich, dieser Wert ist bislang von uns nirgendwo übersteuert worden; mit anderen Worten, er bleibt immer noch Gesetz, solange nämlich, wie er nicht übersteuert wird. Das ist im übrigen genau der Stein des Anstoßes, wenn Skinner sich über default.css ereifern. Leider gibt es keinen Weg eine Klasse zu "reseten", einmal definiert muss sie immer wieder überschrieben werden, einmal definiert wird sie auch zwangsläufig immer ausgeliefert. Halb so wild, könnte man meinen. Man muss ja SkinObject nicht verwenden im eigenen Skin. Was aber geschieht mit den generischen Definitionen? Wieder ein Beispiel aus der default.css:

H1  {  
    font-familyTahomaArialHelvetica;  
    font-size:  20px;  
    font-weight:    normal;  
    color#666644;  


Hier wird von DNN festgelegt, wie Überschriften auszusehen haben, die z.B. vom HTML Editor in Texten eingefügt werden. Da ich keinen Einfluss darauf habe, ob und wie der Editor einen H1 Tag setzt um eine Überschrift zu formatieren, muss ich die komplette Klasse wohl oder übel in meinem Skin, bzw. in meinem Portal überschreiben.

Space
Space Space
Kategorien  

Autoren  

Archiv