kss icon indicating copy to clipboard operation
kss copied to clipboard

Documenting Breakpoints with KSS

Open dmolsen opened this issue 10 years ago • 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.

dmolsen avatar Nov 02 '13 16:11 dmolsen

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?

benschwarz avatar Nov 12 '13 06:11 benschwarz

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?

annez avatar Nov 15 '13 15:11 annez

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.

kneath avatar Dec 20 '13 07:12 kneath