DotNetNuke CSS hierarchie

[PdeBie]

Hoi allen,

ik ben bezig met het herschrijven van de CSS van een DotNetNuke website. De CSS van deze site is echt slordig met allerlei misbruikte klasses, !important's en weet ik wat nog meer verspreid over tig files.

Hier een stukje over de stylesheets hoe het volgens DNN zelf zou moeten:
http://www.dnnsoftware.co...uke-stylesheets-explained

In de laatste alinea lees ik het volgende:

If you want to create DNN skins effectively it is important to understand the order in which the stylesheets get loaded.
The order is; Modules, Framework, Skin, Container, Portal.

Dus eerst wordt Module.css geladen, vervolgens de Framework stylesheet etc.

Bij de omschrijving van de laatste CSS file (Portal.css) staat het volgende:

This file is specific to a portal. By default it does not contain any CSS, but it can be edited by a site admin from within DNN to overrule CSS in the skins. (Mostly used for small tweaks).

Wellicht snap ik de gedachten gang van CSS (of van DotNetNuke in dit geval) niet, maar je wilt de gemene delers van een website toch in een file verzamelen en kleine tweaks per module? Dus alle form elementen style je in een CSS die over de gehele site wordt gebruikt (Portal.css bijvoorbeeld) en kleine tweaks (op formulier B moeten foutmeldingen groen i.p.v. rood) op Module niveau?

Maar dan klopt de volgorde van deze files toch niet en zou dit andersom moeten?

Anders zou ik in elke module.css voor alle tweaks !important moeten gebruiken, omdat deze anders overschreven worden in de file met de gemene delers.

Wie o wie kan me wat meer uitleg geven hierover?

[ Voor 28% gewijzigd door PdeBie op 11-06-2014 09:47 . Reden: extra info gevonden ]

[TheNephilim]

Volgens mij is de volgorde niet zo raar. Een module heeft in eerste instantie zijn eigen 'opmaak'. Bijschrift zal (bijv.) niet zo opvallen terwijl de labels duidelijk zichtbaar zijn. Dat is iets wat de ontwikkelaar van de module zal bepalen. Jij kan met je portal css, de stijl daarvan alsnog aanpassen. Zeer waarschijnlijk laat je de 'structuur' staan en pas je enkel wat kleurtjes en lettertypes/-groottes aan.

Ik heb geen verstand van DotNetNuke hoor, maar ik gok dat dat het idee erachter is.

[PdeBie]

Maar je wilt toch zaken die in het algemeen hetzelfde zijn (bijvoorbeeld labels hebben een lettergrootte van 12pt) op een zo'n laag mogelijk niveau hebben?
Dat zou ik dan persoonlijk in de skin.css of wellicht het framework.css.

Maar nu geldt bij module B dat de labels beter op moeten vallen en dat ze lettergrootte 14pt moeten hebben (puur een voorbeeld!), dan moet je dat dus in een CSS file eerder bepalen. Dat is toch raar? Dat zou je toch juist later willen vastzetten, zodat hij alle eerdere declaraties overschrijft?

En ik zit hier gewoon met hetzelfde probleem. Ik snap de gedachtengang van DNN niet. Sowieso vind ik de naam voor de laatste CSS file ook raar. Portal.css. Ik zou verwachten dat daar elementen met hun properties in staan die voor het hele portaal (de hele site) gelden.

[ Voor 20% gewijzigd door PdeBie op 11-06-2014 10:59 ]

[MoietyMe]

Sowieso slaat het nergens op om meerdere CSS-files in te laden, dus daar begint de ongein al. Als ik jou was zou ik in Portal.css verwijzen naar eigen CSS bestanden door middel van includes:

Cascading Stylesheet:

@import "base.css";
@import "modules.css";
@import "exception.css";

Of hoe je die dingen ook wil noemen

[ Voor 25% gewijzigd door MoietyMe op 11-06-2014 11:40 ]

[PdeBie]

Mja, dat is de structuur van DotNetNuke. En laat ik me daar maar aan houden, want anders gaan er straks wellicht weer zaken mis als we nieuwe modules aanschaffen of wanneer er updates plaatsvinden.

[incaz]

Het klinkt inderdaad niet erg logisch, maar als alle modules geprefixt worden met een class of id maakt het niet uit - dan hebben ze toch prioriteit. (Dus .module p{ font-size: 14px;} en p{ font-size: 12px;} geeft een basislettertype van 12px maar in de betreffende module wordt het 14px, in welke volgorde ze ook geinclude worden. Wat niet direct opgevat moet worden als pleidooi voor de structuur van DNN trouwens.
(En jaja, rems zijn ook mooi.)

Overigens: @import is niet beter dan link: http://stackoverflow.com/questions/7199364/import-vs-link
Dan kun je beter gaan voor scss/less (al dan niet icm uglify of iets dergelijks) - nette code aan de achterkant, redelijk geminifiede css voor de browsers.

[PdeBie]

Ow dat is nog wel een goede inderdaad, prefixes opnemen in de module.css.

[MoietyMe]

@incaz: SCSS of LESS is inderdaad nog een betere oplossing