[vdnkh]

I've used a similar, albeit more opinionated library for boilerplate UI stuff (modals, dropdowns, etc.) and the issue I have with it is styling. It works fine for the well-defined use cases but when you need to style something not part of the proptypes or as a child/parent of the given prop, the treatment becomes worse than the cure. You have to resort to rooting around the DOM with dev tools, determining the proper divs (which are usually horribly long and messy), make the style, and hope the library isn't overwriting it at runtime.

[meemoo]

Rebass does all styling inline. You can override per instance (pass in `style` prop), or "globally" via the React `context`. Example themes [1] can be seen in the demo [2] ("Config" dropdown in top right).

[1] https://github.com/jxnblk/rebass/tree/master/demo/configurat... [2] http://jxnblk.com/rebass/demo/

[lgas]

What prevents you from assigning your own class names and styling based on those?

[vdnkh]

You can't directly access the classNames of child components i.e. if the component is composed of an <h1> inside of a <div> (with <div> being the top-level component), you cannot directly set the className of the h1 if a prop doesn't exist to do so

[lgas]

But you can set the classname of the component and then refer to it as ".componentclass h1" or similar, right? Or is that what you are saying gets too unwieldy?

[Mekkanox]

Using ".component-name <insert child tag>" goes against semantic UI conventions and couples your custom styles to the tags instead of the classes in the component. It quickly becomes brittle when trying to update those styles if the tags change in an updated version, or if the rendered output changes structure, etc.

[chatmasta]

Maybe it's time to rethink your conventions...? The solution to your problem is in front of you, but you're avoiding implementing it because of strict adherence to arbitrary conventions.