Adam Wathan

Cambridge, Ontario, Canada Full-Stack Developer Joined almost 7 years ago

  • 2 stories
  • Posted to A Utility-First CSS Framework for Rapid UI Development, in reply to Roman Pohorecki , Nov 02, 2017

    Hey, framework author here! Like Beni mentioned in his reply, we totally agree and have tooling and workflows baked into the framework for extracting these common patterns into component classes when you feel the need to do it:

    We just don't provide classes like btn by default because in my experience with frameworks that do, you end up fighting with default styles and undoing things which I think is more trouble than it's worth. Better to give people the building blocks to create whatever button style they want, and give them tooling to easily create abstractions around those building blocks when needed.

    2 points
  • Posted to Best practices for SVG icons, Oct 25, 2017

    As a developer who works with SVG icons provided by designers a lot, I can definitely say including the canvas makes things a lot easier on our end :thumbs_up:

    18 points
  • Posted to CSS Utility Classes and "Separation of Concerns", in reply to Emre Avci , Aug 10, 2017

    Thanks Emre!

    If I see a pattern repeating enough and I can confidently say to myself, "if I change one of these, I'm going to want to change all of them," I'll usually make a new class that serves as a higher level abstraction around that group of utilities. Card is a good example for sure.

    I prefer not to do this for everything though, only when I see patterns. Otherwise you end up with this giant ball of CSS that's super coupled to your particular project, and you have to constantly make new classes even for parts of your UI that are never repeated, so your CSS size will grow linearly with your project size, which is death for maintainability in my experience.

    I wouldn't use extend because it has a lot of nasty side effects on your source order, especially when a component tries to extend a utility, because it'll move that component definition to the same place in the stylesheet where the utility is defined, which means that component's styles may get precedence over other utility styles you might want to add as modifiers.

    Instead, use mixins. This is really easy in Less because any class can already be used as a mixin, but if you are using Sass, I would extract a mixin from a utility as soon as I wanted to reuse it, and use that mixin in both the component and the original utility, like:

    EDIT: Code samples don't turn out great here, so check out this gist instead:

    0 points
  • Posted to Sketch 45, Jun 28, 2017

    Color picker updates are nice! I'd love to get an HSL picker one day though, drives me crazy that we use HSL in browsers but HSB in every design tool.

    1 point
  • Posted to Site Design: Shopify, Mar 23, 2016

    "But how is that design going to scale to larger screens?"

    "How about we just stick some big grey bars on the sides and call it done?"

    1 point
Load more comments