Interoperable CSS

Re:Interoperable CSS by EGreg on Monday June 22, 2015 @10:06AM (#9758380)

I've spent the last four years building a platform for reusable components, which "just work" across all devices, and across domains. So I've had to deal with reusability to the extreme:

* Installer and versioning across apps and plugins

* Common file system and conventions

* Common event system with automatic unregistering of events

* Common system handling user accounts/contacts/security/etc.

* Common system for handling data/access/realtime updates/offline notifications.

Let me tell you, REAL interoperability is hard. It goes without saying that everything is namespaced. But then you have to build a robust system which marries components to the Web's best practices, which are based around resources. For example you have web "pages" which you can just drop "tools" (components) on. For these tools to "just work" while being reusable, the system has to literally have a way of swapping their stylesheets and scripts in and out on demand. Then it has to provide all the events to hook into and machinery for "activating" these tools:

* Events for constructing parents before children

* Events for initializing parents after children

* Async loading on demand of all scripts/stylesheets as fast as possible

* Compiling and minifying everything into a couple filesfor production

* Support for versioning and storing some (most) of the code in local bundles for downloaded PhoneGap apps

And then you still get questions such as "how does a Streams/related tool interoperate with a Q/tabs tool on the SAME ELEMENT, so I can combine the behaviors and have a bunch of tabs that represent articles related to a particular topic?" The tabs are supposed to "just work" and the "related" tool is supposed to "just work".

So when it comes to CSS, a few years ago I just went with the straightforward approach:

You call Q.addStylesheet(...) and it "just works". It adds your stylesheet when your tool is loaded and then removes it when it's not needed. Each class and id is supposed to be prefixed by the namespace of the plugin bundle you're distributing. Each tool would have classes that are prefixed with that tool's name. Naturally, you avoid ids in the actual plugin, but each tool has an id which the app can use to style things.

You can take a look at the result here:

https://github.com/EGreg/Platform/blob/master/platform/plugi...

And the corresponding JS modules:

https://github.com/EGreg/Platform/tree/master/platform/plugi...

Here is an example of a Streams/related tool integrating with a Q/tabs tool:

https://github.com/EGreg/Platform/blob/master/platform/plugi...

So that's a proven style I would recommend.

[ Parent | on HN ]

Re:Interoperable CSS by EdSharkey on Monday June 22, 2015 @10:22AM (#9758488)

Seemed like the 'juice' in this interoperable CSS concept was that you could pull just the CSS classes you needed from the imported css, not simply include the whole import. It's (purportedly) an unopinionated approach to composing CSS that's bound to encourage reuse and continuous refactoring without any unneccessary bloat in the output. Winner winner chicken dinner!

[ Parent | on HN ]