Interoperable CSS

[skrebbel]

I really really love this idea. My only beef, currently, is that it generates this kind of CSS (taken from [0]):

    ._23_aKvs-b8bW2Vg3fwHozO { background: red; }
    ._23_aKvs-b8bW2Vg3fwHozO { color: green; }
    ._23_aKvs-b8bW2Vg3fwHozO ._13LGdX8RMStbBE9w-t0gZ1 { color: green; }
    ._23_aKvs-b8bW2Vg3fwHozO ._13LGdX8RMStbBE9w-t0gZ1 .global-class-name { color: blue; }

This seems like a pain to debug using devtools. I'd love if the generated classnames could resemble the original classnames, e.g.

    .my-fantastic-component-24xMw

Or even just

    .my-fantastic-component-1

Given that webpack has global program knowledge anyway, it should be able to prevent name clashes if multiple css files use the same local class name, no?

I see that there's nothing in this standard, however, that would prevent readable class names.

[0] https://github.com/webpack/css-loader#local-scope

[Ambroos]

For webpack:

  You can configure the generated ident with the
  localIdentName query parameter (default [hash:base64]).
  Example for easier debugging:
  css-loader?localIdentName=[path][name]---[local]---[hash:base64:5]

From the docs. Results in classes like these:

  src-components-MyFantasticComponent---myClass---3ZAMU

Other packaging systems that use CSS modules will probably offer something similar.

[thom_nic]

I think the ugliness is driven from a goal to create globally unique class names, that wouldn't conflict with e.g. a pre-built widget that was pulled from a third-party CDN rather than passing through the same asset builder.

Which is not to say readability couldn't still be improved. Hopefully builders would have something akin to uglify options - how much do you want to minify and munge during your build process.

[pluma]

This sounds great, but the obvious problem with Webpack & co seems that they are entirely useless for isomorphic code. There's just no way to make require work like that for code that has to work on the server as well (which is one of the things React allows us to do).

[skrebbel]

This is just plain untrue. The trick is simply to make Webpack generate a special build for Node.js that doesn't access the DOM.

With oldschool webpack style-loader, all you need is the well documented & supported ExtractTextPlugin to save the .css to a separate file, and there's nothing left for node to choke on. I'm not sure whether the same works as easily for the OP's idea though, but at a first glance I don't see why not.

The only real disadvantage is that you're feeding Node webpack-generated code, and not vanilla JS files. I've yet to find the real big problem with this, though, other than a slightly slower save-build-reload cycle.

[pornel]

I use Webpack for isomorphic code. The trick is to hook up loaders in node via:

    require.extensions['.css'] = loaderFunction

[pygy_]

I'm working on a preprocessor that addresses that issue. It consumes JS objects/arrays and spews out CSS with localized class and animation names and a unmangled -> mangled dictionary.

http://j2c.py.gy

The stylesheet can be inserted in the VDOM, very easily in modern browsers (IE9+). The isomorphic scenario is more involved when IE8- support is required because you can't just have `<stlye>{styles}</style>` work out of the box on the client, you must access the DOM element and set its `.styleSheet.cssText` property.

[madeofpalk]

Yahoo's Flexible yo generator creates an isomorphic application using web pack. https://github.com/yahoo/generator-fluxible

I'm not sure of the details or how it manages to make it work server side (if it does at all), but they do use Webpack for /something/ in an isomorphic app.

[fiatjaf]

I thought you were going to talk about CSS stylesheets that could be used in a lot of contexts and different websites, instead of in only one, like http://fiatjaf.alhur.es/programming/reusable-pure-css-themes...

[chrramirez]

I believe less' `:extend` pseudo-class is a better starting point to implemented scoped styles. See: http://lesscss.org/features/#extend-feature

[3solarmasses]

This seems like a step in the right direction. I think we all intuitively know that the current global nature of CSS is plain wrong.

A system like this would make it much easier to swap in new ui elements to an app without worrying about breaking styles elsewhere.

[talmand]

I disagree, I don't intuitively know that the global nature of CSS is plain wrong. I have never seen an example that explains to me why the global nature is wrong. I would actually like to see it.

Swapping new ui elements without worrying about breaking styles elsewhere is quite easy with even basic vanilla CSS.

[dominotw]

i use nested css with react components. Seems to nicely solve the collision issue.

   .component-name{
        .label-header ...
        input{..
    }

[talmand]

This is the thing that gets me. Most people who complain about CSS not doing this or not doing that seem to not understand how CSS actually works. Avoiding collision in CSS is so freaking easy it's funny to see Javascript based solutions for it.

I really wish that browsers could parse nested CSS like we do with SASS and LESS so that we can move on from this type of stuff.

Loading CSS on demand I can get behind because it makes sense. But there's no reason to create these strange class name solutions to avoid collisions, which make it hard to use browser developer tools, when you can namespace now. Today. With vanilla CSS even.

[pearjuice]

Relevant XKCD:

https://xkcd.com/927/

[rrrx3]

Always relevant. In life, and in code.

[EGreg]

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...

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

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

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

And the corresponding JS modules:

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

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.

[EdSharkey]

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!