A point of clarification, the inclusion of HTML in KSS blocks is actually a pattern I actively recommend against. It's something I've chosen not to include in KSS core a number of times for exactly this reason (even when my own co-workers submit the PR: https://github.com/kneath/kss/pull/97)
If you're using KSS, I highly recommend tying it as close to your actual markup generation as possible. For me, that means rendering partials directly from rails with dummy objects. That way if the partial changes, the styleguide changes.
Wouldn't it be nice to have a repository of many Style Guides, where the users can vote on each to decide which one is better - some kind of mixture of Quora, StackExchange, HN...
I've been using it since launched and it's definitely helping me out, especially in my side projects with different programming languages.
This is just an alternative instead of using a Style Guide generator.
Very interesting, i've been playing with KSS and boy the learning curve is pretty high on implementation.
The best way i've found to generate a styleguide (so far) is during the build process, there is a grunt plugin called grunt-kss (has SASS support) that i'm using to generate and deploy the "living style guide" to an internal server when ever a build is generated for production.
Really helps with the design dept. so they know what basic components on [x] website look like and can check them against designs.
Something I've been wondering about is whether it would be possible to generate a page illustrating all the rules in an scss document(or less). Because scss documents use nesting it should be possible to construct the necessary divs (or other elements if specified in the CSS rules) to illustrate any style components. Is there anything stopping us from building a grunt task or whatever to generate the styleguide?
Ian, I'm trying to save your content to Instapaper so I can refer to the article offline on my mobile device, but your canonical URL meta tag is incorrect.
Curious if people think this sort of components driven development approach scales down to very small teams (2-5 ppl) or is this approach just for the big guys?
The upsides remain the same, but in small teams there is less pressure to go for a component architecture, so you have to come up with the discipline to go through the extra effort initially.
Yep. And if you make special test pages which render individual components and integrate those with huxley, you have tests for visual regressions basically for free.
A point of clarification, the inclusion of HTML in KSS blocks is actually a pattern I actively recommend against. It's something I've chosen not to include in KSS core a number of times for exactly this reason (even when my own co-workers submit the PR: https://github.com/kneath/kss/pull/97)
If you're using KSS, I highly recommend tying it as close to your actual markup generation as possible. For me, that means rendering partials directly from rails with dummy objects. That way if the partial changes, the styleguide changes.