5 ms·
I think with the devtools catching up, it would be possible to see those variables and trace their values to what scope they originated from, similar to how 'j
by noway421 9y ago
I think with the devtools catching up, it would be possible to see those variables and trace their values to what scope they originated from, similar to how 'jump to location in css file' works. That would require being able to compile to native css vs cssnext different targets though for dev and production, which is not supported anywhere right now AFAIK (next.js/create-react-app doesn't have it?)
Css classes are not necessarily components, but rather a set of classes can be defined as component (like BEM advices to do, for example, where block, element and modifiers compose a 'component'). Defining world-global css variables can be useful too though, for example for colours, screen resolutions and global text sizes.
- pluma 9y agoCSS custom properties do however suffer from the same problems as CSS selectors and HTML custom elements, especially the global namespace they use. CSS custom property name conflicts will be just as painful as CSS class name conflicts and HTML custom element name conflicts. But luckily CSS-in-JS (aka CSS) libraries embracing them already seem to handle them much like class names: an implementation detail you shouldn't worry about so they'll just generate the names for you instead of forcing you to keep track of them. Of course this means the actual source for these variables will live in JS but this is generally what you want anyway.