System Specific CSS

I'm not 100% about this, but it is worth watching out that your solution doesn't actually end up being more performance intensive than having a bunch of css rules which are completely ignored by the browser. AFAIK, CSS is pretty light in that regard.

My point is that even if core did this, it might end up being worse for the browser opposed to simply loading all of the css and some of it going unused

I've got a professional history of being trash at estimating performance impacts, but I bet someone out there has written about this

I trust my lord and savior scss to help me maintain my css rats nests. 🙂

But this could be a good api GL request. Maybe poke around and come up with a couple solid use cases which are currently a pain to implement.

It'd be great if you could find some research showing that excessive css rules are bad for paint times.

And I would strongly recommend you make no assertions about the simplicity of a request when writing up the GL for it 😉

Just append your system specific stylesheet during the init hook. Like this:

const systemCSS = {
   wfrp4e: '/modules/<your module name>/css/wfrp4e.css'
};

Hooks.once('init', () =>
{
   const href = systemCSS[game.system.id];

   if (href)
   {
      document.getElementsByTagName('head')[0].append(Object.assign(document.createElement('link'), {
         href,
         rel: 'stylesheet',
         type: 'text/css',
         media: 'all'
      }));
   }
});

There should be no performance penalty.

@Mouse0270 gave LeaguePoints™ to @MLeahy (#20 • 119) and @Calego (#1 • 1427)

@Mouse0270 gave LeaguePoints™ to @MLeahy (#20 • 120)

You might be waiting a while for it to get added to core if it ever does; I suppose still worth filing an issue to document the request. When there is an easy shim for a feature that very few would use I think it'd be rather low priority.

Of course I should note that the href part should probably be tested on at least the Forge. You might have to scan through the links in head and find your main style sheet then do a string replacement just so you get the right base HREF.

Consider also that this usecase doesn't come up very often. So that plays into the "how much value does this add to core" weight that the Foundry Gaming devs think about.

It's mostly with large scale UI changes or skins, which have a propensity to conflict with opinionated systems.

That and the maintaining a new feature burden that the core team will consider when adding any new feature.

Personally, I'll throw out a in that you can use a preprocessor to combine all your stylesheets into one for the distributed module.

good lord that sounds awful to me

😆

I see what you mean, but jinkies that doesn't sound easier to maintain

I think mostly the attitude Foundry Gaming has here is that "If a module is so different as to want different files for different systems, it should be split into multiple modules with different required systems"

hence all the "PF2e drag ruler integration" and such modules

I'll be doing custom loading of code with the TyphonJS Plugin Manager which is part of the new runtime library I'm putting out. You'll be able to define a system & module data structure that optionally will load plugins of interest when any given system or module is active.

This for instance will be used for any external module integrations for say time / calendar handling in the new quest log.

Things can start to get nasty when you pepper your code w/ conditional logic. if this module active / load this. and then elsewhere in the code you have explicit connections between any of the module specific code as you'll be peppering your code w/ conditional logic that is hard to maintain.

LMRTFY does(or did) some system specific code, I don't remember exactly how it worked it out.

The limitation is that you're expecting a different root file for each system, where in reality I think most applications have a "child" file (in esmodules cases) which is different for each system.

- my-module.js // common stuff
  (imports system specific sub-logic)
  - dnd5e.js
  - pf2e.js

I've just become keenly aware of how close we're edging to #arguing-about-programming and how projects are organized is super subjective. lol why is this so hard...

heh heh.. for sure re #arguing-about-programming... ;P The traditional OOP way of handling this is the facade pattern.

THE REAL SOLUTION
Is to have Scss run natively in the browser. Duh

Now we're cookin with gas.

how fucking hard can it be to have god damn nested css selectors natively ffs

hahaha i know that feel. Seeing it from afar you're like "woooah", but then the high-information-density designer in you starts saying "man that's a lot of wasted space"

Oooo... Looks like nesting for CSS is coming down the pipeline eventually... https://www.w3.org/TR/css-nesting-1/