Separate functional binding from styling

[mistermark]

In a lot of components there's a functional binding by classnames. When these classnames are removed the styling also breaks, and vice versa.

It would be a huge improvement if the styling was disconnect from the functional binding with classes. I just want to be able to remove a class name, along with it's styling, and not have to worry about some functionality breaking.

Maybe introduce something like skins, or themes, to put the whole styling aspect in a whole different parallel universe.

[robhrt7]

Hi,

Nice point Mark! We didn't had priority on styling before, but seems like it's time to work on it. We will need to review our codebase and separate style classes from special .js-hooks.

I could plan it roughly around 0.7.0 release in May. Until that, you are free to leave PR's separating most important things for you.

Also, on your own risk, you can remove SourceJS UI CSS and replace it with yours forked version of assets/css.

[robhrt7]

I reviewed the question again, and came to conclusion, that it won't be possible to separate all functional classes from styling using special .js-* hooks. Since some important markup classes like .source_section and .source_example must be easy to use, as they could be written by hand. But we will try to cover most of the UI markup using the separation pattern and maybe also provide an alternative hook classes.

I will still recommend forking at least some of source styles, and to override them completely. You can setup your own bundle, including some of SourceJS style modules in it, and overriding only specific files.

With 0.5.1 testing page for all Spec related typography will be presented, so you will be able to review all your changes in any markup combination possible.

[robhrt7]

One of the main v,0.7 features will be easy theming and styling of SourceJS UI. This will come handy with upcoming redesign.

[mistermark]

I'll be very much looking forward to the easy theming of SourceJS. This is also one of my concerns when talking about separating the functional class used by JS functionality and the styling part.

Right now I'm creating custom template views and trying to clean up the class="" definitions, but it's a trial and error process to figure out which classes are pure styling and which have JS attached to it.