Moving CSS into JS adds a barrier preventing people not already deep in JS land from styling stuff. Doing CSS the classical way means you lose the advantages of JS infrastructure (dependency management, avoiding a global namespace). For authors of generic components, both suck.
I'm hitting a bit of a wall here https://github.com/codemirror/codemirror.next/issues/40#issuecomment-450885805
It's short notice, but Recurse Center is giving out $10,000 fellowships for women to participate in the next batch. This is a huge and great opportunity! RC has been extremely significant in my development as a programmer and it's a wonderful community. I'm happy to answer any questions if you have them! https://www.recurse.com/blog/145-fellowships-for-women-working-on-open-source-programming-projects-research-and-art
I guess you could try to document the appropriate ranges for a given use case, but since use cases can't all be enumerated this breaks down. Can it be solved on the API level?
Ideally, you'd specify priorities relative to something else, but since this is supposed to be modular, you shouldn't actually need to know what other modules you'll be ordering in advance.
So if you want to allow modules to specify priority for something, just using numbers quickly gets you something I'd call the z-index problem: people input ridiculously big numbers to 'make sure' their thing gets priority.
And if something else does need to take priority over that, the next person has to use even huger numbers and you get a mess. Same with !important (in CSS). Is there a better approach?
Follow friends and discover new ones. Publish anything you want: links, pictures, text, video. This server is run by the main developers of the Mastodon project. Everyone is welcome as long as you follow our code of conduct!