42 comments

  • Andrew NaterAndrew Nater, over 8 years ago

    The units section really got me. Responsive principals point to the contrary. Any reason to stick with px over (r)em, particularly with typography?

    7 points
    • Benjamin De Cock, over 8 years ago

      While relative units are theoretically superior, they're in my experience confusing and harder to work with.

      4 points
      • Luke Whitehouse, over 8 years ago

        So its not a best practice, its something you do because you find them confusing?

        3 points
        • Benjamin De Cock, over 8 years ago

          I came back to px recently after using em/rem for years. Relative units used to be very important (notably on IE where fonts wouldn't be resizable otherwise) but that's not the case anymore. They're now harder to use for no good reason, basically.

          2 points
          • Hmphry xHmphry x, over 8 years ago (edited over 8 years ago )

            They're still useful. Try zooming in an out of a page without relative units. People still use zoom on desktop.

            2 points
          • Russell Heimlich, over 8 years ago

            Relative units (em) are superior to absolute units (px) when you change the default font-size of the browser. If you use relative units for your media queries then the layout will behave the same way as zooming in on the page (control/command +). If you use pixels nothing will change.

            Example: visit https://css-tricks.com and change your default font-size to 32px for dramatic effect. Nothing happens. Now do the same at http://www.americanpressinstitute.com

            0 points
    • Mike HeitzkeMike Heitzke, over 8 years ago

      Yeah, very much a preference. Rem is the correct unit to use IMO, but I've found it hard to use with larger group efforts.

      3 points
    • Dan HoughDan Hough, over 8 years ago

      It looks like we've come to the conclusion that px is a preference for @bdc based on his opinion, so I'd like to share how and why I use rem, others may find this useful :)

      My main reason for using rem is in order to easily keep margins, padding, and other whitespace-affecting things consistent with font size and well-proportioned. I make three basic assumptions:

      1. It's good to follow the rule of thumb that a margin around an element should be the size of a single "M" character
      2. Margins should be linearly proportional - have a standard size, then a smaller one (half size) and a larger one (double size)
      3. There should be a limited number of font sizes on the site, and the body copy should be the most common one

      That means the standard margin is the width of a single "M" character at the most common font size, which can be set in the html selector in CSS, and if I want to use that standard margin I need look no further than 1rem. I can easily figure out a small margin using 0.5rem and a large one using 2rem. It's a good starting point, at least.

      Then if you decide that you want to change the base font size and thus the margins, you need only change it in one place, the html selector.

      This works really well for me. Any disagreements/opinions?

      1 point
  • Bill Columbia, over 8 years ago

    Getting a good amount of heat here - you must be doing something right :P I was curious about you ommitance of the <head> and <body> tags, in the Brevity section. It's my understanding that this will cripple older browsers, no?

    *Disclaimer - I have to make sites that work on IE8 :x

    4 points
  • Lee MartinezLee Martinez, over 8 years ago (edited over 8 years ago )

    Someone's been drinking functional programming kool-aid :-)

    1 point
  • Andrew ZimmermanAndrew Zimmerman, over 8 years ago (edited over 8 years ago )

    I tend to agree with most of these.

    Why use hex over HSV or HSL? I've grown fond of this over the past nine months.

    Being a very old hand, I find keeping the HEAD and BODY tags makes it easier to mentally place things.

    Thanks for compiling and presenting.

    1 point
    • Benjamin De Cock, over 8 years ago

      I like HSL per se too, but it is unfortunately pretty much useless in practice as most design tools use HSB instead.

      1 point
      • Andrew ZimmermanAndrew Zimmerman, over 8 years ago (edited over 8 years ago )

        Ahh. I found colorizer.org a while back, but truth be told, I still fire up PhotoShop for color combo info. This is for generating images for print documentation.

        0 points
      • Nathan CooperNathan Cooper, over 8 years ago

        I use LESS and its lighten/darken functions use HSL. It didn't realize until comparing output colors with mockups from Photoshop that HSL and HSB aren't the same. Sometimes the difference is subtle, other times it's very noticeable.

        I now use tint/shade functions instead of lighten/darken. They get closer to the intended color, but the resulting value still isn't identical to one Photoshop generates. However I like that with tint/shade produces more gradations of color before turning pure white or black.

        1 point
  • C___ F_____C___ F_____, over 8 years ago (edited over 8 years ago )

    Looks good, but what's your reasoning behind dropping the <head> and <body> tags? I've never seen that done before.

    1 point
  • Matt SistoMatt Sisto, over 8 years ago (edited over 8 years ago )

    Lost me at this selector listed under "Good": li + li {...}

    0 points
    • Benjamin De Cock, over 8 years ago

      Why?

      0 points
      • Matt SistoMatt Sisto, over 8 years ago (edited over 8 years ago )

        It's too specific, IMHO, and inefficent.

        (edited for clarity)

        0 points
        • Benjamin De Cock, over 8 years ago

          I'm… not sure to get your point. ಠ_ಠ

          0 points
          • Matt SistoMatt Sisto, over 8 years ago

            Oh, hmm. There is a section in your README.md called "Specificity". Anyway, you're using both tag and descendent selectors there.

            "The descendant selector is the most expensive selector in CSS. It is dreadfully expensive — especially if the selector is in the Tag or Universal Category."

            See: http://css-tricks.com/efficiently-rendering-css/

            0 points
            • Benjamin De Cock, over 8 years ago
              1. li + li is not a descendant selector.
              2. You should basically never care about selector performance anyway. To quote Paul Irish:

              You are not allowed to care about the performance of * unless you concatenate all your javascript, have it at the bottom, minify your css and js, gzip all your assets, and losslessly compress all your images.

              1 point
              • Matt SistoMatt Sisto, over 8 years ago (edited over 8 years ago )

                Woops, you're right on the descendent/sibling selector mixup. :coffee: Using two tag selectors like that still makes me cringe.

                I have a lot of respect for Paul Irish, but I think that quote is absolutely absurd.

                1 point
                • Benjamin De Cock, over 8 years ago

                  Nope, it's not absurd. It's, in fact, 100% right.

                  2 points
                  • Matt SistoMatt Sisto, over 8 years ago (edited over 8 years ago )

                    To me that sounds like "I'm not going to combat climate change because the rest of the world isn't."

                    Do your part.

                    Edit:

                    Let me revise the above statement... Stylesheets that are expensive to execute and serving big files are two totally different issues and you should care about both of them. It's like, "I don't care about climate change because there's a polio crisis in western Africa."

                    1 point
                • Lee MartinezLee Martinez, over 8 years ago

                  So it would be better to pollute your stylesheets with .first or .last classes because it would save you a few of microseconds or whatnot of parsing?

                  I'd argue using a adjacent sibling selector is far more maintainable than having to remember to always add superfluous selectors in your markup.

                  0 points
                  • Matt SistoMatt Sisto, over 8 years ago (edited over 8 years ago )

                    Well, I would use an nth selector or something for targeting the first or last instance of an element if it made sense absolutely.

                    Sure, the performance hit might be very slight in isolation. However I've found that when maintaining a large project over the course of many years, you can easily find yourself dealing with a "death-by-a-thousand-papercuts" kind of situation if you rely too heavily on the more convenient selectors.

                    My opinions favor my preference, but I'm just trying to be pragmatic. I don't see an extra handful of classes as "pollution" or less maintainable at all. I see it as a greater separation of concerns, in that I would rather my styles not be so coupled to a particular HTML structure as is the case with adjacent sibling selectors and the like.

                    For context: More times than I can count, I've been working on a project with my team where I style some stuff using sibling selectors or something, only to have the layout break when Backbone wraps each element (view) in a div, or Ember spits out a bunch of <script> tags.

                    These are easy enough problems to solve and many of these particular annoyances seem to be going away as the frameworks (and techniques) mature, but dealing with that has greatly influened my preferences.

                    1 point
  • Colm TuiteColm Tuite, over 8 years ago

    Curious why you advocate not modifying the global box model?

    0 points
  • Mike HeitzkeMike Heitzke, over 8 years ago

    Lots of nice stuff here in here, which generally means, lots of stuff that I agree with.

    Omitting the option head/body is still a big foreign to me, but I get it. I probably just like the structure.

    I'd be interested to hear about why you should avoid altering the default box model though. Not advocating use of the universal selector and gutting the whole thing, but I don't find much issue with changing it as needed.

    0 points
    • Benjamin De Cock, over 8 years ago

      Mostly for consistency. I'd actually be fine with a global * { box-sizing: border-box; }, but changing the behavior for just some elements is misleading imho. The example I provided in the guidelines shows a particularly bad use case for box-sizing: border-box: there's no need for a block element to get a width: 100%.

      1 point