News for hackers. Stuff that matters.
Re:Interoperable CSS by skrebbel on Monday June 22, 2015 @07:54AM (#9757622)
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

Re:Interoperable CSS by Ambroos on Monday June 22, 2015 @09:23AM (#9758080)
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.
Re:Interoperable CSS by thom_nic on Monday June 22, 2015 @09:19AM (#9758059)
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.