Discussion: How do css-modules compare to scoped styles + extending custom elements? about css-modules

[geelen]

Hey @kenkouot, this is a perfect spot to ask the question, and it's a good one :)

I'd love if you could provide a bit of a code example about what these "noop" elements might look like. The best I can think of is a "container" element, much like the default container in React Native, which went on to inspire @necolas' React Native Web. But I don't really know my way around modern Polymer/Web Component patterns for stuff like this, so I'd love some guidance there.

As for your two points, it is true that CSS Modules requires your markup to be dynamic so it can inject the compiled classnames, but that doesn't necessarily have to be JS, and certainly doesn't need to be at runtime. CSS Modules is a very natural fit for React projects at the moment (see https://github.com/gajus/react-css-modules), but we're working on making it slot into other workflows. I've started a project to figure out a good API for using CSS Modules without JS. If you've got any thoughts I'd be happy to hear them.

As for CSS Modules vs "the standards", there certainly is a sense that CSS Modules is trying to do now what new proposals hope to do in the future, so there's going to be some points where they're incompatible. But what I think we're really hoping for is a coffeescript-style outcome, where by building out from what's possible right now we help inform the "real" specifications as they mature, as CS did with ES6.

But as far as I'm concerned, the purpose of CSS Modules is to explore whether it is truly beneficial in organising and maintaining styles. I would suggest the same of style-in-JS projects like Radium as well as the React-Native-for-the-web or "noop" Polymer components. For me, the most powerful idea in CSS Modules is composition, where you can deconstruct your visual inventory into atomic classes, and assemble them at a module level, without duplicating markup or hindering performance. I'm yet to see a concept in the alternative approaches that I've felt has been a "omg must have!" that's made me want to steer CSS Modules in that direction. But I'm still looking eagerly.

So please send through some examples and we can discuss some concrete use-cases, if you like.

[studiosciences]

I was trying to find out how polymer did their "combining styles scoped to a custom element by default" with a polyfill, but I couldn't quite figure out how that worked in the cases of containers. Does it use a descendent selector or prefix all class names?

Descendent selectors can be problematic when one element/view contains another:

<element-a>
    <a class="button">

    <element-b>
         <a class="button">
    </element-b>
<element-a>

How does Polymer address the conflict that both classes use the same name, but should be styled completely differently? In CSS Modules, element a's button class will have a different hash than element b's button, so it will not cascade.

[sergeylukin]

@studiosciences Regardless to Polymer, something like theme parameter could be accepted by button component, that way all styles will be inside that component and they will always have same hash. If button need to look different when inside <element-b>, you may be interested to check out this topic: #40 Hope that helps

[kevinSuttle]

Same question for React elements. I know they render to standard DOM elements, but I'm wondering from a CSS process perspective if there is a way to (or if it's not recommended to) base styling off of JSX names.

NotificationMessage {
  font-family: "Helvetica Neue", HelveticaNeue, Helvetica, sans-serif;
  font-weight: 400;
  font-style: normal;
  color: #5a0017;
  font-size: .75rem;
  padding-left: 0.875em;
  margin-left: 7.7em;
}