20 comments

  • Joshua TurnerJoshua Turner, 7 years ago

    Can I use this styleguide in my own work?

    Sure, go ahead! We are planning to open-source our styleguide soon, so feel free to use it any way you wish.

    Way to be awesome. I'll definitely be using some of your modal styling in future projects.

    13 points
  • John Jackson, 7 years ago

    Awesome work, Colm!

    4 points
  • David ThornDavid Thorn, 7 years ago (edited 7 years ago )

    "Default modal: There are two modal sizes which can be triggered with classes .modal--s and .modal--s."

    I think you meant to list a different class for the second modal.

    1 point
  • Cole BemisCole Bemis, 7 years ago

    Awesome work! I can see your markup getting pretty cluttered with all those classes though.

    1 point
  • Andrew Simchik, 7 years ago

    This is beautiful and inspiring. Thanks for sharing it!

    1 point
  • Julian LengfelderJulian Lengfelder, 7 years ago

    I dont really get your responsive classes example. Why have separate classes for each breakpoint for a simple float: left?

    1 point
    • David BachmannDavid Bachmann, 7 years ago

      That's very silly indeed. A class for every little thing. "Do One Thing and Do It Well."-philosophy gone wrong.

      0 points
    • Colm TuiteColm Tuite, 7 years ago (edited 7 years ago )

      Sometimes it makes sense to group multiple declarations on a single selector, where those declarations are all necessary to perform a specific function. Utility classes like Nicole Sullivan's media block are a perfect use case.

      Most of the time though, it's best to stick to single-purpose classes. When each class just performs a single purpose, it's easy to understand how a class affects a block of markup. The gzip algorithm also favours this approach, resulting in lighter CSS files. Single-purpose classes also render faster than render-blocking CSS files. Most importantly, you can rest assured that any changes you make will just affect a single part of your app.

      If you're concerned about bloated markup or similarity with inline styles, Adam Morse (mrmrs) shattered that theory with this mic-drop piece.

      Also, you might be interested in Harry Roberts's piece on the single responsibility principle.

      4 points
      • Pete MillerPete Miller, 7 years ago

        I see some benefits in but the negatives outweigh them IMO. don't you miss the freedom for each element to define specific 'breakpoints' that are appropriate for its unique content, where any of its styles can change?

        For example a flexbox container whose children have a max-width of 410px but you only want event numbered columns. Normally for this, I would define 100% width by default, change to 50% when viewport size is calc(410px * 2 - margin * 4), and change to 25% when viewport size is double that. Would you create more repeatable (but probably never repeated) classes for that, or introduce custom component.

        I think BEM and its variants are a much nicer solution, and even easier to maintain consistency. https://css-tricks.com/bem-101/

        Also I could be interpreting this wrong but the last article you point to ends with "It’s important not to take this too far; classes should be abstracted but ideally not presentational. Classes like .round-corners for the sake of SRP are really not all that advisable."

        But I do love your styleguide, how it looks and what it represents for your design and development process, and the example it sets for others. So, congratulations for that.

        0 points
        • Colm TuiteColm Tuite, 7 years ago

          I'm not sure what freedom you're referring to that you think I'm giving up. Any element can have any of its styles change at any breakpoint. I don't think we're giving anything up in that regard.

          I haven't used Flexbox in production yet. I haven't come across a scenario yet where I couldn't achieve the result I need with just basic html/css. That might change if layouts become more complex.

          I disagree with Harry on that point. I don't see anything wrong with presentation classes as long as specific color names are not mentioned. If you abstract all values out into reusable scales, then there are no problems at all.

          1 point
      • Julian LengfelderJulian Lengfelder, 7 years ago

        Thanks for your explanation and all the links.

        I am quite familiar with the single purpose approach and am using it for some of my components, but I was wondering why you are using breakpoint specific float classes. Not just a simple .float-left class which applies to all breakpoints in the same way. Something about this example felt off to me.

        Anyway, thanks for sharing the styleguide. It is a amazing piece of work.

        0 points
        • Colm TuiteColm Tuite, 7 years ago (edited 7 years ago )

          Because often, we don't want to apply the same float value at every breakpoint. Sometimes we want float: none on small screens and float: left on large screens.

          The same goes for all properties.

          1 point
  • Surjith S MSurjith S M, 7 years ago

    How is this style guide done? (The Technology). The Sections without page reloading etc..? Is there a boillerplate? or any plans to open-source the source-code as well?

    1 point
    • Colm TuiteColm Tuite, 7 years ago

      Marvel is a single-page app. What that means basically, is when you click a navigation link, rather than navigate away to the next page, we empty the current page, then pull the next page's content in and update the URL. It's a common technique these days which makes for a faster, slicker experience.

      We're planning to open-source the styleguide, but probably not the single-page appness as that's completely unrelated.

      Maybe check out Rails Turbolinks, React or Backbone.js.

      6 points
  • Niek Volkert, almost 7 years ago

    Nice work Colm! When are you guys planning to make the styleguide open-source?

    0 points
  • Antonio Pilolli, 7 years ago

    Great work, but I'm wondering why the different naming convention for the components.

    Each of our CSS classes adhere to a strict naming convention.

    With this example .float-left-m, .textAlign-center, .verticalAlign-middle.

    But the componets have classes as avatar--m, button--m, uiIcon--m, etc...

    Why the double hyphen?

    0 points
    • Colm TuiteColm Tuite, 7 years ago

      This is a fairly standard approach to BEM naming.

      The root class defines the base component styles. A single hyphen refers to a component child. A double hyphen refers to a component modifier.

      0 points