Documenting Breakpoints with KSS
Opened this issue · 3 comments
I'm considering including KSS support in an interface library and quasi-styleguide project called Pattern Lab. One of the features of the project allows designers to test their "patterns" in a fluid layout and it would be great to document the changes someone had to make because of it. I was wondering if there are plans to add a formal format to the spec for documenting changes to styles across breakpoints. I know I make my breakpoint changes at the component-level so KSS would be really helpful for documenting this. For example, I might make the logo of a site bigger at a specific breakpoint:
.logo {
float: left;
max-width: 8rem;
margin: 0.4rem;
@media all and (min-width: $bp-med) {
max-width: 9rem;
}
}
If documenting media queries is outside the scope of this project that's cool. I can hack something together and shoot it back for consideration. Just wanted to make sure I didn't go too far off the tracks if you had thoughts in this direction.
I'm not sure what we would do syntactically, @dmolsen, but if you've got a proposal then its worth putting it forward.
How would you see this working?
I've already rewritten the parser to accept Media Queries and parse the child rules within them, but they've been used specifically for webkit/moz/ie media query targets.
We could try something like, in the stylesheet comments
// @media max-width $blah - Mobile breakpoint, logo is smaller
Which could be translated as a modifier class like this:
.media-max-width-48em { max-width: 9rem; }
Thoughts?
I'd love to see some proposals around how to deal with varied devices in KSS. Should we displays all the variances at once? That could be a lot of clutter. Should they be separate pages? That would require people to know to add ?mode=large-table
or some trigger. Should they be just as is, and force the actual browser to render the appropriate one? I think there's a good amount to consider, but I haven't spent any time thinking about how to approach it.
Right now for GitHub, we have a separate mobile & web styleguide. This works for us because we've chosen to have separate interfaces for mobile vs desktop rather than go the responsive route. This is easy for us since we just point the parser at a different set of stylesheet directories.
But as you can see, they're pretty different in usage — it turns out to be really nice to render the mobile version in a desktop form since that's where the designing/production ends up happening.