RosenborgSupporterSoftware / RUSK

RBKweb Ultimate Survival Kit
MIT License
1 stars 2 forks source link

Dynamiske settings vs. injected CSS #54

Open havremunken opened 5 years ago

havremunken commented 5 years ago

I RFS hadde jeg CSS som jeg injiserte (for et ord!) i RBKweb-sidene for å få frem fargelegging av ting osv.

CSS er jo i utgangspunktet en bra ting. MEN vi har settings fra brukerne i runtime som kan endres på etc.

Betyr det at vi helt eller delvis må generere CSS dynamisk og slenge inn i siden? Hvordan får vi til dette slik at det blir riktig når en brukerfant vil at noe skal være blått istedenfor grønt?

Ikke sett på hvor dynamisk man kan gjøre CSS injection i userscripts i Chrome extensions enda men det må da forskes på.

larsjaas commented 5 years ago

Fra Trolls-Be-Gone:

(function() {
    var node = document.createElement('style');
    document.body.appendChild(node);
    window.addStyleString = function(str) {
        node.innerHTML = str;
    }
}());

Og deretter:

addStyleString(".trollbutton { border-radius: 5px; color: #000000; padding: 4px; background-color: #aaaaaa; display: inline-block; cursor: pointer; }");

Ser ut fra implementasjonen som om addStyleString() burde endres til å hete setStyleString(), og så må vi ha en wrapper som setter opp style-snutter som konkateneres og legges inn, og at hver snutt evt kan oppdateres individuelt fra settings hos brukeren.

havremunken commented 5 years ago

Jeg hadde innerst inne håpet at vi kunne ha en hel CSS stylesheet som fil som lå i manifest-fila, men ser jo at det er urealistisk å bundle less eller sass eller noe sånt inn her... ;)

Det er ikke noen bedre grunn til at jeg undersøkte i den retningen enn at

  1. Alt blir samlet på ett sted.
  2. Vi får brukt verktøyene for det de er godt for (VS Code er ok å editere css i f.eks.)
  3. Redd det blir mye dirty sanches av masse moduler som sniker inn CSS i document på hver sin front.

Men alt dette er sikkert bare grunnløse hangups, tipper vi får løst det.

larsjaas commented 5 years ago

Er det ikke egentlig best om hver modul holder sin custom css separat for seg selv, så slipper vi git-konflikter og vi ser hva som hører til hva? Kan selvsagt ligge som en plain css-fil og ikke bundles inn i .ts-filen i strenger og slikt, og bygge-steget kan konkatenere de til en felles css-fil sammen med global css for hele systemet. Variabler vet jeg ikke med - har mest erfaring med handlebars-templates, men dine forslag er sikkert mer egnet?

havremunken commented 5 years ago

Jeg har et eksperiment på gang for "mine" moduler som bruker sass for å generere CSS som blir dynamisk slengt inn på siden. Det ser ut som dette blir en suksess, altså at det virker som det skal. Det er en god ting.

Men da vender jeg tilbake til om dette er noe vi burde hatt "felles". Jeg ser ønsket om å ha egne CSS-filer pr. modul, men hva om vi rett og slett har et felles regime hvor RUSK spør hver extmod om hva den ønsker å pumpe inn, og så gjøres det som en del av prosessen?

Fordelen med dette - da kan vi ved settings-endringer ta vekk CSS og legge ny inn igjen uten en page refresh.

Also, vi slipper å gjenskape "dynamisk CSS" i masse moduler. Vi lager det sånn at hver extmod leverer fra seg et objekt som leverer fra seg CSS (i SASS-format) samt key value pairs med SASS-variabler man ønsker å bruke. RUSK setter alt sammen, kverner det gjennom SASS, og leverer til browser.